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

Готова биться об заклад: если вы бросите честный взгляд на команду, нечасто выпускающую релизы, то сразу же увидите проблемы. Процесс подготовки релиза занимает много времени. Инженеры-программисты обычно не чувствуют себя ответственными за окончательное качество кода и оставляют эту работу на команду по контролю качества, что обычно создает много задержек в двусторонней связи между ними. Если в процессе релиза возникают проблемы, это приводит к сбоям в производстве (или вообще в разработке продукта). Неспособность команды часто осуществлять релизы приводит к целому ряду болезненных последствий.

Здесь вы можете сказать: «Спасибо за совет, но у меня нет времени для работы над этим с учетом нашего напряженного плана» или «Наши системы не предназначены для частых релизов». Или, наконец: «В конце концов, не так уж важно, что мы вносим в наши продукты много изменений».

И все же задайте себе еще вопросы. Работает ли ваша команда в полную силу? Ваши инженеры не боятся новых вызовов и растут над собой? Довольно ли вашим прогрессом подразделение по продукции? Есть у ваших людей время, чтобы писать новый код и разрабатывать новые системы? Если ответы положительные, то замечательно. Забудьте о моих предостережениях. Вы полностью контролируете ситуацию. Если ответы отрицательные, то у вас проблемы и вы не уделяете им внимания на свой страх и риск.

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

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

Частота проверок кода

Трудно обеспечить применение гибких (agile) методов в команде, где не понимают ценность разбивки работы на маленькие составные элементы. Скорее всего, вам всегда придется учить этому новичков, только что пришедших из колледжа. Однако следует отметить: зачастую даже старшие разработчики нуждаются здесь в определенной помощи и контроле. Я не собираюсь выступать адвокатом ни одной из конкретных методик разработки программного обеспечения, но считаю: инженерам, не пишущим тестов, труднее справиться с разбивкой своей работы. Освоение навыков в тестирующей программной среде (даже если инженеры не участвуют в тестировании программ каждый день) может помочь им приобрести такое умение.

Я заостряю ваше внимание на этой теме потому, что новому менеджеру зачастую бывает трудно сказать людям, писавшим код столько же, сколько он, если не больше, что их методы работы требуют улучшения. Стремление избежать конфликтов живет глубоко в каждом из нас, и затрагивать кого-то лично бывает очень трудно. Если ваша компания стремится к быстрой разработке программных продуктов, то разрешать инженерам-программистам уходить в себя на недели и писать код в одиночку, не допуская общего контроля над созданной версией, — значит тормозить работу всей команды и порождать проблемы. Ведь вы управляете не командой ученых и исследователей. (Или все же управляете? Тогда пропустите этот раздел.) Для вас должно быть нормально ожидать, что продвигающаяся вперед работа регулярно обновляется.

Частотность сбоев

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

Вы можете работать в компании, где разработчики поддерживают созданный ими код или системы. В этом есть свои минусы: возложение на членов команды обязанностей по частым дежурствам в режиме on call по поводу возникающих сбоев, да еще вечерами или по выходным, изматывает специалистов. Несмотря на этот риск, есть и свои плюсы: прежде всего реагируют на проблему и устраняют ее самые подходящие люди. Став менеджером, вы можете испытывать соблазн выйти из роли пожарного. Могу вас понять. Но если ваша команда сама занимается устранением неполадок и сбоев в программах, то вы должны лично участвовать в работе по поддержанию продукта. Возможно, вам не следует слишком часто участвовать в разрешении инцидентов, но от вас будут ожидать большей доступности, если занимающийся данной конкретной проблемой программист нуждается в помощи.

Анализ возникающих сбоев и неполадок должен включать в себя следующий вопрос: «Правильно ли поставлена в моей команде работа с точки зрения каждодневного достижения максимального результата?» Когда работа с неполадками становится простым реагированием, а не деятельностью по уменьшению их количества, она может снижать способность команды работать с максимальной отдачей. Инженеры дежурят на телефонах, они выматываются, занимаясь массой проблем и не добиваясь ничего, кроме временного устранения последствий очередного сбоя в программе, а потом передают печальную эстафету очередному бедному малому. Если работа со сбоями и поддержкой программ строится в вашей команде именно так, то коллектив не добьется максимальной производительности, а его члены, отправляясь на очередную «пожарную вахту» по телефонным дежурствам, начнут с каждым днем ненавидеть свою работу все больше. В таких случаях вам как лидеру следует сконцентрироваться на обеспечении команде времени, нужного для дизайна более надежных систем, или написании кода, исправляющего сбои по мере возникновения.