Agile – для fixed bid?

Вообще я яростный противник fixed bid-проектов. Fixed bid-проект обычно оставляет и у Заказчика, и у Исполнителя чувство обоюдного проигрыша – Заказчик недополучил функционал, Исполнитель недополучил прибыль (если очень упрощенно). Для того, чтобы этого не произошло, требуется несколько заходов танцев с бубном – во-первых, нужно вдумчиво поработать над концепцией и ТЗ, используя дорогостоящего аналитика и отвлекая (тоже недешевых) ключевых специалистов Заказчика для сессий JAD; во-вторых, нужно установить процесс управления изменениями; и в-третьих, даже при всем при этом чтобы корректно посчитать этот самый fixed bid нужно иметь историю работы команды или релевантную статистику по организации – чтобы перевести полученный юзкейсы и вайрфрэймы в часы работы и календарные дни длительности (из чего и складывается в конечном итоге цена). Ну и в добавок требуется увязать это все в контракте, создав доброжелательную обставновку вооруженного перемирия и взаимного недоверия. Но проект сделать можно. Следствием такого проекта (при условии того, что оговоренный в контракте процесс не похерят в процессе работы) с весьма большой долей вероятности будет адекватная качественная система.

Так в чем проблема? Дык собственно проблемы никакой нет – при использовании подхода, указанного выше. Но давайте посмотрим – так ли на самом деле устроен изнутри типичный fixed bid-проект, в котором многи узнают проект, на котором они сейчас работают.

Заказчик прибегает и говорит – “хочу вот CRM! Сколько будет стоить?” Исполнитель отвечает – “ну это вообще сильно зависит… Что CRM должен уметь? Какие фичи нужны?” Заказчик пучит на него глаза – “Как что уметь? Натурально – управлять отношениями с клиентами! Так сколько?” Исполнитель тяжело вздыхает и начинает объяснять очевидные вещи: проектный треугольник, да риски, да план… Заказчик говорит – “Нет, ты не понял. Я тебя про проектный треугольник не спрашивал. Я спросил сколько стоит?” Исполнитель говорит “Ну давай хоть ТЗ прикинем! Мы форсированно разработаем, за пару недель!” Заказчик – “Что?!! Пару недель?!! И еще платить за Аналитика?!! Персоны-шмерсоны, проектирование интерфейса?!! И на выходе ничего кроме бумаги?!!.. Никогда!” Исполнитель хватается за голову – “Да идите вы к черту, не будем мы с вами работать!..” Заказчик отвечает “да никуда вы не денетесь, я с вашим главным водку пил, он мне обещал, мы с ним друзья детства, и вообще – вам не нужен референс одной из крупнейших компаний в отрасли? Да тут очередь желающих работать чисто за референс!..” Исполнитель крякает и говорит – “Ладно, давайте хоть в контракт включим  про управление изменениями!” Заказчик делает невинные глаза – “Извините, у нас стандартная формая контракта, и изменения формы контракта не предусмотрены! Да и вообще – зачем хорошим людям контракт, правильно? Главное ведь – доверие! Вот тут подпишите пожалуйста, на листе с перечислением санкций…” Неизбывная тоска застывает в глазах Исполнителя, ибо он все это уже видел – дальше мы будем делать сферического коня в вакууме в высосанные из пальца сроки за половину денег…

Короче говоря – по факту традиционный подход “фиксированный “функционал = фиксированные деньги” не прошел. То, что вас ждет – deathmarch-проект, забег на время на петляющую дистанцию неизвестной длины. Нормальный человек говорит “спасибо, развлекайтесь сами.” А мы зачем-то беремся участвовать. Что делаем дальше? Мы садимся и думаем – “вот же … *censored*!!!” Нет, не так 🙂 Мы садимся и думаем: “что я могу сделать для того, чтобы бежать как можно быстрее, и по возможности меньше петлять?”. Идеи приходят сами собой:

  1. Все формальности – к едрене фене! Поскольку мы отказались от них на уровне контракта – выкинем их и из жизни. Можешь сказать вместо того чтоб писать меморандум – скажи. Документ не входит в условия поставки? В топку! Ну и так далее.
  2. Если уж предстоит сделать много – давайте хоть не переделывать! Для этого надо с первого раза попадать в цель – делать функционал так, как его хочет видеть Заказчик. И укорачивать обратную связь.
  3. Чаще будем делать билды! И ставить их на продакшн. Чтоб была так сказать приемка самим фактом установки и использования.
  4. Давайте экономить на багах! А давайте. Для этого тестирование должно происходить раньше.
  5. Нет ТЗ – будем выспрашивать у Заказчика! Правильная мысль. Неплохо бы тогда чтоб он сидел онсайт или по крайней мере был доступен в любое время.
  6. Юнит-тесты помогут нам отлавливать ошибки в изменившейся бизнес-логике! С этим друдно спорить. хUnit в руки – и вперед!

Даже из этого уже торчат уши agile. Хотите иметь шансы сделать этот проект? Выберите одну из agile-методик. Пишу русским по белому и еще выделяю красным – иметь шансы. Не более того. То есть у вас по прежнему хорошая вероятность завалить проект. Но появились шансы. Большие или меньшие. А даже один шанс из шести – уже не такая маленькая вероятность, чтоб она не могла случиться.

Tags: ,

Post Author

This post was written by who has written 29 posts on Agile.by.

  • Konstantin Razumovsky

    >>5.Нет ТЗ – будем выспрашивать у Заказчика!

    Денис, а был реальный опыт разработки CRM-системы без ТЗ? Если да, то на основании чего тестировали ваши QA, и как проводил приемку заказчик, если не секрет?..

  • Денис Петелин

    Да, делали одну такую.
    Делали от сценария бизнес-процесса, по шагам.
    Метод изготовления – аджайл в чистом виде:

    * определили таймбоксы для каждого шага (release planning)
    * много рисовали вариантов на бумаге, чтобы понять, как лучше сделать следующий шаг
    * тестеры это все попутно описывали в сценарии, подбирали тестовые данные, указывали на дырки
    * потом на этих же сценариях и проверяли

    В общем получилось недурно.

  • http://yuri.shilyaev.com Yuri Shilyaev

    Я сторонник того, чтобы в случае фиксированных отношений разбивать проект на мелкие fixed bid проекты. Проект, который очевидно на 6ть месяцев делить на 3 двухмесячные. Либо же делать первый проект фиксед, а потом предлагать переход на итерационный подход.
    Но в целом фиксед прайс не исключает итерационный подход. Да, делает сложным, не всем заказчикам может быть понятен… Но в любой fixed bid проект надо перетягивать средства снижения рисков из agile.

  • Денис Петелин

    Я тоже сторонник чтобы разбивать.
    Но есть камрады, которые работают в отраслях где разбивать запрещено – госзаказ, например.
    За последнее время видел несколько примеров – сначала дается эстимэйт на коня в вакууме, подписывается контракт, делает продукт – и ТОЛЬКО ПОТОМ, по факту реализации, пишется ТЗ и ТРП.
    И разговоры про то, что это неправильно, делу не помогают 🙂

  • http://alovak.com Павел Габриель

    Для гос заказа мы писали ТЗ на … 3 страницы и проект длился 6 месяцев. Бюджет был фиксированным и вобще ни от чего не зависел %-) Заказчик четко понимал, что хочет видеть, а мы ему часто показывали то, что мы делали. В итоге результатом были все удовлетворены.