Зачастую работая с отечественными заказчиками мы сталкиваемся с одной и той же ситуацией, которая так или иначе касалась любого исполнителя:
- Здравствуйте, мы хотим сайт как http://www.xxxxx.web (показывают мега-портал с неизвестным функционалом). Сколько будет стоить ?
Любой человек, будучи в душе хоть немного с "коммерческой жилкой" сразу начинает соображать что нельзя упустить шанс заработать, и начинает называть цену откровенно говоря наугад. Причем заведомо называют заниженную цену, чтобы не упустить заказчика, не задумываясь о том, что будет дальше.
Почему мы повторяем одну и ту же ошибку, и как научиться правильно определять цену подобного проекта? Ответ на вопрос вроде бы очевиден - глубже изучить сайт, оценить объем предстоящей работы, добавить риски, затраты на кофе и валерьянку, и назвать заказчику сумму. Но, опять же, возникает дилема - назвать большую сумму = потерять заказчика и отдать проект конкурентам (они назовут меньше сумму), студентам (они пообещают сделать за еду). Или же слукавить, занизив сумму, а потом выбивать дополнительные деньги, аргументируя "подводными камнями" и шантажируя отказом от проекта… В любом случае мы применяем подход Fixed Price (Фиксированная цена за продукт под ключ), что не является правильным при данной задаче.
На Западе очень распространен подход Time&Material (Время и материалы), причем он широко распространен не только в области разработки но и в других отраслях, где требуются значительные средства и усилия архитектора, менеджера проекта, маркетолога. Нашему заказчику пока такой подход ассоциируется с игрой в наперстки на вокзале - т.е. ему может казаться, что в итоге все, кроме него, останутся в выигрыше.
Но давайте взглянем с другого ракурса на данный подход: заказчик платит за реальную работу, т.е. за время, потраченное проектной командой на работу над проектом. Если заказчику нужна "ссылочка на календарик", то нет проблем, но если в процессе разработки выяснится, что календарик должен быть не простой, а китайский (что заказчик явно упустил из виду, когда писались требования к проекту), то это совсем другое дело. Сделать, опять-таки, не проблема, но кто оплатит дополнительные работы, возникшие по причине рассеянности, а может быть и безответственности заказчика.
Вроде проблема мелочевая, но давайте подумаем кто за нее заплатит в итоге:
- при Fixed Price проекте эта работа явно была включена в "риски". Если бюджет рисков уже исчерпан - исполнитель резюмирует "невозможно выполнить". В лучшем случае заказчик проекта обвинит исполнителя в шарлотанстве… в худшем начнутся судебные тяжбы.
- при T&M - исполнитель найдет все возможные пути решения проблемы, т.к. он заинтересован в продаже своих программистов, т.к. в разнице между куплей его на рынке и продажей на проект лежит и его хлеб.
Очевидно приемущество на T&M-стороне. 1:0 в пользу T&M
Рассмотрим еще один классический сценарий, с которого и начался этот пост. Объем проекта не ясен ни заказчику, ни тем более исполнителю.
- при Fixed Price подходе вероятность получить провальный проект в виду того, что заложеный бюджет слишком мал для проекта - 50%. Остальные 50% - это то, что заказчик переплатит за проект.
- при T&M подходе - комманда работает ровно столько сколько платит заказчик. Хочет новую "фичу" - оплати по счету. Тут нет переплат и минимальны риски провала проекта, т.к. менеджер проетка сделает все возможное, чтобы получить еще одну копеечку и утилизировать команду.
2:0 в пользу T&M
Теперь немного о внедрении самого подхода T&M. В первую очередь компания должна быть готова к работе, т.е. должна быть система, в которой менеджер проекта ставит задачи в проект, оценивает время выполнения, а разработчики по факту выполнения задачи отчитываются за потраченное время. В эту систему должен иметь доступ и заказчик, чтобы он мог контралировать задачи, а не задавать вопросы по факту выставления счета - "Откуда такая суммаа? o_O"
Далее всегда должен быть менеджер проекта со стороны заказчика (onsite) и со стороны исполнителя (offsite), который контролирует задачи и рабочие вопросы по ходу проекта. Хорошим тоном исполнителя будет так же выставлять в счет работу менеджера проекта.
Резюме:
Работа с подходом T&M более выгодна обеим сторонам. Заказчик получает в итоге то, что он хочет, исполнитель получает прибыль от работы. Но такой подход требует больших усилий от обеих сторон, и наличие определенной материально-технической базы. Важным плюсом такого подхода является то, что он дисциплинирует обе стороны - заказчика и разработчика.