Как системному аналитику грамотно составить ТЗ

Ah, техническое задание… Этот загадочный документ, который одни считают бюрократической блажью, а другие — священным писанием проектной документации. И знаете что? Оба лагеря ошибаются (впрочем, как обычно).

Представьте, что вы заказываете костюм у портного, не указав ни размера, ни фасона, ни материала — просто «сделайте красиво». Абсурд? А ведь именно так часто поступают при заказе программного обеспечения. «Нам нужна система автоматизации. Чтобы все было удобно и работало быстро». И потом искренне удивляются, почему результат не оправдал ожиданий (спойлер: потому что их никто не описал).

Техническое задание — это не просто документ с печатью и подписью генерального директора (хотя и это важно, чего уж там). Это своего рода «договор о намерениях» между заказчиком и исполнителем, детальная карта проекта с четко обозначенными границами, требованиями и ожиданиями. Причем важен он не только для крупных государственных проектов с их любовью к ГОСТам, но и для любого проекта, где есть хотя бы минимальная сложность и больше одного участника.

И да, я знаю, что некоторые команды гордо заявляют «мы работаем без ТЗ, у нас agile». Что ж, это их право — так же, как право врача работать без диагноза, просто выписывая таблетки наугад. Только потом не стоит удивляться, почему проект превратился в бесконечную череду переделок и «а вот еще бы хорошо добавить…».

Основные мифы о техническом задании

Знаете, что общего между ТЗ и Йети? О них ходит множество мифов, но мало кто видел настоящий экземпляр (особенно Йети, с ТЗ ситуация чуть получше). Давайте разберем самые популярные заблуждения, которые я регулярно слышу на встречах с клиентами (обычно где-то между «нам нужно как у Apple» и «сделаем MVP за две недели»).

• Миф №1: «ТЗ — это просто формальный документ для галочки» Ага, а брачный контракт — это просто бумажка для бюрократов. До первого серьезного конфликта, конечно. ТЗ — это ваш спасательный круг, когда заказчик говорит «но мы же хотели совсем другое» (спойлер: нет, не хотели, вот документ с подписями).
• Миф №2: «ГОСТ 34 безнадежно устарел» Забавно, но те же люди обычно не считают устаревшими колесо или электричество. ГОСТ 34 описывает базовые принципы создания систем, которые актуальны независимо от того, используете вы перфокарты или квантовые компьютеры. К тому же, в 2022 году стандарты обновились — правда, об этом знают немногие (видимо, слишком заняты рассказами об устаревших ГОСТах).
• Миф №3: «ТЗ нужно только для госсектора» А документы на машину нужны только для ГИБДД, да? На самом деле, четкое ТЗ нужно везде, где есть сложные проекты и необходимость договариваться. То есть практически везде, если вы не пишете калькулятор для себя любимого.
• Миф №4: «Чем толще ТЗ, тем оно лучше» О да, особенно если измерять качество проекта в килограммах документации! На самом деле, хорошее ТЗ должно быть как юбка — достаточно длинным, чтобы охватить всё важное, но достаточно коротким, чтобы оставаться интересным (простите за сексистскую метафору, но она слишком хорошо подходит).
• Миф №5: «Разработчики и так всё поймут» Конечно, ведь все разработчики — телепаты и экстрасенсы. А если серьезно, даже самые гениальные программисты не смогут реализовать то, что существует только в воображении заказчика. Особенно учитывая, что в воображении заказчика это обычно выглядит как-то иначе каждый вторник.

Структура технического задания

Давайте поговорим о том, как должно выглядеть правильное ТЗ. И нет, ответ «как 200 страниц мелкого текста» — неправильный (хотя я встречал и такое, причем половина страниц была заполнена копипастой из других проектов).

Введение (или «Давайте познакомимся»)

Здесь мы рассказываем, кто все эти прекрасные люди и организации, решившие создать новую систему. Название проекта (желательно без креатива в стиле «Суперпупермегасистема 3000»), заказчик, исполнитель — всё как в приличном обществе. Плюс краткое описание системы, чтобы случайный читатель понял, о чём вообще речь.

