Руслан Раянов: Как создать свою CRM

Какие действия рекомендуется сделать при выборе исполнителей:

– Просмотреть их сайт, портфолио, кейсы, демонстрации.

– Проверить отзывы исполнителя. Свяжитесь с людьми, которые оставили эти отзывы.Поговорите с ними по скайпу, телефону.

– Дают ли они сразу полезную информацию по проекту? Есть ли у них четкий план по созданию вашей CRM?

– Поищите информацию об исполнителе через поисковые системы и социальные сети. Соотносятся найденные данные с тем образом, который строит исполнитель на своем сайте?

Допустим, вы выбрали одного исполнителя и решили с ним работать. Что дальше? Настало время написать ТЗ.

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

Разработка ТЗ для создания CRM на заказ – это довольно большая и объемная работа, которая требует не только фиксации требований заказчика, но и проработки предметной области клиента, предпроектирования некоторых модулей системы, создания тестовой функциональности с учетом специфики процессов.

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

Что же должно включать полноценное ТЗ?

➢ Структуру будущего продукта. Для CRM – это состав кабинетов пользователей и их функционала (страниц). Структура – это исходный элемент для всех остальных работ по ТЗ.

➢ Макеты и текстовое описание всего функционала по структуре. Макеты визуализируют ТЗ. Это снижает риски недопонимания между заказчиком и исполнителем Чаще всего исполнители тяготеют к техническому языку, а заказчики – к бизнес-целям. Макеты позволяют общаться на одном языке – все видят один и тот же интерфейс и общаются не на абстрактном уровне, а на уровне кнопок, таблиц, меню и т.д.

➢ Требования по интеграции. Если система связана с внешними ресурсами, то вы должны прописать, как именно система будет взаимодействовать с ними и в каком объеме. Например, интеграция с 1С. Не пишите в ТЗ «Сделать интеграцию с 1С» – 1С содержит сотни таблиц в базе данных. Очень трудоемко сделать интеграцию всех объектов 1С с приложением, да вам это и не нужно в большинстве случаев. Лучше указать, какие именно объекты надо синхронизировать с приложением (клиенты, заказы, единицы измерения, товары и т.д.). Указывайте также предпочтительный способ реализации (например, через веб-сервисы) – это позволит избежать недоразумений на стадии разработки.

➢ Согласен, вы не можете знать всех нюансов. В этом плане вам должен помогать исполнитель, который пишет ТЗ. Задавайте ему максимум вопросов по реализации. Его задача – предоставить вам информацию, а вы на ее основании уже решаете какой вариант выбрать.

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

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

➢ Если говорить о дизайне CRM, то главная его задача – это не мешать пользователю. На мой взгляд, здесь не нужно придумывать велосипед – можно взять готовый шаблон и использовать его.

➢ Проработка «узких мест». Если в вашем проекте есть сложные механизмы, то лучше их проработать на этапе ТЗ. Это снижает риски проекта. В случае если не найдется приемлемого решения, то лучше изменить что-то на этапе ТЗ, а не на этапе разработки системы. Почему? Это дешевле. Раньше обнаружена ошибка – дешевле ее исправить. Самые дорогие ошибки – на этапе эксплуатации. Пример: автоматическая генерация пароля. В начале проекта вы сделали так, что пароль генерируется слишком простой. Сейчас изменить это несложно. Теперь представьте, что у вас система запущена, и в ней работают 100 пользователей. Будет довольно непросто сменить всем пароли (поменять данные в базе, оповестить пользователей, часть пользователей не поймет что произошло и у вас появятся дополнительные расходы на техподдержку).