От разработчика до руководителя

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

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

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

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

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

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