Сайт как бизнес

Поисковое продвижение сайтов (SEO), создание сайтов в Минске (Беларусь).

Канал «СТАРТАП ТЕХНОЛОГИИ»: об ИТ-бизнесе, стартапах, инвестициях

Подпишись на рассылку блога об интернет-бизнесе:

Экономим на разработке web сайта (Fixed price vs Time & Material)

пока нет комментариев

После прочтения бессмертного произведения об утопии все мы начинаем понимать что живем в неидеальном мире!

Зачастую работая с отечественными заказчиками мы сталкиваемся с одной и той же ситуацией, которая так или иначе касалась любого исполнителя:

- Здравствуйте, мы хотим сайт как 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 более выгодна обеим сторонам. Заказчик получает в итоге то, что он хочет, исполнитель получает прибыль от работы. Но такой подход требует больших усилий от обеих сторон, и наличие определенной материально-технической базы. Важным плюсом такого подхода является то, что он дисциплинирует обе стороны — заказчика и разработчика.



Автор: Валерий Хвалев.

8 декабря, 2009 в 9:04 пп

Подпишись на обновления блога по e-mail или RSS!

Оставить мнение