Хэллоуин — время поговорить о страхах. Я работаю продакт-менеджером в 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 почему-то не подходит и на рынке нет подходящего решения, напишите свои пожелания к такому софту, возможно, что-то мы включим в план разработки.
Комментарии (16)
spam312sn
31.10.2018 13:52+1А чего боитесь вы?
Что если не справлюсь со сложной задачей — меня уволят, урежут зарплату или ещё что-то. Ну и слишком часто уточнять сложную задачу тоже стрёмно — ещё чего подумают, что джуна взяли, раз не может с таким справиться, и найдут на моё место другого.
Был случай, когда в первый месяц испытательного срока я не успевал разобраться в проекте и медленно выполнял задачи — в итоге урезали зарплату, а потом уволили через два месяца, сразу после того, как вышел с больничного. В другой компании дали задачу для какого-то хитро выдуманного рассчёта каких-то бонусов, без объяснения вводных данных и с мутной формулировкой. В итоге очень часто уточнял непонятные для меня моменты, получал ещё более невнятные ответы, и меня в конце концов уволили, тоже в период испытательного срока. Вот отсюда и растут ноги синдрома самозванца — после таких мест работы я начал сомневаться в том, что я действительно что-то умею и понимаю. Хотел даже профессию сменить.
natrif Автор
01.11.2018 05:51Не секрет, что правильно поставленная задача — это 80% решения проблемы. Когда задача поставлена размыта, глупо ожидать хорошего результата. Ведь если четких требований, то результатом будут в любом случае недовольны. Вам как-то сильно не повезло, судя по всему даже не было возможности раскрыться и показать, на что способны. Печально(
ehots
31.10.2018 16:42Ожидал увидеть то, о чем могу не догадываться и на что стоит обратить внимание, но к сожалению ничего нового =(
Как то все весьма типично для любого девелопера на мой взгляд.
berez
31.10.2018 17:39-4Тестирование — верный способ выпустить продукт без баг.
Без баг и ошибк.
Интересный нынче ходить тенденц в русский язык. Окончань всем ставить лень.
Как преодолеваем страх уронить всё
1. Все разработчики команды делают код-ревью каждой фичи.
Коллективное объ*боглаживание нового кода? Интересненько, интересненько… Звучит как нечто полезное, но по факту это — растранжиривание времени разработчиков и размазывание ответственности на всех. Кто виноват? А никто не виноват, всем колхозом работали.
Это был удар по самолюбию. Так сложилось, что все программисты моей команды вышли из тестировщиков (ручных и авто). Вернуться к ручному тестированию для них — сделать шаг назад.
Какая-то очень специфичная ситуация.
В очередной раз убедились, что тестеры — это важное звено команды. Именно они отвечают за качество выходящей в релиз фичи.
Напомнило протокол комсомольского собрания: в очередной раз слушали — постановили, выше флаг, крепить, нести с честью.
Простите, не сдержался.
Я переживала, что это демотивирует моих разработчиков.
У вас там и так дурдом: спринты, боязнь стать тестером… Какая тут мотивация.
Еще и начальница купоросит на нервяках.
Эксепшн-мен отвечал на все вопросы, а тимлид рассказывал, что и как должно работать
Exception man — это человек — бросака исключений? Представляю, как он на вопросы отвечал… :)
У нас было два стендапа. Сначала ходили в биллинг, потом обсуждали итоги внутри нашей команды.
Умом-то я понимаю, что речь о скрамах, но перестать хихикать не могу… Два стендапа, бгыгыгы… Гарик Собака Харламов присутствовал или так, своими силами? :)
Кстати, шутки шутками, но когда я летел авиакомпанией «Победа» и они по трансляции пустили приветственную речь в исполнении Гарика — я весьма прифигел. Когда комик-стендапёр рассказывает вам о том, как пользоваться кислородной маской в случае разгерметизации кабины, впечатления очень двойственные…
Старую версию мы писали на С++11
Хи-хи.
У нас в проекте одиннадцатый стандарт буквально недавно только разрешили использовать. :)
Старая версия у них…
«а вдруг тут меня ждёт больше проблем, я не разберусь и меня выгонят».
Если сотрудники боятся увольнения — контора в целом гниловата. Новые технологии тут ни при чем.
Но будем честными, в запасе у нас есть еще пара непобежденных фобий. Боязнь дедлайнов, например, или страх не ужиться с новичками.
Дедлайны — исключительно из-за хренового планирования и менеджмента.
А с новичками — тут уж как повезет. Бойся, не бойся, — если человек в душе идиот, он полюбасу всем плешь проест.Doktor3lo
01.11.2018 04:24+2Про русский язык — согласен, остальное — весьма спорно
У нас в проекте одиннадцатый стандарт буквально недавно только разрешили использовать. :)
И вообще, завидуйте молча ;)
TimsTims
31.10.2018 19:49Например, мы добавляем в панель управления поддержку новой модели коммутатора, маршрутизатора или PDU
Но ведь раз оборудование новое и вы его пока не умели поддерживать — почему бы его не подключить к тестовому контуру, чтобы на нём всё обкатать, а как закончите — переносить спокойно (спокойнее) в прод?natrif Автор
01.11.2018 05:39Мы так и делаем, если есть оборудование, которое можно подключить к тестовому контуру.
Но бывают и такие ситуации, когда приходит новый клиент, мы не поддерживаем какую-то определенную модель, которую он использует, а у него все оборудование уже в проде. А добавить поддержку нужно, иначе в полной мере панелью нельзя будет пользоваться. Или текущий клиент хочет добавить новую фичу, а у него тоже все в продакшене. Вот тогда обкатываем на боевом оборудовании.a_e_tsvetkov
01.11.2018 11:59Вот это воля к победе. Чтобы тестировать в продакшене нужно иметь адамантиевые тестикулы.
panteleymonov
01.11.2018 01:41+1А чего боитесь вы?
Неадекваты страшнее всего. Особенно когда их много, они сбиваются в стадо, то неадекватом становишься сам. А еще это заразно.TimsTims
01.11.2018 10:07Вы прям зомби-апокалипсис описали. Заразные. Страшные. Их много. Стадо. Сам таким становишься…
panteleymonov
01.11.2018 11:57А оно так и есть зомби-апокалипсис начался, особенно после прочтения ряда статей про собеседования. Как оно должно быть и как есть на самом деле и что от этого никуда не деться, все друг от друга заражаются безысходностью, и только не зараженные пытаются писать статьи и единицы организовывают честные фирмы как оборону в суровых условиях беззакония — самый настоящий апокалипсис. :)
757NF
01.11.2018 05:40+1«Баг» — это родительный падеж множественного числа слова «бага». Не у всех ведь это «баг».
barbanel
natrif Автор
Ну тут несколько вариантов возможно, если все-таки оказались в такой ситуации… либо научиться с этим жить, либо сменить место работы, либо сменить начальника.