Привет. Меня зовут Инга, и я работаю в digital-агентстве Alente. Мы занимаемся разработкой и продвижением сайтов. Фронт-офис компании состоит из менеджеров, которые заправляют коммуникацией в проектных командах, с клиентами и между ними. Но, помимо этого, в перечень работ любого нашего менеджера, будь то продаван, аккаунт или производственник, входит объяснение всяких непонятных для клиента терминов и в целом добавление прозрачности всем процессам, которые мы как специалисты осуществляем в своей работе.
Одной из самых тёмных и непонятных тем для наших клиентов (текущих и потенциальных) была оценка временных затрат на разработку сайтов.
Стоит сказать о том, что мы в Alente всегда делали относительно небольшие коммерческие проекты: корпоративные сайты, интернет-магазины и несложные веб-сервисы. За 12 лет привыкли работать по фиксированной оценке, так как задачи стали более-менее типовыми. Мы сделали калькулятор с вилками по оценкам этапов и считали всё по нему — и, как правило, попадали в эти оценки. В калькуляторе были типовые блоки, например «отзывы», «страница с каталогом товаров», «авторизация по электронной почте» и прочие.
Шли годы — мы умнели, качали маркетинг и продажи. К нам стали поступать задачки посложнее: образовательные платформы с разными ЛК, интеграции с огромными 1С-ками, сложные анимации и прочие, ранее незнакомые, но очень интересные фичи. Данных для адекватной оценки на этапе продажи не хватало. Если и получалось продать проект, по итогу часто промахивались — и потом приходилось объяснять клиентам, что нужно доплатить, обработать негатив и не свалиться в минус. Мы поняли, что нам самим надо апгрейдить формат представления оценки клиенту, чтобы снять часть проблем с самих себя же в будущем. И мы стали приучать клиентов к почасовой оценке.
Оцени то, не знаю что
Всё начинается с продаж. Для начала мы решили квалифицировать лиды на оцениваемые (типовые), то, что у нас когда-то было, и нечто совсем неоцениваемое. Для каждого типа лидов у нас своя стратегия работы.
Про типовые лиды мы уже рассказывали — там, как и прежде, работает калькулятор. Если есть отдельные сложные фичи, собираемся на быстрый покер и оцениваем их.
«То, что когда-то было» — это проекты, аналоги которых мы уже реализовывали. Тут мы заходим в нашу систему учёта затраченных на проект ресурсов и можем с уверенностью ориентироваться по этим отчётам.
«Нечто неоцениваемое» — самый страшный (как нам казалось) зверь. Тут мы вкладываем побольше ресурса в оценку. Как правило, сложные проекты являются и самыми интересными. Это могут быть стартапы, веб-сервисы с системами «личных кабинетов», сложными интеграциями. На такое не жалко и весь отдел программистов на покер собрать. Тут мы делаем подробную смету с почасовой оценкой, но от вилок пока не отходим, так как ни дизайна, ни внятного ТЗ на этапе предварительной оценки, как правило, нет.
В смету вносим декомпозированную задачу, оцениваем разработку в формате «от… до…» по каждой фиче, добавляем время на проектирование, тестирование и отладку.
В итоге получаем предварительную смету, благодаря которой происходит волшебное: клиент понимает, какие фичи наиболее тяжёлые в реализации. Ему так удобнее планировать спринты или вообще фильтровать функционал будущего сайта.
После презентации такой сметы мы рассказываем про обязательный предпроектный этап, после проведения которого мы сможем дать не просто вилки, а уже точную смету на реализацию той или иной фичи. В предпроектный этап входят техническое задание, сбор ключей или семантики (если надо), визуал (подбор референсов, мудборды), прототипы, аналитика и точная смета.
Сейчас кто-то в комментариях закричит: «Это не T & M!» — и будет совершенно прав.: )
А что в итоге-то?
Новые сметы имели очень неожиданный и приятный эффект:
- Нам стало легче продавать индивидуальную разработку. Те самые интересные проекты, которые развивают нас как разработчиков и позволяют больше зарабатывать, стали приходить к нам и сейчас заполняют 100% нашего производственного плана.
- Мы подсадили всех наших клиентов на сметы. Теперь никто не хочет возвращаться к тем поэтапным оценкам — все ждут наши таблички.
И, что самое интересное: T & M сам попросился в нашу жизнь.
Клиент, который понял, как подрядчик оценивает работы и откуда берутся чеки, становится вашим братишкой. Вы теперь на одной стороне. Клиент ставит задачи чётче, а если он сам не знает, чего хочет… точнее так:
Если он сам не знает, что точно сработает и принесёт ему денег, — он придёт на T & M.
Потому что надо будет тестировать гипотезы, щупать аудиторию — в общем, заниматься процессами. Наш первый проект на T & M стал таким по инициативе клиента. Второй — тоже.
T & M с оплатой за результат
T & M, как известно, — это оплата процесса. Но мы не процессники. Это не вяжется с этикой компании и её целями. Поэтому у нас своя версия T & M — тоже про результат.
- В договорах и допсоглашениях зафиксирован перечень работ, выполняемый в рамках оплаченных часов, но с поправкой на то, что условия могут меняться по соглашению сторон. Мы не принуждаем клиентов доплачивать, если мы не уложились в свою оценку: мы объясняем, почему так случилось, стараемся предупредить заранее и нивелировать недопонимание и негатив.
- Отчитываемся за проделанную работу. Все работы производственников фиксируются в нашей самописной системе, из которой мы выгружаем отчёты по часам и работам. Сейчас, кстати, пилим новую версию этой системы. Обязательно напишем про неё статью!
Всегда есть план реализации спринта — но мы понимаем, что план может корректироваться. На наш взгляд, такой подход честен и справедлив. Хоть и не T&M-ный в чистом виде.
А что фикс?
С проектами по фиксированной оплате мы не собираемся прощаться — да и не получится. Мы часто сотрудничаем с госучреждениями или крупными промышленными предприятиями, вопрос планирования бюджетов в которых не терпит гибкого подхода. В таких случаях мы закладываем риски и перестраховываемся, чтобы обезопасить себя от убытков в случае сложно оцениваемых проектов.
Что выбрать — фикс или T & M?
Сейчас нам больше нравится T & M, потому что:
- Проект вести хоть и сложнее, но интереснее. Клиент достаточно сильно вовлечён и заинтересован.
- Проект ведётся прозрачно, делится на небольшие итерации.
- Оценка адекватнее. Обычно для оценки небольшого спринта данных достаточно, поэтому покер планирования не похож на битву экстрасенсов.
- Проекты рентабельны.
Минусы подхода:
- Тратим время на сметы для лидов, которые могут и не сконвертироваться в клиентов.
У фиксированной оплаты тоже есть свои плюсы:
- Большим компаниям так проще работать и они готовы платить за большие этапы сразу.
- Есть чёткие требования к результату, которые редко меняются в процессе работ. Взяли проект — и пилим, пилим, пилим. Никакого стресса.
- Разговор про оценку ведётся один раз. Продавать в ходе проекта не нужно, потому что всё уже обсудили и оценили сразу. При почасовой оплате оценку спринтов каждый раз приходится защищать заново.
Минусы подхода:
- Большой риск провалиться в минус из-за отсутствия информации на оценке.
- Ещё раз прочтите 1-й пункт. Этот минус самый страшный, его должно быть достаточно.: )
Конечно, чистый T & M, скрам-доски и спринты по всем канонам Agile для нас ещё где-то в будущем — но мы уверены, что тот подход, который мы применяем сейчас, нам соответствует. Наши клиенты довольны, мы — тоже.
Будем очень признательны, если вы поделитесь в комментариях своими подходами к оценке проектов.