Разработка технических заданий на систему
Две крайности написания ТЗ и как найти свой баланс
Подробное техническое задание
Описать все детали. Как можно больше и подробнее. Ещё подробнее…
Декларируемые цели подробного ТЗ:
- Снизить неопределенность и риски проекта
- Уменьшить вероятность ошибок при настройке системы
- Исключить возможности для разночтения
- Предусмотреть все нюансы и пожелания пользователей
- Как можно точнее просчитать трудоемкость и стоимость настройки информационной системы
- Создать идеальный документ, к которому можно будет апеллировать при тестировании и приемке системы
До какой-то степени детализация технического задания действительно работает на достижение этих целей. Но неизменно наступает момент, когда дальнейшее описание подробностей в ТЗ теряет смысл и приводит лишь к удорожанию и росту рисков проекта.
Риски разработки излишне детализированного ТЗ
- затягивание времени проекта
- бизнес меняется, и ТЗ можен оказаться устаревшим к моменту написания
- увеличение стоимости разработки технического задания (и проекта в целом)
- документ на 100500 листов, который никто не будет в состоянии внимательно и вдумчиво прочитать
Техническое задание «на салфетке»
Не тратить время на описание, ведь «и так все понятно»
Декларируемые цели настройки без ТЗ:
- Внедрить систему «как можно быстрее», уменьшить время проекта
- Сэкономить деньги на этапе «написания кучи бумаг»
На сегодня есть гибкие технологии (Agile) создания и внедрения информационных систем предприятий, и построение системы «на лету» действительно возможно. Тем не менее, это требует достаточно высокого уровня управленческой зрелости, а также доверия между исполнителем и заказчиком. И даже в случае использования Agile-подходов целесообразно фиксировать в документах цели создания информационной системы и контуры движения к этим целям на каждом из шагов (спринтов).
Риски разработки информационной системы без ТЗ
- получить в результате «не то, что хотели»
- конфликты между разработчиком и заказчиком на этапе приемки системы (не к чему апеллировать)
- возникновение новых требований и пожеланий пользователей и бесконечные доработки
В каждом конкретном проекте баланс разумной детализации технического задания находится в разной точке. В зависимости от автоматизируемых задач, качества диагностики и оценки, уровня управленческой зрелости Заказчика и Исполнителя, качества подбора и адаптации управленческих методик под задачи, опыта взаимодействия и уровня доверия между специалистами Заказчика и Исполнителя.
Для сдвига баланса в сторону «внедрить информационную систему быстро и качественно» при разработке технического задания мы рекомендуем (в дополнение к работе по принципам AGILE):
- Доверять разработку технических заданий специалистам-практикам, имеющим подтвержденный опыт успешных внедрений.
- Разрабатывать ТЗ под конкретную платформу (с учетом её специфики и возможностей)
- При разработке техзаданий использовать «прототипирование» (в процессе подготовки ТЗ делается настройка некоторых элементов будущей информационной системы сразу в программном продукте)
- Использовать для разработки информационных систем предприятий гибкие программные продукты, позволяющие с небольшими затратами вносить изменения в настроенные модули
В любом случае, на этапе разработки технического задания на информационную систему целесообразно применить принцип «разумной достаточности», и делать не «идеальный документ», а тот, который позволит не спорить о границах проектах (как «вширь», так и «вглубь») и эффективно выстроить совместную работу команд Заказчика и Исполнителя в соответствии с согласованным подходом к управлению проектом. Давайте просто посмотрим на ваши задачи и вместе подумает — как именно их можно решить быстрее.
