Как стать автором
Обновить
Dodo Engineering
О том, как разработчики строят IT в Dodo

5 ошибок начинающего лида

Время на прочтение 6 мин
Количество просмотров 33K

У каждого тимлида есть своё кладбище сотрудников управленческих ошибок. Каждый день публикуются новые статьи «5 ошибок начинающего разработчика», «7 примеров того, как не надо управлять процессами», «100 и 1 способ укладываться в сроки». И это круто!


Чужие грабли экономят ваше время, делают вас смелыми, похлопывают по плечу и наглядно дают понять, что не один вы такой «я сделяль», и все это проходили.



Ошибка по Ожегову – это неправильность в мыслях или действиях, а, возможно, и одновременно. А как же обойтись без них новичку с новым кругом обязанностей? Пожалуй, никак, но можно постараться смягчить удары. На своем примере я расскажу о тех ошибках, которых мне не удалось избежать в процессе становления меня как лида. Надеюсь каждая история тебя либо улыбнет, ведь ты вспомнишь себя в детстве начале своего пути, или же заставит задуматься над тем, а как же не наступить на подобные грабли самому.


Предыстория


Последние 6 лет я посвятила тестированию, сменив несколько компаний, команд с целью получить актуальные и уверенные знания о том, как создавать качественный продукт, и какую роль в этом процессе могут играть тестировщики-инженеры. Иногда причиной ухода становилось отсутствие возможности обучаться у сильных коллег тестировщиков (а это необходимо в самом начале пути), ведь их просто не было. Опробовала свои силы как в ручном, так и в автоматизированном тестировании. И именно после того, как я прокачалась в автоматизации, мне представилась возможность попробовать себя в роли лида тестировщиков с опытным Agile-коучем.


Для меня словно мир перевернулся в тот момент. Привычка предлагать решения и самостоятельно их реализовывать окрепла и не хотела меня покидать. Оказалось, что стиль работы инженера-автоматизатора никак не вяжется с новой ролью руководителя небольшой группы людей. Перейдем к деталям.


Ошибки


№1 Менеджер «Здесь и сейчас»


У меня лучше получалось решать точечные вопросы «здесь и сейчас», но это не всегда приближает команду к заявленной цели.


Рассмотрим пример. В самом начале становления нового формата QA в Dodo, познакомившись с тем как устроено тестирование и желанием всех начать автоматизацию еще вчера, я решила, что ее нужно начать в ближайшее время. (О том как мы меняли процессы можно узнать из доклада «Алиса в стране QA») Нам всем очень хотелось избавить ребят от ежедневной рутины ручного регрессионного тестирования на 9 странах.


Следуя принципу «решаю проблемы здесь и сейчас», мы организовали встречу с тестировщиками, составили карту действий, расставили приоритеты, выделили каждому тестировщику время на автоматизацию и приступили к реализации задач с карты. Первым делом определились с инструментом и представили свой план ускорения регресса на общем собрании ИТ. Тестировщики радовались появившимся тестам и верили в скорое избавление от ручной рутины.


Однако, оказалось, что мы покрыли тестами то, что съедало много времени тестировщика, но при этом практически никогда не менялось разработчиками и слабо влияло на процессы бизнеса.


Что делать? Советы Кэпа


Глубже разбираться в проблеме, искать причины, а не следствия. Велика вероятность, что ваши ожидания того, что именно тестировщики – это основной кладезь знаний о системе с точки зрения пользователя, сильно завышены. Стоит позвать на первые собрания разных представителей ИТ компании, попросить помощи с фасилитацией встречи у scrum-мастера, предварительно обговорив с ним, какой результат ты хотел бы получить.

№2 Менеджер «Опытный инженер»


Второй мой фейл – это «шапка» опытного инженера. Все самые сложные задачи попадали ко мне.


Формирование PageObject, реализация базового набора методов для работы с нашей системой, скрипты запуска в CI/CD – всё это я по привычке решила взвалить на себя. Не стала я делегировать и коммуникацию с продуктовыми командами, инженерами инфраструктуры, и собеседования, и тексты вакансий. По словам наставника, наша QA команда была «зеленой» (новички) во всех смыслах. Разумеется, я решила сначала обучить ребят тому, что знаю сама, наблюдая за их работой, чтобы со временем делиться своими задачами.


Проблема в том, что с тем количеством встреч (общие встречи, командные встречи, внутреннее обучение, 1&1, собеседования, тестовые дни), что свалились на мои плечи, я перестала укладываться в рабочее время со своими задачами. Восьми часов в день не хватало, и я начала это компенсировать свободным временем, которое тратила на кодинг, тексты, подготовку к собеседованиям с кандидатами. Остатки драгоценных часиков я проводила с ребятами в паре с целью обучения и постепенного развития проекта с автотестами. Мое переключение контекста каждый час-два замедляло нас по всем фронтам: автоматизация, коммуникации QA c командами и прочее. Низкие темпы становления крутых QA-инженеров и автоматизации процессов приводили к тому, что и на выходных я работала, чтобы сделать пятилетку за пару месяцев.


Что делать? Советы Кэпа


