На первый взгляд, если заказчик программного обеспечения точно знает, чего он хочет, и оформляет это в подробном документе на 100-150 страниц, то это самый эффективный подход к выбору решения. Ему достаточно будет пройтись по рынку и «приложить» свое техническое задание к существующим информационным системам. Ту, которая будет соответствовать ТЗ, заказчик и выберет. Теоретически. А на практике?
Получается, что компания сначала потратила деньги на разработку подробного ТЗ, а потом теряет время на поиск несуществующего идеала.
Значительная часть требований технического задания – это описание решений, а не проблем. Клиент сам придумал, как должна работать система, чтобы она решала его бизнес-задачи. Но это вовсе не значит, что его решение самое эффективное.
Гораздо выгоднее подключить к созданию ТЗ потенциального подрядчика — разработчика программного обеспечения. У него уже есть опыт внедрения десятков таких систем, и его опыт поиска самых удобных и выгодных вариантов решений задач заказчика может быть очень полезен.
Главное, что должен сделать заказчик при совместной разработке технического задания – составить перечень функциональных требований. Его можно дополнить формализованным описанием бизнес-процесса, в виде текста или блок-схемы.
| Пункты функциональных требований | Чем это поможет | |
|---|---|---|
| 1 | Есть требования к API и документация с описанием работы с ними | У вас появится возможность интегрировать систему управления закупками с другими информационными системами — причем, без участия разработчика |
| 2 | Есть схема бизнес-процесса, который нужно автоматизировать. В бизнес-процессе выделены обязательные и необязательные этапы — с учетом того, что от необязательных можно безболезненно отказаться | Вы можете максимально точно представить, насколько информационная система соответствует вашему бизнес-процессу, какие доработки вас ожидают и ожидают ли вообще. Появляется возможность проверить соответствие информационной системы в коробочном виде схеме бизнес-процесса |
| 3 | Есть краткое описание обязательных этапов бизнес-процесса | Позволяет детально определить, способна ли информационная система поддерживать бизнес-процесс, сформулировать |
| 4 | Есть краткое описание результатов каждого обязательного этапа бизнес-процесса | Позволяет понять, как в информационной системе происходит переход от этапа к этапу и сравнить этот алгоритм с алгоритмом бизнес-процесса, который будет автоматизирован |
| 5 | Описаны роли пользователей. Лучше, если формат описания будет иметь вид матрицы RACI | Помогает формализовать работу участников бизнес-процесса, распределить их права и обязанности в информационной системе |
| 6 | Описание измеримых эффектов внедрения информационной системы | Возможность измерить результаты позволяет объективно оценить, насколько успешным было внедрение: например, увидеть, что закупки стали проводиться быстрее, а ошибки при оформлении заявок на закупки исчезли. В идеале — измерять эффект может не только заказчик, но и разработчик. Так он сможет предложить корректировки в работе информационной системы для достижения или улучшения ожидаемого эффекта. |
Значимость каждого требования может быть разной — поэтому оценка соответствия программного продукта функциональным требованиям возможна только после их ранжирования. Нужно разделить требования на важные, не важные и те, которыми можно пренебречь. Сделать это можно вместе с разработчиком: по тому же принципу, по которому дорабатывается техническое задание.
Пример блок-схемы, которая описывает бизнес-процесс заказчика
Простой алгоритм совместной доработки ТЗ включает в себя:
- Составление списка требований к системе.
- Pазделение требований из задания на обязательные и необязательные.
- Фильтрацию необязательных требований на нужные (их реализуют в будущем) и ненужные (от них отказываются навсегда).
- Сравнение списка необязательных требований с планом развития информационной системы — возможно, то, что заказчик требует сейчас, уже включено в будущие релизы.
- Сравнение стоимости информационной системы «по версии в ТЗ заказчика» и по новой версии ТЗ.
Подведем итоги: