Есть две великие школы проектирования процессов.
Есть две великие школы проектирования процессов. Первая школа говорит: «Давайте сначала договоримся, а потом что‑нибудь сделаем». Вторая: «Давайте сначала что‑нибудь сделаем, а потом уже договоримся, что именно мы сделали». В первой школе собираются серьёзные люди, рисуют схемы, пишут документы, спорят над формулировками полгода. — Сначала чётко опишем, кто кому что должен, какие поля обязательные, какие статусы допустимы. К моменту, когда всё согласовали, бизнес уже три раза передумал, кого, кому и что вообще должен. Зато есть чудесный PDF на 120 страниц и чувство, что работа проделана титановая. Во второй школе всё проще: — Я тут уже накидал сервис, он почти работает, посмотрите. — А где описание? — Да там же в коде всё понятно. Понятно, конечно, ровно одному человеку — автору. Остальные просто запоминают: «Если дернуть вот сюда, иногда возвращает вот это. Главное — не спрашивать, почему». В первом подходе любимый спорт — бесконечные согласования. — Это поле точно string? — Может, всё‑таки enum? — А вдруг завтра понадобится ещё одно значение? Чувствуешь, как система стареет, ещё не родившись. Во втором подходе спорт другой: догонять реальность. — Мы тут добавили новое поле в ответ. — А кто‑нибудь об этом знает? — Ну вы же видите по факту. Документация — это живой организм, пусть адаптируется. Адаптируется, да, в виде аналитика, который в проде ловит сюрпризы и потом задним числом придумывает, как это объяснить на человеческом языке. В идеальном мире сначала люди договариваются, что они вообще хотят от процесса, а потом делают так, чтобы код это уважал. В реальном мире чаще всего выходит гибрид: сначала кто‑то быстренько наклепал решение, потом вокруг него начинают срочно рисовать красивые схемы, чтобы не было стыдно показывать руководству, и в конце всем рассказывают, что именно так и задумывалось «с самого начала».