В этой, 12 статье из серии «Менеджмент цифрового мира», я продолжаю рассказ о схеме Scrum, начатый в предыдущей статье «Итерации Scrum – целостная схема, а не прикольная картинка».
А что Вы скажете на то, что большинство заказчиков хотят понимать бюджет ми этапность проекта ДО его начала? Для этого и делается предварительный этап по подготовке технического задания, где всё расписывается с максимальной детализацией, доступной на текущий момент. Agile не даёт такой возможности. Часто встречаю его использование во внутренних процессах разных банков, но там денег дофига, им вполне можно поиграться с разными технологиями. Взять тот же Сбертех. Фантик красочный (типа грамотные программисты, новейшие технологии и т.п.). А на выходе пустота - продукта нет! Поэтому для внутренних нужд при наличии финансирования это ещё может подойти. Особенно когда заказчиком является другой отдел :-) Но в реальной жизни, когда в роли заказчика выступает сторонняя организация, это, увы, не работает!
В том то и дело, что эта максимальная детализация потом не выдерживает столкновения с реальностью. Как из-того, что реальность успевает уплыть, так и из-за невозможности оценить все детали в сложной социотехнической системе. В результате готовый софт, сделанный по этому ТЗ - не работает. Наша компания узнала про Agile в 2007 и начала его осваивать, сначала в проектах для коммерческих заказчиков (потому что там нет ограничений по нормативно диктуемому процессу), а потом - и с более консервативными госструктурами - Центральный Банк, ГазПромБанк. И они нас ценят именно потому, что на выходе из проекта получается реально работающий продукт, решающий их проблемы и в нужные сроки. А получается он за счет того, что мы быстро выходим на демонстрации и интеграционные испытания, и в результате вскрываются проблемы, которые не были учтены в ТЗ (его часто делает IT Заказчика) - а дальше проблемы успеваем решить. Там есть накладные расходы на правильное оформление, но все равно эффективнее получается. Я в 2016 делал доклад о накопленном опыте ведения проектов на AgileDays-2016 http://mtsepkov.org/GosAgile-CUSTIS-AgileDays-2016
Это - собственный опыт. Чужих кейсов тоже много, есть, например, очень интересный кейс РосКомНадзора, который я слышал от Марины Макарчук в конце 2015 на AgileKitchen в аппарате правительства России по применению Agile. Кейсу уже было три года. Там был подрядчик с классическим проектным подходом, который каждые полгода, к смене нормативки, выкатывал новые релизы для 17 систем их It-ландшафта, и в результате месяц-другой Роскомнадзор стоял на ушах - интеграция сбоила, а двухнедельный срок для обработки обращений Роскомнадзору никто не отменял. Они потребовали трехнедельных релизов, в результате подрядчик был вынужден внедрить и другие практики - и в результате все устойчиво работает и развивается уже несколько лет. Конспект у меня на сайте http://mtsepkov.org/GosAgile-2015-11 там есть ссылки на презентации, видео тоже можно найти.
Вообще в 2009-2012 годах на конференциях была достаточно популярна тема применения Agile в Fixprice-проектах. Основных идея две: (а) в оценку закладывается буфер и дальше идет слежение за его расходованием и (б) надо внимательно следить за соответствием ТЗ фактическому состоянию, вскрывать проблемы и дальше искать решения в обмене скоупа работ. И если со стороны Заказчика есть люди заинтересованные в реальном внедрении, а не в подписании актов, то процесс идет. А если их нет - то в проект лучше не ввязываться с самого начала.
Так что Agile работает сильно лучше, чем тщательное планирование. Иначе бы не стал стандартом отрасли.
А что Вы скажете на то, что большинство заказчиков хотят понимать бюджет ми этапность проекта ДО его начала? Для этого и делается предварительный этап по подготовке технического задания, где всё расписывается с максимальной детализацией, доступной на текущий момент.
Agile не даёт такой возможности. Часто встречаю его использование во внутренних процессах разных банков, но там денег дофига, им вполне можно поиграться с разными технологиями. Взять тот же Сбертех. Фантик красочный (типа грамотные программисты, новейшие технологии и т.п.). А на выходе пустота - продукта нет!
Поэтому для внутренних нужд при наличии финансирования это ещё может подойти. Особенно когда заказчиком является другой отдел :-)
Но в реальной жизни, когда в роли заказчика выступает сторонняя организация, это, увы, не работает!
В том то и дело, что эта максимальная детализация потом не выдерживает столкновения с реальностью. Как из-того, что реальность успевает уплыть, так и из-за невозможности оценить все детали в сложной социотехнической системе. В результате готовый софт, сделанный по этому ТЗ - не работает. Наша компания узнала про Agile в 2007 и начала его осваивать, сначала в проектах для коммерческих заказчиков (потому что там нет ограничений по нормативно диктуемому процессу), а потом - и с более консервативными госструктурами - Центральный Банк, ГазПромБанк. И они нас ценят именно потому, что на выходе из проекта получается реально работающий продукт, решающий их проблемы и в нужные сроки. А получается он за счет того, что мы быстро выходим на демонстрации и интеграционные испытания, и в результате вскрываются проблемы, которые не были учтены в ТЗ (его часто делает IT Заказчика) - а дальше проблемы успеваем решить. Там есть накладные расходы на правильное оформление, но все равно эффективнее получается. Я в 2016 делал доклад о накопленном опыте ведения проектов на AgileDays-2016 http://mtsepkov.org/GosAgile-CUSTIS-AgileDays-2016
Это - собственный опыт. Чужих кейсов тоже много, есть, например, очень интересный кейс РосКомНадзора, который я слышал от Марины Макарчук в конце 2015 на AgileKitchen в аппарате правительства России по применению Agile. Кейсу уже было три года. Там был подрядчик с классическим проектным подходом, который каждые полгода, к смене нормативки, выкатывал новые релизы для 17 систем их It-ландшафта, и в результате месяц-другой Роскомнадзор стоял на ушах - интеграция сбоила, а двухнедельный срок для обработки обращений Роскомнадзору никто не отменял. Они потребовали трехнедельных релизов, в результате подрядчик был вынужден внедрить и другие практики - и в результате все устойчиво работает и развивается уже несколько лет. Конспект у меня на сайте http://mtsepkov.org/GosAgile-2015-11 там есть ссылки на презентации, видео тоже можно найти.
Вообще в 2009-2012 годах на конференциях была достаточно популярна тема применения Agile в Fixprice-проектах. Основных идея две: (а) в оценку закладывается буфер и дальше идет слежение за его расходованием и (б) надо внимательно следить за соответствием ТЗ фактическому состоянию, вскрывать проблемы и дальше искать решения в обмене скоупа работ. И если со стороны Заказчика есть люди заинтересованные в реальном внедрении, а не в подписании актов, то процесс идет. А если их нет - то в проект лучше не ввязываться с самого начала.
Так что Agile работает сильно лучше, чем тщательное планирование. Иначе бы не стал стандартом отрасли.