Разбор ситуации(кейса) 4 для ПМа. Коммерческое предложение (Proposal)
Продолжая разбор кейсов для ПМа. Вот ссылка на предыдущие разборы кейсов
- Разбор кейса 1. Начало проекта.
- Разбор кейса 2. Риски.
- Разбор кейса 3. Оценка даты завершения и размера команды.
Четвертый кейс будет про разработку коммерческого предложения при заказной разработке ПО для англоговорящих заказчиков.
Условие кейса
В процессе переговоров по новому проекту на заказную разработку клиент ожидает от вас документ коммерческого предложения(proposal) в ответ на свой запрос RFI (Request for information) или тендерное предложение.
Суть проекта: клиент хочет создать внутреннюю корпоративную соц сеть, для неформального общения сотрудников (они могут делать посты а-ля Инстаграм и FB), но клиент контролирует пользователей, приватность информации и может добавлять информационные посты в ленту (важные объявления). Необходимость появилась из-за большого количества офисов по всему миру и такое приложение позволит усилить корпоративную культуру и сблизить коллег из разных стран. В проекте будут следующие части: веб админка, мобильные приложения для iOS и Android.
После оценки входящей информации от клиента, вы предполагаете следующие части проекта: планирование (discovery), дизайн (design), разработка (development) и подготовка к релизу (release). В команду входят разработчики, дизайнеры, бизнес-аналитик, ПМ. Вы хотите дать свое коммерческое предложение только по первой большой фазе проекта, ввиду большого объема проекта для оценки и небольшого времени, которое было выделено для оценки и разработки предложения.
Какие разделы в бы включили в документ предложения и какую информацию предоставили?
Решение
Для начала определимся, для чего составляется Коммерческое Предложение (КП). По определению, КП — это документ, в котором рассказывается о предлагаемой услуге или товаре. Его главная задача — заинтересовать потенциального клиента или покупателя и побудить его заключить контракту на оказание услуги или поставку товара.
В нашем случае КП составляется для того, чтобы убедить клиента приобрести услугу по разработке ПО именно в нашей компании. По сути, весь наш документ — это аргументация, почему наша компания лучше всего подходит для решения задачи или достижения целей клиента.
Основные правила
Правила, которые надо помнить при составлении КП:
- КП — это в первую очередь маркетинговый, продающий документ, и уже потом технический
- КП — это не контракт, он не подписывается и не имеет юридической силы
- Дизайн КП должен быть стандартным, согласно единому дизайн документу вашей компании
- Всё, что не помогает нам продавать, не должно быть в КП
- КП не должно содержать «приложений», подробно описывающих тот или иной процесс или документацию
- Вместе с КП стоит приложить несколько примеров успешных проектов, в идеале как можно более похожих или использующих те же технологии, что и решение, которое мы продаем
- План проекта отсылается клиенту по запросу
- КП должно быть в формате, пригодном для печати на принтере. Очень хорошо для этого подходит PDF, в который можно сконвертировать КП из текстового документа.
- КП составляется на самых ранних стадиях, когда у нас есть только высокоуровневые планы и очень приблизительная оценка бюджета и команды
- Нет стандартного шаблона КП, который подойдет во всех случаях. В каждом случае вам необходимо доработать шаблон под конкретного клиента и его потребности.
Структура КП
Структура КП может различаться в зависимости от многих факторов: доступное время на подготовку, специфика контракта (Fixed Price, T&M, сервисный контракт на поддержку, контракт на фазу бизнес-анализа перед разработкой большого КП на весь проект ), тип клиента (корпорация, стартап, посредник).
Вот пример структуры КП:(нажав на ссылку в левой колонке вы можете сразу перейти к этому разделу в документе КП, составленного по условиям кейса)
Обложка (Title page) | Название документа КП, логотип и название клиента, для которого сделано, дата |
Содержание (Contents) | Страница содержания документа. Хорошей практикой считается добавление такой страницы только когда она не более чем 10% от остального контета, то есть когда КП содержит 12 и более страниц |
Краткое описание проекта/услуги/решения (Executive Summary) | Секции этого раздела:описание компании (маркетинговая информация)описание полученной информации от клиента, на основании которой делается это предложение (RFP, тендер, прямой запрос и т.д)коротко ключевые факты — общая стоимость, рейты, длительность Рекомендации:этот раздел оказывает ключевое влияние на успех всего КП, стоит проработать его детально и внимательно — раздел должен занимать не более 1-2 печатных страниц и содержать достаточно информации для принятия решения клиентом |
Техническое предложение (Technical Proposal) | Техническое описание в КП должно быть сформулировано языком, понятным даже для слабо подготовленного в техническом плане клиента. Для этого стоит избегать сложной лексики, сложных диаграмм и избыточного количества подробностей |
1.1. Общее описание решения (System Overview) | Описание проекта: кто клиент, его бизнес домен, бизнес задачи проекта, общее описание функционала предлагаемого решения, наше понимание запроса/задачи клиента, перечисление предоставленной клиентом документации |
1.2. Содержание проекта (Project Scope) | Перечисление списка частей и высокоуровневых работ проекта. В литературе это упоминается как ИСР — иерархическая структура работ, в английской WBS — work breakdown structure |
1.3. Описание подхода к решению задачи проекта (Solution aim and suggested approach) | Что мы предлагаем сделать для решения задачи, из чего состоит решение, например: мобильное приложение и веб сервис, или веб сервис для клиентов и веб сервис для сотрудников (админка) и так далее.На какие части предлагается поделить весь проект, контрольные точки.Какой подход мы предлагаем, например, классический поэтапный (waterfall) или гибкий итеративный (agile)Примеры дизайна.Этот раздел может содержать подразделы для каждой из фаз проекта, а также отдельный раздел с описанием технологий, диаграммой архитектуры и топологией всей системы. |
1.4. Поставки проекта (Deliverables) | Описание результатов работы над проектом. Например: Мобильное приложение в AppStore Веб сервис, работающий в продуктовом окружении UI дизайн приложения Документ спецификаций (SRS) Исходный код Пользовательская документация |
1.5. Команда проекта (Project Team) | Предполагаемая команда проекта: роли, количество членов команды в каждой роли, описание задач и зоны ответственности. По запросу клиента можно указать CV конкретных людей из вашей компании, которые обладают соответствующими компетенциями |
1.6. План проекта (Project Plan) | Высокоуровневый примерный временной план проекта с указанием контрольных точек, фаз и поставок. Чаще всего предоставляется в виде диаграммы Ганта но возможно и другое представление, например в виде ленты времени или просто таблицы с перечислением контрольных точек и фаз |
Коммерческое предложение (Commercial Proposal) | финансовая сторона предложения, без избыточных деталей |
2.1. Бюджет и сроки (Estimated Costs and Timelines) | Укажите примерную стоимость всего проекта целиком.Расписание платежей этой суммы по частям, часто привязанное к контрольным точкам проекта или к крупным поставкам и фазам. Укажите рейт карту (если это не проект с фиксированной ценой) только если об этом попросил клиент или это необходимо для обьяснения стоимости проекта |
2.2. Допущения (Project Assumptions) | Предположения и допущения, на основе которых мы планировали наше решение для задач проекта. Примеры допущений: -мобильное приложение будет поддерживать только портретную ориентацию девайса -клиент предоставит файлы перевода для локализации -библиотека Х будет использована для генерации QR кода -админская панель будет разработана с использованием open source библиотеки YAdmin Допущений не должно быть много, оптимально не более 5-6 допущений в списке. Допущения должны быть только о том, что влияет на стоимость проекта или они должны подкреплять и обьяснять его стоимость. |
О компании (about X) | Маркетинговая информация вашей компании: факты, регалии, партнеры, преимущества и так далее. Не более нескольких страниц, больше графической информации, чем текста Приведите несколько примеров похожих проектов, которые вы успешно сделали в прошлом для других клиентов. |
Дополнительно можно добавлять такие разделы описывающие ваш подход к работе, предлагаемую методологию, которой вы следуюете и другую информацию, которая поможет вам продать проект, но не стоит увлекаться — никто не будет читать десятки страниц предложения внимательно, скорее обратят внимание на несколько самых важных разделов, необходимых для принятия решения. Именно поэтому раздел с кратким описанием решения (executive project summary) и раздел со стоимостью и финансовой информацией (Estimated costs and timelines) часто являются ключевыми, а остальные разделы служат для их дополнительной поддержки.
Пример КП составленный по описанной структуре для проекта из описания кейса