Post #1173

💬Как я хотел управлять ожиданиями клиентов, и что из этого вышло Прочитали и пересказали статью Максима Панфилова Мой основной бизнес — студия разработки panfilov_digital, которой в этом году исполняется 10 лет. «Сколько будет стоить разработка?» — всегда спрашивают клиенты на первой же встрече. Но в IT дать точную оценку работ невозможно. Я придумал решение, как сформировать правильные ожидания. Мы работаем спринтами — проект разделяется на этапы, каждый из них оценивается обособленно и отрабатывается по Fix Price. Это оптимально для обеих сторон. С одной стороны, заказчик может прогнозировать затраты по этапам, с другой стороны, исполнитель не подписывается под большой проект и сохраняет гибкость в планировании. Разделяем работу на следующие шаги: 1. Проектирование — ТЗ + дизайн; 2. Запуск MVP / первой версии; 3. Если проект большой — поэтапное внедрение новых функций. Как дать примерную оценку разработки Есть универсальный способ оценки проекта — ☝️ пальцем в небо умножить на 3.14. Клиентов этот способ редко устраивает. Тогда на помощь приходит опыт. За 20 лет я запустил более 500 проектов и могу примерно прикинуть, сколько времени моя команда потратит на выполнение задачи. А значит, могу сделать приблизительную оценку разработки. Логика такая: — умножаем время на ставку, получаем затраты на исполнителя; — суммируем затраты на всех исполнителей, получаем затраты на весь проект; — от этой суммы выстраиваем вилку +/- с разбросом в зависимости от сложности проекта и опыта команды выполнения похожих задач. Я сделал гугл-таблицу с расчётами по этой логике. Как сделать более точную оценку разработки Примерная оценка все еще может отличаться от фактической цены на 50%, а то и на 100%. Поэтому когда клиент соглашается на поэтапную работу, мы делаем приблизительную оценку на все работы и первым этапом продаём проектирование с фиксированной стоимостью. Результатом этапа проектирования является техническое задание: описание бизнес-требований, бизнес-логика, макеты дизайна и функциональное описание вместе с технической спецификацией. Когда есть такое ТЗ, программисты могут дать более точную оценку своей работы. Мы фиксируем стоимость этапа проектирования, потому что даже если у клиента появятся новые вводные на этапе ТЗ, то это не сильно увеличит трудозатраты на его создание (дизайн + техническое описание). Гораздо хуже, если хотелки будут возникать во время программирования: переделывать написанный код намного затратнее. Что произошло после того, как мы внедрили шаблоны на практике ➡️ Кейс №1 — сделали оценку, не стали работать. Пришёл клиент по ссылке с сайта, который мы сделали для другой компании. Хотел так же. Сделали приблизительную оценку в гугл-таблице. Коммерческий директор сказал, что все ок, нужно то же самое, но дешевле. Такая постановка вопроса нас не устроила, мы отказались работать с этим клиентом. Итог. Использование шаблона для предварительной оценки помогло быстро перейти к заключению сделки. А то, что она в итоге сорвалась, не повлекло для нас больших потерь. ➡️ Кейс №2 — сделали оценку, ТЗ и дизайн, и передали другому подрядчику. С повторным запросом пришёл клиент, для которого мы уже делали один сайт. Сделали предварительную оценку в гугл-таблице, вилка бюджета устроила. Разбили работу на два этапа — проектирование и программирование. Мы успешно сдали этап проектирования. Но заказчик принял решение, что разработкой и поддержкой сайта должны заниматься местные белорусские подрядчики, чтобы сократить возможные риски. Итог. Все в плюсе — ТЗ + дизайн как отдельный этап даёт ценность: у клиента есть гибкость в выборе подрядчика, а у нас в любом случае есть работа, даже если клиент примет решение идти в разработку с другой командой. Источник #личный_опыт#больше_клиентов_и_продаж