Фактически, можно сказать, что сегодня на рынке можно купить типовые сайты стоимость до 5 тысяч USD. Да, понятие "типовой" значительно расширено Битриксом. Можно купить сайты выше 10 тысяч USD и заметно выше, причем там вам никто не скажет, что Битрикс что-то не может и все сделают и поднимут любую нагрузку. А вот купить сайт от 5 до 10 тысяч довольно тяжело. (Цены на услуги приведены для Москвы. В других городах ценовая планка бывает до 3 тысяч и после 5 тысяч, например.)
Это парадокс, но это фактическое положение вещей на рынке. И описанная проблема - это не проблема партнерской сети Битрикса, а общая проблема рынка веб-разработок.
[spoiler]
С одной стороны, очень мало заказчиков в ценовой группе от 5 до 10 тысяч. Выделяемый бюджет редко превышает 5 тысяч или если уже превышает, то заметно и для больших проектов. По своему опыту знаю, что тяжелее всего продавать сайты по цене 6-8 тысяч и это подтверждают наши партнеры, которые переходили из группы до 5 в группу после 10.
Но вот в чем проблема? Тут уже есть несколько объяснений.
Причина №1 - борьба интересов
Сайты ценой выше 5 тысяч заказывают уже крупные клиенты и там исполнитель, т.е. партнер имеет дело не с собственником бизнеса, с которым относительно легко решать вопросы, а с сотрудниками, которые видят свою задачу в том, чтобы выжать из студии все, что возможно и поднять свой рейтинг в глазах начальства. Причем, зачастую, руководство понимает, что исполнителя нельзя выжимать в ноль, надо оставить доходность, иначе невыгодно долгосрочное сотрудничество, но исполнителям эта логика незнакома. Получается, что партнеры, которые не умеет работать с такими клиентами уйдут в глубокий минус и больше не полезут на этот рынок или задерут цену за риски выше 10 тысяч.
Причина №2 - бюджет
Видимо существует сегодня психологическая величина выделяемого бюджета в 5 тысяч USD. Ну не должен сайт стоить больше 5 тысяч, не важно даже, какое ТЗ мы собираемся реализовать. И крайне редко прикидывают, что даже если считать по 20$ час человека, то на 5 тысяч можно купить 250 часов работ. Что равняется примерно 1.5 месяцам работы одного человека. А если учесть, что управление проектом съедает порядка 40% времени, а хороший дизайнер, постановщик или программист уже стоит на рынке под 35-50$ в час, то получается совсем немного реальных работ. Зарплаты то выросли, как это не прискорбно констатировать, вслед за ценами на квартиры. Студии начинают нанимать фриланс, качество падает, возникают проблемы сопровождения. Одним словом, проблемы клиентов зачастую становятся проблемами всего рынка.
Причина №2 - туманное ТЗ
Реально, разработчики не могут оценить ТЗ клиента с большой точностью, особенно, если это проект большой. Почему? Да просто зачастую нет этого ТЗ или то, что называется ТЗ - это условность и попытка начать процесс, потому что сроки поджимают. Да, используя Битрикс, партнеры основательно страхуются. Даже если клиенту в голову придет супер идея, 95% уверенности, что в Битриксе уже есть ответ угрозе выхода бюджета в глубокий минус. НО! Что самое печальное, неясное ТЗ съедает все больше времени на управление проектом, его администрирование и бесконечные совещания с клиентом. А тут Битрикс не может помочь студии не уходить в минус.
Я думаю ситуация может измениться только в том случае, если клиенты научатся платить почасовую за программирование, дизайн и управление, как во всем мире. А разработчики научатся честно выставлять такие счета и не требовать больше того, что затрачено. Но пока прогресс в этом направлении слабый и виден только в проектах выше 25 тысяч и длительность больше 5 месяцев. Фактически, такие проекты переходят в процесс непрерывной разработки и заказчики выкупают объемы работы у студии, обеспечивая стабильные выплаты студии.
Да, кстати, большая проблема в переходе на почасовую оплату программистов и дизайнеров, это необходимость почасовой оплаты управленцев при ведении проекта
Если с мыслью о покупке фактических работ еще как-то клиенты могут смириться, то с необходимостью платить за обсуждения, встречи и поиск оптимальных решений пока не готовы. Но надеюсь, что лед сдвинется.
Те, кому нужны большие и успешные проекты уже идут в этом направлении.
Думаю, первыми моду эту покажут 1с-ники. У них собственно уже много подходов на почасовке. До моды осталось не так много.
Зачастую клиент не может обеспечить грамотным ТЗ, поэтому логичен выход - написание ТЗ осуществляется разработчиком на основе бизнес-требований заказчика. Для больших проектов (как и для средних, собственно) важным первоначальным этапом становится "определение проекта". Эта часть тоже оплачивается заказчиком. Результатом этого этапа получается "документ об образе и границах проекта" (Карл Вигерс "Разработка требований к ПО"), так же часто документ называют "креативный бриф"). Документ позволяет с достаточной степенью точности определить сложность проекта, его особенности и пр. Заказчик, в принципе, может воспользоваться этим документом для заказа разработки уже другой компании. Другому разработчику так же становится проще определить примерную стоимость разработки + уже известно что это за проект, какие у него цели/задачи и планируемые способы их достижения. Заказчик здесь уже экономит на встречах (которые, кстати тоже должны заноситься в бюджет) и совещаниях.
Лично я в последнее время прихожу именно к такой схеме работы. Стоимость первоначального этапа невелика, зато и заказчику и будущему потенциальному разработчику становится понятно, что это будет за проект, следовательно, риски по проекту могут быть сильно уменьшены.
Иногда получается создать ореол таинственности вокруг разработки и назначить сумму за разработку, которая в конце-концов выйдет долларов на 30 в час. Недавно взялись за проект, не обозначив границы проекта, договорились на сайт-визитку за $800 на версии Старт, но клиент начал вносить изменения ежедневно и мои затраты на зарплату сотрудников, занятых в проекте, превысили ожидаемую оплату в несколько раз. В данном случае почасовая оплата была бы кстати.
Заказчик, будь то владелец бизнеса или сотрудники проектного отдела, зачастую не совсем хорошо разбирается в тонкостях программирования, а соответственно оценить правильность выставленной цены не может.
Разработчики пользуясь этим могут назначить и 35, и 75, и 100 баксов в час по принципу: сколько скажем, столько и будет, все равно никуда не денется от нас.
При адекватном понимании всех сторон, проблемы с определением стоимости работ возникают не часто.
Почасовая оплата - это правильно и уже работает (как минимум в нашей компании). Но клиент должен заранее знать бюджет если не проекта, то хотя бы одного из немногих этапов проекта.
На почасовую оплату смотрят также косо, как и в 2007-м. Примерная оценка воспринимается как конечная и переговоры просто заканчиваются. Объяснения о том, что такая сумма нужна, чтобы проект точно завершился, не убеждают. Люди не умеют работать ни с фрилансерами, ни со студиями. Очень часто приходится сталкиваться с предложениями устроиться к заказчику на работу или хотя бы работать на их территории.