В докладе c ноябрьской конференции Outsource people Егор описывает успешную практику: как компаниям вести проект FP (Fixed Price = проект с фиксированной стоимостью) и какие риски существуют при этом.
Риски проекта начинаются еще на pre-sale (препродажной) стадии. Далее в статье пойдет речь о модели стандартного FP проекта, когда клиент приходит к вам за определенным решением. Как правило это человек из бизнеса, у которого в большинстве случаев нет опыта в IT. Этот клиент не может сам даже примерно прикинуть бюджет. Например приходит заказчик с описание проекта на салфетке или с «Я хочу инстаграм» и запрашивает оценку проекта.
Часто заказчик ставит агрессивные сроки и запрашивает оценку по времени и стоимости у многих компаний. На этапе первого проекта клиент обычно о вас ничего не знает и стремится свести риски со своей стороны к нулю. В то же время, если клиент уже работал с вами, то его проще перевести на Time&Material (почасовую оплату), тем самым решив все проблемы.
Егор Цынкевич имеет 11 лет опыта в IT, начинал как разработчик в области информационной безопасности, что помогает в pre-sale стадии. Развивает бизнес польской компании уже 2 года.
О компании Polontech LLC: Atlassian эксперты, большой опыт в ITIL консультации, в описании бизнес-процессов, помогают другим компаниям в оптимизации.
Самый главная проблема — недобросовестные конкуренты. И обычно это не какие-то плохие люди или бандиты. Это может быть любая молодая компания, в которой 5 разработчиков или просто плохо настроены бизнес-процессы. Они не умеют оценивать. Возможно, это второй или третий проект, который они вообще в жизни пытаются сделать. Они смотрят — какой-то мобильный проект. Прикидывают: «10 тысяч евро нам хватит?» Подумали — хватит. И вперед — делать.
На pre-sale стадии возникает конфликт интересов компании разработчика и интересов заказчика. Заказчик приходит к вам, чтобы вы решили его проблему. А вы со своей стороны начинаете проводить начальный бизнес-анализ. Можно условно сказать, что вы «создаете еще больше проблем». Вы даже можете тем самым его потерять уже на этом этапе, потому что конкуренты могут не задавать всех этих вопросов и сказать: «да 10 тысяч, все в порядке, мы вам сделаем». На самом деле правильно считается, что заказчику нужно задавать вопросы, чтобы понять его бизнес-цель. Соответственно недобросовестные конкуренты, не называя необоснованно низкие pre-sale стадии цены перетягивают на себя проект, но при этом получают в придачу массу рисков. Чтобы не оказаться в роли таких конкурентов следует эти риски осознавать.
Рассмотрим разные варианты развития ситуации. Предположим, вы назвали цену, которая устроила клиента. Далее вы провели pre-sale стадию, но вы ошиблись в эстимейте или у вас плохо настроены процессы разработки. Далее происходящее пойдет по одному из двух путей. Первый вариант lose-win (проигрыш одной стороной, выигрыш другой): заказчик «прогибает» вас по уже оговоренным требованиям и срокам. Вы продолжаете разработку уже в 10 раз превысив предварительную оценку. Заказчик отчасти выигрывает по финансам теряя в сроках, если компания не решила проблему, подключив дополнительных программистов. Но проигрывает сама компания превратив проект в глубоко убыточный.
Другой плохой вариант — win-lose. Вы выполнили функциональные требования заказчика и успели все сделать в срок. Но в таком виде приложение часто не готово выйти на рынок. Все дополнительные доработки вы предлагаете доплачивать отдельно. Тогда заказчик задумается: за разработку заплатил и рассчитывал с помощью ПО достичь определенного результата. Но в итоге нет ни успешного продукта ни денег.
Lose-lose – это крайний вариант. В этом случае команда заваливает проект и перестает выходить на связь, поняв, что дальше продолжать убыточный проект просто невозможно. Заказчик теряет и деньги и время.
Далее мы обсудим философию win-win. При ней даже в случае проблем по проекту, заказчик и сторона компании все равно выигрывают. Но для такой работы необходима особая философия. Рассмотрим варианты, когда вообще стоит браться за FP проекты.
1. Необходимо быть избирательным в проектах. Большая ошибка молодых команд, когда они пытаются браться за все подряд. Предположим у них была экспертиза в похожем проекте и они готовы назвать эстимейты. При этом они не берут во внимание, что заказчик может быть не похожим.
Буквально в сентябре у компании Егора был шанс получить проект FP с большим бюджетом у очень крупной корпорации. Но компания за него не взялась. Им было известно, что эта корпорация любит продавливать компании поменьше на существенное количество доработок бесплатно. Они либо принимают проекты по два года, либо стараются не заплатить, либо стараются вывести проект на штрафы. Возможно даже, что заплатят, но в процессе работы исполнители испытают море неприятностей.
Егор справедливо считает, что в процессе должны выигрывать обе стороны — и заказчик и компания. Убыточно вести бизнес только с позиции сиюмитной выгоды.
2. Необходимость в понятных функциональных требованиях очевидна. Браться за проект, где непонятно, что надо сделать и еще на фиксированной оплате – верх беспечности.
3. Должна быть экспертиза в похожих решениях и технологиях. Понятно, что брать проект на FP игнорируя «не зная броду – не лезь в воду» — может выйти боком.
Определимся, о каком именно FP проекте идет речь. Мы рассматриваем некорпоративное решение, так как с корпорациями немного другой подход. Там если вы боретесь за какой-то серьезный многочасовой проект, то либо вы либо продаете часы бизнес-аналитиков, либо инвестируете в бизнес-анализ со своей стороны, что потом включается в вашу маржу.
У Егора был опыт работы с корпорациями в следующем стиле: корпорация передает вам задачу. С их стороны даже есть PM, но они просто ждут окончания срока проекта. На письма они отвечают, но особо не вникают в происходящее. Но тажке встречается и более распространённый вид заказчика, который всегда лезет и пытается понять, что происходит, активно участвуя в разработке.
В данном случае рассматриваем варианты, когда: заказчик плохо разбирается в IT; общие эстимейты не превышают, предположим 2 000 часов; заказчик готов активно участвовать в проекте и вникать в детали используемых технологий.
Чего стоят опасаться так это агрессивных дедлайнов. Обычно все люди бизнеса пытаются вас «прогнуть» аргументами типа: «Что здесь делать? У google вообще одна страница, давайте сделаем аналог уже на следующей неделе». Эти люди привыкли вести переговоры и необходимо быть аккуратными, никогда не соглашаясь на те жесткие дедлайны, которые предлагает заказчик.
Теперь собственно о том, как работа с FP проектами происходит в Polontech,
Егор предлагает поделиться своим опытом. Polontech продает fixed price проекты используя подход SCRUM. Клиенту сообщается, что данные требования, которые он предоставил, в принципе понятны и есть возможность сделать грубые эстимейты. Но, для оценки и минимизации рисков со стороны исполнителя, ему предлагается делать этот проект по спринтам.
Теперь главный вопрос, как добиться согласия заказчика на такой подход. Когда он приходит со своим описание проекта, команда Егора не начинает пинг-понг, как обычно делают неопытные sales задавая множество уточняющих вопросов, на прояснение которых у заказчика может уйти до двух месяцев. В итоге предпродажный период затягивается и компания уже инвестирует в клиента, рискуя ничего не получить.
Вместо этого Polontech предлагает заказчику написать userstory (короткое описание алгоритма конкретного использования продукта конечным пользователем), чтобы понять как этим продуктом будут пользоваться. Заказчика не просят писать сложные ТЗ, а вместо этого предлагают 10 «историй» использования проекта. На опыте Егора 10 историй никто не написал. Как правило дело ограничивается пятью историями. На последних заказчик и сам начинает понимать, и ему можно объяснить: «Посмотрите, вы еще сами не до конца понимаете этот проект, но так как мы понимаем, что у вас есть задачи бизнеса, мы готовы подключиться. Давайте запишем эти конкретные 3-4-5 user-story в спринты, которые обойдутся в N часов». Таким образом заказчик понимает чего ему ожидать за потраченный бюджет в формулировке определенной функциональности.
Далее подписывается контракт, в котором заказчик обязуется оплатить на функционал «юзер-стори» эквивалент 1000 часов. Таким образом исполнитель прикрывает свою сторону и может быть уверен, что за этот проект получит эквивалент минимум 1000 часов. Условно можно сказать, что получается скрытый TM. Предоплатой за проект 50-60%, остальное по сдаче проекта. Деальное планирование задач идет обычно на две недели. Для начала все задачи заносятся в product backlog.
Без определенных правил ведения такого проекта не обойтись.
В Polontech внедрили следующие правила:
1. Заказчик обязуется участвовать в ходе разработки. Они обычно на это соглашаются с радостью
2. Не начинать спринт, пока не утвержден детальный функционал. Предварительно были описаны юзер-стори. После этого необходимо согласовать детали с заказчиком. У вас есть гарантированное количество часов, плюс ко всему на этапе согласования контракта заказчику надо дать понять, что весь дополнительный функционал, который не будет входить в юзерстори будет расцениваться как change request. И пока заказчик не скажет, что вот эти кнопки на две недели вперед утверждены – спринт не начинается. Это замечательно тем, что заказчик довольно быстро договаривается с вами о конечном виде своего продукта. Он участвует в этом процессе и видит, что без его вклада ничего не начнется. И поэтому соглашается с предложениями довольно быстро.
3. Если детализированный функционал включает в себя доработки и функционал, не оговоренный в первоначальных требованиях, клиент должен согласиться на change requests
4. Не начинать новый спринт, пока не сдали текущий. Мы получаем FP проект, но в то же время заказчик участвует и он понимает, что пока текущий этап не примет, дальше разработка не продолжается.
5. Одно совещание с клиентом в неделю для обсуждения прогресса и для обсуждения следующих спринтов. Общение с клиентом критично, так как он должен быть постоянно в курсе происходящего. Соответственно он наблюдает, как и что происходит и у него не накапливается негатив. Собственно, если для решения какой-то задачи необходимо уточнение у заказчика, то это должно быть сделано в течение трех дней. Это обязательное правило для PM Polontech, так как случались ситуации, при которых на новых спринтах заказчик спрашивал «Почему мы не включили в спринт мой новый функционал». А виноват был PM, который не уточнял у заказчика.
6. Задержка дедлайна по спринту по вине клиента ведет к автоматическому сдвигу сроков проекта и штрафы за простой команды, если это необходимо.
Надеемся, что эта статья и доклад окажутся для вас полезными. А Fixed Price проекты будут развивать бизнес отношения с заказчиками и будут прибыльными для вашей компании.
Дополнительно:
9-15 июня Мы запускаем онлайн конференцию Online Outsource People 2014 со спикерами из Boeing, TATA, TicketMaster и российских, украинских и белорусских компаний. Всего 36 докладов в формате вебинаров. Темы конференции: бизнес, маркетинг и продажи в разработке на заказ.
Автор: outsourcepeople
