Итерационная методика VS каскадная при внедрении СЭД
Проектное управление, управление рисками - высококлассынй внедренец должен владеть набором методик. Новая методика Agile насколько она подходит для внедрения СЭД?
Итерационная методика внедрения имеет определенные преимущества перед классической, но как убедить заказчика ее использовать. Мне, как исполнителю, итерационная методика приятней. С ней более спокойно работается (меньше нервотрепка), результат более интересный и полезный заказчику (на мой взгляд), нет длинных приемок продукта и т.д.
Как это разумно обосновать заказчику, что именно такой подход даст лучшие результаты?
Совсем недавно старались одного заказчика убедить в полезности именно итерационной методики. Сработал следующий аргумент: в сравнении итерационного и классического подходов, при равной общей стоимости работ исполнителя, в итерационном случае больше времени вкладывается именно в разработку функционала. При сравнении детальных планов-графиков работ, в итерационном случае на функционал тратиться почти на 30% больше (соответственно и функционала должно быть больше).
Тут https://www.youtube.com/watch?v=lif3VxoBQyM (с 3:30)
Парень дает достаточно интересную аргументацию в пользу итерационного внедрения (правда там он говорит о разработке веб): быстрый и понятный результат, прозрачность действий, приоритеты, и честный рассказ про удачи и неудачи.
С другой стороны, на этом видео говорится, что при внедрении готового продукта более применим "каскад".
Предлагаю поделиться мнениями по аргументации в пользу итерационного либо классического внедрения.
Комментарии 4
Agile-методики при всей своей привлекательности часто не подходят для заказчика. Дело в том, что все государственные заказчики, ФГУПы, большинство коммерческих компаний реализуют проекты через конкурсы. А в конкурсе всегда фиксируется цена, функционал и сроки, что неприемлемо для Agile.
Честно говоря, слабо верится. Можете пояснить - из чего возникла такая разница?
Да, на SEC(R) 2014 был интересный доклад от одного действительно интересного человека. Посмотреть видео и скачать презентацию можно здесь.
Жалко, что парень на видео самое интересное и не рассказал. К сожалению, рамочный договор - это не панацея.
Выше Александр правильно описал ситуацию с тендерами и конкурсами. Мало кто из коммерсантов сейчас готов работать по схеме с возмещением затрат, т.к. риски неудач практически полностью ложатся на него самого. А рисковать, тем более в кризисное время, никто не готов. Контракт с фиксированной ценной - единственный вариант передать максимум рисков на поставщика, что мы собственно и наблюдаем не только на рынке IT.
Другой вопрос, каким образом исполнитель распорядится имеющимся бюджетом. На мой взгляд итерационный подход
освоения бюджета, необходимо применять у клиентов без четких ожиданий от системы. Признаками этого является размытое или обобщающее ТЗ, отсутствие явного бизнес-заказчика и отсутствие понимания у заказчика разницы проектного и процессного управления. При наличии одного из этих сигналов, вероятнее всего, каскад приведет у провалу, а итерации позволят по крайней мере сформировать четкие ожидания от системы.