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