Paladin Engineering

Слова «сайт» иногда скрывают целую систему Представьте типичный разговор. Бизнесу нужен новый сайт: несколько страниц, форма заявки, каталог и современный дизайн. Через неделю в список добавляются вход для клиентов, история заказов, документы, уведомления и разные права для менеджеров. Внешне это всё ещё сайт. Но по поведению уже веб-приложение. Если не заметить разницу в начале, бюджет и сроки начинают расти не потому, что команда «передумала», а потому, что у проекта появился другой тип задачи...

История ниже — гипотетический собирательный сценарий, а не подтверждённый кейс Paladin Engineering.* Представьте ситуацию: у компании есть одна рабочая таблица. В ней заявки, оплаты, документы, ответственные и комментарии. Пока процесс ведут два человека, всё выглядит терпимо. Потом добавляются новые участники — и внезапно у каждой строки появляется несколько версий. Один сотрудник исправил статус, другой продолжил работу по старому файлу. Руководитель спрашивает, сколько задач реально открыто, а в ответ получает новую сводку, которую кто-то собирает вручную...

Представьте ситуацию: команда хочет запустить веб-приложение и уже собрала список экранов. Кажется, осталось найти разработчиков и «сверстать кабинет». Но на первом рабочем сценарии выясняется: у разных ролей разные права, данные приходят из двух систем, а пользователь должен понимать, что произошло после ошибки. Приложение ещё не началось, а решений стало больше. Экран показывает только часть работы. За формой стоят правила проверки, состояния, роли, сохранение, уведомление и обработка сбоя. Поэтому...

Представьте ситуацию: в компании хотят «простой портал для сотрудников». В списке — заявки, документы и уведомления. На первой встрече это звучит компактно, а через неделю выясняется, что заявку нужно согласовать по-разному для трёх отделов, файл нельзя показывать всем, а статус должен приходить ещё и в почту. Экранов почти не прибавилось, зато проект стал другой системой. Типичный сценарий начинается с хорошего намерения: перенести знакомую таблицу в аккуратный интерфейс. Ошибка в том, что таблица скрывает правила...

Типичный собирательный сценарий начинается с фразы: «Нарисуйте первый экран, а дальше разберёмся». Через несколько обсуждений выясняется, что у ролей разные правила, данные лежат в нескольких местах, а главный сценарий зависит от внешнего API. Макет уже есть, но решение задачи ещё не доказано Discovery — это работа до основной разработки, которая уменьшает неопределённость. Команда разбирает проблему, пользователей, данные, интеграции и границу первой версии. Результатом должны быть решения, а не просто набор встреч...