Хабрахабр

5 страхов разработчиков, которые мы преодолели

Хэллоуин — время поговорить о страхах. Я работаю продакт-менеджером в IT-компании, поэтому речь пойдёт про кошмары разработчиков. Но не обычные, а те, что появляются во времена перемен.

Мы радуемся изменениям, но иногда, чего скрывать, боимся их. Когда компания развивается — меняет подход к разработке, создаёт новые продукты и расширяет возможности текущих, десятками принимает сотрудников, тем, кто работал по-старому, бывает тяжело перестроиться. Сегодня расскажу об этих страхах и о том, как нам удалось их преодолеть. Я работаю продакт-менеджером уже год и за это время столкнулась с пятью крупными страхами своей команды.

1. Страх уронить всё

Тестирование — верный способ выпустить продукт без баг. Но иногда для проверки кода нет оборудования.

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

Ошибка стоит дорого. В каких-то случаях тестированием допустимо пренебречь, но не в нашем. Ошибёшься в паре строк кода — и «ляжет» дата-центр. Не инициализируешь всего одну переменную, и в половине случаев перестанет устанавливаться операционная система. Как вы понимаете, отвечать за «упавший» ЦОД не хочет никто, поэтому в моей команде этот страх на первом месте (хоть он и не связан с преобразованиями в компании).

Как преодолеваем страх уронить всё

  1. Все разработчики команды делают код-ревью каждой фичи.
  2. Ведём списки того, без чего задача не может выйти в релиз.
  3. После релиза разработок анализируем, что не учли. Подробно описываем, что было сделано и какое поведение наблюдали, чтобы в любой момент можно было вернуться к задаче и всё восстановить в памяти.
  4. Постоянно обновляем базу знаний. Выделяем время на документацию для разработчиков, делимся знаниями между собой на тех. учебах и стендапах.
  5. И последнее, главное. Заказные разработки для клиентов тестируем вместе с ними на предоставленном оборудовании.

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

2. Страх остаться без тестера

У нас разработчики пишут юнит-тесты, а ручным тестированием занимаются отдельные люди. Но однажды случился форс-мажор, и команда осталась без ручного тестера. Не выпускать фичи мы не могли, поэтому разработчикам пришлось проверять друг друга.

Так сложилось, что все программисты моей команды вышли из тестировщиков (ручных и авто). Это был удар по самолюбию. Ребята боялись, что если будут справляться сами, тестеров им не вернут. Вернуться к ручному тестированию для них — сделать шаг назад. Но страх оказался беспочвенным, через пару спринтов тестировщик занял своё место в команде, а из опыта мы вынесли много полезного.

Какой профит принесло перекрестное тестирование

  1. Вспомнили «молодость» и вновь посмотрели со стороны тестировщика на разработку. В некоторых случаях стали добавлять дополнительные экшены, чтобы облегчить жизнь тестеру. Например, генерацию статистики для проверки.
  2. Подтвердили давно известный факт, что разработчик не может тестировать свой код, так как закрывает глаза на некоторые вещи. Поэтому ребята тестировали код друг друга.
  3. В очередной раз убедились, что тестеры — это важное звено команды. Именно они отвечают за качество выходящей в релиз фичи.

3. Страх попасть в другую команду

DCImanager вышел в 2013 году. За шесть лет технологии изменились, пришло время делать новую версию, мы решили делать её с нуля. Нарисовали прототипы, определили MVP, расставили приоритеты. Разработку старой версии заморозили, а к новой приступать не могли — к релизу уже готовились два новых продукта, все силы были брошены на них, надо было немного подождать. На время затишья моим разработчикам предстояло стать проектной командой BILLmanager, другого нашего продукта для автоматизации хостинга.

Разработчики инженерного во всех смыслах этого слова продукта боялись браться за биллинг. И тут обнаружился ещё один страх. Я переживала, что это демотивирует моих разработчиков. Им казалось, что это не их область, что разбираться в куче счетов неинтересно. В отличие от нас, команда биллинга радовалась разгрузке.

На несколько спринтов мы ушли в работу над BILLmanager, и этот опыт тоже оказался полезным.

Коротко о том, как происходило внедрение

  1. Чтобы минимизировать стресс перехода в другой продукт, команда оставалась командой и не зависела от ребят из BILLmanager.
  2. Задачи выбирали по принципу «нужно сделать ещё вчера, но не хватает рук». Задачи обсуждали продуктологи, потом при планировании очередного спринта я транслировала их в команду.
  3. Разработчики BILLmanager были нашими менторами. Эксепшн-мен отвечал на все вопросы, а тимлид рассказывал, что и как должно работать
  4. У нас было два стендапа. Сначала ходили в биллинг, потом обсуждали итоги внутри нашей команды.

