Майк Монтейро в книге «Дизайн — это работа» пишет: «Есть формулы, которые якобы помогают определить цену проекта. Они предлагают сложить свои расходы, арендную плату, коммунальные услуги и прочее, а затем добавить сумму желаемой прибыли. Проблема большинства этих формул в том, что они рассчитывают, как едва прикрыть свою задницу».

Есть 2 способа решить вашу задачу: либеральный и радикальный.

Либеральный способ направлен на снижение возможных рисков: внедрите этап проектирования, результатом которого станет составление подробного технического задания (для вас) и прототипов с пояснениями, как что работает (для клиента). Договоритесь о взносе страховой части и о расчете окончательной суммы по факту (помогут CRM учета рабочего времени).

Радикальный способ: перейдите к гибкой модели разработки, при которой проект поделен на итерации, по каждой из которой четко зафиксированы временной интервал и стоимость . Fix time fix money flex scope.

Если говорить о высоком ценовом сегменте, то проекты должны оцениваться экспертами, неоднократно решавшими такие задачи, индивидуально. В небольшой компании это, скорее всего, основатель бизнеса. Эксперт способен увидеть «подводные камни» и правильно спрогнозировать время выполнения задач (с адекватным запасом часов).В идеале, оценок должно быть несколько, чтобы мнения разных экспертов свести к «общему знаменателю».

Проекты в нижнем ценовом сегменте нельзя оценивать индивидуально, иначе можно потонуть в бесконечной череде безрезультативных мнений. Действуйте иначе: — заранее подготовьте необходимый функционал; — составьте подробное стандартное ТЗ и назначьте фиксированную цену за проект, включающую минимальный объем доработок типового функционала; — организуйте процесс работы с клиентом так, чтобы существенная часть его желаний либо удовлетворялась предусмотренным функционалом системы, либо корректно отклонялась. Тестирование и управление проектом обязательно закладываются в цену.

Проблему стоит искать не столько в расчете необходимых часов для разработки, а в самом бизнес-планировании деятельности. Отличный материал на эту тему уже есть на портале http://www.cmsmagazine.ru/library/items/management/skolko-stoit-chas-raboty-programmista/, поэтому перейдем к ответам:

1. Проекты можно условно разбить на несколько групп: простые, средней сложности и сложные (эксклюзивные). Строим матрицу — визитки, лендинги, каталоги, магазины, а на пересечении — стоимость часа разработки. Первоначальное создание матрицы займет некоторое время, но дальнейшая оценка будет более простой и наглядной. 
    
2. Отклонения в расчетах возможны, но это заранее оговаривается в контракте. Наценки возможны за срочность (задействовано больше разработчиков, работа в выходные дни). 
    
3. Время на тесты закладывается изначально при разработке, заказчик получает готовый продукт (и да, он может протестировать его функционал дополнительно и указать на несоответствие ТЗ, что потребует доработок). 
    
4. Старайтесь разбить каждый проект на несколько этапов. Это позволит быстро выявлять слабые места и контролировать ход процессов. Помните — у любого задания есть ответственный и дедлайн, и чем раньше менеджер проекта заметит проблему, тем лучше.

Предварительный расчёт [времени на сайт] основывается на опыте создания «похожего» и субъективной оценке факторов, способных изменить время «по опыту». Рекомендую учитывать следующие факторы:

• Насколько чётко поставлена задача? Если есть пробелы, не определены ожидания/требования/критерии оценки, заказчик говорит «сделайте сайт, вы же профи», прибавьте 30% к времени «по опыту». На деле изменение задачи может повлечь гораздо более серьёзные изменения, поэтому старайтесь уточнить требования. 
   
• Качества разработчика: способен ли решать сложные задачи, перестраиваться, работать под давлением. Если есть слабые места, риск проблем и увеличения срока, весьма существенный. Прибавьте ~30%.

Первый пункт — больше ответственность заказчика, и за это можно смело брать деньги, а второй пункт — на ваше усмотрение.

Тестирование входит в оплаченные часы, конечно: это работа, которую должен выполнить специалист, чтобы сайт работал.

Срок реализации проекта по нашему опыту — 200-400% от чистых часов.

