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

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

У каждого инженера-программиста 10 продуктивных недель в квартал

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

Планируйте 20% всего рабочего времени команды на общую работу по поддержанию технологического уровня программирования

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

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

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

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