Посмотрите на этот график с основными факторами провалов IT-проектов.
На мой взгляд, это пример непонимания природы разработки.
Авторы статьи рекомендуют больше времени уделить оценке времени и сроков.
Но если посмотреть на длинный хвост из факторов, которые авторы статьи считают неважными или незначительными, то именно эти факторы и влияют на соответствие планов факту.
Скоуп изменился, людей не хватает, коммуникации не эффективные, пользователи не вовлечены, нехватка ресурсов…
Оценка, вероятно, была корректной, но в идеальном мире, где нет всех тех проблем, которые содержаться в других факторах.
На мой взгляд в этом распределении вообще не должно быть фактора оценки, потому что оценка – это прогноз, то, что происходит до начала проекта, а все остальные факторы, – это факт, то, что происходит во время проекта.
При этом график остается полезным, и выводы можно сделать такие:
1. С высокой вероятностью скоуп изменится, учитывайте это в оценке и закладывайте практики по управлению скоупом
2. С высокой вероятностью людей не будет хватать, или будут пробелы в компетенциях, – учитывайте в риск-модели отсутствие ключевых компетенций на некоторый срок
3. Сразу формируйте план коммуникаций, учитывайте, что это только план и конкретные методы необходимо будет стабилизировать (как, с кем, как часто коммуницировать)
4. Если на момент старта проекта нет ресурсов (окружений, каких-то коробочных решений, например), закладывайте это в риск-модель, ресурсы не появляются волшебным образом
5. В начале проекта максимально часто пересматривайте риск модель и сверяйтесь с планом, фиксируйте отклонения, начало – период максимальной неопределенности
(источник графика: http://paper.ijcsns.org/07_book/201905/20190509.pdf)
@sergey486
На мой взгляд, это пример непонимания природы разработки.
Авторы статьи рекомендуют больше времени уделить оценке времени и сроков.
Но если посмотреть на длинный хвост из факторов, которые авторы статьи считают неважными или незначительными, то именно эти факторы и влияют на соответствие планов факту.
Скоуп изменился, людей не хватает, коммуникации не эффективные, пользователи не вовлечены, нехватка ресурсов…
Оценка, вероятно, была корректной, но в идеальном мире, где нет всех тех проблем, которые содержаться в других факторах.
На мой взгляд в этом распределении вообще не должно быть фактора оценки, потому что оценка – это прогноз, то, что происходит до начала проекта, а все остальные факторы, – это факт, то, что происходит во время проекта.
При этом график остается полезным, и выводы можно сделать такие:
1. С высокой вероятностью скоуп изменится, учитывайте это в оценке и закладывайте практики по управлению скоупом
2. С высокой вероятностью людей не будет хватать, или будут пробелы в компетенциях, – учитывайте в риск-модели отсутствие ключевых компетенций на некоторый срок
3. Сразу формируйте план коммуникаций, учитывайте, что это только план и конкретные методы необходимо будет стабилизировать (как, с кем, как часто коммуницировать)
4. Если на момент старта проекта нет ресурсов (окружений, каких-то коробочных решений, например), закладывайте это в риск-модель, ресурсы не появляются волшебным образом
5. В начале проекта максимально часто пересматривайте риск модель и сверяйтесь с планом, фиксируйте отклонения, начало – период максимальной неопределенности
(источник графика: http://paper.ijcsns.org/07_book/201905/20190509.pdf)
@sergey486