Аудит проектной документации — это быстрая проверка, можно ли по вашим файлам реально построить, протестировать и внедрить систему без гаданий на кофейной гуще: 15 вопросов отсеивают «красивые PDF» и показывают дыры в целях, требованиях, ролях, интеграциях, сроках и критериях приёмки.

Самая дорогая ошибка новичка в IT (и у джуна, и у «перебежчика») — думать, что документация нужна «для галочки». На практике она нужна, чтобы деньги не уехали в никуда, а сроки — в бесконечное «ещё недельку». В российских реалиях это особенно бодрит: подрядчик, 1С, пара интеграций с Госуслугами/СМЭВ (или хотя бы с «Контуром»), согласование с безопасниками — и вот проект уже живёт по принципу «как-нибудь договоримся». Спойлер: договоримся — но через допсоглашение.

Я видел проекты, где «ТЗ» было на 6 страниц, из которых 3 — титульник, а оставшееся — «сделать как в приложении». И да, приложение было скриншотом чужого сайта. А потом удивление: почему оценка выросла вдвое и тестировщики плачут. Поэтому ниже — аудит проектной документации: чек-лист аудита документации, который можно прогнать за 60–90 минут и сразу понять, где у вас болит (и сколько это будет стоить).

Что именно мы аудируем и почему это экономит деньги

Какие документы обычно проверяют

В типовом проекте (внутреннем или с подрядчиком) встречаются:

• Vision/Концепция — зачем делаем и что считаем успехом;
• BRD (Business Requirements Document) — бизнес-требования простым языком;
• SRS/ТЗ — системные требования: что должна делать система;
• User Stories / Use Cases — сценарии пользователя;
• Прототипы/UI — макеты, кликабельные или нет;
• Интеграции — какие системы, какие данные, какие форматы;
• НФТ (нефункциональные требования): производительность, безопасность, доступность;
• План тестирования/критерии приёмки — как поймём, что «готово».

Почему аудит документации — это ROI, а не бюрократия

Когда нет критериев «готово», у команды появляется бесконечная игра «а мы так не договаривались». Цена ошибки на стадии требований обычно в разы ниже, чем на стадии разработки и внедрения. По ощущениям практики: один спорный абзац в ТЗ легко превращается в 2–10 дней переделок (разработка + тесты + согласования). Если в команде 5–7 человек, считайте сами — особенно если часть людей на аутсорсе.

Практический вывод: аудит бизнес-требований и ТЗ перед стартом разработки — это способ купить себе время и предсказуемость, а не «ещё одну встречу».

Подводный камень: проверять только полноту («всё ли написано») и не проверять проверяемость («можно ли это принять»).

Чек-лист: 15 вопросов для аудита проектной документации

Блок 1. Цели, ценность, границы (1–4)

1. Цель проекта измерима? Есть метрика (время обработки заявки, конверсия, снижение ручного труда), а не «повысить удобство».
2. Определены стейкхолдеры и владелец решения? Кто принимает финальное «да» по требованиям и приёмке. Один человек/роль, не «комитет».
3. Есть явные границы scope (что не делаем)? Записанное «не входит» снижает риск бесконечных «а ещё вот это».
4. Понимаем “для кого”? Роли/персоны, контекст использования, ограничения (офис/полевые сотрудники, мобильные устройства, медленный интернет).

Вывод: если цели не измеримы — сроки и бюджет тоже будут «на глазок».

Ошибка: путать цель проекта с перечнем фич.

Блок 2. Требования: ясность и проверяемость (5–9)

5. Требования атомарны и однозначны? «Система должна быстро формировать отчёт» — не требование. «Не более 10 сек на выборке до 50k строк» — уже разговор.
6. Есть трассируемость? Бизнес-требование → функциональное требование → тест-кейс/критерий приёмки. Хоть в таблице, хоть в Jira/YouTrack.
7. Разрулены конфликтующие требования? «Сделать максимально безопасно» и «чтобы входили по SMS без лишних шагов» — конфликт, его надо решить заранее.
8. Критерии приёмки прописаны для ключевых сценариев? Что именно демонстрируем на приёмке: данные, роли, ошибки, отчёты, логи.
9. Есть словарь терминов? Чтобы «клиент» не оказался то юрлицом, то физлицом, то вообще «контрагентом из 1С».

