[Простые ответы] Смета проекта "для чайников"
Как правильно рассчитывать часы проекта? Всем, доброго дня! Мы небольшая региональная компания. Организовались мы чуть более года назад. Сели в маленький офис, теперь расширились, набрали людей. Но есть одна проблема: весь этот год мы работаем в холостую. У нас есть хорошие заказчики, наш Rate 1000/час, весь этот год мы изучали CMS, принимали решения какую использовать в своей компании, которая давала бы нам скорость разработки, масштабирование, качество, удовлетворяла бы заказчиков, наконец пришли к выводу, что надо садиться на Битрикс (при всех его сюрпризах). В конечном итоге мы пришли к выводу, что работаем в холостую, так как неправильно рассчитываем время проекта в части программирования, на конференциях этого нам не рассказывают, в интернете конкретики нет. Хотелось бы спросить более опытных коллег, как происходит этот процесс на примере самого простого сайта? Как происходит процесс расчета технической части? Он приблизителен или необходимо всегда до часа рассчитать, и разработчик обязан уложиться? Входит ли тестирование в оплаченные заказчиком часы? Какие коэффициенты закладываются и оплачивает ли их заказчик или же это кладется на плечи студии? Как срок течения проекта должен отличаться от «чистых» часов, которые рассчитываются в ТЗ? Понимаю, что в 2-х словах не расскажешь, но хотя бы приблизительно. Заранее всем спасибо!
Артём Федоревич, «Дюк&Ко»
Лучшие ответы недели
Майк Монтейро в книге «Дизайн — это работа» пишет: «Есть формулы, которые якобы помогают определить цену проекта. Они предлагают сложить свои расходы, арендную плату, коммунальные услуги и прочее, а затем добавить сумму желаемой прибыли. Проблема большинства этих формул в том, что они рассчитывают, как едва прикрыть свою задницу». Есть 2 способа решить вашу задачу: либеральный и радикальный. Либеральный способ направлен на снижение возможных рисков: внедрите этап проектирования, результатом которого станет составление подробного технического задания (для вас) и прототипов с пояснениями, как что работает (для клиента). Договоритесь о взносе страховой части и о расчете окончательной суммы по факту (помогут CRM учета рабочего времени). Радикальный способ: перейдите к гибкой модели разработки, при которой проект поделен на итерации, по каждой из которой четко зафиксированы временной интервал и стоимость. Fix time fix money flex scope.
Илья СабуровКомпания: WebProfy (Kokoc Group)Должность: Директор производства
Если говорить о высоком ценовом сегменте, то проекты должны оцениваться экспертами, неоднократно решавшими такие задачи, индивидуально. В небольшой компании это, скорее всего, основатель бизнеса. Эксперт способен увидеть «подводные камни» и правильно спрогнозировать время выполнения задач (с адекватным запасом часов). В идеале, оценок должно быть несколько, чтобы мнения разных экспертов свести к «общему знаменателю». Проекты в нижнем ценовом сегменте нельзя оценивать индивидуально, иначе можно потонуть в бесконечной череде безрезультативных мнений. Действуйте иначе: — заранее подготовьте необходимый функционал; — составьте подробное стандартное ТЗ и назначьте фиксированную цену за проект, включающую минимальный объем доработок типового функционала; — организуйте процесс работы с клиентом так, чтобы существенная часть его желаний либо удовлетворялась предусмотренным функционалом системы, либо корректно отклонялась. Тестирование и управление проектом обязательно закладываются в цену.
Проблему стоит искать не столько в расчете необходимых часов для разработки, а в самом бизнес-планировании деятельности. Отличный материал на эту тему уже есть на портале http://www.cmsmagazine.ru/library/items/management/skolko-stoit-chas-raboty-programmista/, поэтому перейдем к ответам: 1. Проекты можно условно разбить на несколько групп: простые, средней сложности и сложные (эксклюзивные). Строим матрицу — визитки, лендинги, каталоги, магазины, а на пересечении — стоимость часа разработки. Первоначальное создание матрицы займет некоторое время, но дальнейшая оценка будет более простой и наглядной. 2. Отклонения в расчетах возможны, но это заранее оговаривается в контракте. Наценки возможны за срочность (задействовано больше разработчиков, работа в выходные дни). 3. Время на тесты закладывается изначально при разработке, заказчик получает готовый продукт (и да, он может протестировать его функционал дополнительно и указать на несоответствие ТЗ, что потребует доработок). 4. Старайтесь разбить каждый проект на несколько этапов. Это позволит быстро выявлять слабые места и контролировать ход процессов. Помните — у любого задания есть ответственный и дедлайн, и чем раньше менеджер проекта заметит проблему, тем лучше.
Мнение редактора проекта «Простые ответы»
Вопрос оказался настолько широким, что я впервые за весь проект испытал сложности с выбором ответов для «Топ-3». Приношу за это извинения и предлагаю проследовать в шорт-лист — там тоже есть очень хорошие идеи.
Ответы (шорт-лист)
Предварительный расчёт [времени на сайт] основывается на опыте создания «похожего» и субъективной оценке факторов, способных изменить время «по опыту». Рекомендую учитывать следующие факторы: Насколько чётко поставлена задача? Если есть пробелы, не определены ожидания/требования/критерии оценки, заказчик говорит «сделайте сайт, вы же профи», прибавьте 30% к времени «по опыту». На деле изменение задачи может повлечь гораздо более серьёзные изменения, поэтому старайтесь уточнить требования. Качества разработчика: способен ли решать сложные задачи, перестраиваться, работать под давлением. Если есть слабые места, риск проблем и увеличения срока, весьма существенный. Прибавьте ~30%. Первый пункт — больше ответственность заказчика, и за это можно смело брать деньги, а второй пункт — на ваше усмотрение. Тестирование входит в оплаченные часы, конечно: это работа, которую должен выполнить специалист, чтобы сайт работал. Срок реализации проекта по нашему опыту — 200–400% от чистых часов.
Александр СугаковКомпания: Superpovar.RUДолжность: Руководитель проекта
При расчёте всегда надо стремиться к точности, но «до часа» рассчитать не получается — в работе всегда появляются нюансы даже при подробном ТЗ. Разработчик может сделать более сложную задачу заметно быстрее расчётного времени, а с простой закопаться, например, в тонкости документации партнёра, которым необходимо интегрироваться, чтение форумов и общение с поддержкой. Поэтому стараемся распланировать до часа, но понимаем, что сходиться оно должно не по каждой задаче, а в сумме. Тестирование обязательно входит. И тестированием должен заниматься отдельный человек —программисты не видят свои ошибки. Коэффициенты закладываются изначально в часы и таким образом заказчик их оплачивает. Срок течения проекта, по-хорошему, должен отличаться от «чистых» часов временем, отведённым на переговоры с заказчиком (уточнения в ТЗ, пожелания, дополнения и доработки) и с другими вовлечёнными сторонами (провайдеры GeoIP, соц. сети, платёжные системы… с кем там ещё приходится интегрироваться по ходу проекта).
Рассчитывать нужно не часы, а степень готовности проекта от минимума до максимума при работе сразу пары человек, например, дизайнер и технолог. Изучай цель и срок, важный для клиента, отсюда появятся решаемые задачи. Используйте принцип FFF = FixTime, FixBudget and FlexScope. Т.е. уложиться в срок с изменением функционала (часто деградация дизайна не как оформления, а как решения задачи). Это может звучать «дико» для заказчиков, как это так мы планировали одно, а сделали чуть иначе или недовыполнили. Здесь помогают недельные итерации и метод прогрессивного jpeg-а. Т.е. после каждой итерации проект готов (работает, можно запускать в эксплуатацию) на n% от количества итерация, меняется только степень «прожарки» всего проекта сразу (улучшения, повышения конверсии). Вначале слабая детализация качества проекта и последующее улучшение, но проект уже работает и это позволяет развивать его постепенно и оценивать точно по срокам.
Анар МехтиевКомпания: ArtektivДолжность: Генеральный директор qb-systems
В двух словах на самом деле тяжело рассказать, но тезисно можно. Главное — оценку должен производить не сам разработчик, а тимлид или архитектор, потому что необходимо учесть следующие важные факторы: 1 — Опыт — самый основной фактор при оценке, причем учитывается опыт собственной разработки, с поправочными коэффициентами людей, которые предположительно будут вести разработку. 2 — Уровень проработки не только всего проекта (области применения и т.д.), но и отдельных задач в рамках проекта. 3 — Тестирование, как системное, так и user-acceptance. 4 — Заложить небольшой управленческий резерв (допустимые изменения и т.д.) Что касается тестирования, то неважно — как вы его будете оценивать: явно выделите тестирование в отдельную позицию в смете, или заложите его стоимость в разработку, главное просто не забыть его учесть. Относительно коэффициентов и о том, кто их оплачивает: Процесс формирования часовой ставки, которую вы озвучиваете заказчику, складывается из себестоимости + %прибыли * на кол-во часов. А вот какой именно процент прибыльности вы закладываете — это вопрос к каждой компании отдельно, и зависит от сегмента рынка и еще многих факторов, например, собственной жадности. Ну и самый больной вопрос, про отличие просчитанных часов от реальной длительности проекта: 100% всегда будет отличаться. Это факт и надо его принять. Для предотвращения простоев разработчиков, необходимо планировать ресурсы так, чтобы в случае остановки работ по одному проекту, разработчик мог достаточно быстро переключиться на другой. Кроме того, чем больше у вас проектов, тем меньше будет простоев. Хотя, управление ресурсами и планирование, это уже более обширная тема.
Хотите ответить на следующий вопрос? Что бы дать простой ответ на следующий непростой вопрос, вступайте в нашу группу и следите за анонсами: каждый вторник мы публикуем новый вопрос и ждем ответы до пятницы.
Задать вопрос экспертам
Полный текст статьи читайте на CMS Magazine
