Хэллоуин — время поговорить о страхах. Я работаю продакт-менеджером в IT-компании, поэтому речь пойдёт про кошмары разработчиков. Но не обычные, а те, что появляются во времена перемен.
Когда компания развивается — меняет подход к разработке, создаёт новые продукты и расширяет возможности текущих, десятками принимает сотрудников, тем, кто работал по-старому, бывает тяжело перестроиться. Мы радуемся изменениям, но иногда, чего скрывать, боимся их. Я работаю продакт-менеджером уже год и за это время столкнулась с пятью крупными страхами своей команды. Сегодня расскажу об этих страхах и о том, как нам удалось их преодолеть.
Тестирование — верный способ выпустить продукт без багов. Но иногда для проверки кода нет оборудования.
Мы делаем DCImanager, панель для управления серверами и дата-центрами, и часто в виртуальной среде создать условия, в которых будет работать код, невозможно. Например, мы добавляем в панель управления поддержку новой модели коммутатора, маршрутизатора или PDU, а на тестовом стенде такого оборудования нет.
В каких-то случаях тестированием допустимо пренебречь, но не в нашем. Ошибка стоит дорого. Не инициализируешь всего одну переменную, и в половине случаев перестанет устанавливаться операционная система. Ошибёшься в паре строк кода — и «ляжет» дата-центр. Как вы понимаете, отвечать за «упавший» ЦОД не хочет никто, поэтому в моей команде этот страх на первом месте (хоть он и не связан с преобразованиями в компании).
Как преодолеваем страх уронить всё
У нас разработчики пишут юнит-тесты, а ручным тестированием занимаются отдельные люди. Но однажды случился форс-мажор, и команда осталась без ручного тестера. Не выпускать фичи мы не могли, поэтому разработчикам пришлось проверять друг друга.
Это был удар по самолюбию. Так сложилось, что все программисты моей команды вышли из тестировщиков (ручных и авто). Вернуться к ручному тестированию для них — сделать шаг назад. Ребята боялись, что если будут справляться сами, тестеров им не вернут. Но страх оказался беспочвенным, через пару спринтов тестировщик занял своё место в команде, а из опыта мы вынесли много полезного.
Какой профит принесло перекрестное тестирование
DCImanager вышел в 2013 году. За шесть лет технологии изменились, пришло время делать новую версию, мы решили делать её с нуля. Нарисовали прототипы, определили MVP, расставили приоритеты. Разработку старой версии заморозили, а к новой приступать не могли — к релизу уже готовились два новых продукта, все силы были брошены на них, надо было немного подождать. На время затишья моим разработчикам предстояло стать проектной командой BILLmanager, другого нашего продукта для автоматизации хостинга.
И тут обнаружился ещё один страх. Разработчики инженерного во всех смыслах этого слова продукта боялись браться за биллинг. Им казалось, что это не их область, что разбираться в куче счетов неинтересно. Я переживала, что это демотивирует моих разработчиков. В отличие от нас, команда биллинга радовалась разгрузке.
На несколько спринтов мы ушли в работу над BILLmanager, и этот опыт тоже оказался полезным.
Коротко о том, как происходило внедрение
Какую пользу разработчики вынесли из внедрения в другую команду
Компании нужно как можно больше сильных программистов, поэтому когда разработчик прокачивает hard skills и переходит на уровень Middle, обучение новичков становится его обязанностью. Но в целом менторство обычно лежит на тимлиде. Так было и в нашей команде, пока опыт ведущего разработчика срочно не понадобился в другом продукте. Оставшимся без тимлида программистам предстояло взять на себя обучение и новичков, и друг друга.
Быть ментором страшно. Надо отвлекаться от своих задач, настраиваться на другого человека, объяснять то, что иногда сам понимаешь на уровне интуиции и объяснять так, чтобы тебя поняли. Если падаван не понял — это и твоя проблема. Если он сделал ошибку, и ты не заметил — отвечаешь ты.
Я не буду давать советы, как стать хорошим ментором, это тема для отдельной статьи. Но мы справились, а из этого довольно стрессового опыта вынесли следующее:
Когда затишье закончилось, пришло время приступать к новой версии продукта DCImanager. Казалось бы, вот он долгожданный момент. Сейчас полной амбициозных людей командой начнем всё с нуля — без оглядки на старые баги и исторически сложившиеся странные зависимости в коде. Но и тут нашлось место страху.
За несколько лет технологии ушли далеко вперёд. Старую версию мы писали на С++11 и с использованием make, для новой выбрали C++17, CMake, Conan и Docker. Команде надо все это изучить и научиться применять. Очередной выход из зоны комфорта, челлендж и мысль «а вдруг я не смогу и буду хуже остальных», «а вдруг тут меня ждёт больше проблем, я не разберусь и меня выгонят». Новые технологии мы ещё осваиваем и борьба с этим страхом еще в процессе.
Как быстрее осваивать новые технологии
Я воспринимаю эксперименты как возможность узнать новое, стать лучше и стараюсь, чтобы моя команда смотрела на свои страхи также. Я думаю, что настрой ребят во многом зависит от меня. Когда веришь в продукт и в разработчиков, прислушиваешься к ним на стендапах и разбираешь проблемы на ретроспективах, поддерживаешь в передрягах и объясняешь необходимость перемен, тогда им проще преодолевать страхи.
Но будем честными, в запасе у нас есть еще пара непобежденных фобий. Боязнь дедлайнов, например, или страх не ужиться с новичками. Пока кажется, что с ними ничего нельзя поделать — просто смириться. Но может быть со временем наш взгляд изменится.
А чего боитесь вы?
P. S. Если хотите первым увидеть демо-версию DCImanager — отправляйте контакты на почту bizdev@ispsystem.com с темой «Хочу посмотреть на новый DCImanager». Когда будет готово, мы вам напишем. Или если вам нужен продукт для управления серверами, но текущий DCImanager почему-то не подходит и на рынке нет подходящего решения, напишите свои пожелания к такому софту, возможно, что-то мы включим в план разработки.
Когда компания развивается — меняет подход к разработке, создаёт новые продукты и расширяет возможности текущих, десятками принимает сотрудников, тем, кто работал по-старому, бывает тяжело перестроиться. Мы радуемся изменениям, но иногда, чего скрывать, боимся их. Я работаю продакт-менеджером уже год и за это время столкнулась с пятью крупными страхами своей команды. Сегодня расскажу об этих страхах и о том, как нам удалось их преодолеть.
1. Страх уронить всё
Тестирование — верный способ выпустить продукт без багов. Но иногда для проверки кода нет оборудования.
Мы делаем DCImanager, панель для управления серверами и дата-центрами, и часто в виртуальной среде создать условия, в которых будет работать код, невозможно. Например, мы добавляем в панель управления поддержку новой модели коммутатора, маршрутизатора или PDU, а на тестовом стенде такого оборудования нет.
В каких-то случаях тестированием допустимо пренебречь, но не в нашем. Ошибка стоит дорого. Не инициализируешь всего одну переменную, и в половине случаев перестанет устанавливаться операционная система. Ошибёшься в паре строк кода — и «ляжет» дата-центр. Как вы понимаете, отвечать за «упавший» ЦОД не хочет никто, поэтому в моей команде этот страх на первом месте (хоть он и не связан с преобразованиями в компании).
Как преодолеваем страх уронить всё
- Все разработчики команды делают код-ревью каждой фичи.
- Ведём списки того, без чего задача не может выйти в релиз.
- После релиза разработок анализируем, что не учли. Подробно описываем, что было сделано и какое поведение наблюдали, чтобы в любой момент можно было вернуться к задаче и всё восстановить в памяти.
- Постоянно обновляем базу знаний. Выделяем время на документацию для разработчиков, делимся знаниями между собой на тех. учебах и стендапах.
- И последнее, главное. Заказные разработки для клиентов тестируем вместе с ними на предоставленном оборудовании.
Однажды мы добавляли для уже работающих коммутаторов управление агрегациями портов. При совершении ошибки работа сетевого оборудования в дата-центре была бы полностью остановлена. Клиент приезжал в свой дата-центр в три часа ночи и контролировал ситуацию, чтобы в случае чего быстро откатиться на старую версию и возобновить работу оборудования. Мы могли потерять удаленный доступ, и работа ЦОД была бы парализована.
2. Страх остаться без тестера
У нас разработчики пишут юнит-тесты, а ручным тестированием занимаются отдельные люди. Но однажды случился форс-мажор, и команда осталась без ручного тестера. Не выпускать фичи мы не могли, поэтому разработчикам пришлось проверять друг друга.
Это был удар по самолюбию. Так сложилось, что все программисты моей команды вышли из тестировщиков (ручных и авто). Вернуться к ручному тестированию для них — сделать шаг назад. Ребята боялись, что если будут справляться сами, тестеров им не вернут. Но страх оказался беспочвенным, через пару спринтов тестировщик занял своё место в команде, а из опыта мы вынесли много полезного.
Какой профит принесло перекрестное тестирование
- Вспомнили «молодость» и вновь посмотрели со стороны тестировщика на разработку. В некоторых случаях стали добавлять дополнительные экшены, чтобы облегчить жизнь тестеру. Например, генерацию статистики для проверки.
- Подтвердили давно известный факт, что разработчик не может тестировать свой код, так как закрывает глаза на некоторые вещи. Поэтому ребята тестировали код друг друга.
- В очередной раз убедились, что тестеры — это важное звено команды. Именно они отвечают за качество выходящей в релиз фичи.
3. Страх попасть в другую команду
DCImanager вышел в 2013 году. За шесть лет технологии изменились, пришло время делать новую версию, мы решили делать её с нуля. Нарисовали прототипы, определили MVP, расставили приоритеты. Разработку старой версии заморозили, а к новой приступать не могли — к релизу уже готовились два новых продукта, все силы были брошены на них, надо было немного подождать. На время затишья моим разработчикам предстояло стать проектной командой BILLmanager, другого нашего продукта для автоматизации хостинга.
И тут обнаружился ещё один страх. Разработчики инженерного во всех смыслах этого слова продукта боялись браться за биллинг. Им казалось, что это не их область, что разбираться в куче счетов неинтересно. Я переживала, что это демотивирует моих разработчиков. В отличие от нас, команда биллинга радовалась разгрузке.
На несколько спринтов мы ушли в работу над BILLmanager, и этот опыт тоже оказался полезным.
Коротко о том, как происходило внедрение
- Чтобы минимизировать стресс перехода в другой продукт, команда оставалась командой и не зависела от ребят из BILLmanager.
- Задачи выбирали по принципу «нужно сделать ещё вчера, но не хватает рук». Задачи обсуждали продуктологи, потом при планировании очередного спринта я транслировала их в команду.
- Разработчики BILLmanager были нашими менторами. Эксепшн-мен отвечал на все вопросы, а тимлид рассказывал, что и как должно работать
- У нас было два стендапа. Сначала ходили в биллинг, потом обсуждали итоги внутри нашей команды.
Какую пользу разработчики вынесли из внедрения в другую команду
- Другой продукт — чужой код, в котором нужно разобраться; плюс другая логика работы, которую нужно понять. Благодаря менторству тимлида и терпению эксепшн-мена мы успешно освоились в биллинге, прокачали новые скиллы и довольно быстро пилили доработки.
- Конечно же, мы подсмотрели как некоторые вещи устроены внутри другой команды. Может показаться, что все у всех одинаково, но как бы не так. Различия кроются в мелочах. Лучшее и удобное взяли себе за правило (например, подсмотрели и, немного переделав под себя, стали использовать скрам-доску, переняли некоторые моменты code style и пр.).
4. Страх стать ментором/остаться без тимлида
Компании нужно как можно больше сильных программистов, поэтому когда разработчик прокачивает hard skills и переходит на уровень Middle, обучение новичков становится его обязанностью. Но в целом менторство обычно лежит на тимлиде. Так было и в нашей команде, пока опыт ведущего разработчика срочно не понадобился в другом продукте. Оставшимся без тимлида программистам предстояло взять на себя обучение и новичков, и друг друга.
Быть ментором страшно. Надо отвлекаться от своих задач, настраиваться на другого человека, объяснять то, что иногда сам понимаешь на уровне интуиции и объяснять так, чтобы тебя поняли. Если падаван не понял — это и твоя проблема. Если он сделал ошибку, и ты не заметил — отвечаешь ты.
Я не буду давать советы, как стать хорошим ментором, это тема для отдельной статьи. Но мы справились, а из этого довольно стрессового опыта вынесли следующее:
- Объясняя, надо давать больше контекста. В голове всё красиво, а когда рассказываешь, получается вырвано и непонятно.
- На ревью надо не просто смотреть код, а разбираться, что человек пытался этим кодом решить. Тогда проще понять его логику и найти ошибки.
- Делиться знаниями полезно: учишься формулировать мысли; раскладываешь всё по полочкам в своей голове; пока объясняешь, находишь лучшее решение задачи.
5. Страх не освоить новые технологии
Когда затишье закончилось, пришло время приступать к новой версии продукта DCImanager. Казалось бы, вот он долгожданный момент. Сейчас полной амбициозных людей командой начнем всё с нуля — без оглядки на старые баги и исторически сложившиеся странные зависимости в коде. Но и тут нашлось место страху.
За несколько лет технологии ушли далеко вперёд. Старую версию мы писали на С++11 и с использованием make, для новой выбрали C++17, CMake, Conan и Docker. Команде надо все это изучить и научиться применять. Очередной выход из зоны комфорта, челлендж и мысль «а вдруг я не смогу и буду хуже остальных», «а вдруг тут меня ждёт больше проблем, я не разберусь и меня выгонят». Новые технологии мы ещё осваиваем и борьба с этим страхом еще в процессе.
Как быстрее осваивать новые технологии
- Не стесняться спрашивать у старших и опытных коллег, не бояться показаться глупым.
- Документировать, чтобы ускорить процесс погружения новеньких и не рассказать по 10 тысяч раз одно и то же. Вести базу знаний.
- «Окей-гугл» всегда в помощь. Если не работает, то см. п.1.
Не страхи, а вызовы
Я воспринимаю эксперименты как возможность узнать новое, стать лучше и стараюсь, чтобы моя команда смотрела на свои страхи также. Я думаю, что настрой ребят во многом зависит от меня. Когда веришь в продукт и в разработчиков, прислушиваешься к ним на стендапах и разбираешь проблемы на ретроспективах, поддерживаешь в передрягах и объясняешь необходимость перемен, тогда им проще преодолевать страхи.
Но будем честными, в запасе у нас есть еще пара непобежденных фобий. Боязнь дедлайнов, например, или страх не ужиться с новичками. Пока кажется, что с ними ничего нельзя поделать — просто смириться. Но может быть со временем наш взгляд изменится.
А чего боитесь вы?
P. S. Если хотите первым увидеть демо-версию DCImanager — отправляйте контакты на почту bizdev@ispsystem.com с темой «Хочу посмотреть на новый DCImanager». Когда будет готово, мы вам напишем. Или если вам нужен продукт для управления серверами, но текущий DCImanager почему-то не подходит и на рынке нет подходящего решения, напишите свои пожелания к такому софту, возможно, что-то мы включим в план разработки.
