Заказчик не покупает спринты

Признание для начала: я сертифицированный скрам-практик. Проходил курсы ScrumTrek по Product Ownership и скрам-мастерству, годами вёл команды по всем канонам — спринты, стендапы, ретро, доска, горящие дедлайны в Jira. А до этого десять лет руководил проектами на другом полюсе — классический waterfall и ГОСТ 34 в атомной отрасли: техзадание толщиной с кирпич, стадии, приёмо-сдаточные испытания по протоколу. Так что дальше будет не ворчание человека, который «не разобрался» в одном из лагерей. Дальше будет наблюдение человека, который пожил в обоих — достаточно долго, чтобы перестать продавать заказчикам и то, и другое в чистом виде.

«Мы работаем по Agile» — что слышит заказчик

Подрядчик говорит: «Мы работаем спринтами, каждые две недели — демо, скоуп гибкий, оценка в стори-поинтах». Себя он слышит современным. А заказчик — собственник дистрибуторской компании, у которого теряются заказы, — слышит вот что: «Мы не скажем, когда будет готово. Не скажем, сколько это будет стоить в итоге. Что именно вы получите — тоже пока не скажем, скоуп же гибкий. Но каждые две недели мы будем показывать вам что-нибудь».

И знаете, что самое неприятное? Заказчик всё понял правильно. Это подрядчик не понял, что только что сказал.

Скрам придумали для другой ситуации: постоянная продуктовая команда внутри компании, с постоянным финансированием, которая делает продукт без конечной точки. Там это работает — я видел своими глазами. Но в отношениях «заказчик платит подрядчику за результат» скрам-словарь превращается в способ красиво не брать обязательств. Спринт — это единица усилий. А заказчик платит за единицы результата. Между этими двумя валютами нет обменного курса, и все разговоры про «velocity команды» — попытка убедить заказчика, что курс есть.

Демо каждые две недели, или Театр прогресса

Отдельно про «поставлять работающий продукт каждые две недели». В подрядной разработке это слишком часто превращается в «подделывать работающий продукт каждые две недели» — одна буква, а какая честная. За два часа до демо всё судорожно склеивается скотчем, данные захардкожены, кнопка ведёт на заглушку, «это мы потом отрефакторим». Демо прошло, заказчик покивал, скотч отклеился до следующего демо.

Заказчик, кстати, этот театр чувствует — не может сформулировать, но чувствует: ему две недели что-то показывали, а пользоваться по-прежнему нечем. Накопите три-четыре таких демо, и на пятом он спросит: «а что из этого уже работает?» — и это будет самый честный вопрос за весь проект.

Про канбан скажу мягче: это хороший инструмент для потока однотипных задач — поддержка, ретейнер, багфиксы. Там он у меня и живёт. Но канбан — это способ организовать очередь, а не обязательство. Показывать заказчику доску и называть это планом — всё равно что показывать желудок и называть это ужином.

Что заказчик покупает на самом деле

Три вещи, всегда одни и те же:

1. Результат, который можно потрогать. Не «мы продвинулись по бэклогу», а «заказы дилеров больше не теряются — вот реестр, вот цифра за неделю».
2. Дату и сумму. Не оценку в попугаях, а число в календаре и число в договоре.
3. Право остановиться. Возможность после любого куска сказать «достаточно» — и остаться с работающим куском, а не с половиной недостроенного моста.

Заметьте: ни один из трёх пунктов не противоречит здравому ядру гибких методов. Итерации — прекрасно. Короткие циклы — прекрасно. Ранний работающий продукт — вообще главное, что agile дал миру. Проблема не в итерациях, а в том, что подрядчики продают заказчику свою внутреннюю кухню вместо его результата. Как я это формулирую для себя: скрам — на кухне, этапы — в зале. Внутри я могу хоть стендапы с самим собой проводить. Но договор и разговор с заказчиком — на языке этапов с результатом, датой, ценой и выходом.

План, который понимает даже юрист

