Начнем с начала
Прежде чем что-то оценить, нужно разобраться в том, что вообще хочет заказчик — в чем его идея и какой продукт нужно разработать, чтобы эту идею протестировать. На основе этого уже можно описать, что мы можем сделать, — и оценить то, что описали. Сейчас в Purrweb этим занимаются бизнес-аналитики.
Но когда-то у нас их не было, и процесс оценки стоимости проекта проходил по-другому. Рассказываю, чему мы научились и как смогли улучшить процессы.
Как мы делали это раньше
Нельзя сказать, что старый процесс плохо работал, но он был далек от идеала. Во-первых, он не сохранял историю работы, поэтому было очень сложно возвращаться к проектам. Заказчик получил оценку и ушел с ней подумать, а через полгода вернулся — а мы уже не помним, что мы оценивали, кто этот заказчик и что у него за проект.
Во-вторых, у него не было временных рамок. Так как у нас не было какого-либо фреймворка оценки проектов, мы не могли ставить конкретные задачи с четкими дедлайнами. Мы не знали, когда будет оценка, и какие ожидания по поводу сроков создать заказчику. В целом, весь этот процесс был очень размытым и замятым.
Мы считаем, что прозрачность — это залог успешной коммуникации с клиентом. Поэтому решили изменить процесс оценки стоимости проекта.
Как мы делаем это сейчас
Процесс оценки стоимости проекта
Новый процесс:
- Сохраняет историю работы
- Имеет четкие временные рамки
- Простой и прозрачный
Пресейл начинается с создания тикета. Аккаунт менеджер общается с заказчиком на созвоне, узнает его ожидания и бизнес-цели. Потом уже передает бизнес-аналитику краткую информацию по проекту — кто заказчик, ссылка на материалы по проекту, что нужно оценить (например, дизайн и фронтенд разработку), и когда дедлайн. Для этого у нас есть отдельный чат в Slack.
Аккаунт менеджеры создают тикет — бизнес-аналитики забирают проект на оценку
Пресейл саммари
После того, как аккаунт менеджер созвонился с заказчиком и получил нужную информацию, он составляет пресейл саммари — это строго структуризированный документ. Так мы синхронизируем видение проекта между аккаунт менеджером и бизнес-аналитиком.
В первой части содержится информация о заказчике: кто он, откуда к нам пришел, как ему пришла в голову идея создать свой продукт, и информация о проекте: какая нужна функциональность и визуал. Здесь могут быть примеры конкурентов — какие фичи можно позаимствовать и что использовать как референс. При этом референсы могут быть любые, если вы не уверены, как должен выглядеть ваш продукт, вы можете сказать, как делать не надо. Так у дизайнера не будет каких-то жёстких рамок, и при этом он точно не сделает что-то, что вам не понравится.
Во второй части описываем, что конкретно нужно оценить, фиксируем ожидания заказчика по бюджету и прикрепляем материалы. Материалы заказчика тоже могут быть любые — от презентации в PowerPoint до готового дизайн-концепта.
Наша задача — полностью погрузиться в проект, чтобы понять, что от нас хотят. На основе имеющихся материалов мы выстраиваем первоначальную логику продукта и уже тогда даем цифру, на которую клиент может ориентироваться.
Описание функциональности
Раньше у нас была таблица, в которой мы что-то как-то описывали и давали какую-то оценку. Именно так: как-то и какую-то. Таблица не была стандартизирована (каждый заполнял ее в меру своих умений), ее было сложно воспринимать и контролировать. Она не учитывала время на старт проекта, интеграции, время на ревью кода, время на изменение итерации для дизайн-проектов, время работы QA специалистов, менеджеров. К тому же, с этой таблицей менеджеры делали множество ошибок в работе — попросту непонятно было, куда смотреть, что там вообще описано.
Теперь мы используем единый для всех оценок шаблон. Такую таблицу легко понимать и контролировать — все подписано и понятно, куда смотреть. Читается слева направо, сверху вниз.
Чтобы описать функциональность, мы двигаемся от общего к частному. Сначала формируем список эпиков — это основные фичи продукта. Потом эпики разбиваем на истории — это краткие описания потребностей пользователей. Они пишутся по определенному формату:
Как <пользователь>, я могу <совершить действие>
Эти истории легко оценивать: они короткие, легко читаются и всем понятны. Обычно одна история — это задача, которую можно выполнить за спринт.
На отдельной странице пишем итоговую оценку — по строчкам расписаны часы на дизайн, разработку, QA тестирование, и часы менеджера. Заказчик смотрит и сразу понятно, сколько времени займет проект и сколько денег на него потребуется.
Такая структура таблицы позволяет аккаунт менеджеру управлять оценкой прямо во время созвона с заказчиком. Можно легко добавить или убрать фичи, чтобы попасть в бюджет. Плюс, помогает не допускать ошибок. Как? Смотрим на первую колонку, проверяем, все ли эпики учтены. Если, например, нет аутентификации или логинки — это сразу заметно.
Как мы считаем время на разработку
Для этого у нас есть учет вероятностных факторов. Проекты по разработке мы оцениваем по трем вероятным исходам событий. Берем оптимистичное (to), пессимистичное (tp) и наиболее вероятное время ™ и по формуле высчитываем ожидаемое время, за которое мы справимся с этой задачей.
Оценка
Процесс оценки стоимости проекта проходит с тимлидами и ведущими дизайнерами. У них много опыта и они знают команду — понимают, кто сколько времени потратит на выполнение каждой задачи.
Инструменты которые мы используем на разных этапах оценки проектов:
- Отдельный канал в слаке — позволяет хранить историю работы по каждому тикету и хранить все тикеты в отдельном месте.
- Краткий отчет по созвону — нужен, чтобы сохранять информацию о пресейле.
- Чеклист забываемых штук. Есть такие вещи, которые иногда забываются — иконки, админка. Сделали чеклист, чтобы ничего не терять.
- Шаблон оценки. О нем мы уже рассказали выше.
Инсайты из мира разработки и экспертный взгляд на цифровые продукты в нашем Telegram-канале Стартап-пикап.
ПодписатьсяНаши успехи
- Делаем до 16 оценок в неделю
- Среднее время подготовки оценки — 6-8 часов
- Попадаем в 92% оценок по дизайн-проектам
Круче оценки — круче проекты
Определить, подходит вам компания по разработке или нет, можно уже на этапе пресейла. Это видно по тому, как они подходят к оценке вашего проекта, насколько они заботятся о нем.
Наша старая система оценки проектов была недостаточно хороша, мы это понимали и решили поработать над ошибками, чтобы сделать процессы пресейла более прозрачными и понятными не только для клиентов, но и для нас самих.
Теперь, когда вы обращаетесь в Purrweb за разработкой продукта:
- Вы точно знаете, когда получите оценку.
- Получаете максимально точную оценку.
- Точно знаете, за что платите.
- Получаете документ, в котором четко расписаны часы и стоимость работ.
Если хотите узнать, сколько будет стоить ваш проект — напишите нам. Мы поможем воплотить идею в жизнь!
