Если попытаться описать digital-производство честно, то это не цепочка этапов и не «воронка задач». Это система, в которой одновременно существуют:

• идеи, которые ещё не проверены;
• решения, которые уже начали разрабатываться;
• ожидания клиента, которые опережают реальность;
• ограничения технологий, которые всегда всплывают позже.

Всё это живёт одновременно. Поэтому главная иллюзия новичка — вера в последовательность. В реальности нет «сначала дизайн, потом разработка». Есть постоянное взаимное влияние.

Формально всё начинается с задачи, но фактически — с того, как её поняли разные участники. Уже на этом этапе возникает первая точка расхождения:

• клиент думает категориями бизнеса;
• дизайнер думает категориями опыта пользователя;
• разработчик думает категориями системы и ограничений;
• PM думает категориями сроков и рисков.

И один и тот же запрос сразу превращается в четыре разные версии реальности.

Когда PM смотрит на дизайн как на "картинку", он теряет главное. Дизайн — это процесс, в котором одновременно решаются несколько задач.

Самая опасная ошибка — воспринимать дизайн как визуальный этап. На самом деле дизайн — это этап, где абстракция превращается в конкретные обязательства. Каждый экран фиксирует будущую реальность разработки.

И если упростить, то дизайн — это момент, когда идея начинает стоить денег. Потому что всё, что нарисовано, потом нужно будет реализовать, поддерживать и адаптировать.

Одна из самых частых иллюзий в проектах в том, что многие думают, что разработчик просто переносит дизайн в код. На практике разработка — это самостоятельный слой решений.

Если дизайн фиксирует идею, то разработка возвращает в неё ограничения. И это всегда момент столкновения, потому что разработка живёт в другой логике:

• производительность;
• масштабируемость;
• поддерживаемость;
• зависимость от технологий;
• поведение в разных средах.

И здесь почти всегда происходит одно и то же: то, что красиво, оказывается сложным, а то, что просто в дизайне, оказывается дорогим в коде.

Креатив в digital-производстве часто романтизируют. Кажется, что это зона свободы. Но в реальности он существует внутри жёсткого поля ограничений.

Потому что любое решение должно одновременно:

• соответствовать бренду;
• работать на бизнес-цель;
• быть реализуемым технически;
• укладываться в сроки;
• не ломать другие части системы.

И поэтому креатив — это не генерация идей, а фильтрация идей через ограничения.

Есть огромный пласт работы, который не отображается в задачах. Это «скрытая работа производства». Она не фиксируется как отдельные пункты, но занимает большую часть времени:

• уточнения между дизайном и разработкой;
• пересогласования деталей;
• адаптация решений под ограничения;
• синхронизация ожиданий;
• возвраты на доработки.

И именно здесь сгорает большая часть сроков. Не в задачах, а в переходах между задачами.

Если разобрать почти любой срыв сроков, он возникает не в одном месте — он появляется на стыках. Именно там, где встречаются разные типы работы:

• дизайн — разработка;
• клиент — команда;
• креатив — ограничения;
• ожидания — реальность.

И каждый такой стык — это потенциальная точка напряжения.

Если убрать иллюзию линейности, процесс больше похож на постоянную корректировку системы. Что-то уточняется. Что-то переделывается. Что-то упрощается, а что-то добавляется. PM в этом процессе не наблюдатель, он — координатор постоянных изменений.

В нормальном режиме коммуникация — это обмен информацией. В кризисе — это инструмент управления ожиданиями и решениями и здесь критично не только что сказать, но и как.

Неправильная коммуникация выражается в тревожных формулировках («у нас проблемы», «мы не успеваем»), тогда как правильная строится на фактах, причинах и сценариях.

Например:
PM объясняет, что проект отклонился от плана из-за конкретного этапа и предлагает несколько вариантов: сохранить объём сдвинув срок или сохранить срок сократив часть функционала. В этом случае клиент не теряет контроль над ситуацией.

Digital-производство — это не линейный процесс и не последовательность этапов. Это система взаимных ограничений, решений и конфликтов, которые постоянно влияют друг на друга.

Роль PM здесь не в том, чтобы передавать задачи между командами, а в том, чтобы удерживать систему в рабочем состоянии в условиях постоянных изменений, возвратов и пересборок.