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

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

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

Инженерная составляющая за пределами кода

Менеджмент на уровне нескольких команд иногда становится весьма запутанным. Компании ведь нанимают менеджеров частично потому, что у них есть инженерная подготовка и знания. Но многие думают, что серьезный менеджмент — это уже не инженерия. В конце концов, серьезный менеджер ведь не участвует активно в написании кода и не занимается дизайном систем, верно?

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

В популярной книге по менеджменту «Сначала нарушьте все правила»13 обсуждается, на какие вопросы вы должны уметь отвечать, чтобы предсказать, насколько продуктивной и успешной может оказаться та или иная команда. Среди них следующие.

Знаю ли я, чего ждут от меня на работе?

Достаточно ли у меня материалов и оборудования, чтобы успешно выполнять свою работу?

Имеется ли у меня возможность каждый день заниматься тем, что получается у меня лучше всего?

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

Измерители здоровья вашей команды

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

Частота релизов