Тест вместо приёмки
Passed в колонке результата не значит принято. Приёмку подписывает бизнес-владелец, и её ведут отдельной колонкой.
Матрица трассировки требований (RTM) показывает путь каждого требования из BRD: решение, сборка, тесты, приёмка. Так видно, что сделано, что проверено, что принято и что сделано сверх требований. Здесь шаблон в Excel и первые семь требований учебного проекта.
Всё, что справа от линии, идёт в фазу 2 через запрос на изменение (CR).RTM — таблица, в которой у каждого требования есть ID, раздел BRD, тип, приоритет по MoSCoW, ссылки на дизайн и сборку, номера тест-кейсов и два статуса: результат теста и приёмка. Это разные вещи. Тест может пройти, а приёмку заказчик ещё не подписал.
Главная задача матрицы — контроль объёма. Всё, что не связано с требованием, лишнее. Всё, что изменено, должно ссылаться на одобренный запрос на изменение (CR): для этого в матрице есть отдельная колонка Change Ref.
Заводят после подписания BRD, когда у требований есть ID и приоритет. Обновляют на каждом цикле SIT и UAT. Перед подписанием приёмки проверяют, закрыты ли все строки Must тестом и приёмкой.
ID, номер раздела BRD («BRD §3.1») и формулировка. Формулировка должна проверяться: порог, срок или объём, а не «быстро» и «удобно».
Must — без этого приёмки не будет. Should и Could — то, что можно отложить. Won't — явно вне текущего релиза. Тип выбирают из списка: Functional, Non-functional, Security и другие.
Ссылка на раздел дизайна (HLD или LLD), номер релиза и ID тест-кейсов. Пустая ячейка тест-кейсов — дыра в покрытии, и её видно сразу.
На SIT и UAT обновляй результат теста. Приёмка — отдельный статус: он остаётся Pending до подписи бизнес-владельца, даже если тест прошёл.
Любое изменение записывают с номером одобренного запроса на изменение в колонке Change Ref. Нет одобренного CR — нет изменения.
Passed в колонке результата не значит принято. Приёмку подписывает бизнес-владелец, и её ведут отдельной колонкой.
«Данные должны обновляться часто» не проходит тест. «Не реже чем каждые 15 минут», как в BR-002, проверить можно.
В шаблоне результат выбирают из списка: Not run, Passed, Failed, Blocked. Написанное от руки «Done» или «Pass» выпадает из списка и не окрашивается.
Матрицу заполнили перед приёмкой и больше не открывали. Тогда она ничего не доказывает. Её обновляют на каждом SIT и UAT, а не один раз.
Первые семь требований из десяти в матрице проекта AI Social Pulse. Статусы на 4 сентября 2026 года.
| 1 | Req ID | Source (BRD §) | Requirement Statement | Type | Priority (MoSCoW) | WBS / Design Ref | Build Item / Release | Test Case ID(s) | Test Result | Acceptance Status |
|---|---|---|---|---|---|---|---|---|---|---|
| 2 | BR-001 | BRD §3.1 | The Trend Radar shall show the top 20 trending topics for the last 24 hours across six sources | Functional | Must | 1.4.3 / LLD §4 | Release 1 | TC-001, TC-002 | Passed | Accepted |
| 3 | BR-002 | BRD §3.2 | Source data shall be refreshed at least every 15 minutes | Non-functional | Must | 1.4.2 / LLD §6 | Release 1 | TC-010 | Passed | Accepted |
| 4 | BR-003 | BRD §3.3 | Duplicate posts in the trends feed shall not exceed 1% per topic | Non-functional | Must | 1.4.2 / LLD §6 | Release 1 | TC-011, TC-012 | Failed | Pending |
| 5 | BR-004 | BRD §3.4 | An editor shall be able to export a trends report to PDF and XLSX | Functional | Should | 1.4.3 / LLD §4 | Release 1 | TC-020 | Passed | Accepted |
| 6 | BR-005 | BRD §4.1 | The Audience Dashboard shall forecast reach for 7 and 30 days | Functional | Must | 1.4.3 / LLD §7 | Release 2 | TC-030, TC-031 | Not run | Pending |
| 7 | BR-006 | BRD §4.2 | Forecast error (MAPE) shall not exceed 15% on the validation set | Non-functional | Must | 1.4.2 / LLD §8 | Release 2 | TC-032 | Not run | Pending |
| 8 | BR-007 | BRD §5.1 | The platform shall ingest the six sources listed in SOW §4: X, Instagram, Facebook, web news (RSS), Client CMS and Google Trends | Functional | Must | 1.4.2 / LLD §3 | Release 2 | TC-040 | In progress | Pending |
AI Social Pulse — вымышленный учебный проект PM Simulator: компании, люди и цифры придуманы для обучения. Названия компаний на этой странице заменены ролями. Полный образец и ещё 40 заполненных документов этого проекта — в симуляторе.
Внутри: Read Me, RTM.
Не нашёл своего вопроса — напиши в Telegram, отвечу.
BRD описывает, что нужно бизнесу. RTM прослеживает каждое требование из BRD до тестов и приёмки. BRD — документ, который подписывают, а RTM — рабочая таблица, которую ведут до конца проекта.
Если требований несколько десятков и приёмку ведёт один человек, таблицы с ID и статусом приёмки хватит. Полная матрица нужна, когда приёмку подписывают несколько сторон или проект проверяют по аудиту.
Четыре категории приоритета: Must — обязательно, Should — важно, но можно выпустить без этого, Could — желательно, Won't — не в этом релизе. Название составлено из первых букв слов Must, Should, Could, Won't, и в шаблоне они стоят в выпадающем списке.
На английском, в формате международных компаний: Requirement Statement, Test Case ID, Acceptance Status. Названия колонок можно перевести, но значения в выпадающих списках и подсветки лучше не трогать: подсветка сравнивает слова точно.
В симуляторе матрица появляется на третий день: BRD писали под другие приоритеты, UC1 уже в UAT, и заказчик хочет заново договориться о скоупе. Всё, что не вошло в границу, идёт в фазу 2 через запрос на изменение, и в матрице у такого требования есть номер CR.
эпизод 1 «Человек, которого уволили» · день 3: Скоуп, требования, ресурсы
Ты в деле?Один платёж · доступ навсегда
Возврат в течение двух суток с момента оплаты, без объяснения причин.
Цели, границы, вехи, управление и полномочия PM — документ, которым запускают проект.
Что уже случилось и мешает работе: серьёзность, срочность, владелец, срок и эскалация.
Кто делает, кто отвечает, с кем советуются и кого информируют — по каждой задаче.