Хабрахабр

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

Каждый день публикуются новые статьи «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-команд, ребята весьма самостоятельны и способны сами принимать решения по технической реализации, сотрудничеству с другими командами. Да, мы шли к этому больше года, но никто не обещал, что управление людьми – это легко.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть