При работе с госзаказчиком или крупными коммерческими организациями с государственным участием часто наблюдается гадкая проблема: они обязаны размещать свои заказы и принимать их результаты в рамках строго определённых процедур. Добавим к этому вторую проблему: конечные пользователи в крупных организациях, как правило, очень занятые люди, и доступ исполнителя к ним весьма ограничен. Как построить agile-процесс в таких условиях?
На деле да, agile можно применять в fix-price. Одно из решений недавно было предложено ldmitry в статье «Agile с фиксированной стоимостью — это реально».
Мы воспользовались другим, более «классическим» способом: абстракцией. Поскольку заказчик в нашем случае является слабым звеном, применим абстракцию в отношении именно заказчика. Для этого мы должны ввести в проект очень аккуратного и грамотного специалиста, умеющего работать как с требованиями заказчика, так и с техническими вопросами. У нас этим занимается системный архитектор, контролирующий концепцию проекта и потому по роду деятельности чаще занимающий внутри проекта сторону заказчика, чем сторону команды проекта. Именно этот человек будет работать с заказчиком в рамках внешней fix-price-оболочки проекта и являться product owner-ом для внутреннего процесса. Заказчик абстрагируется от внутренних процессов исполнителя, но его видение результата проекта всегда совпадает с видением исполнителя.
Допустим, есть классический случай: тендер на выполнение некоторой информационной системы для госзаказчика. По природе это — fix-price. Доступ к конечным пользователям весьма ограничен, бюджет и сроки фиксированы.
По согласованию с заказчиком проект делится на несколько этапов. Как правило, первый этап — разработка технического задания (требования + техническое решение). Второй этап можно отвести на необходимую исследовательскую работу. Далее несколько последовательных этапов поставки продукта, вплоть до финального релиза. Каждый этап длительностью 4-6 недель (классический спринт). Штука в том, чтобы основные неопределённости снять на первых этапах проекта, а на последних решать вопросы реализации, которые не требуют большого участия заказчика.
Перед участием в тендере необходимо обязательно провести анализ будущего проекта на реализуемость. И не ввязываться в авантюру, если нет достаточных резервов.
Итак, предположим, что тендер мы выиграли. Заказчик к нам не особо лоялен, но обязан рассказать, что он хочет получить в итоге. Поэтому на первом этапе основная нагрузка ложится на аналитиков и архитекторов. Но чаще всего и программистам находится работа: например, как только становится известными форматы экспортируемых или импортируемых данных и протоколы связи с внешними системами, имеет смысл создать эмуляторы этих систем; как только становится понятными основные макеты форм UI, можно начать подбор стороннего фреймворка или начать создание своих компонентов.
Список задач, связанный с анализом и разработкой технического решения понятен и, как правило, интересен для заказчика. Ему могут открыться совершенно неожиданные возможности. И, как правило, совместная работа быстро создаёт единое видение будущего продукта и способствует росту доверия между заказчиком и исполнителем.
Таким образом, никаких существенных препятствий для применения agile на первом этапе работ нет. Есть только одна вещь, на которую руководству проекта нужно обратить внимание: сроки и бюджет этапа должны быть строго ограничены, а шаги, которые должны предприниматься при выходе этапа за эти ограничения, должны быть проработаны заранее немедленно применяться, если какой-либо предел будет нарушен. Таким образом, создаётся некоторое пространство внутри проекта с ограниченным бюджетом, внутри которого можно достаточно свободно применять гибкую методологию. Product owner-ом для такого agile становится не представитель заказчика, а руководитель проекта или системный архитектор, контролирующий выполнение общей концепции проекта.
Итогом первого этапа является единая концепция проекта, которая понятна и заказчику, и исполнителю. Проект имеет чёткую цель и сформулированные задачи верхнего уровня, которые позволяют эту цель достичь. Если этого результата нет, то вряд ли стоит продолжать работы.
Вторым результатом первого этапа становится некоторый список проблем, которые таят в себе более 90% оставшейся неопределённости. Чаще всего такие проблемы имеют технологическую основу. Можно ли за 2 минуты выполнить перерасчёт модели из двух миллионов сущностей с десятком параметров в каждой? Пока не попробую, не узнаю. Нужно проводить исследование. Устранение таких вопросов — цель второго этапа.
На втором этапе заказчику тоже интересно участвовать. Но он редко может себе позволить прежний график постоянной вовлечённости. Поэтому мы показываем ему только результаты работ за неделю на примере некоторого прототипа. Плюса два: заказчик видит, что алгоритм работает успешно, но при этом видит, что проект ещё не обрёл нужного воплощения. Доверие заказчика к исполнителю растёт, а понимание концепции остаётся единым и постоянно уточняется. Мой опыт показывает, что при возникновении сложных проблем даже технического характера заказчик может подсказать решение: «Не получается быстро распарсить большой набор данных? Нет проблем, попросим разработчиков другой системы чуть изменить формат данных!»
Agile прекрасно работает, хотя сам заказчик об этом не знает. Но руководство проекта по-прежнему контролирует «контейнер», в котором живёт agile в рамках основного fix-price-процесса, не давая гибкости процесса захватить слишком много бюджета, времени и ресурсов.
Этапы поставки проходят в том же ключе. Заказчику показываются результаты работы. К сожалению, часто заказчик не может уделять прежнее внимание проекту. Тогда демонстрация проводится только раз в 4-6 недель в конце спринта (для заказчика это оговоренная в самом начале поставка по результатам этапа). Product owner тем не менее еженедельно пристально смотрит демонстрации команды, контролируя соответствие решений принятой концепции. Поскольку основная масса неопределённости была снята на ранних этапах, то тут неожиданные существенные изменения требований случаются редко. И даже когда они случаются, можно показать заказчику условия договора и сказать «fix-price!» Нет в договоре и согласованном техническом решении такого требования. И начинается некоторый торг, в результате которого как раз используется привычный принцип «если что-то добавляется, то что-то удаляется». Ведь заказчик не знает, что мы гибкие!
По завершению проекта все довольны: заказчик уже давно свыкся с тем, что некоторые функции пришлось отложить на будущее развитие проекта (и я даже догадываюсь, кто их будет делать!), а исполнитель вовремя сдал вполне качественный продукт.
Вот так может жить agile в рамках fix-price.
Мы применяли такой подход при разработки системы планирования для Единой энергосистемы России. При подготовке к тендеру мы провели анализ реализуемости и подготовили предварительное решение. С этим решением мы выиграли тендер. Проект стартовал. Мы согласовали с заказчиком несколько этапов поставки. Я, как системный архитектор и автор концепции, занял позицию «прослойки» между разработчиками и заказчиком. Моей задачей было защитить процесс от влияния заказчика, а нашу общую согласованную концепцию — от разрушения разработчиками. Во внутреннем scrum-е я занял позицию владельца проекта, а тимлид — позицию scrum-мастера. Вместе с руководителем проекта мы ввели ограничения на каждый этап и предусмотрели, как нам реагировать на нарушения этих ограничений.
На первом этапе мы создали «техническое задание» — спецификацию требований и описанием технических решений. Это позволило достичь общего видения будущей системы и проявило некоторые технологические моменты, которые нужно было изучить. При этом разработчики заложили основной каркас системы и начали обкатку взаимодействия с внешними системами.
На втором этапе мы сделали всю исследовательскую работу. В итоге мы показали прототип, который выполнял главный бизнес-процесс системы с заданными параметрами качества. На этом этапе все основные неопределённости были сняты.
Именно на втором этапе мы едва не нарушили ограничения по времени, выделенному на этап. У нас сложно продвигалась работа с динамической генерацией исполняемого кода. Нужно было, чтобы пользователи могли сами писать процедуры коррекции данных, которые на лету должны были подхватывать наши расчётные сервера. Сторонние решения один за другим оказывались неприменимыми по разным причинам. Из трёх оставшихся после предварительной апробации решений ни одно нас полностью не устраивало. Поскольку время и бюджет, отведённые на этот этап, поджимали, была задействована процедура «аварийного» принятия решения: ведущие специалисты и руководство собрались и после краткого обсуждения просто ткнули пальцем в одно из решений. Впоследствии недостатки этого решения нам пришлось компенсировать реализацией своего дополнительного кода. Но такое решение вопроса сняло неопределённость и освободило нас от необходимости дальнейшей плотной работы с заказчиком, а, главное, сохранило проект в приемлемых рамках.
Далее мы сделали ещё две промежуточные поставки. Самой сложной была финальная поставка, когда полностью работающую систему нужно было внедрить в «боевую» инфраструктуру заказчика. Тут снова в проект включились технические специалисты заказчика, вместе с которыми мы настроили решение и провели заключительную оптимизацию по результатам измерения количественных метрик.
Таким образом, нам удалось отделить наш процесс разработки от внешних ограничений. На текущий момент система уже год находится в промышленной эксплуатации. И мы недавно выиграли тендер на дальнейшее её развитие.
Краткое резюме:
- Имеем основной процесс разработки, классический «водопад», соответствующий природе проекта, но с относительно большим количеством промежуточных этапов поставки по 4-6 недель каждый. Для каждого этапа установлены жёсткие ограничения по срокам, бюджету и ресурсам и заранее предусмотрены действия при нарушении указанных ограничений.
- Внутри основного процесса создаём вложенный процесс, который использует agile. Product owner — не представитель заказчика, а архитектор, контролирующий общую концепцию проекта. Scrum master не должен быть архитектором, контролирующим общую концепцию проекта. Работа команды ведётся, как в типовом scrum-е. Тот же product backlog, те же sprint backlogs. Спринт совпадает с этапом поставки и составляет 4-6 недель.
- Для заказчика сохраняется приемлемая для него работа по схеме fix-price.
- Для исполнителей обеспечивается использование гибкой методологии, но с жёстким контролем концепции и заранее продуманными ограничениями на каждый спринт.
Автор: max-kuznetsov
