Продакты должны найти решение проблем бизнеса и покупателей. Но причины у проблем могут быть разные; решения одной и той же проблемы, возникшей по одной причине, могут быть разные (с разным влиянием на пользователя и бизнес).
Поэтому продакт снижает неопределённость выбора: какую проблему решать и какое решение выбрать, чтобы получить нужный эффект.
Проджект обеспечивает реализацию/исполнение/execution выбранного решения.
Можно сказать, что проджект повышает надёжность реализации выбранного варианта: уменьшает устранимую вариативность/изменчивость/variability работ и снижает последствия оставшейся изменчивости.
Чтобы снизить устранимую вариативность работ, нужно:
– уменьшить число отвлечений (на лишние работы, запросы, по ошибке прилетевшие к вам),
– отложить дату старта новых работ, если загрузка уже высокая,
– уменьшить незапланированные переключения,
– уменьшить число переделок,
– уменьшить число задержек из-за отсутствующей информации и по другим причинам,
– обеспечить предварительную подготовку к выполнению работ (full kitting),
– уменьшить размер релизов (small batch size),
и тп.
–– то есть, делать всё то, что мы делаем в рамках резидентур "Рабочего развития", начиная с R1 "Распожаризация".
Чтобы снизить последствия оставшейся вариативности, требуется:
– управлять буферами:
– буфером capacity/мощности (для срочных работ, восстановления после инцидентов и тп),
– буфером времени (защищает завершение проекта или критического пути),
– снизить число простоев ограничения (например, за счёт того, что вы лучше готовите рабочие продукты/артефакты на входе)
– отслеживать ранние сигналы возможного срыва и продумывать план решения (fallback'и и пр).
С неопределённостью выбора вариантов решения проджекты не работают. Но, пожалуй, с некоторым допущением можно сказать, что проджекты работают над устранением неопределённости в головах команды по поводу выбранного варианта решения. Нужно обеспечить единое понимание командой реализуемого варианта, чтобы не получилось в итоге, что сделали "капусту вместо яичницы" 😉