Цели и задачи проекта (или «Зачем мы здесь собрались»)

Самый важный раздел, хотя многие почему-то считают его формальностью. Здесь мы отвечаем на главный вопрос: «Что мы хотим получить в итоге?» И нет, «крутую систему» — это не ответ. Цели должны быть конкретными и измеримыми, как в старом добром SMART (помните такое из курсов менеджмента?).

Требования к функциональности (или «Что система должна уметь»)

Это как список способностей для персонажа в RPG, только вместо «Огненный шар 80-го уровня» у нас «Автоматическое формирование отчетов по заданным критериям». И да, тут нужны конкретные примеры: не просто «система должна уметь работать с данными», а «система должна обрабатывать CSV-файлы объемом до 1 ГБ с временем загрузки не более 30 секунд».

Требования к совместимости (или «С кем нашей системе придется дружить»)

Знаете, что общего между корпоративной системой и подростком? Оба должны как-то уживаться с окружающим миром, даже если очень не хочется. Только в случае с системой мы можем четко прописать правила этого «общения» заранее. И да, это очень важная часть ТЗ, о которой часто забывают (а потом удивляются, почему новенькая система не дружит с древним сервером бухгалтерии).

Технические требования (или «На чем это будет работать?»)

• Требования к серверам (и нет, фраза «чем мощнее, тем лучше» не считается)
• Минимальные характеристики рабочих станций (потому что не у всех последний MacBook Pro)
• Сетевая инфраструктура (включая максимально допустимые задержки и требования к пропускной способности)
• Периферийное оборудование (принтеры, сканеры и прочие «а это нам тоже понадобится»)

Программная совместимость (или «С каким софтом придется дружить?»)

• Поддерживаемые операционные системы (и их версии – да, это важно!)
• Требования к браузерам (потому что «во всех браузерах» обычно означает «ни в одном нормально»)
• Зависимости от сторонних библиотек и фреймворков (спойлер: их всегда больше, чем кажется изначально)
• Совместимость с системами виртуализации (если применимо)

Интеграционные требования (или «Как общаться с внешним миром?»)

• Поддерживаемые протоколы обмена данными (REST, SOAP, или может, голуби почтовые?)
• Форматы данных для интеграции (XML, JSON, CSV и другие любимые программистами аббревиатуры)
• Требования к API (включая версионирование, потому что API без версий – это как суп без соли)
• Ограничения по безопасности при интеграции (потому что «просто открыть порт» – не лучшая идея)

И помните: хорошо описанные требования к совместимости – это как правила дорожного движения. Может быть, не самое увлекательное чтение, но точно лучше, чем разбираться с последствиями их отсутствия.

Лайфхак: создайте матрицу совместимости, где по одной оси будут компоненты вашей системы, а по другой – всё, с чем они должны взаимодействовать. Помогает выявить потенциальные проблемы на раннем этапе (и да, такая таблица отлично смотрится в приложении к ТЗ).

Требования к производительности (или «Насколько быстро всё должно летать»)

Раздел, где мы определяем, будет ли наша система Ferrari или старым «Запорожцем». Сколько пользователей одновременно, сколько операций в секунду, какой объем данных. И главное — никаких расплывчатых формулировок типа «система должна работать быстро» (спойлер: для разных людей «быстро» — это очень разные вещи).

Интерфейсные требования (или «Как это должно выглядеть»)

Тут описываем всё, что касается взаимодействия с пользователем и другими системами. И нет, фраза «интерфейс должен быть интуитивно понятным» запрещена под страхом расстрела (метафорического, конечно). Нужны конкретные требования: расположение элементов, логика навигации, форматы данных для интеграции.

Требования к безопасности (или «Как не дать взломать всё на свете»)

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

Ограничения и допущения (или «Чего система делать не будет»)

Возможно, самый недооцененный раздел ТЗ. Здесь мы честно говорим, чего НЕ будет в системе. Это как список противопоказаний на лекарстве — неприятно читать, но очень важно знать заранее.

Условия эксплуатации (или «В каких условиях это должно выжить»)

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