Не бойтесь делегировать задачи. У всех есть право на ошибку и не стоит его отбирать, как бы тебя ни гипнотизировали лиды других команд или наставник, не ведись. Твои ребята должны сами захотеть доверять тебе и следовать за тобой, всегда экспериментируй. Соберитесь вместе, определите то, какие из процессов можно улучшить, кто из ребят готов их продвигать, а возможно некоторые из них можно передать за пределы вашей команды. Опытный фасилитатор поможет сделать так, чтобы выбранные совместно решения не остались только на бумаге. Самостоятельная эффективная команда – это то, к чему должен стремиться каждый руководитель.

№3 Менеджер «Обратная сторона микроменеджмента»


Еще одной из ошибок часто является микроменеджмент. Мне пришлось столкнуться с ее обратной стороной – неявный жесткий контроль.


Стараясь избегать слежки за каждым шагом ребят и ограничения фронта работ, я начала «навязывать» ребятам их «безграничные» возможности: планы развития, исследовательские задачи, выступления, курсы, организация митапов, походы в гости к другим компаниям и прочие активности. Намерения благие – обучение, прокачка и оттачивание навыков, расширение кругозора, новые знакомства в профессиональной сфере. Это же все то, чего мне так не хватало, когда я начинала работу тестировщиком. Проблема в том, что команда хочет право выбора: выступать или нет, смотреть или нет, а я же загнала их в жесткие рамки.


– Ребята, мы делаем митап. Нам нужны следующие роли, подарки, будут вот такие докладчики. Без вашей помощи мы не сможем сделать запоминающееся мероприятие.
– Ребята, в декабре будет Heisenbug. Я уже заказала онлайн-трансляцию для нас, забронировала переговорку, а в субботу транслирую с домашнего компьютера. Все за?
– Ребята, мы на этой неделе идем в гости в компанию «Одноклассники» знакомиться с тем, как у них построена автоматизация.


Данные возможности воспринимались как рамки-ограничения, которые все так не любят. Моя инициатива выглядела безальтернативной, а главное она была не настолько эффективной, как ожидалось.


Что делать? Советы Кэпа


Излишняя забота о ребенке приводит к тому, что он вырастает инфантильным или начинает делать все наоборот назло родителям. Похоже, так можно сказать и о заботе руководителя о своей команде. Мотивируй, а не заставляй, собери встречку на тему «Как нам расширять свой кругозор в IT?» и внимательно слушай коллег, не начинай с порога называть все способы, что тебе известны. А главное не бегай за своими коллегами с предложением выступить на конференции и попасть на интереснейший мастер-класс. Объяви о возможности – этого будет достаточно.

№4 Менеджер «Везде так делали»


Возможно, какие-то из решений, сработавших у тебя раньше в другой команде/компании, не найдут поддержки в новых условиях и реализована будет идея коллеги, далекого от области тестирования ПО, но крутого в разработке. Аргументация, что твое решение поддержали и продолжают активно развивать уже на базе сообщества, вряд ли убедит кого-то сделать также, но на местном стеке технологий.


Что делать? Советы Кэпа


Главное не начать себя угнетать тем, что твои профессиональные навыки и знания ставятся под сомнение и никак не учитываются при принятии решений. Либо ищи достойные аргументы, которые найдут поддержку у команды, либо согласись с командой.

№5 Менеджер «Истеричка»


Важную роль в процессе становления тебя как профессионала/мастера своего дела играет наставник. Но есть один нюанс, твое восприятие помощи наставника. Если между вами недоверие друг другу, то эффект от совместной деятельности вряд ли порадует и команду, и всех вокруг.


Советы, рекомендации, подчеркивание сильных и слабых сторон принятых решений – это основная ценность работы с учителем для меня. Однако, часто коучи используют другой формат обучения: они без предупреждения организуют тебе сложную ситуацию, например, конфликт в команде на почве выбора технологий, умывают руки и наблюдают за твоими действиями. Для меня все закончилось тем, что проект с автотестами стал ответственностью команд разработки из-за высокого порога вхождения, на котором настаивал коуч. Данный расклад всех устраивает, и продолжать битву за простоту было бы бессмысленно.


Что делать? Советы Кэпа


Важно будет усвоить такой момент: крики, бросание бумаг, удаление кода друг друга, презентация тобой и наставником разных видений стратегии и тактических шагов, слезы – не помогут. Так вы лишь затянете процесс приближения к цели, а возможно будете постоянно откатываться назад, ведь с вами будут бояться иметь дело, сидеть на одном этаже, сомневаться в здравости ваших идей. Попробуй не принимать быстрых решений, разберись, зачем коучу нужен был этот конфликт, в чем ты слаб и как разрулить ситуацию не взрываясь по пустякам.

Подведем итоги


Выше я описала 5 моментов слабого менеджмента от опытного инженера-автоматизатора. С трудностями, описанными выше, можете столкнуться и вы, и лишь от вашей подготовленности, характера зависит то, насколько успешной будет твоя битва и насколько сплоченной и сильной станет твоя команда. Моя же история завершилась достижением поставленной цели.


Тестировщики сейчас являются частью Dev-команд, ребята весьма самостоятельны и способны сами принимать решения по технической реализации, сотрудничеству с другими командами. Они самостоятельно пишут скрипты, отбирают новых ребят-тестировщиков, проводят митапы и многое-многое другое. Да, мы шли к этому больше года, но никто не обещал, что управление людьми – это легко.

Теги:
Хабы:
+39
Комментарии 400
Комментарии Комментарии 400

Публикации

Информация

Сайт
dodo.dev
Дата регистрации
Дата основания
Численность
201–500 человек
Местоположение
Россия