Что будешь смотреть если нужно срочно принять проект?

Приемка проекта в срочном режиме: Критический алгоритм действий

При срочной приемке проекта я действую по принципу управляемого риска. Цель — не всесторонний аудит, а быстрая оценка жизнеспособности и выявление «красных флагов», которые могут привести к немедленному провалу. Мой фокус смещается с «идеально» на «безопасно и управляемо». Весь процесс структурирую по ключевым доменам.

1. Документация и формальные основания (Legal & Governance)

Первым делом проверяю юридический и формальный фундамент. Без этого принятие проекта — огромный риск.

• Договор и SOW (Scope of Work): Сверяю, что было подписано и что фактически сдано. Ищу явные несоответствия, особенно в границах проекта, критериях приемки (acceptance criteria) и списке обязательных поставок (deliverables).
• Акты и подписи: Проверяю наличие подписанных промежуточных актов, протоколов совещаний, где клиент подтверждал ключевые этапы. Отсутствие такой истории — тревожный сигнал.
• Открытые риски и issues: Изучаю журнал рисков и проблем. Особое внимание — к открытым критическим рискам, перешедшим в проблемы (например, нерешенный вопрос с интеграцией со сторонним API).

### Чек-лист: Документы для срочной проверки
- [ ] Подписанный договор/доп. соглашения
- [ ] Техническое задание (SOW) с четкими критериями приемки
- [ ] Акты о завершении ключевых этапов (если были)
- [ ] Журнал рисков (обращаю внимание на статус: Open -> Critical)
- [ ] Список дефектов высокого приоритета (High/Critical Severity)

2. Качество и соответствие требованиям (Quality & Scope)

Здесь я применяю «снайперский» подход, а не сплошную проверку.

• Критический функционал (Core Flow): Лично тестирую главный пользовательский сценарий (happy path). Например, для интернет-магазина: регистрация -> выбор товара -> оформление заказа -> оплата -> получение чека. Если это не работает, проект не готов.
• Критерии приемки (Acceptance Criteria): Беру 3-5 самых важных критериев из ТЗ и проверяю их выполнение. Часто они прямо связаны с оплатой.
• Технический долг и стабильность: Запрашиваю у лида разработки сводку по критическим багам (Severity 1/Blocker) в трекере (Jira, YouTrack). Смотрю на метрики стабильности: есть ли падения продакшн-окружения (downtime) за последнюю неделю? Каково время отклика ключевых операций?
• Безопасность (Security): Проверяю, проведен ли хотя бы базовый пентест для критических модулей (аутентификация, оплата, работа с ПД). Ищу в отчетах уязвимости уровня Critical/High.

3. Инфраструктура и эксплуатация (Ops & Infrastructure)

Проект должен не только работать, но и быть передан в эксплуатацию.

• Доступы и документация: Требую предоставить полный пакет документов для эксплуатации (runbook): схемы архитектуры, конфигурации, процедуры развертывания (deployment), мониторинга и отката (rollback). Проверяю наличие и актуальность.
• Права доступа: Убеждаюсь, что у нашей команды или команды заказчика есть полный доступ ко всем системам: репозитории кода, серверы, CI/CD, базы данных (в рамках безопасности), сторонние сервисы. Потеря доступа — это потеря проекта.
• Среда выполнения (Production Readiness): Смотрю, развернуто ли решение на продуктовом окружении заказчика или на нейтральной площадке. Проверка на «тестовом стенде разработчика» не считается.

# Пример быстрого запроса к команде для проверки инфраструктуры
$ curl -I https://prod-api.client-domain.com/healthcheck # Проверка доступности продакшн-API
$ ssh deploy-user@prod-backend -- "cat /etc/release-info" # Проверка версии релиза (если доступ есть)

4. Люди и коммуникации (People & Communication)

Критический, но часто упускаемый аспект.

• Назначение ответственных: Фиксирую, кто со стороны заказчика является лицом, уполномоченным подписывать акт. Также определяю, кто с нашей стороны становится точкой контакта на период гарантийной поддержки.
• Открытые вопросы: Провожу срочную встречу с ключевыми техлидами. Задаю один вопрос: «Что сейчас мешает нам поставить галочку «Готово» и спать спокойно?». Ответы часто выявляют скрытые технические или коммуникационные проблемы.
• Голос заказчика: Связываюсь с ключевым контактным лицом заказчика и в формате 15-минутного созвона уточняю, есть ли у него нерешенные претензии по функционалу, которые блокируют приемку. Информация из первых рук бесценна.

5. Формирование отчета и принятие решения (Decision Making)

На основе собранных данных я готовлю срочный отчет о приемке (Flash Acceptance Report) с разделами:

• Зеленые зоны: Что соответствует договору и работает стабильно.
• Желтые зоны (риски): Несоответствия, которые можно задокументировать и перенести на пост-продакшен (например, второстепенные баги).
• Красные зоны (блокеры): Критические несоответствия, делающие приемку невозможной прямо сейчас.

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

Если красные зоны отсутствуют, а желтые — задокументированы и согласованы с заказчиком в виде плана исправления, проект может быть принят условно, с четким списком действий на период пост-продакшн поддержки. Если же выявлен критический блокер (не работает ядро системы, нет доступа, есть юридический конфликт), приемка останавливается, и все ресурсы бросаются на его устранение. Главное в срочной приемке — прозрачность и управление ожиданиями всех сторон.