О том, как качественно и понятно составить техническое задание рассказывает старший эксперт практики ERP SAP группы компаний Лига Цифровой Экономики, Екатерина Синица.
Типичные ошибки при составлении ТЗ
ТЗ предназначено для окончательного формулирования требований к продукту проекта, в нашем случае – к информационной системе (ИС). Большинство проблем, связанных с разработкой и согласованием ТЗ, вызвано неполным охватом всех видов требований при их анализе. Напомним, они делятся на функциональные (требования к тому, ЧТО должна делать ИС) и нефункциональные (требования к тому, КАК должна функционировать ИС).
При анализе функциональных требований аналитик сталкивается со всем многообразием проблем нечеткого и неполного формулирования требований заказчиком. Чтобы обеспечить их полноту и непротиворечивость, полезно выстраивать иерархию (дерево) требований, на вершине которой будет цель проекта, на следующем уровне – бизнес-требования (понимание, зачем данная ИС нужна и какие бизнес-потребности удовлетворяет), еще ниже, раскрывая каждое бизнес-требование, будут располагаться пользовательские требования (бизнес-сценарии, user stories или use cases), а в самом низу – детальные функциональные требования с описанием действий ИС в каждом конкретном сценарии.
Анализируя нефункциональные требования, чаще всего забывают или недостаточно хорошо прорабатывают требования к интеграции со смежными системами. Чтобы снизить этот риск, необходимо привлекать к разработке ТЗ архитектора ИС и изучать ИТ-ландшафт заказчика.
Также часто сложность представляет анализ системных требований (какие лицензии нужны, на каком оборудовании будет размещаться ИС) и требований к безопасности (аутентификация пользователей, обеспечение отказо- и катастрофоустойчивости системы, разработка частной модели угроз). Привлекайте в качестве источников требований специалистов профильных служб заказчика – поддержки пользователей и информационной безопасности. Их требования и рекомендации необходимо учитывать наравне с функциональными требованиями бизнес-заказчика.
Отдельная и очень большая проблема при анализе нефункциональных требований к ИС – работа с требованиями к интерфейсам. Здесь часто можно встретить слова об «удобстве», «эстетической привлекательности», «соответствии мировым тенденциям дизайна» и прочие образцы нечетких, субъективных, непроверяемых требований, реализовать и протестировать которые, вероятнее всего, не удастся. Лекарство от этой беды – детализация (попробуйте вместе с заказчиком расписать по пунктам, что означает требование «удобство для пользователя») и нахождение подходящих шкал для оценки степени реализации каждого такого требования. Иногда удается найти объективную, всеми признанную шкалу – например, взять цветовую схему интерфейса из корпоративного брендбука заказчика.
Частой ошибкой при разработке ТЗ является недостаточная детализация требований. Настройки и сценарии работы с ИС могут быть описаны слишком общо и поверхностно, целевые процессы формализуются на слишком высоком уровне. И когда дело доходит до реализации этих требований, у разработчиков возникает огромное количество вопросов. Чтобы дать максимально качественный результат этапа проектирования в виде ТЗ, целесообразно проводить:
1) Структурный анализ – моделирование структуры, понимание компонентов ИС и взаимосвязи между этими компонентами;
2) Анализ процессов – моделирование рабочего взаимодействия всех участников процесса, в котором предполагается задействовать ИС;
3) Функциональный анализ – моделирование всех возможных сценариев работы ИС и ее взаимодействия с акторами (пользователями) и смежными системами;
4) Информационный анализ – моделирование структуры данных (выделение объектов и их атрибутов, определение взаимосвязей между объектами) и потоков прохождения этих данных по процессам;
5) Анализ интерфейсов – моделирование (а в идеале прототипирование) пользовательских интерфейсов, проектирование рабочих мест пользователей.
Ошибки проектирования хорошо видны задолго до начала разработки, если мы пытаемся представить себе механизм их проверки. Неслучайно в ГОСТ 34.х документ «Программа и методика испытаний» является приложением к ТЗ. Настоятельно рекомендуется формировать сценарии тестирования ИС одновременно с фиксированием требований к этой ИС. Это позволит существенно повысить качество проектирования.
Как сделать ТЗ понятным для всех участников проекта
Отдельная большая проблема на этапе разработки ТЗ – это его согласование. заказчик, который не очень хорошо разбирается в технических аспектах ИС, скорее всего, будет испытывать большие опасения, подписывая обширное ТЗ. Опасения связаны с несколькими моментами:
1. Банальное непонимание технических нюансов. Заказчик не будет подписывать то, что ему непонятно. Он передаст ТЗ на согласование в смежные структуры, профильные подразделения, экспертам и специалистам всех смежных служб – и этот процесс может затянуться на несколько месяцев. Такой проблемы может не возникнуть, если до начала согласования ТЗ, а в идеале – до начала его разработки, вы с заказчиком договоритесь о формировании рабочей группы, в которую войдут специалисты всех служб клиента, с которыми нужно будет согласовать документ. Этих людей вы будете задействовать в качестве источников требований, их мнению основной заказчик сможет доверять.
2. Страх, что после утверждения ТЗ будет невозможно внести изменения в требования к результатам проекта. Чтобы снять эти опасения и иметь возможность делать проекты в постоянно меняющейся бизнес-среде, были сформулированы принципы гибкой разработки Agile Manifesto. Но не все заказчики знают эти принципы, и не все команды им следуют. Лучше в самом начале договориться с заказчиком о порядке управления изменениями в требованиях на протяжении всего проекта. Тогда и для вас, и для заказчика согласованное ТЗ станет основой, «печкой» для начала разработки ИС, но ни в коей мере не терминальным ограничением на ее функциональность.
3. Базовое недоверие к поставщику. Заказчик может бесконечно долго вычитывать и придираться к малейшим шероховатостям в тексте ТЗ только потому, что ему кажется, что исполнитель некомпетентен, неаккуратен и все сейчас сломает. Этот страх снимается только опытом взаимодействия с данным клиентом. Именно поэтому так важна лояльность старых заказчиков – с ними и ТЗ быстрее согласовываются, и проекты легче делаются. Работая с заказчиком впервые, не экономьте на прототипах – если он увидит, что вы и впрямь умеете делать крутые решения, доверие к вашей команде возрастет.
Подводные камни
Форматирование. Как ни странно, очень много сил и времени у команды может уйти на переделывание ТЗ в тот формат, который нужен заказчику. Рекомендуется заранее, до начала разработки ТЗ, согласовать с клиентом формат, а в идеале попросить в качестве шаблона ранее согласованное ТЗ по схожему проекту.
Забытые требования к эксплуатации. Мы, как правило, увлекаемся проектированием самой ИС, а на продумывание структуры пользовательской документации, программы обучения, подходов к миграции данных – всего того, без чего наша ИС никогда не сможет полноценно работать – времени часто не остается.
Внутреннее согласование. Очень часто разработчиков и тестировщиков не приглашают к согласованию ТЗ. А это неправильно, потому что только эти специалисты смогут вовремя заметить существенные ошибки, которые заказчик, весьма вероятно, пропустит.
Общая рекомендация – если вы хотите, чтобы разработка, согласование и последующая реализация ТЗ не представляли собой череду неразрешимых проблем и мучений, используйте опыт предшественников, обобщенный в очень скучных, но таких полезных книжках, как:
a. ГОСТ серии 34.х и 19.х;
b. Стандарты ИСО/МЭК по системной инженерии;
c. Методологии внедрения конкретного ПО (ASAP, MSF, RUP и т. д.);
d. Рекомендации Свода знаний по бизнес-анализу (BABOK).