Требования к физическому окружению:

• Температурный режим (и нет, фраза «главное, чтобы не плавилось» не подойдет)
• Влажность (потому что серверы, как и люди, не любят сауну)
• Электропитание (включая допустимые перепады напряжения и требования к ИБП)
• Физическая безопасность (от «закрывать дверь на ключ» до «биометрическая аутентификация с анализом ДНК» – в зависимости от паранойи заказчика)

Требования к надежности:

• Время восстановления после сбоев (потому что «когда-нибудь заработает» – это не метрика)
• Допустимое время простоя (спойлер: «никогда» – это не реалистичное значение)
• Режим резервного копирования (потому что «авось не удалится» – плохая стратегия)
• План аварийного восстановления (или «что делать, когда всё пошло не так»)

Требования к масштабируемости:

• Пиковые нагрузки (сколько пользователей одновременно могут решить, что им срочно нужен отчет)
• Объемы данных (спойлер: через год их будет в два раза больше, чем вы планировали)
• Географическое распределение (от «все сидят в одном офисе» до «филиалы на Марсе»)
• Возможности расширения (потому что система должна расти вместе с бизнесом)

Лайфхак: составьте таблицу «что будет, если…» и пропишите реакцию системы на разные ситуации. Например:

• Что будет, если отключат электричество?
• Что будет, если температура поднимется до +35°C?
• Что будет, если количество пользователей вырастет в 10 раз?

И помните: хорошо описанные условия эксплуатации – это как инструкция к дорогому вину. Вроде бы мелочь, но разница между «хранить при комнатной температуре» и «хранить при 18°C в темном месте» может стоить очень дорого.

Помните: хорошая структура ТЗ — это как хороший скелет: вроде и не видно, но без него всё разваливается. И да, можете сохранить эту структуру себе в закладки — она не раз спасет вам жизнь (ну, или хотя бы нервы).

Как правильно разрабатывать ТЗ?

Или, как я это называю, «Руководство по превращению хаоса в структурированный документ без потери рассудка» (спойлер: последнее не гарантируется).

Немного теории, или «Почему ГОСТ всё-таки был прав»

Прежде чем нырнуть в практические шаги разработки ТЗ, давайте сделаем небольшой экскурс в теорию. Нет-нет, не убегайте! Я обещаю, что не буду цитировать ГОСТы целиком (хотя, признаюсь, искушение было).

Согласно стандартам (тем самым, которые «безнадежно устарели», помните?), создание автоматизированной системы проходит через несколько стадий:

1. Формирование концепции (или «Что мы вообще хотим?»)
   • Исследование предметной области
   • Оценка целесообразности создания системы
   • Формирование требований пользователей
2. Техническое задание (или «Как это должно работать?»)
   • Детализация требований
   • Определение функциональных характеристик
   • Согласование с заказчиком
3. Эскизный проект (или «Набросок будущего»)
   • Предварительные проектные решения
   • Оценка реализуемости
4. Технический проект (или «Теперь по-взрослому»)
   • Детальные проектные решения
   • Разработка алгоритмов
   • Проектирование базы данных
5. Рабочая документация (или «Инструкция по сборке»)
   • Разработка программ
   • Разработка эксплуатационной документации
6. Ввод в действие (или «Поехали!»)
   • Подготовка объекта автоматизации
   • Обучение персонала
   • Проведение испытаний
   • Сдача в эксплуатацию

И знаете что? В этой последовательности есть своя логика. Это как строительство дома: сначала проект, потом фундамент, и только потом стены и крыша. А не как у некоторых: «Давайте сначала построим, а потом разберемся, что это получилось».

В современных IT-проектах эти стадии могут называться по-другому и идти в немного другом порядке (привет, agile!), но суть остается той же: сначала думаем, потом делаем. А техническое задание? Оно как раз находится на стыке между «думаем» и «делаем», что делает его критически важным документом.

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

Шаг 1. Определение целей проекта (или «Куда бежим?»)

