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