14.05.2024

Все мы знаем, что оценка – один из самых главных этапов коммерческого предложения. Именно исходя из неё клиент принимает решение, будет он инвестировать в разработку проекта или нет.

Любая оценка представляет собой фундаментально две вещи: time and material. Это означает, что есть оплата:

• За работу специалиста;

• За материальную составляющую проекта (например: лицензии, подписки).

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

Также и в нашей истории. Есть базовые элементы, без которых проект не разработать – это аналитика и дизайн. Мы ещё называем это этапом проектирования. После того, как аналитика выполнена, проект получает определенные границы и рамки, благодаря которым разработчики работают уже с меньшей неопределенностью и абстракциями.

Далее идёт основная фаза – оценка разработки программного обеспечения. Сама разработка делится на две составляющие:

• Бизнес логика, реализованная на сервере;

• Интерфейсная часть для пользователей системы.

И, конечно, любой проект имеет завершающую фазу, когда идёт проверка на его соответствие. Вот уже на этом этапе подключаются инженеры, отвечающие за эксплуатацию, и первые пользователи системы (обычно это специалисты по тестированию 👨)

Задача команды на этом этапе: постараться сломать то, что ломаться не должно. А также проверить, что всё работает так, как задумывалось изначально.

Исходя из того, с каким запросом и вводными данными приходит клиент, определяется формат оценки.

Лично мы используем эти:

1. Оценка по периодам.

Этот способ подойдет, если проект очень объёмный, не имеет чёткого ТЗ.

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

Исходя из средней ставки, мы получаем примерную стоимость проекта (а ещё в таком формате очень удобно оценивать стоимость поддержки).

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

• Конечно, декомпозировать проект до состояния задач разработчикам не получится, но выписать продуктовые фичи и разбить их на каждого участника команды вполне реально. Каждая фича оценивается отдельно. Чаще всего в районе 20-30 часов.

Если нужно с большей точностью прикинуть количество часов на небольшом отрезке задач, этот формат для вас.

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

Бывают случаи, когда у клиента нет четкой идеи, что он хочет сделать.

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

Оценка проекта всегда начинается с общения с клиентом.

Для начала нужно понять, для чего этот проект делается. Важно отбросить мнение, что бизнес – ради денег, и понять, какие цели преследуют разработка того или иного сервиса 💻

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

Как мы и писали выше, оценка состоит из:

1. Выбора формата оценки;

2. Формирования тела оценки (составление бэклога, генерация идей, гипотеза о затраченном времени на проект);

3. Проставления часов;

4. Валидации команды;

5. Валидации отдела продаж;

6. Презентации.

Самый трудный и долгий этап - составление тела оценки. До недавнего времени в нашей команде этим занимался только CTO. Сейчас же для декомпозиции мы привлекаем системных аналитиков. И у них отлично получается!

Дальше все просто – CTO проставляет часы на этапы проекта и показывает результат сначала команде разработке, а потом CEO.

По какой логике мы ставим часы?

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

Во-вторых, это субъективный опыт членов нашей команды, который в сумме должен складываться в объективную картину.

В-третьих, мы используем устоявшиеся формулы:

QA = 30% от разработки

PM = 20% от разработки + QA

Часы на фронтенд > Часы на бэкенд *1,3

Часы на фронтенд > Часы на дизайн

И, конечно, презентация! Ни в коем случае не стоит отправлять оценку заказчику без комментариев и контекста. Как минимум, вы упускаете шанс сделать еще одно касание с клиентом, а как максимум, заказчик неправильно поймет вас и, как следствие, не купит 😶

Многие встраивают оценку в КП в Notion и презентуют ее на онлайн-встрече. Кто-то выполняет оценку в виде лендинга и отправляет ссылкой на сайт, это реально дает вау-эффект.

Мы же готовим кастомную презентацию и презентуем на звонке. Реже – записываем видео.

Инструменты оценок, которыми мы сами пользуемся с удовольствием

Как вы поняли, сами оценки легко шаблонируются. Делимся своими с вами, друзья!

Скачать документ

Документ, с примерной структурой презентации

А если нужно сделать запись, мы используем сервис Loom. Шаблона там нет, просто пользуйтесь 😉

Оценки – серьёзная и глубокая тема. Сегодня мы рассмотрели их только в рамках подготовки КП.

Проджекты действуют по-другому, с большей точностью и чуть большей степенью определенности. Мы обязательно напишем об этом позже!

1. Делитесь в комментариях, была ли полезна наша статьи и понравились ли вам наши шаблоны? 😊