Цель – проект

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

Постановка задачи

Руководство проектом может начинаться в различных состояниях:

• есть задача, под неё подбирается руководитель проекта и команда;

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

• есть команда, которая выбирает задачу.

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

Понятно, что трудоёмкость постановки и качество соответствующих технических требований в этих трёх случаях будут различными, но руководитель должен стремиться, чтобы неопределённость, как существенный фактор риска, свести к минимуму.

Оценка

Оценка задачи необходима, чтобы выяснить основные параметры проекта: время его выполнения, стоимость, количество участников. На начальном этапе проекта оценка крайне сложна, причём, как правило, параметры занижаются, что нередко приводит к «безнадёжному проекту» [4] или к срыву сроков и выход за границы бюджета. Причин неверной оценки много: неопределённость задачи на начальном этапе, желание заказчика получить «побыстрее и подешевле», переоценка своих возможностей у разработчиков, конкурентная борьба, неадекватная оценка рисков. Как бы то ни было, программисты обычно проигрывают. Чтобы уменьшить этот эффект, мы обычно разбиваем проект на две части: вначале отдельным договором оформляем разработку технического задания (анализ задачи), а затем на основании полученных сведений договариваемся о разработке системы.

Методы оценки проекта – это тема отдельного разговора, в любом случае её точность во многом зависит от квалификации руководителя и выбранной методики.

Планирование

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