Технологические риски

Эта группа рисков объединяет риски связанные с используемыми технологиями. Со времён зарождения отрасли производства программного обеспечения было создано великое множество технологий. Технологии создавались для того, что бы решать задачи по некоторому шаблону: не всегда «всё заново и как хочется», а с уже известными выделенными этапами и средствами. Для каких-то задач хороши одни технологии, но не применимы другие, а для других наоборот.

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

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

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

Риски связанные с квалификацией персонала

Хотя этой группе рисков обычно уделяют мало внимания, когда как она не менее важна, чем две предыдущие. Насколько сотрудники, которые участвуют в проекте, опытны в применяемых технологиях? Есть ли опыт ведения аналогичных проектов, достаточен ли опыт менеджера проекта?

Проект не могут спасти гении-одиночки, если основная масса участников проекта – дилетанты. Если программисты не разбираются в UML диаграммах, а аналитики только их и создают, то проект можно даже не начинать.