Риск в IT-проекте нельзя убрать одной фразой в договоре и нельзя переложить целиком на подрядчика. Его снижают конкретные решения: ясные границы первой версии, доступ к исходным материалам, прозрачные статусы, ранняя проверка интеграций, критерии приёмки и понятный маршрут для изменений. Самая надёжная схема — сделать неизвестные видимыми до разработки, а затем проверять их короткими циклами. Это не гарантирует идеальный результат, но уменьшает вероятность дорогих сюрпризов.
Откуда обычно берётся риск
Заказчик часто оценивает проект по финальному экрану, а проблемы находятся в невидимых связях: кто владеет данными, что делать при повторном запросе, какие права нужны менеджеру, где хранится история изменения, как система узнаёт о сбое внешнего сервиса. Если эти вопросы не задать, команда всё равно примет решения — только позже и дороже.
NIST Secure Software Development Framework предлагает общий набор практик, который можно встроить в разные жизненные циклы разработки. Для заказчика ценность SSDF не в том, чтобы выучить весь документ, а в том, чтобы говорить с подрядчиком о безопасных практиках, проверках и ответственности на понятном языке.
Первый CTA. Если проект уже обсуждается, но риски и границы размыты, отправьте задачу Paladin Engineering на предварительный разбор: сначала определим неизвестные и только потом будем оценивать работу.
Карта рисков до подписания договора
Соберите риски в пять групп. Так проще увидеть, где нужна аналитика, а где достаточно простого решения.
| Группа | Вопрос | Что должно появиться |
|---|---|---|
| Продукт | Какая проблема решается и что не входит в первую версию? | Сценарии, границы MVP, список отложенных функций |
| Данные | Кто источник истины, какие данные чувствительны, как хранится история? | Модель данных, роли, правила доступа и аудита |
| Интеграции | Что будет при задержке, дубле или недоступности внешнего сервиса? | Контракты обмена, повторные попытки, ручной маршрут |
| Поставка | Как часто показывается результат и кто принимает этап? | Демо, критерии готовности, порядок исправлений |
| Эксплуатация | Кто запускает, обновляет, наблюдает и восстанавливает систему? | Доступы, инструкции, резервные копии, журнал решений |
Не все риски нужно превращать в длинный документ. Важно, чтобы у каждого существенного риска был владелец, способ проверки и решение о том, что делать при плохом сценарии.
Как зафиксировать границы первой версии
Фраза «сделать личный кабинет» слишком широкая. В ней могут скрываться регистрация, приглашения, роли, документы, оплата, уведомления, чат, экспорт и интеграция с учётной системой. Для оценки нужно разложить запрос на действия пользователя и состояния процесса.
Хорошая граница MVP отвечает на четыре вопроса:
- Кто выполняет действие?
- Какие данные нужны на входе?
- Как система подтверждает результат?
- Что происходит при ошибке или отмене?
Например, «отправить заявку» — это не только кнопка. Нужно решить, можно ли отправить её повторно, кто увидит черновик, как заявитель узнает о статусе и кто вправе изменить решение. Эти уточнения влияют и на интерфейс, и на базу данных, и на тесты.
Что проверять в работе подрядчика
Демо должно показывать сценарий, а не только экран
На демонстрации полезно пройти обычный путь и один отказ: неверные данные, недоступный сервис, отсутствие права, повторное нажатие. Так видны не только макеты, но и состояние системы.
Доступы и исходный код должны быть частью поставки
До старта согласуйте, где находится репозиторий, кто владеет аккаунтами, как выдаются доступы и что передаётся при завершении этапа. Пароли не должны пересылаться в открытом виде; нужны роли и управляемая передача доступа.
Изменения нужно разделять на уточнение и новую работу
Если новый факт исправляет ошибочное понимание исходного сценария, это одна ситуация. Если появляется новый канал, роль или интеграция — другая. Для обеих нужен короткий журнал: что изменилось, почему, как это влияет на сроки и состав поставки.
Безопасность должна быть проверяемой
OWASP ASVS помогает переводить разговор о веб-безопасности в требования и проверки. Не обязательно включать весь стандарт в каждый договор; полезнее выбрать релевантные пункты: авторизация, управление сессией, валидация ввода, доступ к объектам, безопасная конфигурация и журналирование.
Минимальный pre-publish и release gate для проекта
Перед выпуском проверьте не только happy path.
- Каждая роль видит только разрешённые данные и действия.
- Повторная отправка не создаёт неожиданный дубль.
- Ошибка внешней интеграции понятна пользователю и оператору.
- Критические изменения попадают в журнал.
- Формы работают с клавиатуры, показывают ошибки и не теряют введённые данные без предупреждения.
- Есть инструкция запуска, резервного восстановления и обращения за поддержкой.
W3C WCAG 2.2 описывает проверяемые критерии доступности, включая навигацию, фокус, ввод и сообщения об ошибках. Это полезная часть приёмки даже для внутреннего сервиса: доступность — не декоративная надстройка, а качество выполнения задачи разными пользователями.
Второй CTA. Paladin Engineering может помочь превратить эти пункты в discovery-документ, прототип, backlog и критерии приёмки. Обсудить задачу можно на странице веб-разработки или через контакты.
Какие условия стоит записать в договорённости
Результат этапа
Укажите не только название этапа, но и артефакт: прототип, схема ролей, работающий сценарий, тестовый отчёт, инструкция или релиз в конкретном окружении.
Критерии приёмки
Критерий должен быть наблюдаемым: пользователь с ролью X выполняет действие Y, получает результат Z; при ошибке система показывает сообщение и сохраняет или отклоняет данные по заданному правилу.
Ответственность за внешние зависимости
Если сроки зависят от API, доступов, контента или решения третьей стороны, это нужно назвать. Иначе задержка выглядит как провал разработки, хотя причина находится за пределами команды.
Передача и поддержка
Согласуйте доступ к репозиторию, окружениям, доменам, мониторингу, документации и резервным копиям. Отдельно опишите период исправления дефектов и порядок дальнейших изменений.
Ошибки заказчика, которые увеличивают неопределённость
Выбирать по обещанию «сделаем всё»
Широкое обещание без списка сценариев не является оценкой. Просите показать, что входит в первую версию и какие предположения использованы.
Откладывать интеграции до конца
Интеграция может зависеть от формата данных, лимитов, прав и поведения ошибок. Критичную связку лучше проверить небольшим техническим прототипом.
Принимать только визуальный результат
Экран без роли, состояния загрузки и ошибки не показывает готовность продукта. Принимайте пользовательский сценарий целиком.
Не назначать владельца решения
Если никто не может быстро ответить по приоритету, данным и компромиссам, команда начинает угадывать. Владелец продукта нужен даже при небольшой разработке.
Считать изменения бесплатными по умолчанию
Изменения неизбежны, но их влияние должно быть видимым. Прозрачная переоценка безопаснее, чем накопление молчаливого долга.
Практический план на первые две недели
1. Зафиксировать три главных сценария и границы MVP.
2. Составить карту ролей, данных и интеграций.
3. Выделить один технический риск для прототипа.
4. Согласовать демо, критерии приёмки и журнал решений.
5. Проверить передачу доступов, репозитория и окружений.
FAQ: кто отвечает за риски проекта
Риски разделяются между заказчиком, подрядчиком и владельцами внешних зависимостей. Важно не назначить виновного заранее, а определить владельца каждого риска и способ проверки.
Нужен ли договор, если проект маленький
Даже небольшой проект выигрывает от письменных границ, результата этапа, доступа к коду и критериев приёмки. Документ может быть компактным, но не должен оставлять ключевые решения устными.
Как понять, что оценка ненадёжна
Тревожные признаки — отсутствуют предположения, не названы интеграции, нет плохих сценариев, всё описано одним сроком и не указано, что передаётся заказчику. В такой ситуации сначала нужна проработка, а не сравнение цифр.
Стоит ли требовать фиксированную цену
Фиксированная цена полезна для понятного объёма. Для исследовательской части лучше фиксировать результат и лимит этапа, а изменения проводить через согласованный change request.
Что делать при конфликте требований
Вернуться к цели сценария, показать противоречие и зафиксировать решение владельца продукта. Молчаливое выполнение всех пожеланий обычно увеличивает срок и снижает проверяемость результата.
Как Paladin Engineering может помочь
Paladin Engineering может провести discovery, связать бизнес-цели с пользовательскими сценариями, определить технические риски и подготовить понятные критерии приёмки. Такой подход не обещает отсутствие проблем — он делает проблемы управляемыми до того, как они станут переделкой.
Комментарии