Начнем с самого забавного — попытки понять, чего же на самом деле хочет заказчик. И нет, «как у Apple, только лучше» — это не цель. Тут нужно копать глубже: почему возникла потребность в новой системе? Какие проблемы она должна решить? Какой результат будет считаться успешным?

Лайфхак: если заказчик не может внятно объяснить цель проекта за 2-3 предложения — у вас проблемы. Большие проблемы.

Шаг 2. Сбор требований (или «Охота за хотелками»)

Это как собирать пазл, только все детали постоянно меняют форму, а некоторые активно сопротивляются сборке. Важно собрать требования от всех заинтересованных сторон:

• Бизнес-требования (что хочет руководство)
• Пользовательские требования (что нужно конечным пользователям)
• Технические требования (что возможно реализовать в принципе)

При этом помните: каждое «было бы здорово добавить» увеличивает стоимость и сроки проекта. Иногда экспоненциально.

Шаг 3. Согласование с заинтересованными сторонами (или «Семь кругов ада»)

Здесь начинается самое интересное — попытка привести всех к общему знаменателю. Спойлер: это почти невозможно, но очень необходимо. Каждая сторона будет отстаивать свои интересы, и ваша задача — найти баланс между «хотелками» и реальностью.

Полезный совет: заведите табличку противоречащих требований. Она пригодится, когда начнутся споры «а вот Маша из бухгалтерии сказала…».

Шаг 4. Разработка структуры документа (или «Складываем пазл»)

Теперь, когда у нас есть куча разрозненных требований, нужно сложить из них что-то осмысленное. Используйте структуру, которую мы обсуждали ранее, но не бойтесь адаптировать её под специфику проекта.

Главное правило: любой человек с базовым пониманием предметной области должен суметь прочитать ваше ТЗ и понять, о чём речь.

Шаг 5. Оценка и уточнение требований (или «Фильтруем бред»)

На этом этапе нужно пройтись по всем требованиям и задать себе три вопроса:

• Это реально можно сделать? (технически)
• Это реально нужно делать? (с точки зрения бизнеса)
• Это можно проверить? (с точки зрения тестирования)

Если хотя бы на один вопрос ответ «нет» — требование нужно переформулировать или удалить.

Шаг 6. Итоговое согласование и утверждение (или «Последний бой»)

Финальный этап, где документ проходит последнюю проверку и собирает подписи. И помните: подпись на ТЗ — это как подпись на векселе. Теоретически её можно оспорить, но лучше семь раз проверить, прежде чем подписывать.

Круговая диаграмма показывает распределение типов требований в техническом задании

Бонусный совет: держите под рукой валерьянку. Она может пригодиться на любом из этих этапов.

Основные трудности при составлении ТЗ

Или, как я это называю, «Сборник граблей, на которые наступают все» (включая автора этих строк, что уж там скрывать).

«А где взять исходные данные?» (классика жанра)

Знакомая ситуация: вас назначили писать ТЗ для системы, о которой никто толком ничего не знает. Заказчик уверен, что вы телепат, а все документы «где-то были, но потерялись». В такой ситуации есть два пути:

• Правильный: вернуться к началу и провести полноценное обследование
• Реальный: придумать исходные данные самому и включить их в ТЗ (спойлер: заказчику придется их изучить при согласовании)

«Требования как желе»

Мой любимый случай — когда требования меняются быстрее, чем вы успеваете их записать. «А давайте добавим… А может лучше вот так… А вот я вчера видел в инстаграме…» Решение? Фиксируйте дату и версию каждого требования. И да, заведите журнал изменений — он спасет вас, когда через полгода кто-то спросит «а почему это так?».

«Согласование длиной в вечность»

Особенно весело, когда у заказчика организация на 500+ человек, и каждый считает своим долгом внести правки в ТЗ. Причем правки часто противоречат друг другу, а некоторые отделы принципиально не общаются между собой. Мой рекорд — 3 месяца согласований и 28 версий документа (и это был не самый сложный проект).

«Слишком много деталей!»

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

«У нас тут кое-что забыли…»

