Comments 10
Скорее тут всплывает фактор непределенности, общие зарисовки крупного объекта дорабатываются с помощью спринтов, когда идет дробление и обсуждение потребностей и функционала.
Если развернуть анализ и разбить проекты по временному промежутку (от года и выше), то скорее всего они претерпят изменения в силу гибкости и выхода новых инструментов.
Очень путает тут термин "успешный" - все таки чаще успешным проектом называют тот, который окупился, а не который реализован в срок.
Ну и личное мнение - корреляция с размером тут неочевидна. Ну или опять таки некорректно выбран термин. Если его заменить на "простой" - "сложный" - то внезапно станет статья очень КЭПовской - сложные проекты реже реализуются в срок.
Какой-то очень примитивный анализ.
Если на входе есть ТЗ и на выходе мы проверяем сделан каждый пункт из него или нет, то что делать с фичами, которые добавили в процессе работы, а с теми от которых отказались?
Почему ТЗ по умолчанию считается корректно описанным? И какой шанс сделать успешный проект, основанный на неуспешном ТЗ?
Неуспешным считался проект, в котором был реализован не весь требуемый функционал, либо проект был реализован в полном объеме, но с нарушением сроков, либо с превышением бюджета.
А как же вариант что проект вообще не был реализован
Было бы интересно посчитать процент успешных проектов в зависимости от бюджета, количества сотрудников и т п, чтобы иметь более конкретные данные.
Например, McKinsey провела глобальный опрос ИТ-проектов в 2012 году, который показал примерно то же самое, что более крупные проекты имеют более низкий уровень успеха, чем более мелкие проекты. Их опрос показал, что проекты с бюджетом более 15 миллионов долларов имеют показатель успеха всего 25% по сравнению с показателем успеха 50% для проектов с бюджетом менее 1 миллиона долларов. Тут уже конкретные цифры, которые можно учесть при планировании.
Зависимость вероятности успеха проекта от его размера