Какую пользу разработчики вынесли из внедрения в другую команду

  1. Другой продукт — чужой код, в котором нужно разобраться; плюс другая логика работы, которую нужно понять. Благодаря менторству тимлида и терпению эксепшн-мена мы успешно освоились в биллинге, прокачали новые скиллы и довольно быстро пилили доработки.
  2. Конечно же, мы подсмотрели как некоторые вещи устроены внутри другой команды. Может показаться, что все у всех одинаково, но как бы не так. Различия кроются в мелочах. Лучшее и удобное взяли себе за правило (например, подсмотрели и, немного переделав под себя, стали использовать скрам-доску, переняли некоторые моменты code style и пр.).

4. Страх стать ментором/остаться без тимлида

Компании нужно как можно больше сильных программистов, поэтому когда разработчик прокачивает hard skills и переходит на уровень Middle, обучение новичков становится его обязанностью. Но в целом менторство обычно лежит на тимлиде. Так было и в нашей команде, пока опыт ведущего разработчика срочно не понадобился в другом продукте. Оставшимся без тимлида программистам предстояло взять на себя обучение и новичков, и друг друга.

Надо отвлекаться от своих задач, настраиваться на другого человека, объяснять то, что иногда сам понимаешь на уровне интуиции и объяснять так, чтобы тебя поняли. Быть ментором страшно. Если он сделал ошибку, и ты не заметил — отвечаешь ты. Если падаван не понял — это и твоя проблема.

Но мы справились, а из этого довольно стрессового опыта вынесли следующее:
Я не буду давать советы, как стать хорошим ментором, это тема для отдельной статьи.

  1. Объясняя, надо давать больше контекста. В голове всё красиво, а когда рассказываешь, получается вырвано и непонятно.
  2. На ревью надо не просто смотреть код, а разбираться, что человек пытался этим кодом решить. Тогда проще понять его логику и найти ошибки.
  3. Делиться знаниями полезно: учишься формулировать мысли; раскладываешь всё по полочкам в своей голове; пока объясняешь, находишь лучшее решение задачи.

5. Страх не освоить новые технологии

Когда затишье закончилось, пришло время приступать к новой версии продукта DCImanager. Казалось бы, вот он долгожданный момент. Сейчас полной амбициозных людей командой начнем всё с нуля — без оглядки на старые баги и исторически сложившиеся странные зависимости в коде. Но и тут нашлось место страху.

Старую версию мы писали на С++11 и с использованием make, для новой выбрали C++17, CMake, Conan и Docker. За несколько лет технологии ушли далеко вперёд. Очередной выход из зоны комфорта, челлендж и мысль «а вдруг я не смогу и буду хуже остальных», «а вдруг тут меня ждёт больше проблем, я не разберусь и меня выгонят». Команде надо все это изучить и научиться применять. Новые технологии мы ещё осваиваем и борьба с этим страхом еще в процессе.

Как быстрее осваивать новые технологии

  1. Не стесняться спрашивать у старших и опытных коллег, не бояться показаться глупым.
  2. Документировать, чтобы ускорить процесс погружения новеньких и не рассказать по 10 тысяч раз одно и то же. Вести базу знаний.
  3. «Окей-гугл» всегда в помощь. Если не работает, то см. п.1.

Не страхи, а вызовы

Я воспринимаю эксперименты как возможность узнать новое, стать лучше и стараюсь, чтобы моя команда смотрела на свои страхи также. Я думаю, что настрой ребят во многом зависит от меня. Когда веришь в продукт и в разработчиков, прислушиваешься к ним на стендапах и разбираешь проблемы на ретроспективах, поддерживаешь в передрягах и объясняешь необходимость перемен, тогда им проще преодолевать страхи.

Боязнь дедлайнов, например, или страх не ужиться с новичками. Но будем честными, в запасе у нас есть еще пара непобежденных фобий. Но может быть со временем наш взгляд изменится. Пока кажется, что с ними ничего нельзя поделать — просто смириться.

А чего боитесь вы?

S. P. Когда будет готово, мы вам напишем. Если хотите первым увидеть демо-версию DCImanager — отправляйте контакты на почту n.trifonova@ispsystem.com с темой «Хочу посмотреть на новый DCImanager». Или если вам нужен продукт для управления серверами, но текущий DCImanager почему-то не подходит и на рынке нет подходящего решения, напишите свои пожелания к такому софту, возможно, что-то мы включим в план разработки.

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

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

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

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

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