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

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

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

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

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

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

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

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

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