Классическая ситуация: ТЗ уже почти готово, как вдруг кто-то вспоминает про «маленькую» деталь. Например, что система должна интегрироваться с древним legacy-приложением, написанным на COBOL во времена первых динозавров. Или что требования по безопасности включают соответствие стандарту, о котором никто раньше не слышал.

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

И помните главное правило составления ТЗ: что бы ни пошло не так — это нормально. Ненормально только делать вид, что всё идет по плану, когда вокруг горит дедлайн.

Советы по написанию качественного ТЗ

Или, как я это называю, «Инструкция по превращению словесного хаоса в читаемый документ» (основано на реальных граблях).

Пишем четко и понятно

Давайте сравним два варианта описания одного и того же требования:

• Плохо: «Система должна работать быстро и обеспечивать удобный доступ к данным» (Что значит «быстро»? Что подразумевается под «удобным»? Это как сказать повару «сделайте вкусно» — результат непредсказуем)
• Хорошо: «Система должна обеспечивать время отклика не более 2 секунд при одновременной работе до 100 пользователей, с возможностью доступа к любым данным за последние 3 года не более чем в 3 клика» (Конкретно, измеримо и проверяемо — прямо как в учебнике)

Боремся с двусмысленностью

Помните старый анекдот «казнить нельзя помиловать»? В ТЗ такие ситуации — не шутка. Вот примеры:

• Двусмысленно: «При возникновении ошибки система может отправить уведомление администратору» (Может, но не обязана? А когда именно должна?)
• Однозначно: «При возникновении критических ошибок (список в приложении А) система ДОЛЖНА отправить уведомление администратору в течение 5 минут»

Структурируем текст

Ваше ТЗ должно быть как хороший детектив — с понятным сюжетом и без лишних отступлений. Используйте:

• Нумерацию разделов (и да, 1.1.1.1.1.1 — это уже перебор)
• Маркированные списки (но не более трех уровней вложенности, иначе можно сойти с ума)
• Таблицы (особенно для описания параметров и ограничений)

Визуализация — ваш друг

Иногда одна картинка действительно стоит тысячи слов. Особенно когда речь идет о:

• Схемах бизнес-процессов
• Диаграммах взаимодействия компонентов
• Макетах интерфейсов
• Алгоритмах обработки данных

Только не увлекайтесь — если ваше ТЗ напоминает комиксы Marvel, что-то пошло не так.

Бонус: секретное оружие

Держите под рукой список слов-триггеров, которые сигнализируют о потенциальных проблемах:

• «обычно»
• «предполагается»
• «и т.д.»
• «примерно»
• «возможно»
• «в некоторых случаях»

Увидели такое в тексте — значит, требование нуждается в уточнении. И да, я сам регулярно ловлю себя на использовании этих слов (профессиональная деформация, знаете ли).

И помните: хорошее ТЗ — это не то, к которому нельзя придраться (таких не бывает), а то, которое поможет создать именно то, что нужно заказчику. Даже если сам заказчик пока не совсем понимает, что ему нужно.

Заключение

Или, как я это называю, «Послесловие для тех, кто дочитал до конца» (спасибо за ваше терпение, кстати).

Знаете, что общего между хорошим техническим заданием и единорогом? Многие считают, что они не существуют в природе. Но на самом деле (спойлер!) хорошее ТЗ вполне реально создать — просто нужно понимать несколько ключевых принципов:

• ТЗ — это не бюрократическая формальность, а рабочий инструмент. Как молоток: может быть простым или навороченным, но главное — чтобы работал.
• Идеальных ТЗ не бывает (как и идеальных проектов), но к этому нужно стремиться. Это как с фитнесом — важен не конечный результат, а регулярные упражнения.
• Хорошее ТЗ защищает интересы всех сторон. Оно как брачный контракт: не самая романтичная вещь, зато все точно знают, чего ожидать.

И помните: время, потраченное на составление качественного ТЗ, окупится сторицей. Особенно когда через полгода кто-нибудь спросит «а почему это работает именно так?», и у вас будет документ с ответом, а не только седые волосы и нервный тик.

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

P.S. А если вы всё-таки решите работать без ТЗ — держите под рукой успокоительное. Пригодится.