Любая оценка стоимости проектных задач практически никогда не совпадает с временем, которое фактически будет затрачено на их решение. По моему опыту, каким бы не был опытным оценщик, погрешность его оценки будет примерно такая же, как у менеджера, который знаком с предметом поверхностно. Это выливается в овертаймы, проблемы с планированием и недовольство заказчиков. Разбираемся в подходах к оценке проектов, рисках и нивелировании последствий неправильной оценки.
Подходы к оценке проектов
Основных моделей оценки (и оплаты) проектов две, и они пересекаются с двумя основными подходами к управлению проектами.
- Fix-price — это оценка сроков/стоимости проекта в целом. Чаще всего используется при “водопадном” подходе и четком техническом задании.
- Time and material — когда функционал не фиксирован, и новые задачи поступают в процессе – это agile.
Используются и гибридные методы. Например, в случае полной разработки сайта, у нас есть абсолютно неопределенный этап дизайна, который в процессе будет пересматриваться десяток раз, и более-менее понятные процессы программирования. Например, дизайн пропускают через тайм-материал, а верстку-программирования через фикс-прайс, с оценкой непосредственно перед стартом. Да, оценивать весь проект сразу и целиком — такой себе вариант, но он зачастую проще, нежели трата времени на объяснение, что разбиение проекта на несколько частей может оказаться выгоднее. Бизнесу удобнее заранее знать, сколько он потратит на проект, а не жить в неопределенности до выполнения первой части проекта.
Оценка стоимости проекта происходит в двух плоскостях: времени и денег. Происходит это путем вычисления того, сколько нужно времени и умножением его на стоимость часа специалиста. Оба показателя примерно одинаково важны для бизнеса — задача, выполненная за немного денег и много времени точно так же несет в себе убыток — но не такой очевидный для менеджера или исполнителей. При том, внутренний заказчик, с которым у вас нет прямолинейных финансовых отношений, точно так же платит и фактически так же подвержен потерям.
Оценка стоимости проекта по Fix Price
Фиксированный прайс подразумевает, что в процессе работы оценка не изменится. При таком подходе мы, фактически, продаем конечный продукт, а не время на разработку. Какой бы детализированной не была смета — чем больше задач в одном пуле, тем менее точной окажется оценка в конечном итоге. Для заказчика это как лотерея, где он может заплатить меньше, чем стоит проект на самом деле, а может заплатить больше — если исполнителю удалось выгодно продать проект.
Оценка стоимости проекта происходит один раз, и уже на берегу происходят договоренности о суммах и очередности оплаты за проект. Это самый удобный и ленивый вариант, при котором можно сэкономить время еще и на бюрократических операциях, при которых время тратилось бы на оценку каждой отдельной задачи. Все новые задачи оцениваются отдельно и проходят по другим договоренностям, принимаясь на выполнение во время работы над основным проектом, или откладывая на время после его завершения.
В некоторых случаях пересматривается и оценка по фиксированному прайсу. С оценкой действительно можно очень сильно не угадать, и тогда оценка переходит на дополнительное обсуждение. На моей памяти не было ни единого случая, когда заново обсуждались деньги — чаще обсуждается время, и закладывание трат текущего проекта в проекты будущие.
Оценка стоимости проекта по Time and material
Оплата проектов по тайм-материал происходит за время, фактически затраченное на выполнение задачи. Здесь может быть как чистый аджайл – когда заказчик платит за затраченное время постфактум, так и предварительная оценка каждой задачи – как при фикс-прайс, с последующей оплатой фактически затраченного времени.
Time-material подход позволяет оценить стоимость выполнения отдельных задач. Время, затраченное на оценку точно так же нужно учитывать — пряча его в общие часы, или выводя отдельным пунктом. При тайм-материал часто наружу выводится этап исследований (investgations), что практически никогда не отображается при оценке проекта целиком.
Главным минусом работы по модели time and material является в разы увеличивающаяся отчетность. Нужно считать время, которое было затрачено на проект — а это требует технического обеспечения (тайм-трекеры есть в Jira и Redmine) и дополнительного времени работы менеджера. Специалисты-исполнители, как правило, ленятся “списывать” время сразу, и за этим нужно следить. Вытекающий минус — часы могут записываться по памяти и с округлениями. Панацеи здесь нет, и быть не может — только что поставить онлайн-камеру или наблюдателя за столом исполнителя, что если бы и можно было сделать, сильно увеличило бы и стоимость проекта, и качество результатов.
К time and material также относится почти экзотический вариант “продажи” специалиста фулл-тайм. Это когда специалист отдается в распоряжение клиента, выполняет его задачи, отчитывается и оценивает напрямую, при том оставаясь в штате компании. Позволю себе замечание, что покупка всего времени специалиста в конечном итоге окажется дешевле найма сотрудника в штат — несмотря на изначально кажущиеся высокие цифры. Здесь и экономия на рекрутинге, и момент в том, что специалист все же не остается один-на-один с заказчиком. Обязательно будет кто-то на стороне компании, кто проконтролирует работу специалиста и в случае чего поможет разрулить задачи. Также отмечу, что если на фулл-тайм берется начинающий специалист, есть шанс получить услуги бесплатно, или почти бесплатно — как вложение нашей компании в обучение разработчика. Это как модели для бесплатных стрижек у начинающих мастеров — заказчик также должен учитывать риски.
Кто и как оценивает стоимость выполнения задач
Вот, где-то на бизнесовом уровне решили, что проект будет идти по фикс-прайсу, или тайм-материал, проект передали менеджеру и наступил момент, когда проект/задачи нужно оценивать. Примем за отправную точку ситуацию, когда техническое задание уже готово (сделано внутри или получено от клиента), и наша цель — узнать, сколько времени-денег нужно на его реализацию.
Оценкой может заниматься
- Менеджер проекта
- Тим-лид или руководитель отдела
- Непосредственно исполнитель
Если у менеджера достаточно опыта и познания в конкретном предмете, а задача предсказуема — передавать оценку кому-то еще не имеет смысла. Увеличится цепочка оценки, количество пересылок писем-комментариев, размоется ответственность. Это все вызовет дополнительные расходы, за которые, конечно, никто не заплатит.
Тим-лид (или руководитель отдела, или арт-директор) — тот же менеджер, который оценивает задачи, после не участвуя в их реализации, только в контроле если повезет. При прочих равных, от менеджера он отличается в плане оценки даже в худшую сторону — ответственность за соответствие оценки/факта все равно перейдет на плечи менеджера. К тому же, если тим-лид, будучи квалифицированным исполнителем оценит задачу так, как если бы ее делал он сам, шансов на то, что конечный исполнитель влезет в сроки практически не остается.
Делегирование оценки исполнителю кажется самым верным способом. Он задачу оценивает, он разбирается в нюансах задачи, он же будет ее делать и нести ответственность за выполнение задачи внутри команды. Кто бы задачу не оценивал, оценку передавать заказчику нельзя, до момента пока исполнитель с ней не согласится. А исполнителя, по возможности, после не менять.
Этика оценки стоимости проекта
Время на выполнение задачи у опытного специалиста и у новичка будет сильно расходиться. Если в сметах нет соответствующих градаций, клиент рискует сильно переплатить, в случае когда мы передадим задачу неопытному исполнителю. Здесь мы можем применить обратный коэффициент, когда фактически стоимость часа окажется меньше оговоренной. Заставлять клиента платить за джуниора столько же, сколько за синиора — плохой сценарий, и я надеюсь, в вашей компании такого нет. В своих же проектах я сознательно срезаю количество затраченных часов, если это были часы начинающего специалиста, а клиенту об этом сообщено не было. Клиент не должен и не обязан платить за обучение нашего внутреннего сотрудника.
Всякие навороченные компании (преимущественно, бюрократические корпорации) с целью снижения затрат фиксируют стоимость часа работ исполнителя по договору. Фиксироваться может как время работы отдельных специалистов, так и абстрактный час любого исполнителя. Фиксация происходит при перезаключении договора — как правило, раз в год. С позиции экономии этот прием абсолютно ничем не помогает. Если вдруг стоимость производства задач для исполнителя окажется выше, он просто добавит часов исполнителя. Это справедливо как в отношении тайм-материал, так и в отношении фиксированных цен.
Как оценивать время вспомогательных специалистов
С программистами и дизайнерами все более-менее понятно, но что делать с тестировщиками, менеджерами и арт-директорами? Оценить их время действительно еще сложнее, и панацея здесь – использование коэффициентов. Например, заранее обозначаем, что время работы менеджера это 10% от времени работы специалиста. При “тайм-материал” подходе можно выводить работу таких специалистов отдельной строкой. Особенно, если менеджер действительно непрерывно тратит время частями, кратными часу времени.
Риски при оценке задач и проектов
Проектная работа предполагает, что мы делаем что-то, чего еще нет и никто ранее этого не делал. Даже если вопрос стоит в интеграции условного Chat2Desk с Dynamics CRM, что уже тысячи раз кто-то делал, всегда появляются условия, делающие задачу уникальной конкретно в нашем случае. Вот, что может добавлять шансов сорвать сроки:
- Когда задачу оценивает один человек, а делает другой
- Когда исполнитель недостаточно глубоко погрузился в задачу при оценке
- Если нам нужно показать красивые цифры, чтобы продать задачу
- В случае, когда исполнитель на проекте меняется, и запускается повторное исследование задачи
Все это ведет к нарушению договоренностей и срыву сроков. Большинство из этих рисков можно предусмотреть и избежать, но в конечном итоге нужно быть готовым, что как бы гладко все ни шло, шансы уложиться в планируемые сроки нулевые — практически всегда.
Чтобы дать приближенные к реальным сроки, разные менеджеры проектов прибегают к методам умножения оценки на коэффициент. Например, умножают полученную оценку на 2, на 3 — она от этого конечно взлетает, но если такое увеличение стоимости происходит уже в процессе разработке – это более неприятный для заказчика сюрприз.
Решаются проблемы оценки опираясь на контекст и ситуацию. Главное правило — обмен информацией и осознание текущего положения вещей. Если через неделю месячного проекта мы понимаем, что нам скорее нужно два месяца — об этом нужно сообщить заказчику. Здесь речь даже не о том, чтобы менять цифры в счетах (это чревато, на самом деле и такого следует избегать), а в том, чтобы проявить сервисный подход и позволить заказчику скорректировать свои планы.
Резюме + инструмент оценки проекта
В целом, какой бы вариант оценки вы не выбрали, он будет оценкой типа “пальцем в небо” (если только не написали крайне детализированное ТЗ, которое сделало проект еще дороже). Поэтому, оценка стоимости чаще происходит от позиции “мы предполагаем, сколько стоит такой проект, поэтому подбиваем количество часов выполнения к этой сумме”. Это собственно и причина, почему не имеет смысла фиксировать стоимость часа работы специалиста в агентстве — все равно, сумма будет исходить из стоимости проекта.
Бонусом дарю табличку, с помощью которой я оценивал проекты в бытность менеджера проектов по разработке сайтов/приложений: бесплатно в гуглдоке. Появилась она тогда, когда мне стало лень каждый раз проставлять коэффициенты и опрашивать всех участников проекта на предмет оценки времени. Табличку нужно скопировать перед использованием.
Табличка построена на том, что мы можем примерно точно оценить стоимость-время программирования, и никак не можем оценить дизайн и верстку (которая зависит от дизайна). Плюс, нам известна история взаимодействия с клиентом. Поэтому, оценка происходит так: узнаем сколько времени займет программирование + выставляем коэффициент риска, который несет клиент или проект (нулевой риск = единица) — пункты для заполнения отмечены желтым цветом. Все остальные цифры считаются скриптом. Забираем “количество часов с рисками” и общую стоимость проекта. Выводим это в финальную смету — без обозначения коэффициента риска, конечно. О том, что в проект заложены риски тоже лучше без повода не говорить. Пользуйтесь, потом расскажите, что лучше считает стоимость/сроки — живые люди, или две формулы гуглдока.
