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

На связи Ольга, бизнес-аналитик в Outlines Tech. Расскажу, как я погружаюсь в новую задачу, чтобы составить техническое задание за 30 минут. По моей методике 80% работы над ТЗ — понять и договориться, 20% — зафиксировать всё в документ. Благодаря этому не придётся торопиться и придумывать текст с нуля или переделывать текст на ходу.

5 вопросов, чтобы начать погружение в проект

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

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

1. «Какую конкретную проблему пользователя мы решаем этим функционалом?». Для ТЗ это ключевой вопрос, потому что он помогает понять бизнес-логику и отсечь бесполезные хотелки. Условно, если заказчик отвечает на него «нам просто нужно вот так вот», значит, требований пока нет. Есть только идея без понятной цели, и писать ТЗ рано.

Был случай, когда заказчик попросил CRM с графиками, отчётами и «чтобы там всё было». Я спросила, какую проблему он хочет решить. Выяснилось, что менеджеры забывают вовремя обзванивать клиентов. Значит, заказчику нужна не CRM, а простой таск-менеджер для конкретного типа сотрудников. В итоге мы убрали лишнее и оставили только то, что действительно решает задачу, чем сэкономили время на разработку. Все в выигрыше.

2. «Как этот процесс выглядит сейчас?». Вопрос нужен, чтобы не придумывать решение в отрыве от реальности. Пока вы не увидите процесс как есть — на бумаге, в Excel, в старой системе или в чьей-то голове, — проектировать новый рано. Именно здесь обычно скрыты будущие поля, статусы, проверки и интеграции.

Был проект по автоматизации расчёта лимитов кредитования. Я спросила клиента, как этот процесс устроен сейчас. В ответ услышала: есть Мария Ивановна, у неё есть «волшебный» Excel, который никто кроме неё не понимает, плюс несколько блокнотов, и как-то на выходе получается лимит. Мне пришлось разложить эту «магию Марии Ивановны» по шагам: какие данные она берёт, что с ними делает и по каким правилам принимает решения. Из этого по итогу выросла основа будущей системы, которую хотел клиент.

3. «Что произойдет, если всё пойдет не по плану?». Это самый быстрый способ написать раздел «Альтернативные сценарии» и «Обработка ошибок». Обычно заказчики думают только о том, как всё должно работать в нормальной ситуации, но в ТЗ этого мало. Задав этот вопрос, не придётся выдумывать условия для валидаций, проверок и статусов.

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

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

4. «Кто и на каком этапе имеет право видеть или менять эти данные?». Для ТЗ это фундамент раздела «Матрица прав доступа». Если не обсудить этот вопрос с заказчиком заранее, то потом окажется, что одним сотрудникам открыли лишнее, а другим не дали доступ к данным, без которых они не смогут работать.

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

5. «Как мы поймем, что задача выполнена успешно?». В ТЗ это основа раздела «Критерии приемки». Если не задать этот вопрос заранее, после разработки почти всегда начинается одно и то же: «Это не то, я хотел другое». Поэтому результат нужно сразу обсудить с заказчиком и зафиксировать, что именно он хочет увидеть на выходе: какой отчёт, какое уведомление, какое изменение в базе, какая скорость работы и так далее.

Часто бизнес формулирует результат в духе «нужно быстро и качественно». Но это не критерии. Для одной задачи быстро это минута, для другой доля секунды. Для одной системы допустима доступность 95% времени, для другой только 99,9%. Пока я не уточню и не согласую параметры, у команды и заказчика будут разные ожидания.

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

Следующий шаг — борьба с хаосом

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

Глоссарий. Одно и то же слово в разных проектах может иметь разный смысл. Например, в финтехе «счёт» может быть рублёвым, валютным, кредитным или дебетовым. Поэтому сначала я выписываю 10–15 ключевых терминов проекта и договариваюсь с заказчиком, что именно они означают. Если этого не сделать, то возникнет путаница и лишняя суета.

Границы проекта. После глоссария я фиксирую, что входит в задачу, а что остаётся за её рамками. Это нужно, чтобы задача не расползалась по ходу проекта. Например, на тестировании часто появляется что-то в духе: «Ой, а давайте ещё вот эту кнопку добавим, это же несложно». Если не описать границы заранее, такие просьбы сложно отсеивать. 

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

Третье и последнее перед ТЗ — визуальный код

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

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

Теперь переведу текст описания в схему 👇

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

Если схема согласована, то описание к ней пишется само собой. Разработчик посмотрит на схему за 10 секунд и поймет больше, чем из текста за 10 минут.

Техника скоростной сборки ТЗ

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

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

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

Чтобы точно ничего не забыть в новом ТЗ, я проверяю себя по чек-листу:

1. Что делаем: какое изменение вносим, по каким правилам и ограничениям?

2. Где меняем: модуль, сервис, интеграции, точки входа?

3. Какой результат ждём: формат, витрина, интерфейс, расписание выгрузок или событий?

4. Какой срок?

5. Откуда берём данные: таблицы, топики, очереди, внешние источники?

6.  Чем контролируем: критерии приёмки, алёрты, аудит-лог?

7.  Что с нагрузкой: учтены ли взаимозависимости и влияние на смежные процедур?

Про важность вопроса №7. В начале карьеры у меня был проект по сегментации клиентской базы и расчёту кредитных лимитов. Алгоритм работал почти 9 часов, но мы не учли ночное закрытие банковского дня: пока оно не завершалось, другие процессы не запускались. В итоге расчёт не успевал закончиться до начала рабочего дня, и нам пришлось заново дорабатывать решение. Так пропущенная зависимость превратилась в двойную работу для команды.

Итог: ТЗ можно собрать за 30 минут и не терять в качестве

Качество падает не из-за скорости, а из-за попытки каждый раз изобретать велосипед. У аналитика появляется скорость и спокойствие, когда он понимает процесс. 

Это как с первой медицинской помощью: хороший врач работает быстро не потому, что спешит, а потому что знает порядок действий и не тратит время на суету. У аналитика так же. Когда он погружён в задачу, ТЗ не приходится придумывать с нуля. Достаточно собрать его из согласованных с заказчиком решений, простой блок-схемы и готовых модулей.

Чтобы не держать весь алгоритм в голове, я подготовила чек-лист методики в Telegram. В нём — три фазы погружения в проект, шаги для сборки ТЗ и вопросы, которые стоит задать до старта. Сохраните его и попробуйте на следующей задаче.

Спасибо, что прочитали до конца. Поделитесь, сколько времени у вас уходит на ТЗ?