QA_WITH_A_SPOON Telegram 17
Когда онбординг “снизу” встречает онбординг “сверху” - 3

Что я сделала дальше: проанализировала нагрузку и признала, что нельзя одновременно хорошо узнать проект самой и инвестировать силы в рост младших коллег.

Во-первых, скорректировала план:

1. Онбординг “снизу”
2. Онбординг “сверху”

Во-вторых, сразу смирилась, что идеально не получится и заранее простила себе ошибки.

Почти сразу проявились неприятные побочные эффекты:

- Немедленно активизировался внутренний кодоцентризм / инженерный шовинизм - идея “чем что-то ближе к коду, тем ценнее”. В соответствии с этой идеей, инженер по определению ценнее менеджера
- Возникли тревоги: а как понять, что команда хорошо работает, если не проверяешь продукт сама руками? А что, если я вообще забуду, как работать руками? И тогда все пропало

Кажется, это более-менее типовые проблемы человека, который какое-то время сидел на двух стульях (инженерском и менеджерском) и в какой-то момент понял, что два стула это уже многовато, пора выбирать.

Тут мне очень помогла мысль, что, если я вложусь в себя и буду классно делать инженерные задачи - мы как команда в целом будем работать плохо (конечно же, я этого не хочу).
Если же команда работает хорошо, релизы доставляются вовремя, проблем с продакшена прилетает мало - какая разница, сколько инженерных задач сделано тим лидом собственноручно? А вопрос контроля качества работы можно решить с помощью ревью (как тестов, так и тестового покрытия).

Конечно, важно не перепутать идею “инвестировать усилия в младших коллег” и “бебиситтинг”, когда буквально водишь людей за ручку.

Меня от бебиситтинга защищала очень простая вещь: это было было просто невозможно. Например, на прошлом проекте на одного новичка у меня уходило до полутора часов в день (это нормальное обучение, не бебиситтинг). На новом проекте нужно было вести 5-10 человек, причем часть времени там еще параллельно найм шел. Какие там полтора часа в день на человека или тем более бебиситтинг:)

К тому же, если бы я занималась только обучением новичков по 8 часов в день, через пару недель я бы устала до острой ненависти к людям. И силой этой ненависти можно было бы валить деревья!

То есть когда я говорю “инвестировала максимум в обучение”, это надо понимать как “инвестировала максимум сил из того бюджета сил на общение, что у меня был”.

Я отслеживала моменты, когда бюджет сил на общение как-то иссяк и тянет на кого-нибудь нарычать. Отменяла те митинги, которые можно отменить, переносила те, которые отменить нельзя.
Что еще очень поддержало: рабочие задачи из категории “несрочное/некритичное, но приносящее радость”. Это может быть не очень интуитивно - делать что-то не очень срочное и как будто необязательное, когда есть более актуальные задачи. Но выполнение таких задач помогало выдохнуть, снизить уровень напряжения и просто порадоваться тому, что я делала что-то понятное, что даст быстрый результат.
14



tgoop.com/QA_with_a_spoon/17
Create:
Last Update:

Когда онбординг “снизу” встречает онбординг “сверху” - 3

Что я сделала дальше: проанализировала нагрузку и признала, что нельзя одновременно хорошо узнать проект самой и инвестировать силы в рост младших коллег.

Во-первых, скорректировала план:

1. Онбординг “снизу”
2. Онбординг “сверху”

Во-вторых, сразу смирилась, что идеально не получится и заранее простила себе ошибки.

Почти сразу проявились неприятные побочные эффекты:

- Немедленно активизировался внутренний кодоцентризм / инженерный шовинизм - идея “чем что-то ближе к коду, тем ценнее”. В соответствии с этой идеей, инженер по определению ценнее менеджера
- Возникли тревоги: а как понять, что команда хорошо работает, если не проверяешь продукт сама руками? А что, если я вообще забуду, как работать руками? И тогда все пропало

Кажется, это более-менее типовые проблемы человека, который какое-то время сидел на двух стульях (инженерском и менеджерском) и в какой-то момент понял, что два стула это уже многовато, пора выбирать.

Тут мне очень помогла мысль, что, если я вложусь в себя и буду классно делать инженерные задачи - мы как команда в целом будем работать плохо (конечно же, я этого не хочу).
Если же команда работает хорошо, релизы доставляются вовремя, проблем с продакшена прилетает мало - какая разница, сколько инженерных задач сделано тим лидом собственноручно? А вопрос контроля качества работы можно решить с помощью ревью (как тестов, так и тестового покрытия).

Конечно, важно не перепутать идею “инвестировать усилия в младших коллег” и “бебиситтинг”, когда буквально водишь людей за ручку.

Меня от бебиситтинга защищала очень простая вещь: это было было просто невозможно. Например, на прошлом проекте на одного новичка у меня уходило до полутора часов в день (это нормальное обучение, не бебиситтинг). На новом проекте нужно было вести 5-10 человек, причем часть времени там еще параллельно найм шел. Какие там полтора часа в день на человека или тем более бебиситтинг:)

К тому же, если бы я занималась только обучением новичков по 8 часов в день, через пару недель я бы устала до острой ненависти к людям. И силой этой ненависти можно было бы валить деревья!

То есть когда я говорю “инвестировала максимум в обучение”, это надо понимать как “инвестировала максимум сил из того бюджета сил на общение, что у меня был”.

Я отслеживала моменты, когда бюджет сил на общение как-то иссяк и тянет на кого-нибудь нарычать. Отменяла те митинги, которые можно отменить, переносила те, которые отменить нельзя.
Что еще очень поддержало: рабочие задачи из категории “несрочное/некритичное, но приносящее радость”. Это может быть не очень интуитивно - делать что-то не очень срочное и как будто необязательное, когда есть более актуальные задачи. Но выполнение таких задач помогало выдохнуть, снизить уровень напряжения и просто порадоваться тому, что я делала что-то понятное, что даст быстрый результат.

BY Ужасно медленная QA с крайне неэффективными инструментами в поисках Грааля


Share with your friend now:
tgoop.com/QA_with_a_spoon/17

View MORE
Open in Telegram


Telegram News

Date: |

Commenting about the court's concerns about the spread of false information related to the elections, Minister Fachin noted Brazil is "facing circumstances that could put Brazil's democracy at risk." During the meeting, the information technology secretary at the TSE, Julio Valente, put forward a list of requests the court believes will disinformation. Just as the Bitcoin turmoil continues, crypto traders have taken to Telegram to voice their feelings. Crypto investors can reduce their anxiety about losses by joining the “Bear Market Screaming Therapy Group” on Telegram. The Channel name and bio must be no more than 255 characters long While the character limit is 255, try to fit into 200 characters. This way, users will be able to take in your text fast and efficiently. Reveal the essence of your channel and provide contact information. For example, you can add a bot name, link to your pricing plans, etc. A vandalised bank during the 2019 protest. File photo: May James/HKFP.
from us


Telegram Ужасно медленная QA с крайне неэффективными инструментами в поисках Грааля
FROM American