На мой взгляд, наиболее предпочтительна следующая схема взаимодействия: исполнитель и заказчик работают совместно над ТЗ (например, через сессии по скайпу). Причем исполнитель руководит этим процессом, а заказчик выступает в роли источника знаний о системе. Иными словами, исполнитель спрашивает, а заказчик отвечает. Только исполнитель фиксирует изменения ТЗ. Заказчик периодически анализирует ТЗ. Все понятно? Ничего не упущено? Надо что-то дополнить?
Используя такой подход, мы достигаем того, что обе стороны держат под контролем содержимое и форму ТЗ.
Также стоит упомянуть о случаях, когда очень трудоемко написать ТЗ сразу. Система настолько сложна и быстро меняется, что нет смысла писать сразу большое ТЗ. В этом случае необходимо определить область действия ТЗ. Делайте ТЗ только на конкретную часть системы, например, на блок «База клиентов» или процесс «Обработка заказа от клиента».
При этом желательно иметь план внедрения модулей системы. Например, в этом году мы внедрим модули 1-5, а в следующем – 6-9 модули.
Из опыта вспоминаются ситуации, когда некоторые заказчики хотят выполнить очень большой проект за один этап, например, реализовать аналог Avito.ru. Желание заказчика понятно – он хочет избежать риска получить часть продукта, ведь ему нужен целостный продукт. Сам не понимая того, он движет проект к катастрофе, т.к. подобные проекты невозможно сделать одним куском за один раз. Здесь действует цикл «задумка – реализация – получение обратной связи – анализ». Вспомните, Windows не сразу стал тем, что он есть сейчас.
Есть и обратные примеры, когда разработка ведется фрагментарно. Новые функции появляются без всякого плана, спонтанно. Это тоже плохой вариант развития ситуации, поскольку теряется фокус и функции добавляются хаотично.
Очень важный момент. Обе эти ситуации порождает заказчик, а не исполнитель! Именно заказчик определяет стиль стратегического управления продуктом. Исполнителю остается только разве что пожимать плечами и подчиниться пожеланию заказчика. Если у вас большой проект, то имейте стратегический план его развития и не пишите большое ТЗ сразу на всю систему.
Итак, вы нашли исполнителя, написали совместно с ним ТЗ. Пора приступать к разработке CRM. В следующей главе мы рассмотрим, как управлять проектом со стороны заказчика, какие бывают подводные камни и как построить взаимодействие с командой разработки.
Глава 4. Реализация проекта и внедрение системы
Итак, начинаем проект по созданию CRM-системы. Что нужно сделать в первую очередь? Заключить договор. Заключение договора более предпочтительный способ, чем другие.
Работа по безопасной сделке, например, через fl.ru подразумевает использование третьей стороны в качестве арбитража между вами и исполнителем. Тем самым вы предоставляте доступ к своим коммерческим данным третьей стороне. На мой взгляд, подобные сервисы – это некоторый компромисс между официальными договорами и работой без договора.
Работа без договора. Здесь нюанс в том, что разработка системы предполагает длительное сотрудничество. В случае создания простого сайта визитки, возможно, лучше работать без договора (или по договору оферты). Но в случае создания большой серьезной системы у вас должны быть гарантии, что исполнитель не испарится внезапно.
Что прописывать в договоре? В первую очередь – это права на систему, сроки, бюджет и порядок приемки. Обычно такой договор составляется подрядчиком (скорее всего, у него есть типовой договор). Внимательно читайте эти пункты, особенно порядок приемки.