Если подрядчик затягивает разработку
Проверьте не эмоции вокруг срока, а факты: что реально готово, что блокирует релиз и за что сейчас просят оплату.
- есть список задач этапа со статусами: готово, на проверке, заблокировано, не начато
- подрядчик показывает рабочее демо, а не только обещает, что «почти готово»
- понятно, какие конкретные причины сдвинули срок и какие из них уже закрыты
- новый срок привязан к задачам и рискам, а не назван как очередная дата без плана
- оплата этапа опирается на проверяемые артефакты: демо, доступы, changelog, тесты, документы
Симптомы технического тупика
Отметьте признаки, которые уже повторяются, а не появились один раз на отдельной задаче.
- оценки похожих задач растут от релиза к релизу
- новые доработки ломают соседние функции
- подрядчик отвечает общими формулировками без карты причин
- команда не может показать актуальную схему модулей и интеграций
- бизнес не понимает, что действительно готово, а что только почти готово
Если проект нельзя передать или развивать
Передача проекта срывается не из-за отсутствия одного файла, а из-за отсутствия управляемой картины системы.
- нельзя быстро объяснить, из каких модулей состоит система и за что отвечает каждый модуль
- нет списка доступов, окружений, доменов, репозиториев, интеграций и ответственных
- новая команда не может оценить доработки без долгого погружения в код и переписки
- backlog содержит задачи без бизнес-контекста, критериев готовности и приоритета
- текущая команда держит критичные знания в голове, чатах или личных заметках
Документы, которые нужно запросить
Документы нужны не для формальности, а чтобы проверить, можно ли управлять проектом по фактам.
- актуальный список задач и статус ближайшего релиза
- схема модулей, ролей пользователей и ключевых интеграций
- описание процесса деплоя и тестирования
- список известных технических рисков и ограничений
- инструкции по доступам, окружениям и передаче проекта
Если портал ломается после релизов
Повторные поломки после доработок обычно показывают проблему в архитектуре, тестировании, релизном процессе или интеграциях.
- после каждого релиза есть список изменённых модулей и связанных рисков
- критичные сценарии проверяются до выкладки, а не только после жалоб пользователей
- ошибки повторяются в одних и тех же местах: интеграции, роли, заказы, отчёты, платежи
- команда может показать, почему новая доработка затронула соседнюю функцию
- есть план стабилизации, а не только быстрая починка очередного симптома
Вопросы на ближайшем статусе
Эти вопросы помогают отделить нормальную рабочую сложность от потери управляемости.
- что именно сейчас блокирует релиз
- какие задачи требуют предварительного исследования перед оценкой
- какие модули чаще всего создают ошибки после доработок
- какие риски команда уже знает, но пока не закрывает
- что нужно сделать, чтобы новая команда могла безопасно принять проект
Если AI или интеграции упираются в хаос
AI и новые интеграции не исправляют слабую архитектуру автоматически. Часто они быстрее показывают старые проблемы в данных, ролях и документации.
- понятно, какие данные считаются источником истины для портала, CRM, 1C и внешних сервисов
- описаны роли и ограничения: кто может видеть, менять и выгружать информацию
- техническая документация позволяет понять, где брать контекст для AI/RAG или автоматизации
- есть критерии качества ответа, обмена или автоматического действия
- известны сценарии, где AI или интеграция могут навредить из-за неполных данных
Красные флаги
Если несколько пунктов совпадают, лучше не запускать новые крупные доработки без диагностики.
- каждый перенос срока объясняется фразой «там всё сложно»
- документация откладывается до конца проекта
- демонстрации заменяются устными обещаниями
- нет списка критичных ошибок и плана их закрытия
- подрядчик просит новый бюджет без объяснения, что изменилось в проекте
- для AI, интеграций или нового раздела предлагают сразу разработку без проверки данных и архитектуры
Когда нужен аудит
Аудит нужен не всегда. Но он полезен, когда цена следующего решения выше стоимости независимой проверки.
- нужно понять, продолжать ли работу с текущей командой
- проект готовится к передаче другой команде
- сроки сорваны, но причина не подтверждена фактами
- архитектура и документация не позволяют планировать развитие
- портал ломается после релизов, а команда чинит симптомы без карты причин
- AI или интеграции планируются поверх непонятных данных и процессов
- бизнесу нужен план восстановления без конфликта и хаоса
