Назад

Процесс пресейла и оценка проекта: как избежать ошибок?

У вас есть гениальная идея для стартапа и вы хотите создать MVP, чтобы эту идею протестировать. Сразу появляются вопросы — сколько будет стоить разработка, за что вы вообще будете платить? Ответы на эти вопросы можно получить уже на этапе пресейла. Чтобы сделать крутой продукт, важно знать, сколько будет стоить разработка — оценить стоимость и объем работ лучше заранее. Желательно, чтобы оценка проекта приложения была максимально точной, потому что ошибка может дорого вам обойтись. Например, если подрядчик не учтет, что вам нужна интеграция с социальными сетями: в итоге дата релиза сдвинется и вы потратите больше чем рассчитывали. Однако, никто не идеален — раньше и мы не всегда попадали в оценку. Но мы улучшили наши процессы и теперь обходимся без ошибок. В этой статье я расскажу, как у нас это получилось 😉

Время чтения: 5 минут

процесс оценки стоимости проекта
Содержание

Начнем с начала

Прежде чем что-то оценить, нужно разобраться в том, что вообще хочет заказчик — в чем его идея и какой продукт нужно разработать, чтобы эту идею протестировать. На основе этого уже можно описать, что мы можем сделать, — и оценить то, что описали. Сейчас в Purrweb этим занимаются бизнес-аналитики. 

Но когда-то у нас их не было, и процесс оценки стоимости проекта проходил по-другому. Рассказываю, чему мы научились и как смогли улучшить процессы.

Как мы делали это раньше

Нельзя сказать, что старый процесс плохо работал, но он был далек от идеала. Во-первых, он не сохранял историю работы, поэтому было очень сложно возвращаться к проектам. Заказчик получил оценку и ушел с ней подумать, а через полгода вернулся — а мы уже не помним, что мы оценивали, кто этот заказчик и что у него за проект.

Во-вторых, у него не было временных рамок. Так как у нас не было какого-либо фреймворка оценки проектов, мы не могли ставить конкретные задачи с четкими дедлайнами. Мы не знали, когда будет оценка, и какие ожидания по поводу сроков создать заказчику. В целом, весь этот процесс был очень размытым и замятым.

Мы считаем, что прозрачность — это залог успешной коммуникации с клиентом. Поэтому решили изменить процесс оценки стоимости проекта.

Как мы делаем это сейчас

процесс оценки стоимости проектаПроцесс оценки стоимости проекта

Новый процесс:

  • Сохраняет историю работы
  • Имеет четкие временные рамки
  • Простой и прозрачный

Пресейл начинается с создания тикета. Аккаунт менеджер общается с заказчиком на созвоне, узнает его ожидания и бизнес-цели. Потом уже передает бизнес-аналитику краткую информацию по проекту — кто заказчик, ссылка на материалы по проекту, что нужно оценить (например, дизайн и фронтенд разработку), и когда дедлайн. Для этого у нас есть отдельный чат в Slack.

процесс оценки стоимости проектаАккаунт менеджеры создают тикет — бизнес-аналитики забирают проект на оценку

Пресейл саммари

После того, как аккаунт менеджер созвонился с заказчиком и получил нужную информацию, он составляет пресейл саммари — это строго структуризированный документ. Так мы синхронизируем видение проекта между аккаунт менеджером и бизнес-аналитиком.

В первой части содержится информация о заказчике: кто он, откуда к нам пришел, как ему пришла в голову идея создать свой продукт, и информация о проекте: какая нужна функциональность и визуал. Здесь могут быть примеры конкурентов — какие фичи можно позаимствовать и что использовать как референс. При этом референсы могут быть любые, если вы не уверены, как должен выглядеть ваш продукт, вы можете сказать, как делать не надо. Так у дизайнера не будет каких-то жёстких рамок, и при этом он точно не сделает что-то, что вам не понравится.

Во второй части описываем, что конкретно нужно оценить, фиксируем ожидания заказчика по бюджету и прикрепляем материалы. Материалы заказчика тоже могут быть любые — от презентации в PowerPoint до готового дизайн-концепта.

— Антон Сопотов,

Наша задача — полностью погрузиться в проект, чтобы понять, что от нас хотят. На основе имеющихся материалов мы выстраиваем первоначальную логику продукта и уже тогда даем цифру, на которую клиент может ориентироваться.

— Антон Сопотов, 
бизнес аналитик

Описание функциональности

