ТЗ и SRS
Спрашивают, чтобы понять, писал ли ты настоящие документы или только карточки в трекере. Формат часто такой: дают кусок реального технического задания и просят найти проблемы - и тут сразу видно, вычитывал ли человек чужие документы хоть раз.
Стержень: SRS (software requirements specification) отвечает на вопрос «что должна делать система», не отвечая на «как её построить». Плюс служебные вещи, без которых документ не работает вообще: глоссарий, идентификаторы требований, словарь модальных слов.
// Формулировки: «что входит в SRS?», «зачем глоссарий?», «нужна ли документация в Agile?»
Что внутри и чего там быть не должно
Внутри: назначение и границы системы, функции, требования к качеству, внешние интерфейсы, ограничения, допущения. Плюс глоссарий и правила трактовки - как читать модальные слова, что означает незаполненное поле, в каких единицах даны числа.
Чего быть не должно - выбора конкретной библиотеки или фреймворка без причины. Способ достижения результата это зона команды: она знает трудоёмкость альтернатив, а ты нет. Единственное исключение - когда инструмент навязан извне, архитектурным комитетом или регулятором, и тогда его оформляют как ограничение, а не как требование.
Разница между этими двумя оформлениями практическая. Требование можно обсуждать по цене реализации. Ограничение обсуждать бесполезно, его можно только оспорить у источника - и команда должна понимать, в какую из двух категорий попало ограничение на СУБД (система управления базами данных) из реестра.
// Сроки, оценки трудоёмкости и распределение работ тоже не здесь: у них свои документы. Смешивание превращает техническое задание в нечитаемый гибрид, который перестают открывать все стороны сразу.
Глоссарий и модальные слова
Слова «заявка», «клиент», «активный» в разных отделах означают разное, и именно на этом рушатся согласования. Для отдела продаж активный клиент - тот, кто что-то купил за год. Для поддержки - тот, у кого не закрыт договор. Оба уверены, что говорят об очевидном, и оба подписывают требование про «список активных клиентов» с разным пониманием.
Глоссарий фиксирует единственное значение каждого термина и снимает целый класс споров на приёмке. Побочная польза не меньше основной: собранный глоссарий - это уже черновик модели предметной области, сущности из него потом переезжают на схему почти без правок.
Модальные слова несут юридическую нагрузку, особенно если документ входит в контракт. «Должна» - обязательство, которое войдёт в приёмку. «Может» - допустимая возможность, за отсутствие которой никто не отвечает. Смешение приводит к спору о составе поставки, где каждая сторона трактует в свою пользу, поэтому словарь модальных слов выносят отдельным разделом в начале.
// Уникальный идентификатор у каждого требования превращает абзац в объект, на который можно сослаться: из теста, из задачи, из протокола встречи. Ссылка на номер страницы или на цитату поедет при первой же правке документа.
Документ и Agile
Манифест говорит «работающий продукт важнее исчерпывающей документации», а не «документации не нужно». Это правило приоритета при конфликте, а не запрет, и разница принципиальная.
Решает всё цена ошибки и горизонт жизни системы. Там, где система живёт десятилетие, а команды за это время сменятся дважды, сводный документ окупается многократно - он единственный носитель знания, который переживёт людей. Там, где гипотезы проверяют неделями и половину выкидывают, живой бэклог с критериями приёмки честнее толстого тома, который устареет раньше релиза.
Отдельная беда - документ, написанный единым потоком сразу для всех. Его перестают читать все без исключения, потому что каждому нужен свой срез: разработчику детали поведения, тестировщику критерии, заказчику картина целиком на его языке.
// Практический выход - один источник и разные представления из него. Требования лежат в одном месте с атрибутами и связями, а адресату собирается выжимка под его вопрос. Два независимых документа для двух аудиторий разъедутся за месяц.
Как отвечать: «Заказчик подписал ТЗ не читая, а на приёмке заявил, что имел в виду другое»
Подпись под текстом ничего не гарантирует, и обвинять тут некого: требования плохо читаются непрофессионалом, он честно соглашается с тем, чего просто не смог себе представить. Поэтому до подписания я всегда показываю прототип и разбираю ключевые сценарии по шагам на его же реальных примерах - берём конкретную заявку из их работы и проходим по ней. Расхождения вскрываются за минуты и стоят копейки, пока разработка не началась. Второе, что делаю, - не полагаюсь на один документ для всех адресатов: заказчику даю короткий срез на его языке, полную детализацию оставляю команде. Час у макета дешевле месяца переделки после приёмки, и это соотношение не меняется от проекта к проекту.
Кандидат не спорит о вине сторон, а называет конкретную профилактику и объясняет, почему текст в принципе не работает как инструмент согласования с непрофессионалом.
На чём валятся
- −− Фиксируют в задании конкретную технологию без причины и отбирают у команды дешёвое решение.
- −− Пишут документ единым потоком для всех адресатов - его перестают читать все.
- −− Смешивают модальные слова, и состав обязательной поставки становится предметом спора.
- −− Понимают Agile как запрет документации, а не как приоритет при конфликте.
- −− Полагаются на подпись вместо прототипа и получают спор на приёмке.
Проверьте себя
Пять вопросов из банка по этой подтеме. Всего их 13, остальные разбираются в тренажёре.
- Зачем в спецификации отдельный раздел с терминами и определениями?A)Чтобы документ соответствовал требованиям к объёмуB)Чтобы упростить перевод документа на другие языкиC)Чтобы одно слово означало для всех одно и то жеD)Чтобы заменить им описание модели данных
показать ответ и разбор
+C)Чтобы одно слово означало для всех одно и то же// разбор: Слова вроде «заявка», «клиент», «активный» в разных отделах означают разное, и на этом рушатся согласования. Глоссарий фиксирует единственное значение и убирает целый класс споров на приёмке. Побочная польза — он же становится черновиком модели предметной области.
- Разработка жалуется: спецификация огромная, читать невозможно. Что стоит сделать аналитику?A)Сократить требования, убрав менее важные разделыB)Перевести весь документ в формат презентацииC)Переложить чтение на тимлида, раздав ему задачиD)Разбить по адресатам и дать навигацию по разделам
показать ответ и разбор
+D)Разбить по адресатам и дать навигацию по разделам// разбор: Проблема обычно не в объёме, а в том, что документ написан как единый поток для всех сразу. Разработчику нужен свой срез, тестировщику свой, заказчику свой. Помогает структура по областям, оглавление, ссылки между разделами и краткое резюме в начале. Выбрасывать требования ради читаемости — терять содержание.
- Что означает «система должна» в противовес «система может» в тексте требований?A)Разные сроки реализации этих требованийB)Обязательность против необязательностиC)Разный уровень детализации формулировкиD)Принадлежность требований разным подсистемам
показать ответ и разбор
+B)Обязательность против необязательности// разбор: Модальные глаголы в требованиях несут юридическую нагрузку: «должна» — обязательство, входящее в приёмку, «может» — допустимая возможность, за отсутствие которой никто не отвечает. Смешение приводит к спорам о составе поставки, поэтому в серьёзных документах словарь модальностей фиксируют отдельно.
- В спецификации к каждому требованию проставлен уникальный идентификатор. Что это даёт?A)Ускоряет согласование документа с заказчикомB)Позволяет автоматически сгенерировать код по документуC)Упрощает проверку набора на противоречияD)Даёт ссылку для тестов, задач и обсуждений
показать ответ и разбор
+D)Даёт ссылку для тестов, задач и обсуждений// разбор: Идентификатор превращает абзац текста в объект, на который можно сослаться из тест-кейса, задачи, письма или протокола. Без него ссылаются на номер страницы, который поедет при первой же правке. Это техническая основа трассировки и единственный способ обсуждать требование, не цитируя его целиком.
- Заказчик подписал ТЗ не читая, и на приёмке заявил, что имел в виду другое. Что снижает такой риск заранее?A)Увеличить детализацию текста ещё сильнееB)Показывать прототипы и сценарии до подписанияC)Добавить в договор штраф за отказ от подписиD)Согласовывать документ только по электронной почте
показать ответ и разбор
+B)Показывать прототипы и сценарии до подписания// разбор: Текст требований плохо читается непрофессионалом, и подпись под ним ничего не гарантирует. Кликабельный прототип, разбор сценария по шагам и демонстрация на реальных данных вскрывают расхождения до начала разработки. Дешевле один час у макета, чем переделка после приёмки.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.