- PVSM.RU - https://www.pvsm.ru -
Хэллоуин — время поговорить о страхах. Я работаю продакт-менеджером в IT-компании, поэтому речь пойдёт про кошмары разработчиков. Но не обычные, а те, что появляются во времена перемен.
Когда компания развивается — меняет подход к разработке, создаёт новые продукты и расширяет возможности текущих, десятками принимает сотрудников, тем, кто работал по-старому, бывает тяжело перестроиться. Мы радуемся изменениям, но иногда, чего скрывать, боимся их. Я работаю продакт-менеджером уже год и за это время столкнулась с пятью крупными страхами своей команды. Сегодня расскажу об этих страхах и о том, как нам удалось их преодолеть.
Тестирование — верный способ выпустить продукт без баг. Но иногда для проверки кода нет оборудования.
Мы делаем DCImanager [1], панель для управления серверами и дата-центрами, и часто в виртуальной среде создать условия, в которых будет работать код, невозможно. Например, мы добавляем в панель управления поддержку новой модели коммутатора, маршрутизатора или PDU, а на тестовом стенде такого оборудования нет.
В каких-то случаях тестированием допустимо пренебречь, но не в нашем. Ошибка стоит дорого. Не инициализируешь всего одну переменную, и в половине случаев перестанет устанавливаться операционная система. Ошибёшься в паре строк кода — и «ляжет» дата-центр. Как вы понимаете, отвечать за «упавший» ЦОД не хочет никто, поэтому в моей команде этот страх на первом месте (хоть он и не связан с преобразованиями в компании).
Как преодолеваем страх уронить всё
Однажды мы добавляли для уже работающих коммутаторов управление агрегациями портов. При совершении ошибки работа сетевого оборудования в дата-центре была бы полностью остановлена. Клиент приезжал в свой дата-центр в три часа ночи и контролировал ситуацию, чтобы в случае чего быстро откатиться на старую версию и возобновить работу оборудования. Мы могли потерять удаленный доступ, и работа ЦОД была бы парализована.
У нас разработчики пишут юнит-тесты, а ручным тестированием занимаются отдельные люди. Но однажды случился форс-мажор, и команда осталась без ручного тестера. Не выпускать фичи мы не могли, поэтому разработчикам пришлось проверять друг друга.
Это был удар по самолюбию. Так сложилось, что все программисты моей команды вышли из тестировщиков (ручных и авто). Вернуться к ручному тестированию для них — сделать шаг назад. Ребята боялись, что если будут справляться сами, тестеров им не вернут. Но страх оказался беспочвенным, через пару спринтов тестировщик занял своё место в команде, а из опыта мы вынесли много полезного.
Какой профит принесло перекрестное тестирование
DCImanager вышел в 2013 году. За шесть лет технологии изменились, пришло время делать новую версию, мы решили делать её с нуля. Нарисовали прототипы, определили MVP, расставили приоритеты. Разработку старой версии заморозили, а к новой приступать не могли — к релизу уже готовились два новых продукта, все силы были брошены на них, надо было немного подождать. На время затишья моим разработчикам предстояло стать проектной командой BILLmanager [2], другого нашего продукта для автоматизации
И тут обнаружился ещё один страх. Разработчики инженерного во всех смыслах этого слова продукта боялись браться за биллинг. Им казалось, что это не их область, что разбираться в куче счетов неинтересно. Я переживала, что это демотивирует моих разработчиков. В отличие от нас, команда биллинга радовалась разгрузке.
На несколько спринтов мы ушли в работу над BILLmanager, и этот опыт тоже оказался полезным.
Коротко о том, как происходило внедрение
Какую пользу разработчики вынесли из внедрения в другую команду
Компании нужно как можно больше сильных программистов, поэтому когда разработчик прокачивает hard skills и переходит на уровень Middle, обучение новичков становится его обязанностью. Но в целом менторство обычно лежит на тимлиде. Так было и в нашей команде, пока опыт ведущего разработчика срочно не понадобился в другом продукте. Оставшимся без тимлида программистам предстояло взять на себя обучение и новичков, и друг друга.
Быть ментором страшно. Надо отвлекаться от своих задач, настраиваться на другого человека, объяснять то, что иногда сам понимаешь на уровне интуиции и объяснять так, чтобы тебя поняли. Если падаван не понял — это и твоя проблема. Если он сделал ошибку, и ты не заметил — отвечаешь ты.
Я не буду давать советы, как стать хорошим ментором, это тема для отдельной статьи. Но мы справились, а из этого довольно стрессового опыта вынесли следующее:
Когда затишье закончилось, пришло время приступать к новой версии продукта DCImanager. Казалось бы, вот он долгожданный момент. Сейчас полной амбициозных людей командой начнем всё с нуля — без оглядки на старые баги и исторически сложившиеся странные зависимости в коде. Но и тут нашлось место страху.
За несколько лет технологии ушли далеко вперёд. Старую версию мы писали на С++11 и с использованием make, для новой выбрали C++17, CMake, Conan и Docker. Команде надо все это изучить и научиться применять. Очередной выход из зоны комфорта, челлендж и мысль «а вдруг я не смогу и буду хуже остальных», «а вдруг тут меня ждёт больше проблем, я не разберусь и меня выгонят». Новые технологии мы ещё осваиваем и борьба с этим страхом еще в процессе.
Как быстрее осваивать новые технологии
Я воспринимаю эксперименты как возможность узнать новое, стать лучше и стараюсь, чтобы моя команда смотрела на свои страхи также. Я думаю, что настрой ребят во многом зависит от меня. Когда веришь в продукт и в разработчиков, прислушиваешься к ним на стендапах и разбираешь проблемы на ретроспективах, поддерживаешь в передрягах и объясняешь необходимость перемен, тогда им проще преодолевать страхи.
Но будем честными, в запасе у нас есть еще пара непобежденных фобий. Боязнь дедлайнов, например, или страх не ужиться с новичками. Пока кажется, что с ними ничего нельзя поделать — просто смириться. Но может быть со временем наш взгляд изменится.
А чего боитесь вы?
P. S. Если хотите первым увидеть демо-версию DCImanager — отправляйте контакты на почту n.trifonova@ispsystem.com с темой «Хочу посмотреть на новый DCImanager». Когда будет готово, мы вам напишем. Или если вам нужен продукт для управления серверами, но текущий DCImanager почему-то не подходит и на рынке нет подходящего решения, напишите свои пожелания к такому софту, возможно, что-то мы включим в план разработки.
Автор: natrif
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/blog-kompanii-ispsystem/297588
Ссылки в тексте:
[1] DCImanager: https://www.ispsystem.ru/software/dcimanager
[2] BILLmanager: https://www.ispsystem.ru/software/billmanager
[3] хостинга: https://www.reg.ru/?rlink=reflink-717
[4] Источник: https://habr.com/post/428315/?utm_source=habrahabr&utm_medium=rss&utm_campaign=428315
Нажмите здесь для печати.