В мире современных ИТ технологий, когда многочисленные приложения из Google Play и Appstore ежедневно уведомляют об обновлениях, услышать от проектной команды по внедрению ERP системы «проект займет от 9 (оптимистично) до 12 месяцев (реалистично)» — это вполне обычное явление. При этом бывают и более сложные проекты. В одной из компаний, где работал мой знакомый, только этап создания и подписания дизайна процессов длился 6 месяцев. Объем документа дизайна получился довольно внушительный и, в распечатанном виде, вполне мог бы спасти жизнь воину из древнего Китая (говорят что они использовали бумагу в качестве материала для своих доспехов). Времена древнего Китая прошли, однако и сегодня эта стопка бумаги продолжает спасать если не жизни, то, как минимум, нервные системы консультантов на этапе сдачи системы в эксплуатацию. Но от чего документ дизайна не спасает, так это от сдвига сроков запуска проекта и проблем с качеством системы к моменту промышленной эксплуатации. Давайте попробуем разобраться почему это происходит и можно ли как-то по-другому.
Представьте что вы заказываете ремонт своей новой квартиры. Перед началом работ команда подрядчика просит подписать вас текстовый документ, как правило без иллюстраций, о том как ваша квартира будет выглядеть после ремонта, включая все детали: розетки, выключатели, мебель и т д. Руководитель команды предупреждает, что изменения во время этапа приемки скорее всего приведут к дополнительным затратам. По этой причине вы ответственно подходите к задаче, тратите довольно много времени и в конце концов подписываете документ. Ну и, предположим, уезжаете на полгода из страны. И полностью доверяете команде внедрения сделать ремонт самостоятельно без какого-либо контроля и мониторинга с вашей стороны. Через полгода возвращаетесь, заходите в квартиру и видите что готовая квартира не вполне соответствует вашим ожиданиям. Тогда вы просите команду проекта переделать некоторые детали, например, перенести розетки поближе к холодильнику. Команда проекта говорит, что перенести розетки будет довольно дорого стоить и займет много времени, потому что придется долбить стену, а там уже плитка и т д. Вы заходите в спальню, включаете уже установленный кондиционер, и понимаете что он ночью будет дуть прямо на вас. Просите команду передвинуть и его, но получаете примерно такой же ответ как и с розетками. Тем не менее для вас это вопрос принципиальный и вы говорите, что не начнете жить в квартире пока кондиционер не будет там, где надо, потому что в вашей нынешней квартире он именно там, где надо, и вы не видите смысла в переезде, если он ухудшит комфорт вашего ежедневного быта. В результате заезжаете в квартиру на 3 месяца позже исходного плана с 20% превышением бюджета.
Основная проблема, на мой взгляд, состоит в том, что мы пытаемся предусмотреть и зафиксировать все детали на этапе дизайна до начала работ. Этап дизайна затягивается, т.к. бизнес-пользователи редко могут полностью посвятить себя проекту, им приходится заниматься их ежедневными бизнес-процессами. К моменту подписания дизайна, у них накапливается довольно обширный бэклог из отложенных задач и они больше не готовы вовлекаться в проект до этапа тестирования. Они уже потратили большое количество времени на планирование всех деталей и хотели бы увидеть готовую и настроенную систему. Однако готовый результат не соответствует ожиданиям. Одна из причин этого проиллюстрирована ниже:
У нас в компании мы успешно пилотируем новый подход к проектам по внедрению и тиражированию ERP систем. При этом на проектах тиражирования подход позволяет завершить проект даже быстрее обычного плана с последовательными фазами дизайна, разработки и тестирования (aka Waterfall).
Мы перешли от этого:
К этому:
Мы называем этот подход смешанным (Waterfall – Agile) т.к., пользуемся как элементами Agile (работа по спринтам), так и Waterfall (промышленная эксплуатация начинается только после завершения всего проекта). Ускорение происходит за счет того, что, во-первых, мы работаем с бизнес-пользователями параллельно (работа над дизайном будущих спринтов и настройка, разработка текущих), а во-вторых «переносим розетки» поближе к будущему холодильнику до того, как плитку уложили и кухонный гарнитур собрали. Чем больше объем проекта, тем значительнее выигрыш во времени и качестве по сравнению с классическим Waterfall подходом.
Основные характеристики проекта:
На этапе пред-проекта мы оценивали что сделаем проект за 30 недель. По факту, с использованием Agile подхода мы сделали все за 22 недели. За 4 месяца эксплуатации после запуска мы получили 1 запрос на изменение от бизнеса.
Внутренние ИТ команды. Как можно раньше договоритесь с ключевыми ИТ командами, которые будут вовлечены во внедрение. Заручитесь поддержкой руководства, чтобы перейти к диалогу с внешним подрядчиком.
Внешний подрядчик. В проектной команде подрядчика должны быть профессионалы, которые хорошо знают саму систему и Agile принципы внедрения. Новичков быть не должно. Проведите выборочные собеседования с командой перед тем как подписывать контракт.
У бизнес команды должна быть возможность и желание регулярно вовлекаться в проект в течение всех фаз разработки. Это не значит что Бизнесу придется работать больше. Мы перераспределяем их время с обычной фазы дизайна и тестирования внутрь каждого отрезка разработки.
Вопрос 1: Коммерческий отдел просит подписать контракт с подрядчиком с фиксированной стоимостью до начала разработки. Но как оценить стоимость если нет завершенного и подписанного дизайна?
Ответ 1: Мы подписываем Fixed Team контракт с подрядчиком– фиксируем команду и время выполнения проекта, например 8 месяцев. Это не то же самое, что Time-Material, т.к. мы фиксируем длительность и общий объем работ. При этом мы остаемся гибкими в изменении/добавлении бизнес-требований, если длительность проекта и команда не увеличивается.
Вопрос 2: Что если бизнес-пользователи будут постоянно добавлять новые требования во время ревью и планирования каждого спринта?
Ответ 2: В этом случае мы просим приоритизировать требования и убрать те, которые имеют самый низкий приоритет и не укладываются в сроки проекта. Т.е. добавляем новое взамен чему-то существующему. Все эти изменения/новые требования будут нас ждать в любом случае на этапе приемки в независимости от подхода. Но в случае с промежуточной приемкой в конце каждого спринта у нас больше возможностей по управлению этими требованиями, в то время как при приемке непосредственно перед запуском, мы рискуем сроками запуска и качеством системы (качество по определению – это соответствие конечного результата ожиданиям пользователя, а не текстовому дизайну).
Если вас заинтересовала эта статья, у вас есть вопросы, или вы просто хотите поделиться мнением о вышенаписанном, то я буду благодарен, если вы поделитесь обратной связью под публикацией или в личном сообщении. Иллюстрации и идейное содержание статьи при участии Ангелины Абдуллаевой angelina.abdullayeva.
Представьте что вы заказываете ремонт своей новой квартиры. Перед началом работ команда подрядчика просит подписать вас текстовый документ, как правило без иллюстраций, о том как ваша квартира будет выглядеть после ремонта, включая все детали: розетки, выключатели, мебель и т д. Руководитель команды предупреждает, что изменения во время этапа приемки скорее всего приведут к дополнительным затратам. По этой причине вы ответственно подходите к задаче, тратите довольно много времени и в конце концов подписываете документ. Ну и, предположим, уезжаете на полгода из страны. И полностью доверяете команде внедрения сделать ремонт самостоятельно без какого-либо контроля и мониторинга с вашей стороны. Через полгода возвращаетесь, заходите в квартиру и видите что готовая квартира не вполне соответствует вашим ожиданиям. Тогда вы просите команду проекта переделать некоторые детали, например, перенести розетки поближе к холодильнику. Команда проекта говорит, что перенести розетки будет довольно дорого стоить и займет много времени, потому что придется долбить стену, а там уже плитка и т д. Вы заходите в спальню, включаете уже установленный кондиционер, и понимаете что он ночью будет дуть прямо на вас. Просите команду передвинуть и его, но получаете примерно такой же ответ как и с розетками. Тем не менее для вас это вопрос принципиальный и вы говорите, что не начнете жить в квартире пока кондиционер не будет там, где надо, потому что в вашей нынешней квартире он именно там, где надо, и вы не видите смысла в переезде, если он ухудшит комфорт вашего ежедневного быта. В результате заезжаете в квартиру на 3 месяца позже исходного плана с 20% превышением бюджета.
Основная проблема, на мой взгляд, состоит в том, что мы пытаемся предусмотреть и зафиксировать все детали на этапе дизайна до начала работ. Этап дизайна затягивается, т.к. бизнес-пользователи редко могут полностью посвятить себя проекту, им приходится заниматься их ежедневными бизнес-процессами. К моменту подписания дизайна, у них накапливается довольно обширный бэклог из отложенных задач и они больше не готовы вовлекаться в проект до этапа тестирования. Они уже потратили большое количество времени на планирование всех деталей и хотели бы увидеть готовую и настроенную систему. Однако готовый результат не соответствует ожиданиям. Одна из причин этого проиллюстрирована ниже:
У нас в компании мы успешно пилотируем новый подход к проектам по внедрению и тиражированию ERP систем. При этом на проектах тиражирования подход позволяет завершить проект даже быстрее обычного плана с последовательными фазами дизайна, разработки и тестирования (aka Waterfall).
Мы перешли от этого:
К этому:
Мы называем этот подход смешанным (Waterfall – Agile) т.к., пользуемся как элементами Agile (работа по спринтам), так и Waterfall (промышленная эксплуатация начинается только после завершения всего проекта). Ускорение происходит за счет того, что, во-первых, мы работаем с бизнес-пользователями параллельно (работа над дизайном будущих спринтов и настройка, разработка текущих), а во-вторых «переносим розетки» поближе к будущему холодильнику до того, как плитку уложили и кухонный гарнитур собрали. Чем больше объем проекта, тем значительнее выигрыш во времени и качестве по сравнению с классическим Waterfall подходом.
Пример проекта в Mars с использованием смешанного подхода
Основные характеристики проекта:
- 5½ периода (22 недели) от момента Старта до Запуска
- Полная проектная команда – 40 человек (бизнес пользователи и ИТ консультанты, разработчики)
- 4 функциональные команды внутри проектной команды – Финансы, Закупки, Логистика и продажи, Отдел контроля качества
- 4 цикла Бизнес-тестирования с 93% успешных скриптов с первой попытки. 5 очных воркшопов
На этапе пред-проекта мы оценивали что сделаем проект за 30 недель. По факту, с использованием Agile подхода мы сделали все за 22 недели. За 4 месяца эксплуатации после запуска мы получили 1 запрос на изменение от бизнеса.
Ключевые факторы успеха
Внутренние ИТ команды. Как можно раньше договоритесь с ключевыми ИТ командами, которые будут вовлечены во внедрение. Заручитесь поддержкой руководства, чтобы перейти к диалогу с внешним подрядчиком.
Внешний подрядчик. В проектной команде подрядчика должны быть профессионалы, которые хорошо знают саму систему и Agile принципы внедрения. Новичков быть не должно. Проведите выборочные собеседования с командой перед тем как подписывать контракт.
У бизнес команды должна быть возможность и желание регулярно вовлекаться в проект в течение всех фаз разработки. Это не значит что Бизнесу придется работать больше. Мы перераспределяем их время с обычной фазы дизайна и тестирования внутрь каждого отрезка разработки.
Некоторые часто-задаваемые вопросы
Вопрос 1: Коммерческий отдел просит подписать контракт с подрядчиком с фиксированной стоимостью до начала разработки. Но как оценить стоимость если нет завершенного и подписанного дизайна?
Ответ 1: Мы подписываем Fixed Team контракт с подрядчиком– фиксируем команду и время выполнения проекта, например 8 месяцев. Это не то же самое, что Time-Material, т.к. мы фиксируем длительность и общий объем работ. При этом мы остаемся гибкими в изменении/добавлении бизнес-требований, если длительность проекта и команда не увеличивается.
Вопрос 2: Что если бизнес-пользователи будут постоянно добавлять новые требования во время ревью и планирования каждого спринта?
Ответ 2: В этом случае мы просим приоритизировать требования и убрать те, которые имеют самый низкий приоритет и не укладываются в сроки проекта. Т.е. добавляем новое взамен чему-то существующему. Все эти изменения/новые требования будут нас ждать в любом случае на этапе приемки в независимости от подхода. Но в случае с промежуточной приемкой в конце каждого спринта у нас больше возможностей по управлению этими требованиями, в то время как при приемке непосредственно перед запуском, мы рискуем сроками запуска и качеством системы (качество по определению – это соответствие конечного результата ожиданиям пользователя, а не текстовому дизайну).
Если вас заинтересовала эта статья, у вас есть вопросы, или вы просто хотите поделиться мнением о вышенаписанном, то я буду благодарен, если вы поделитесь обратной связью под публикацией или в личном сообщении. Иллюстрации и идейное содержание статьи при участии Ангелины Абдуллаевой angelina.abdullayeva.
