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

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

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

Практические советы по правильному делегированию

Важно помнить, что быть хорошим руководителем — значит уметь правильно делегировать.

Используйте цели команды, чтобы определить, в какие детали следует влезать

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

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

Получайте информацию от систем, прежде чем обращаться к сотрудникам

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

Корректируйте фокус внимания в зависимости от фаз проекта

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

Установите стандарты для кода и систем

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

Нейтрально, а лучше позитивно относитесь к хорошим и плохим новостям внутри команды

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

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