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

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

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

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

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

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

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

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

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

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

Как лучше всего организовать процесс написания ТЗ?

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

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