Вывод: чек-лист аудита документации всегда упирается в тестируемость: если нельзя проверить — нельзя управлять.

Ошибка: хранить требования в «финальной версии Word», которая финальная уже шестой раз.

Блок 3. Данные, интеграции, безопасность (10–12)

10. Описаны данные и источники? Поля, форматы, обязательность, справочники, правила валидации, миграция.
11. Интеграции описаны на уровне протоколов и ответственности? REST/SOAP, очереди, файлы; кто владеет API; SLA; что делаем при недоступности.
12. НФТ и ИБ (информационная безопасность) не забыты? 152‑ФЗ/персональные данные, журналы аудита, роли и права, хранение логов, требования безопасности заказчика.

Вывод: интеграции и безопасность — топ-2 источника «вдруг оказалось» на внедрении.

Ошибка: считать, что «безопасники потом посмотрят» — они посмотрят, и проект посмотрит на новые сроки.

Блок 4. План, риски, управление изменениями (13–15)

13. Есть план релизов и критерии готовности? Define of Done (DoD): код, тесты, документация, обучение, мониторинг.
14. Риски и допущения записаны? «Доступ к тестовому контуру дадут до даты Х», «API будет готово к спринту 3» — и кто отвечает.
15. Есть процесс изменения требований? Change Request: как оцениваем, кто согласует, как фиксируем влияние на срок/бюджет.

Вывод: управление изменениями — это страховка от «мы думали, это мелочь».

Ошибка: не фиксировать договорённости письменно (да, даже если «мы все взрослые люди»).

Таблица для быстрого аудита: что смотреть и где обычно ломается

Два кейса из практики (российская классика)

Кейс удачный: “починили требования — сэкономили месяц”

Проект внутреннего кабинета для сотрудников (интеграции с 1С:ЗУП и сервисом уведомлений). Перед разработкой сделали аудит бизнес-требований: нашли 18 неоднозначностей в расчётах и согласованиях, добавили критерии приёмки и таблицу ролей. Итог: первый релиз вышел без «переделайте, мы не это имели в виду», а внедрение не упёрлось в права доступа. По календарю сэкономили примерно 3–4 недели, потому что не гоняли круги согласований на готовом коде.

Кейс болезненный: “внедрение умерло об интеграции”

CRM для отдела продаж, «интеграция с телефонией и почтой» была описана одной строкой. На UAT (приёмочном тестировании) выяснилось: коллтрекинг в другой системе, API ограничено, а безопасность требует журналировать доступ к карточкам клиентов. Пошли допработы, оценка выросла примерно на треть, сроки — на два месяца. Всё это было видно на этапе аудита документации, но «не хотели тормозить старт». Ну да, не затормозили. Проект разогнался и врезался.

Что в ТОПе по теме и чем этот материал отличается

В поиске обычно два типа результатов: либо академические ГОСТ-раскладки («документация должна содержать раздел 1.1.1»), либо чек-листы уровня «проверьте, что всё согласовано». Полезно, но мало применимо, когда вы junior/BA и вам нужно завтра понять, почему требования разваливаются.

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

Экспертный вердикт и инструмент: мини-шаблон аудита на 1 страницу

Если вы хотите сделать «быстрый аудит документации» без театра, используйте правило 3 колонок. Вставьте в Confluence/Google Docs:

Эта форма хороша тем, что переводит философию в действие: не «документы плохие», а «вот список дыр и кто их закрывает». Если нужна ещё пачка таких разборов — они живут на главной странице: https://itokno.ru.

Частые вопросы