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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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