После того как вы получите 3-10 предложений от подходящих кандидатов, вам предстоит выбрать из них одного. Хотя в некоторых случаях, если ваш бюджет позволяет, вы можете начать работу над ТЗ параллельно несколькими кандидатами. Через некоторое время будет понятно с кем проще и продуктивнее работать. При этом вы никого не обманываете, т.к. другие исполнители получат деньги за проделанную часть работы.
Какие критерии отбора я бы выделил в первую очередь:
➢ Скорость и полнота ответа. Это показывает, насколько заинтересован исполнитель в проекте. Нет заведомо пустых обещаний (например, сделаем и внедрим за 1-2 недели).
➢ Демо и портфолио. Вам необходимо понять какой backend есть у исполнителя. Делал ли он подобные проекты?
➢ Ценовой диапазон и сроки. Насколько их оценки соотносятся с вашей оценкой? Они не должны отличаться более чем в 3 раза.
Какие действия рекомендуется сделать при выборе исполнителей:
– Просмотреть их сайт, портфолио, кейсы, демонстрации.
– Проверить отзывы исполнителя. Свяжитесь с людьми, которые оставили эти отзывы.Поговорите с ними по скайпу, телефону.
– Дают ли они сразу полезную информацию по проекту? Есть ли у них четкий план по созданию вашей CRM?
– Поищите информацию об исполнителе через поисковые системы и социальные сети. Соотносятся найденные данные с тем образом, который строит исполнитель на своем сайте?
Допустим, вы выбрали одного исполнителя и решили с ним работать. Что дальше? Настало время написать ТЗ.
Некоторые заказчики считают, что ТЗ – это просто формальность и исполнители должны делать его бесплатно. Такое может быть, когда продукт настолько типовой, что ТЗ получается при изменении нескольких параметров в шаблоне документа.
Разработка ТЗ для создания CRM на заказ – это довольно большая и объемная работа, которая требует не только фиксации требований заказчика, но и проработки предметной области клиента, предпроектирования некоторых модулей системы, создания тестовой функциональности с учетом специфики процессов.
Отнеситесь к написанию ТЗ с полной серьезностью. От качества ТЗ в дальнейшем зависит качество реализации системы. К тому же ТЗ может служить прототипом для будущей документации по системе.
Что же должно включать полноценное ТЗ?
➢ Структуру будущего продукта. Для CRM – это состав кабинетов пользователей и их функционала (страниц). Структура – это исходный элемент для всех остальных работ по ТЗ.
➢ Макеты и текстовое описание всего функционала по структуре. Макеты визуализируют ТЗ. Это снижает риски недопонимания между заказчиком и исполнителем Чаще всего исполнители тяготеют к техническому языку, а заказчики – к бизнес-целям. Макеты позволяют общаться на одном языке – все видят один и тот же интерфейс и общаются не на абстрактном уровне, а на уровне кнопок, таблиц, меню и т.д.
➢ Требования по интеграции. Если система связана с внешними ресурсами, то вы должны прописать, как именно система будет взаимодействовать с ними и в каком объеме. Например, интеграция с 1С. Не пишите в ТЗ «Сделать интеграцию с 1С» – 1С содержит сотни таблиц в базе данных. Очень трудоемко сделать интеграцию всех объектов 1С с приложением, да вам это и не нужно в большинстве случаев. Лучше указать, какие именно объекты надо синхронизировать с приложением (клиенты, заказы, единицы измерения, товары и т.д.). Указывайте также предпочтительный способ реализации (например, через веб-сервисы) – это позволит избежать недоразумений на стадии разработки.
➢ Согласен, вы не можете знать всех нюансов. В этом плане вам должен помогать исполнитель, который пишет ТЗ. Задавайте ему максимум вопросов по реализации. Его задача – предоставить вам информацию, а вы на ее основании уже решаете какой вариант выбрать.
➢ Особые требования. Сюда можно отнести требования по производительности (хотя в некоторых случаях это сложно спрогнозировать, т.к. приложение работает не изолированно, а в некоторой среде), требования к браузерам, требования по дизайну и др.
➢ При составлении требований указывайте список браузеров и их версии, для которых должно работать приложение. Некоторые версии (например, IE8) не поддерживают такие порталы как ВКонтакте.
➢ Если говорить о дизайне CRM, то главная его задача – это не мешать пользователю. На мой взгляд, здесь не нужно придумывать велосипед – можно взять готовый шаблон и использовать его.
➢ Проработка «узких мест». Если в вашем проекте есть сложные механизмы, то лучше их проработать на этапе ТЗ. Это снижает риски проекта. В случае если не найдется приемлемого решения, то лучше изменить что-то на этапе ТЗ, а не на этапе разработки системы. Почему? Это дешевле. Раньше обнаружена ошибка – дешевле ее исправить. Самые дорогие ошибки – на этапе эксплуатации. Пример: автоматическая генерация пароля. В начале проекта вы сделали так, что пароль генерируется слишком простой. Сейчас изменить это несложно. Теперь представьте, что у вас система запущена, и в ней работают 100 пользователей. Будет довольно непросто сменить всем пароли (поменять данные в базе, оповестить пользователей, часть пользователей не поймет что произошло и у вас появятся дополнительные расходы на техподдержку).
Как лучше всего организовать процесс написания ТЗ?
Во-первых, не думайте что исполнитель полностью напишет за вас ТЗ. Вернее он напишет, но это будет не совсем то, что вам нужно.
Во-вторых, пытаясь сэкономить на ТЗ, некоторые заказчики делают ТЗ полностью самостоятельно. Тем самым они полностью полагаются на свои решения, которые могут быть неоптимальными с технической точки зрения или с точки зрения удобства пользования (юзабилити).
На мой взгляд, наиболее предпочтительна следующая схема взаимодействия: исполнитель и заказчик работают совместно над ТЗ (например, через сессии по скайпу). Причем исполнитель руководит этим процессом, а заказчик выступает в роли источника знаний о системе. Иными словами, исполнитель спрашивает, а заказчик отвечает. Только исполнитель фиксирует изменения ТЗ. Заказчик периодически анализирует ТЗ. Все понятно? Ничего не упущено? Надо что-то дополнить?
Используя такой подход, мы достигаем того, что обе стороны держат под контролем содержимое и форму ТЗ.
Также стоит упомянуть о случаях, когда очень трудоемко написать ТЗ сразу. Система настолько сложна и быстро меняется, что нет смысла писать сразу большое ТЗ. В этом случае необходимо определить область действия ТЗ. Делайте ТЗ только на конкретную часть системы, например, на блок «База клиентов» или процесс «Обработка заказа от клиента».
