В этой, 12 статье из серии «Менеджмент цифрового мира», я продолжаю рассказ о схеме Scrum, начатый в предыдущей статье «Итерации Scrum – целостная схема, а не прикольная картинка».
Мне кажется всё это применимо только к внутренним проектам организации. Для коммерческих задач должен существовать чёткий план со сроками и отчётными точками. И ответственность нужна персональная. Потому что заказчику важно понимать как продвигается проект.
Дмитрий, от четкого плана со сроками нет никакой пользы, если сроки регулярно срываются, а бюджеты - превышаются. Успешность проектного менеджмента в IT никогда не давала более трети успешных проектов, несмотря на высокую стоимость, и этому есть системное объяснение - об этом у меня была статья "Развитие и провал регулярного менеджмента в IT" https://vc.ru/hr/95754-razvitie-i-proval-regulyarnogo-menedzhmenta-v-it И это - проявление более общей проблемы: регулярный менеджмент не умеет организовывать умственный труд, о чем писал еще Питер Друкер. Подробности - в другой статье "Цифровой мир: от физического труда — к умственному" https://vc.ru/future/94043-cifrovoy-mir-ot-fizicheskogo-truda-k-umstvennomu
А Agile для заказчика как раз обеспечивает то, что ему нужно - прозрачность продвижения проекта и реалистичный прогноз достижения результатов. И возможность своевременного принятия мер, если выясняется что проект требует гораздо больше средств и сил - это выясняется в первой четверти-трети проекта. а не перед завершением, как при классическом подходе. О том, как именно это обеспечивается, я еще буду говорить в говорить в своих статьях. А статистика показывает, что на старте успешность проектов Agile и регулярных была сопоставима, только Agile был много дешевле, а постепенно для Agile стали лучшие результаты. Собственно, без этого он бы никогда не завоевал мир, включая IT-отделы крупных корпораций - он сильно противоречит традиционной культуре.
Мне кажется всё это применимо только к внутренним проектам организации. Для коммерческих задач должен существовать чёткий план со сроками и отчётными точками. И ответственность нужна персональная. Потому что заказчику важно понимать как продвигается проект.
Похоже, это очередной набор отвлеченной ерунды от очередного инфоцигана, никогда ничем не управлявшего. Вы на его сайт зайдите.
Дмитрий, от четкого плана со сроками нет никакой пользы, если сроки регулярно срываются, а бюджеты - превышаются. Успешность проектного менеджмента в IT никогда не давала более трети успешных проектов, несмотря на высокую стоимость, и этому есть системное объяснение - об этом у меня была статья "Развитие и провал регулярного менеджмента в IT" https://vc.ru/hr/95754-razvitie-i-proval-regulyarnogo-menedzhmenta-v-it И это - проявление более общей проблемы: регулярный менеджмент не умеет организовывать умственный труд, о чем писал еще Питер Друкер. Подробности - в другой статье "Цифровой мир: от физического труда — к умственному" https://vc.ru/future/94043-cifrovoy-mir-ot-fizicheskogo-truda-k-umstvennomu
А Agile для заказчика как раз обеспечивает то, что ему нужно - прозрачность продвижения проекта и реалистичный прогноз достижения результатов. И возможность своевременного принятия мер, если выясняется что проект требует гораздо больше средств и сил - это выясняется в первой четверти-трети проекта. а не перед завершением, как при классическом подходе. О том, как именно это обеспечивается, я еще буду говорить в говорить в своих статьях. А статистика показывает, что на старте успешность проектов Agile и регулярных была сопоставима, только Agile был много дешевле, а постепенно для Agile стали лучшие результаты. Собственно, без этого он бы никогда не завоевал мир, включая IT-отделы крупных корпораций - он сильно противоречит традиционной культуре.