Пишем коммерческое предложение на разработку сайта

В своих предыдущих постах я уже наверное отмечал, что у заказчика зачастую бывает отличное видение бизнес-задачи, под которую создаётся сайт, но не всегда оказывается чёткое понимание того, каким сайт должен быть. В этом собственно ничего страшного нет, ведь знать всё о сайтах - это прежде всего наша работа. Фрилансеру приходится быть не только программистом, но и аналитиком, умеющим переварить специфику отрасли заказчика в ТЗ для написания конкретного кода.
Составлять полное ТЗ сразу тоже не всегда может оказаться возможным. Не далее чем вчера у меня состоялась встреча с потенциальным клиентом. Он мне говорит - вот мы занимаемся тем-то и тем-то, имеем возможность пополнять сайт тематическими статьями и фотоотчётами, а в результате нам нужно привлечь новых клиентов. Каков будет конечный функционал сайта - для заказчика было не так важно и он предлагал эту задачу решить мне - посмотреть сайты конкурентов и иные материалы, чтобы на основании этого сделать предложение.
Ещё парой недель ранее, другой мой заказчик, с которым мы уже работали, решил делать новую небольшую интра-систему. У них было понимание бизнес-задачи, а также набор экселевских файлов, которыми раньше обходились менеджеры. На основании интервью и анализа этих утилит передо мной встала задача написать коммерческое предложение с описанием функционала для реализации в виде веб-приложения.
Это я клоню к тому, что два документа - коммерческое предложение (КП) и ТЗ нужно чётко различать между собой. Они оба важны и практически всегда взаимо НЕ заменяемы. КП призвано продемонстрировать что и зачем мы будем делать, а в ТЗ уже будут подробности реализации.
Итак, когда я составляю КП оно состоит как минимум из двух основных частей:

1. Общая информация. Здесь нужно определить для чего делается сайт, какая у него планируется целевая аудитория и каким образом ресурс будет ей соответствовать. Описать основные принципы деятельности компании-заказчика, которые сайт должен реализовывать. Задача этого раздела состоит в том, чтобы показать заказчику, что вы правильно поняли его устремления и готовы их реализовать.
2. Описание функционала. Тут можно просто перечислить разделы сайта (или меню приложения, если это не сайт а прикладная система) с кратким описанием их представления, а также, с описанием их предназначения. Т.е. если мы предлагаем на сайте ввести фотогалерею, то нужно обосновать её необходимость исходя из целей работы сайта, определённых выше в "общей информации". К примеру, если компания продаёт услуги по организации дайв-туров, то фотоотчёты о ранее проведённых экспедициях помогут привлечь клиента красотой природы подводного мира и продемонстрировать возможности компании более ярко, чем только текстовая информация.

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

• Краткость. Задача КП не съесть мозг заказчика, а на одной-двух страницах рассказать, как вы собираетесь реализовать его мечту.
• Доступность понимания. Снова к вопросу о мозге. Важно понимать, что термины "домен", "хостинг", "объектный подход", "URL", "Аякс" и прочее - для заказчика могут оказаться тёмным лесом. И посетителей/пользователей сайта в КП лучше называть клиентами компании, а администраторов сайта - сотрудниками компании. Т.е. необходимо войти в роль заказчика и излагать предложение в его категориях мышления. Я говорил своему заказчику - "такая структура подачи информации будет лучше с точки зрения поисковой оптимизации" на что он мне ответил: "А что я буду от этого иметь?". Тогда пришлось переформулировать и сказать что-то вроде: "Больше потенциальных клиентов смогут найти ваш сайт, зайти на него и позвонить вашим менеджерам". Это он понял прекрасно.
• Базирование на пожеланиях заказчика. Всё, что будете писать в КП должно быть не результатом ваших личных измышлений, а плодом анализа пожеланий заказчика и существующих на рынке решений (сайтов конкурентов к примеру).
  
• Информативность. КП может стать не только "открыткой" заказчику, но и хорошей базой для написания ТЗ. Соответственно, нужно составлять КП так, чтобы потом ориентируясь на прописанные в нём принципы можно было легко начать писать ТЗ (а не придумывать его с нуля), ведь по сути, предложенная мной структура КП это и есть техническое задание, только в более общем выражении и терминологии заказчика.

Вот собственно и всё что я хотел написать в этот раз.