Разработка CRM системы на заказ. Что нужно учесть?

Введение

В статье разберем процесс разработки своей CRM и какие нюансы можно встретить на этом пути.

Стадия проработки идеи

Здесь встречаются две крайности: либо очень общее описание, либо попытка все и вся описать сразу, причем в деталях.

Если у вас слишком общее видение будущей CRM (буквально в 2-3 предложениях), это практически никак не продвигает проект вперед - по такому описанию очень сложно давать оценки бюджета, сроков.

Если вы хотите очень детально проработать идею, вы можете потерять много времени на эту проработку, а многое может стать неактуальным уже через 2-3 месяца.

Нужно найти золотую середину - контурное описание границ проекта без углубления в детали реализации и второстепенные вопросы.

Другая ошибка на стадии идеи - думать, что внешняя сторона (консультант, интегратор или просто программист) придумает за вас ваш основной бизнес-процесс.

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

Прорабатывайте и шлифуйте свой уникальный бизнес-процесс, а затем разрабатывайте CRM, которая будет обслуживать этот бизнес-процесс.

Стадию проработки идеи проекта мы оформляем в виде концепта. Здесь можно найти шаблон концепта веб проекта.

Стадия написания технического задания на CRM

ТЗ пишет технический специалист, либо тот кто понимает специфику реализации.

В первую очередь ТЗ пишется для разработчика - чтобы он реализовал то, что требуется заказчику. Заказчику ТЗ нужно для фиксации своих пожеланий.

В целом ТЗ (или микроТЗ на отдельные задачи) - это хороший способ коммуникации между заказчиком и исполнителем. Альтернатива - это конфликты и споры о том, кто как понимает, что по умолчанию должно быть в CRM (здесь будут часто встречаться фразы "ну это же очевидно", "так везде сделано").

ТЗ должно быть детальным. Чем детальнее ТЗ, тем меньше вопросов потом будет при приемке.

Детали защищают как заказчика, так и исполнителя. Детали формируют правильные ожидания.

Если вы пишите ТЗ с опусканием каких-то деталей, то скорее всего где-то придется идти на уступки и договариваться о трактовке по ходу проекта.

ТЗ должно быть только на первую версию программы. Не нужно в ТЗ впихивать все-все пожелания. Лучше детально описать рабочее ядро системы, нежели написать все обо всем понемногу.

Сразу определите четко границы первой версии и пишем ТЗ только под нее.

См. также статью Как мы пишем техническое задание на веб-проект.

Стадия реализации первой версии CRM

На стадии реализации нужен контроль. Сейчас модно говорить о свободе и вреде контроля. Это звучит приятно и для контроллера (меньше работы) и для того, кого контролируют (меньше давления). По факту это просто мы отпускаем вожжи и смотрим что получится.

Контроль нужен, причем динамический. Если все хорошо идет, то контроль можно где-то уменьшать. Если периодически возникают косяки, то контроль усиливается.

По умолчанию необходимо хоть раз в неделю смотреть текущие наработки и давать обратную связь.

Корректирующая обратная связь играет большую роль в проекте. И эти правки важнее того, что есть в ТЗ. Когда пишется ТЗ, то заказчик гораздо меньше знает о системе, нежели до момента, когда он уже ее видит и начинает пробовать пользоваться ей.

Чем раньше к проекту будут привлечены реальные пользователи для сбора отклика, тем лучше будет система отвечать их потребностям.

Вы можете сделать сложную систему вообще не учитывая мнение пользователей. Но не удивляйтесь сопротивлению, когда вы будете ее внедрять.
Дополнительный эффект будет при сопричастности пользователей к созданию. Если человек считает, что он сделал вклад в создание этой системы, разве может он быть против нее?

Стадия внедрения в работу CRM

Внедрение - это боль. Это переход со старых способов работы на новые.

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

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

Ошибки рано или поздно сходят на нет. Важно их оперативно править. Со стороны заказчика важно их точно описывать (скрин, url, иногда видео).

С технической точки зрения в системе должен быть лог ошибок и возможность следить за ходом работы приложения, а также возможность делать периодическую диагностику (выявлять проблемные моменты на ранней стадии).

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

Заключение

Мы рассмотрели стадии разработки CRM системы и возникающие на этих стадия моменты.
Конечно это совсем не исчерпывающий список. Нюансов гораздо больше, некоторые из них проявляются только в отдельных случаях (в силу технических причин, проблемы коммуникации, доверия, сложности бизнес-процессов и т. д.).

Каждый проект сам по себе уникален. Но приняв к сведению идеи из этой статьи, вы снизите риски возможных проблем на своем проекте.

Источник: https://falconspace.ru/blog/razrabotka-crm-sistemy-na-zakaz--chto-nuzhno-uchest