и идеи, выраженные на языке

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

Четко ставить цели.
Определять способ достижения целей.
Контролировать и управлять реализацией.
Анализировать угрозы и противодействовать им.
Создавать команду.

Проект — этот средство стратегического развития. Цель — описание того, что мы хотим достичь. Стратегия — констатация того, каким образом мы собираемся эти цели достигать. Проекты преобразуют стратегии в действия, а цели в реальность.
Участников типового проекта разработки ПО можно условно разделить на пять групп ролей:

Анализ. Извлечение, документирование и сопровождение требований к продукту.
Управление. Определение и управление производственными процессами.
Производство. Проектирование и разработка ПО.
Тестирование. Тестирование ПО.
Обеспечение. Производство дополнительных продуктов и услуг.

У программного проекта имеется четыре фактора, которые определяют его успешность:

Выполнен в соответствие со спецификациями.
Выполнен в срок.
Выполнен в пределах бюджета.
Каждый участник команды уходил с работы в 18:00 с чувством успеха.

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

Финансовая ценность.
Стратегическая ценность.
Уровень рисков.

На верхнем уровне ИСР должны находиться не процессы, а продукты проекта, на следующем уровне — компоненты из которых эти продукты состоят. Выделение компонентов, составляющих программный продукт, это элемент высокоуровневого проектирования, которое мы должны выполнить на фазе планирования проекта, не дожидаясь проработки всех функциональных требований к разрабатываемому ПО.
Помимо работ, непосредственно направленных на создание программного обеспечения, в плане проекта должны быть предусмотрены необходимые ресурсы для обеспечения работ по следующим процессам:

управление содержанием;
управление конфигурациями,
управление качеством,
управление рисками,
управление проектом.

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

Отказываться от управления проектными рисками это все равно, что в кинотеатре не иметь огнетушителей и плана эвакуации на случай пожара.
Все, что мы делаем, управляя проектом разработки ПО, должно быть направлено на борьбу с рисками не уложиться в срок, перерасходовать ресурсы, разработать не тот продукт, который требуется.
Цели управления рисками проекта — снижение вероятности возникновения и/или значимости воздействия неблагоприятных для проекта событий.
Главные причины провала программных проектов:

Требования заказчика отсутствуют / не полны / подвержены частым изменениям.
Отсутствие необходимых ресурсов и опыта.
Отсутствие рабочего взаимодействия с заказчиком.
Неполнота планирования. «Забытые работы».
Ошибки в оценках трудоемкостей и сроков работ.

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

FPA IFPUG — метод функциональных точек,
метод COCOMO II, Constructive Cost Model.

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

Эффективные команды не образуются сами по себе, они кристаллизуются вокруг признанного лидера. Для того чтобы стать лидером, необходимо:

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

Мотивация должна начинаться с подбора сотрудников в команду. В старой экономике людей нанимали за умения и обучали нужному отношению к делу. В новой экономике необходимо поступать с точностью до наоборот: нанимать за нужное отношение к делу и учить необходимым умениям.
Рабочая группа прежде, чем она станет эффективной командой, должна пройти четыре обязательных последовательных стадии: 1) Forming, 2) Storming, 3) Norming, 4) Performing.
Если руководитель не будет прилагать дополнительные усилия команда, рано или поздно, начнет «сползать» с плато наивысшей эффективности в состояние застоя и стагнации. Задача менеджера на этом этапе — «точить пилу»: поддерживать требуемый уровень мотивации, быть штурманом, искать новые пути и открывать новые возможности. Четыре стадии развития команды должны циклически повторяться, чтобы обеспечить непрерывный рост производительности.

Для оперативного управления проектом используется рабочий план. Элементарная работа, как правило, представляет собой отдельное функциональное требование к программному продукту или запрос на изменение, над которым последовательно работают: бизнес-аналитик, проектировщик, разработчик, тестировщик и документалист.
Измерения по проекту необходимо выполнять регулярно, не реже одного раза в 1–2 недели. Для каждого измеримого показателя должны быть определены его плановые значения и допустимые отклонения.
В состав измеряемых показателей должны входить следующие характеристики проекта:

Освоенный и плановый объемы работ и фактические затраты по проекту.
Показатели прогресса и стабильности проекта.
Размер продукта.
Производительность.
Показатели качества программного продукта.

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

Содержание раздела