{"id":4859,"title":"\u0422\u0435\u0441\u0442 \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0430\u043a\u0442\u043e\u0432: vc.ru \u0432 \u0432\u0430\u0448\u0438\u0445 \u0440\u0443\u043a\u0430\u0445","url":"\/redirect?component=advertising&id=4859&url=https:\/\/vc.ru\/special\/bettervc&hash=06e04557a2c39e6c33fa846ba405896b7fed5804f421a1db543b59166c87d7da","isPaidAndBannersEnabled":false}

Как правильно составить техническое задание для разработки ИТ-системы

О том, как качественно и понятно составить техническое задание рассказывает старший эксперт практики 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).

{ "author_name": "Лига Цифровой Экономики", "author_type": "self", "tags": [], "comments": 0, "likes": 0, "favorites": 4, "is_advertisement": false, "subsite_label": "unknown", "id": 162861, "is_wide": true, "is_ugc": true, "date": "Wed, 30 Sep 2020 16:47:32 +0300", "is_special": false }
0
0 комментариев
Популярные
По порядку
Читать все 0 комментариев
Вебинар по внедрению цифровых интеллектуальных технологий в рамках Kazan Digital Week – 2021
Клиенты «Открытие Брокер» могут получить статус квалифицированного инвестора в личном кабинете и мобильном приложении

«Открытие Брокер» значительно упростил процедуру присвоения статуса квалифицированного инвестора для своих клиентов. Теперь его можно получить в личном кабинете на сайте и мобильном приложении «Открытие Брокер» в несколько кликов. Новый функционал позволит инвесторам не тратить время на поездку в офис для подачи документов и пользоваться всеми…

Исследование рынка PR 2021: больше новых инструментов, усиление и расширение влияния и значимости функции

Агентство Buman Media совместно с hh.ru провели исследование российского рынка коммуникаций. В нем приняли участие более 100 директоров и руководителей направлений по корпоративным коммуникациям, работающих в различных отраслях. Сегодня, в День PR-специалиста, мы подводим итоги года в коммуникационной отрасли.

Google перестанет пускать в офисы по всему миру сотрудников без прививок от Covid-19 Статьи редакции

Компания перенесла дату выхода сотрудников с удалёнки с 1 сентября на 18 октября из-за вспышки коронавируса.

Как (и зачем) мы полностью переделали интернет-банк. Опыт Альфа-Банка
Очередной баг Тинькова

В пятницу 23.07 начали падать китайские акции, а у меня на тот момент были МОМО и утро началось с -340$. Я решил избавиться от них, дабы не увеличивался минус. Пятница только началась и надо бы исправить это недоразумение. И я полез в TAL Education Group. Сначала заработал 200$, потом 120$, потом ещё 130$. Итого отбил минус, да ещё и заработал…

Как моё сообщество заработало 1,7 млн рублей на VK Donut

Больше шести лет назад Феликс Зинатуллин основал сервис таргетированной рекламы Церебро Таргет и запустил его сообщество ВКонтакте. Теперь там больше 200 тысяч маркетологов и предпринимателей. За год на донатах через VK Donut паблик заработал 1,7 млн рублей. Вот как это вышло.

Феликс Зинатуллин
«Бросил вызов Nike Air Jordan за мировое господство в кроссовках»: как Канье Уэст шёл к своему миллиарду Статьи редакции

Канье Уэст много лет настаивал на том, что он миллиардер, но Forbes признал за ним этот статус только в апреле 2020 года. В 2021-м журнал оценил состояние 44-летнего рэпера в $1,8 млрд

Канье Уэст Architecturaldigest
Нет смысла тягаться с крупным конкурентом, «вдохновившимся» вашим стартапом? Это не так — рассказываю на личном опыте

Привет, меня зовут Роман Рабочий. Три месяца назад я опубликовал здесь статью про свой стартап — секретаря Машу. А спустя два месяца после запуска Маши вышла копия от одного крупного банка. И вчера эстафету перенял известный сотовый оператор. Рассказываю обо всем по порядку.

Duolingo привлекла $521 млн после выхода на биржу с капитализацией $3,7 млрд Статьи редакции

В 2020 году компанию оценили в $2,4 млрд.

Toyota препятствует переходу на электромобили в Конгрессе США и других странах — NYT Статьи редакции

Компания первой запустила производство «гибридов», но с тех пор отстала от конкурентов.

null