Перед стартом IT-проекта заказчику не нужно заранее знать весь стек и писать идеальное техническое задание. Но нужно уметь ответить на базовые вопросы: какую проблему решаем, для кого, как поймём результат, какие ограничения нельзя нарушить и кто принимает решения. Эти ответы экономят время на оценке и снижают риск построить аккуратную систему не для той задачи.
Чек-лист ниже предназначен не для бюрократии. Он помогает отделить обязательные решения от пожеланий, собрать неизвестные в отдельный список и выбрать первый проверяемый результат. Если пункт пока неизвестен, его не нужно маскировать — его нужно назвать и запланировать способ проверки.
Если проект пока описан несколькими фразами, обсудите старт с Paladin Engineering. На первой встрече полезнее разобрать цель, сценарии и ограничения, чем спорить о фреймворке до понимания задачи.
1. Зафиксируйте бизнес-проблему и владельца результата
Фраза «нужен личный кабинет» описывает решение, но не объясняет, что должно измениться. Заказчик должен назвать текущий процесс, его стоимость или неудобство, участников и результат, ради которого запускается проект. Владелец результата отвечает не за каждую задачу команды, а за бизнес-критерий, по которому можно принять решение о продолжении.
| Вопрос | Хорошая фиксация | Слабая фиксация |
|---|---|---|
| Проблема | заявки теряются между каналами | нужна автоматизация |
| Пользователь | менеджер и клиент с разными ролями | все сотрудники |
| Результат | заявка проходит путь до статуса без ручного дубля | сделать удобно |
| Владелец | роль, принимающая правила процесса | кто-нибудь из бизнеса |
Если владельцев несколько, заранее опишите зоны решений. Иначе команда будет получать взаимоисключающие указания и тратить итерации на внутренние согласования. Назначенный владелец не отменяет экспертные обсуждения, но помогает завершать спор конкретным решением.
2. Опишите пользователей через сценарии
Список ролей полезен только вместе с действиями. Для каждой роли запишите, с чего она начинает, что делает, какие данные видит, что может изменить и чем заканчивается сценарий. Такая карта показывает, какие функции действительно нужны в первой версии, а какие являются удобными, но не критичными.
- кто инициирует процесс и какими данными располагает
- какие шаги обязательны, а какие могут быть отменены
- кто меняет статус и кто только наблюдает
- что происходит при ошибке или неполных данных
- какой результат пользователь считает завершением
Для спорных мест используйте простую пометку: факт, решение или вопрос. Факт подтверждается текущим процессом или документом; решение принимает владелец; вопрос требует исследования. Это помогает не превращать предположение в обязательное требование.
3. Определите границы первой версии
Первая версия не обязана решать всё. Её границы должны описывать один сквозной сценарий, который можно запустить, проверить и принять. За пределами MVP остаются идеи, которые не нужны для проверки главной гипотезы, даже если они кажутся логичным продолжением.
| Попадает в первую версию | Откладывается осознанно |
|---|---|
| сквозной сценарий от входа до результата | редкие исключения без подтверждённой ценности |
| роли и доступы, необходимые для процесса | второстепенные отчёты и сложная аналитика |
| критичная интеграция или безопасный ручной обход | автоматизация, которую можно проверить позже |
| критерии приёмки | пожелания к интерфейсу без влияния на сценарий |
Границы MVP — это не способ скрыть объём работ. Это инструмент честной оценки. Если команда видит, что сквозной сценарий зависит от нескольких неизвестных, их нужно вынести в прототип, spike, интервью или отдельную техническую проверку.
4. Проверьте данные и интеграции до оценки
Интеграция редко сводится к «подключить API». До старта нужно понять владельца внешней системы, формат данных, частоту обмена, правила авторизации, лимиты, ошибки, повторную отправку и поведение при недоступности. Для миграции важны объём, качество, дубли и способ отката. Чем раньше это описано, тем меньше оценка зависит от догадок.
- есть ли документация и тестовая среда
- кто выдаёт доступы и кто отвечает за их отзыв
- какие сущности и поля являются источником истины
- как обрабатываются повторы и частичные ошибки
- что увидит пользователь при сбое внешней системы
- как проверяется результат обмена
Безопасность тоже нужно обсуждать до кода. NIST SSDF предлагает встраивать практики безопасности в жизненный цикл, а не добавлять их после обнаружения проблемы. Для заказчика это означает заранее определить чувствительные данные, роли, журналы действий, резервирование, обновления зависимостей и критерии проверки.
5. Согласуйте нефункциональные требования
Скорость, доступность, безопасность и поддержка влияют на архитектуру не меньше функциональных пунктов. Необязательно сразу знать точные цифры, но нужно назвать критичные ситуации: сколько пользователей ожидается, какие операции нельзя задерживать, что делать при недоступности сервиса, какие данные нельзя показывать другой роли и кто реагирует на инцидент.
| Область | Что зафиксировать до старта |
|---|---|
| Доступы | роли, запретные действия, аудит изменений |
| Надёжность | допустимый простой, резервное копирование, восстановление |
| Производительность | критичные операции, ожидаемые объёмы, границы |
| Доступность | клавиатура, ошибки форм, мобильный сценарий |
| Поддержка | владелец, мониторинг, обновления, реакция |
W3C отдельно указывает, что у полей ввода должны быть понятные labels или инструкции, а ошибки — описываться текстом и сопровождаться подсказкой по исправлению. Это относится и к внутренним системам: сотрудник не должен угадывать, какое значение ожидает форма или почему его действие отклонено.
6. Определите критерии приёмки и способ показа результата
Критерий приёмки описывает проверяемый результат: входные данные, действие, ожидаемое состояние и важное исключение. Формулировка «система работает быстро» не помогает принять работу. Формулировка «менеджер с ролью X создаёт заявку, видит обязательные поля, а при ошибке интеграции получает понятное уведомление и сохранённый черновик» уже задаёт сценарий проверки.
- проверить успешный сценарий с реальными типами данных
- проверить пустые, граничные и неверные значения
- проверить права каждой роли
- проверить повторную операцию и сбой интеграции
- проверить мобильный и клавиатурный путь, если они важны
- назначить человека, который принимает результат
Показывать нужно не только красивый экран. Полезнее увидеть работающий сценарий на каждой контрольной точке: прототип пользовательского пути, технический spike сложной интеграции, MVP, тестовые данные, отчёт о проверках и план передачи. Это позволяет менять решение, пока цена изменения ещё приемлема.
7. Подготовьте рабочий контур проекта
До разработки согласуйте единый канал решений, формат статусов, правила изменения требований, доступ к материалам, окружения и ответственность за инфраструктуру. Заказчику не обязательно управлять задачами команды, но он должен понимать, где увидеть результат, как оставить замечание и что считается принятым.
| Решение | Минимальный артефакт |
|---|---|
| Кто принимает | список ролей и полномочий |
| Как меняем объём | правило оценки влияния на срок и бюджет |
| Как принимаем | сценарии и критерии приёмки |
| Как передаём | доступы, документация, инструкции |
| Как поддерживаем | канал, приоритеты, обновления |
Если подрядчик предлагает фиксировать только список экранов, попросите добавить сценарии, данные, роли, интеграции и критерии готовности. Экран может быть нарисован, но процесс — не работать. Веб-разработка должна связывать интерфейс с правилами бизнеса и эксплуатацией.
Практический чек-лист перед стартом
- описана одна бизнес-проблема и ожидаемый результат
- назначен владелец решения и понятны роли согласования
- выделены пользователи и сквозной сценарий
- границы MVP отделены от backlog
- известны источники данных и сложные интеграции
- названы требования к доступам, безопасности и поддержке
- есть сценарии приёмки с ошибками и граничными случаями
- понятен процесс изменения требований
- определены окружение, доступы и передача результата
- Dzen-материалы для этого запуска не создаются: канал паузирован по инструкции пользователя
Как Paladin Engineering может помочь
Paladin Engineering может подключиться на этапе discovery, чтобы превратить идею в карту сценариев, прототип, техническое задание и план MVP. В зависимости от риска полезным первым результатом может быть не код всего продукта, а проверка интеграции, прототип ключевого пути или набор критериев приёмки.
Если чек-лист выявил больше вопросов, чем ответов, это нормальный результат. Изучите направление веб-разработки или оставьте задачу для обсуждения — следующий шаг должен уменьшать неопределённость, а не превращать её в красивый документ.
FAQ: подготовка IT-проекта
Нужно ли иметь готовое техническое задание?
Нет. Можно начать с проблемы, пользователей, сценария и ограничений. Техническое задание уточняется по мере проверки решений, но ключевые неизвестные нельзя выдавать за решённые.
Кто должен принимать результат?
Назначенный владелец бизнес-результата или делегированная им роль. Команда может консультировать, но без ответственного решения приёмка превращается в бесконечное согласование.
Что важнее: дизайн или архитектура?
Зависит от риска. Пользовательский сценарий проверяют прототипом, сложную интеграцию — техническим экспериментом. Нельзя выбирать один артефакт вместо понимания конкретной неопределённости.
Как не размыть MVP?
Для каждого пункта задайте связь с главной гипотезой и критерием результата. Если связь не видна, отправьте пункт в backlog или сформулируйте, какую проверку он поддерживает.
Что делать, если подрядчик не задаёт вопросов?
Попросить показать допущения, список неизвестных, границы оценки, критерии приёмки и план проверки рисков. Общий ответ без привязки к вашему процессу не заменяет discovery.
Можно ли оценить проект по одному описанию?
Можно дать предварительный диапазон при явно записанных допущениях. Надёжность оценки растёт, когда проверены сценарии, данные, интеграции, роли и критерии готовности.
Комментарии