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

Когда вы близки к срокам завершения проекта, работа состоит в том, чтобы уметь сказать «нет»

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

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

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

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

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

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

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

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

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

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

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

Обратимся к оценке вашего собственного опыта

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

Насколько хорошо, по вашим ощущениям, вы знаете повседневные проблемы в написании, развертывании и поддержке кода в команде?

Насколько часто ваша команда маркирует свою работу как законченную?

Когда в последний раз вы писали программу, устраняя в ней ошибки, или работали в паре с членом команды над трудным для него кодом?

Есть ли в вашей команде один-два человека, негативно проявляющие себя в коллективе? Каковы ваши планы по разрешению таких проблем для обеспечения движения вперед?

Кажется ли вам, что члены вашей команды заинтересованы друг в друге? Улыбаются ли они друг другу на совещаниях? Шутят или говорят на общие темы? Пьют кофе или обедают вместе? Когда в последний раз вы собирались вместе и говорили не о работе?

Как принимаются решения в вашей команде? Есть в ней процедура распределения обязанностей по принятию решений? Принятие каких решений вы оставляете лично себе?

Когда в последний раз вы оценивали завершенный проект, чтобы увидеть, достиг ли он поставленных целей?

Насколько полно понимает ваша команда, почему она работает над конкретными текущими проектами?

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

6

Управление группой команд

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