У вас есть классная идея, ресурсы и умные программисты и все вроде идет по плану, но в конце проекта вы видите провал. Знакомо?

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

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

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

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

1. Принятие вынужденного графика или обязательных сроков завершения/вехи без существенных данных и анализа.

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

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

2. Добавление лишнего персонала для достижения нереального сжатия графика.

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

3. Отсутствие учета и внесения необходимых корректировок в график и бюджетные прогнозы.

«Разве не было бы замечательно, если…?» Эти пять слов могут быть одними из самых страшных, особенно когда их произносят в середине проекта. 

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

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

4. Эмоциональные или «основанные на интуиции» переговоры с заказчиком, без фактов и статистики.

Когда ожидаемый успех или провал программного проекта ставит под угрозу карьеру человека, репутацию компании или сулит большими деньгами, то в ход идут эмоции. Стресс может омрачить мышление, особенно когда ставки высоки. Заказчик может потребовать 6-месячного графика, а в отчетах по предыдущим проектам аналогичных размеров средняя длительность 8-месяцев. Заинтересованный участник может отклонить этот факт и советы от членов команды, заявив, что у «и так справимся». В таких ситуациях следование интуиции может потенциально привести к провалу проекта.

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