От разработчика до руководителя. Менеджмент для IT-специалистов - читать онлайн книгу. Автор: Камиль Фурнье cтр.№ 41

Работайте командой

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

Не затягивайте с отказом

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

Спросите технического директора: мой технический руководитель группы не занимается управлением

У меня есть технический руководитель группы. Он должен был проконтролировать, как один из младших программистов портирует приложение из компилируемого языка Objective-C на открытый язык программирования общего назначения Swift. Я только что выяснил: младший инженер еще даже не составил план проекта и не ответил ни на одно мое замечание относительно дизайна. Как мне заставить технического руководителя разобраться, чтобы мне не пришлось вмешиваться?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В главе 5 я отмечала, что в наше время распространенным недостатком в работе команд программистов является невыпуск кода и что прямой инструмент измерения этого состояния — частота релизов. Я сочувствую вам, если ваша компания не понимает важность частых релизов кода. В современном мире частота изменений кода — один из важнейших индикаторов трудоспособности команды разработчиков. Хорошие менеджеры-инженеры в командах, сосредоточенных на создании продукта, знают, как формировать условия, благоприятные для быстрого продвижения работы вперед. Одна из мер — умение правильно разбить работу на небольшие куски. Даже если в вашей компании не понимают ценности релизов, вы должны помогать команде достигать как можно более высокой частотности для конкретного продукта. Даже если вы считаете, что это не относится к вам, потому что вы заняты разработкой продукта (например, базы данных), не предполагающего частых релизов, я уверена: имеет смысл продвигать почти готовую версию продукта в бета-тестирование. Оно может стать важным инструментом измерения с точки зрения соотношения частотности релизов и стабильности программы.