Раньше у нас была таблица, в которой мы что-то как-то описывали и давали какую-то оценку. Именно так: как-то и какую-то. Таблица не была стандартизирована (каждый заполнял ее в меру своих умений), ее было сложно воспринимать и контролировать. Она не учитывала время на старт проекта, интеграции, время на ревью кода, время на изменение итерации для дизайн-проектов, время работы QA специалистов, менеджеров. К тому же, с этой таблицей менеджеры делали множество ошибок в работе — попросту непонятно было, куда смотреть, что там вообще описано.

процесс оценки стоимости проекта

Теперь мы используем единый для всех оценок шаблон. Такую таблицу легко понимать и контролировать — все подписано и понятно, куда смотреть. Читается слева направо, сверху вниз.

READ MORE  Резать скоуп и фиксить баги в чужом API на лету: как мы справились за два месяца с проектом, на который требовалось не меньше трех

Чтобы описать функциональность, мы двигаемся от общего к частному. Сначала формируем список эпиков — это основные фичи продукта. Потом эпики разбиваем на истории — это краткие описания потребностей пользователей. Они пишутся по определенному формату:

Как <пользователь>, я могу <совершить действие>

Эти истории легко оценивать: они короткие, легко читаются и всем понятны. Обычно одна история — это задача, которую можно выполнить за спринт.

процесс оценки стоимости проекта

На отдельной странице пишем итоговую оценку — по строчкам расписаны часы на дизайн, разработку, QA тестирование, и часы менеджера. Заказчик смотрит и сразу понятно, сколько времени займет проект и сколько денег на него потребуется.

Такая структура таблицы позволяет аккаунт менеджеру управлять оценкой прямо во время созвона с заказчиком. Можно легко добавить или убрать фичи, чтобы попасть в бюджет. Плюс, помогает не допускать ошибок. Как? Смотрим на первую колонку, проверяем, все ли эпики учтены. Если, например, нет аутентификации или логинки — это сразу заметно.

READ MORE  Как написать заявку на разработку сайта или приложения? Рассказываем и показываем

Как мы считаем время на разработку

Для этого у нас есть учет вероятностных факторов. Проекты по разработке мы оцениваем по трем вероятным исходам событий. Берем оптимистичное (to), пессимистичное (tp) и наиболее вероятное время ™ и по формуле высчитываем ожидаемое время, за которое мы справимся с этой задачей.

процесс оценки стоимости проекта

Оценка

Процесс оценки стоимости проекта проходит с тимлидами и ведущими дизайнерами. У них много опыта и они знают команду — понимают, кто сколько времени потратит на выполнение каждой задачи.

Инструменты которые мы используем на разных этапах оценки проектов:

  • Отдельный канал в слаке — позволяет хранить историю работы по каждому тикету и хранить все тикеты в отдельном месте.
  • Краткий отчет по созвону — нужен, чтобы сохранять информацию о пресейле.
  • Чеклист забываемых штук. Есть такие вещи, которые иногда забываются — иконки, админка. Сделали чеклист, чтобы ничего не терять.
  • Шаблон оценки. О нем мы уже рассказали выше.
READ MORE  Как мы за полгода разработали 4 приложения и одну админку для ночного клуба

Наши успехи

  1. Делаем до 16 оценок в неделю
  2. Среднее время подготовки оценки — 6-8 часов
  3. Попадаем в 92% оценок по дизайн-проектам

Круче оценки — круче проекты

Определить, подходит вам компания по разработке или нет, можно уже на этапе пресейла. Это видно по тому, как они подходят к оценке вашего проекта, насколько они заботятся о нем.

Наша старая система оценки проектов была недостаточно хороша, мы это понимали и решили поработать над ошибками, чтобы сделать процессы пресейла более прозрачными и понятными не только для клиентов, но и для нас самих.

Теперь, когда вы обращаетесь в Purrweb за разработкой продукта:

  • Вы точно знаете, когда получите оценку.
  • Получаете максимально точную оценку.
  • Точно знаете, за что платите.
  • Получаете документ, в котором четко расписаны часы и стоимость работ.

Если хотите узнать, сколько будет стоить ваш проект — напишите нам. Мы поможем воплотить идею в жизнь!

Насколько публикация полезна?

Оцени эту статью!

42 оценок, среднее 4.7 из 5.

Оценок пока нет. Поставьте оценку первым.

Так как вы нашли эту публикацию полезной...

Подписывайтесь на нас в соцсетях!

Share