Союз пользователей и ИТ-специалистов: как написать понятное ТЗ на разработку системы

Чтобы ИТ-поставщик при оценке проекта внедрения не насчитал лишнего, нужно правильно описать требования к системе. На практике встречаются две крайности: либо ТЗ составляют слишком поверхностно, либо в него включают то, чего на самом деле пользователю не нужно. Как не упустить важное и дать поставщику достаточно информации, чтобы уложиться в выделенный бюджет и при этом получить функциональное решение?

Если требования пишет только пользователь

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

При этом поставщик в любом случае не сможет закрыть все требования коробочной функциональностью системы. И вынужден будет либо потратить время (своё и заказчика) на согласование ограничений, либо оценить стоимость реализации ТЗ в полном объёме, что увеличит бюджет в несколько раз.

Это одна крайность. Вторая — когда пользователь считает свою область настолько понятной, что не видит необходимости в каких-либо подробностях вообще. В этом случае в требованиях к автоматизируемым процессам можно увидеть разве что их названия. Но правила построения бизнес-процессов в рамках каждого предприятия индивидуальны, а одни и те же процедуры могут называться совершенно по-разному. И всем знакомое «Управление договорами» для одних — это создание документов из шаблонов и их согласование, а для других — то же самое, но с бюджетированием и управлением закупками. Разница масштабов автоматизации огромна.

Если поставщик недооценил масштабы процессов, то чтобы достичь запланированного бизнес-эффекта, заказчику придётся вложить дополнительную сумму или отложить реализацию целевой модели на будущие проекты по развитию. А если переоценил, то клиент потратит деньги, которые мог бы использовать на другие важные задачи.

Если пишут только ИТ-специалисты

Без технических специалистов ТЗ пишется крайне редко, ведь встраивание новой информационной системы в ИТ-ландшафт — это их задача. А вот айтишники часто составляют требования без привлечения бизнес-пользователей, поскольку считают, что опыт сопровождения текущих систем позволяет им дать исчерпывающее описание задач автоматизации.

ИТ-специалистам, продвигающим инициативу внедрения нового ПО, важны:

• высокая масштабируемость системы,
• безболезненное встраивание в текущую инфраструктуру,
• наличие средств, обеспечивающих информационную безопасность,
• эффективное использование серверных мощностей,
• возможность самостоятельной доработки и развития,
• наличие гибких инструментов интеграции,
• лёгкость в самостоятельном сопровождении,
• лучшее соотношение цены и качества в совокупной стоимости владения системой.

Сосредотачиваясь на технических деталях, ИТ-специалисты теряют бизнес-составляющую: потребности, процессы, подходы. И при прочтении ТЗ складывается впечатление, что заказчик ищет не решение для закрытия конкретных бизнес-задач, а глобальную платформу.

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

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

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

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

Рекомендации

Чтобы получить качественную оценку проекта, при составлении ТЗ:

1. Сосредоточьтесь на том, что важно сделать в рамках текущего проекта. Для глобальных планов существуют отдельные документы, например, концепция автоматизации.
2. Описывайте потребности пользователей, а не проектные решения. Каждая система уникальна, и задача поставщика — предложить вам наиболее эффективное решение на базе своих продуктов.
3. Зафиксируйте основных участников и этапы процессов, перечислите виды документов. Понимание специфики работы в вашей компании позволит оптимально оценить их масштабы.
4. Составляйте требования вместе с пользователями и ИТ-специалистами. Так вы минимизируете число неучтённых требований и обеспечите максимально эффективное использование бюджетов.