Прочитал «Цель» Голдратта и поймал себя на том, что почти все проектные проблемы, с которыми я сталкивался, можно описать одной картиной: работа уже сделана, но ценность до пользователя ещё не дошла.

Разработчик закончил задачу — она ждёт ревью. Ревью пройдено — ждёт тестирования. QA готов — ждём окружение или доступы. Всё проверено — ждём окно релиза, согласование, инфраструктурную команду или изменение в соседнем сервисе.

В статусе при этом может быть красиво: «разработка выполнена на 80%», «релиз в плане», «блокирующих проблем нет». Только календарь движется, а пользователь ничего не получает.

Это хорошо видно, когда начинаешь рисовать процесс прямо на встрече. Регламент обычно выглядит логично, пока не переносишь его в схему: здесь задача возвращается на уточнение, тут нет владельца решения, здесь три команды ждут одну, а в конце оказывается, что в процесс вообще не встроена проверка готовности окружения.

Люди перестают спорить друг с другом и начинают спорить со схемой. И это продуктивнее.

В «Цели» ограничение — не обязательно станок в цеху. В IT им может быть один архитектор, через которого проходят решения; QA, который подключается только перед релизом; ИБ без понятного срока согласования; тестовый контур; ручная операция, о которой все вспоминают в последний день.

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