Годы проб привели меня к формату плана работ, который одинаково читают собственник, его бухгалтер, его юрист и я сам. Если присмотреться, это гибрид, взявший лучшее у обоих моих прошлых миров. У ГОСТ 34 и waterfall — то, за что их любят заказчики и суды: этапы, приёмку по критериям и ответственность, зафиксированную на бумаге. У agile — то, ради чего он затевался: короткие куски, каждый из которых заканчивается работающей вещью, а не томом документации, и право свернуть в сторону между кусками. Отброшено тоже с обеих сторон: от ГОСТа — кирпич техзадания, устаревающий до окончания согласования, от скрама — торговля усилиями вместо результата. План умещается в таблицу и прикладывается к договору. Правила такие:

Этап = результат, а не занятие. Название этапа отвечает на вопрос «что появится», а не «чем будем заниматься». Не «разработка интеграции» (занятие), а «заказы из почты автоматически попадают в учётную систему» (результат). Если название этапа нельзя проверить — это не этап, это процесс.

У каждого этапа — критерий приёмки в цифре или в действии. «Все заказы тестовой недели видны в реестре» — можно проверить за десять минут. «Система работает стабильно» — нельзя, и такие формулировки я в план не пускаю, они потом стоят отношений.

Каждый этап полезен сам по себе. Проект строится так, чтобы после любого этапа заказчик мог остановиться и остаться с работающей вещью. Это и есть честная версия «поставлять ценность каждую итерацию» — только без театра: не демо, а эксплуатация.

Точка выхода после каждого этапа — прописана в договоре. Звучит против моих интересов? Наоборот: право уйти — главная причина, по которой заказчику не страшно начать. За всё время эту дверь открывали единицы, но покупали проект — благодаря двери.

Изменения не «впихиваются», а становятся этапами. «А давайте ещё телеграм-уведомления» — отлично, это новый этап с результатом, сроком и ценой, встаёт в очередь. Скоуп-крип умирает не от жёсткости, а от прозрачности.

В плане написано, что нужно от заказчика. Половина сорванных сроков в подряде — это «ждали доступы три недели». Поэтому обязанности заказчика — доступы, тестовые данные, человек для вопросов — стоят в плане рядом с моими, с теми же сроками.

Честная оговорка: план — подзорная труба, а не фотография

Теперь правда, которую подрядчики говорить не любят, а зря. Такой план — не пророчество. Ближайший этап виден резко: результат, срок, цена — твёрдые. А каждый следующий виден чуть размытее, и каждый завершённый этап уточняет последующие. Сделали реестр заказов — и на живых данных выяснилось, что у трёх дилеров форматы, которых «у нас точно нет» (они были). Интеграция после этого станет либо проще, либо сложнее — но станет другой, чем виделась месяц назад.

Это не подрядчик плохой и не заказчик что-то скрыл. Это реальность, у которой свои правила: до соприкосновения с живым процессом любая оценка дальних этапов — прогноз. Поэтому закладывайте люфт на изменения — в сроках, в бюджете и, главное, в голове. Взрослый план отличается от наивного не отсутствием неопределённости, а тем, что она в нём написана: ближний этап — обязательство, дальние — оценка, которая подтверждается или корректируется после каждой приёмки. Подрядчик, который клянётся точной ценой этапа №5 до начала этапа №1, либо не понимает, что говорит, либо заложил такой запас, что вы уже переплатили.

И вторая часть той же правды — для заказчика. Да, я делал похожую функцию десять раз. Но «похожую» — не «эту»: у вас другие люди, другая учётная система, другие дилеры с их форматами. Иногда одиннадцатый раз честнее сделать иначе, чем предыдущие десять — потому что конкретно вашему бизнесу дешевле переделать функцию под свой процесс, чем годами платить за лишние интеграции или ломать работающий процесс под чужое ПО. Вы строите уникальный бизнес — в нём ваша маржа и ваше преимущество. Не забывайте за это платить: уникальность стоит денег ровно в тех местах, где она у вас есть. Экономить надо на другом — на типовом, и хороший план как раз показывает, где у вас что.

Шаблон такого плана с заполненным примером — в соседней заметке-приложении: берите и адаптируйте, он специально написан так, чтобы его можно было приложить к договору почти без правок.

А если коротко: не продавайте заказчику свой процесс. Продавайте его результат — а процесс оставьте себе, какой нравится. Хоть со стендапами.