При расчёте всегда надо стремиться к точности, но «до часа» рассчитать не получается — в работе всегда появляются нюансы даже при подробном ТЗ. Разработчик может сделать более сложную задачу заметно быстрее расчётного времени, а с простой закопаться, например, в тонкости документации партнёра, которым необходимо интегрироваться, чтение форумов и общение с поддержкой. Поэтому стараемся распланировать до часа, но понимаем, что сходиться оно должно не по каждой задаче, а в сумме. Тестирование обязательно входит. И тестированием должен заниматься отдельный человек —программисты не видят свои ошибки. Коэффициенты закладываются изначально в часы и таким образом заказчик их оплачивает. Срок течения проекта, по-хорошему, должен отличаться от «чистых» часов временем, отведённым на переговоры с заказчиком (уточнения в ТЗ, пожелания, дополнения и доработки) и с другими вовлечёнными сторонами (провайдеры GeoIP, соц. сети, платёжные системы... с кем там ещё приходится интегрироваться по ходу проекта).

Рассчитывать нужно не часы, а степень готовности проекта от минимума до максимума при работе сразу пары человек, например, дизайнер и технолог. Изучай цель и срок, важный для клиента, отсюда появятся решаемые задачи. Используйте принцип FFF = FixTime, FixBudget and FlexScope. Т.е. уложиться в срок с изменением функционала (часто деградация дизайна не как оформления, а как решения задачи). Это может звучать «дико» для заказчиков, как это так мы планировали одно, а сделали чуть иначе или недовыполнили. Здесь помогают недельные итерации и метод прогрессивного jpeg-а. Т.е. после каждой итерации проект готов (работает, можно запускать в эксплуатацию) на n% от количества итерация, меняется только степень «прожарки» всего проекта сразу (улучшения, повышения конверсии). Вначале слабая детализация качества проекта и последующее улучшение, но проект уже работает и это позволяет развивать его постепенно и оценивать точно по срокам.

В двух словах на самом деле тяжело рассказать, но тезисно можно. Главное — оценку должен производить не сам разработчик, а тимлид или архитектор, потому что необходимо учесть следующие важные факторы: 1 — Опыт — самый основной фактор при оценке, причем учитывается опыт собственной разработки, с поправочными коэффициентами людей, которые предположительно будут вести разработку. 2 — Уровень проработки не только всего проекта (области применения и т.д.), но и отдельных задач в рамках проекта. 3 — Тестирование, как системное, так и user-acceptance. 4 — Заложить небольшой управленческий резерв (допустимые изменения и т.д.) Что касается тестирования, то неважно — как вы его будете оценивать: явно выделите тестирование в отдельную позицию в смете, или заложите его стоимость в разработку, главное просто не забыть его учесть. Относительно коэффициентов и о том, кто их оплачивает: Процесс формирования часовой ставки, которую вы озвучиваете заказчику, складывается из себестоимости + %прибыли * на кол-во часов. А вот какой именно процент прибыльности вы закладываете — это вопрос к каждой компании отдельно, и зависит от сегмента рынка и еще многих факторов, например, собственной жадности. Ну и самый больной вопрос, про отличие просчитанных часов от реальной длительности проекта: 100 % всегда будет отличаться. Это факт и надо его принять. Для предотвращения простоев разработчиков, необходимо планировать ресурсы так, чтобы в случае остановки работ по одному проекту, разработчик мог достаточно быстро переключиться на другой. Кроме того, чем больше у вас проектов, тем меньше будет простоев. Хотя, управление ресурсами и планирование, это уже более обширная тема.

Проще пареной репы

Чтобы найти правильный ответ, нужно сначала задать правильный вопрос.

Чего мы хотим? По сути, превратить каждого сотрудника студии в предпринимателя. Что важно для предпринимателя? Самое главное для него, конечно, прибыль. Если нет прибыли, остальное уже не важно. А раз так, мы должны привязать мотивацию сотрудников к рентабельности реализованного ими проекта, но при этом связать ее с прибыльностью всего бизнеса. Вопрос в том, как это сделать.

А вот так: прибыль проекта = выручка проекта — (человекочасы проекта * расходы студии / человекочасы студии).

Вопрос оказался настолько широким, что я впервые за весь проект испытал сложности с выбором ответов для «Топ-3». Приношу за это извинения и предлагаю проследовать в шорт-лист — там тоже есть очень хорошие идеи.