Этот раздел завершает рассуждения, начатые в разделах 2.2–3.

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

Термин «проект» стоит в первом ряду пострадавших от затрепанности слов.

Экспедиция на Марс – проект.

Разработка вакцины – проект.

Замена устаревшей части оборудования на что-то более производительное – тоже проект.

И «выпекание» тошнотворно банального сериала – не менее чем проект.

Да даже поползновение полусветской блогерши раз в неделю окунаться в жизнь народную методом «поездка к массажисту на метро» – ух какой проект!

Помилуйте, если все вышеозначенное – проект, то что же тогда простое действие (пусть даже не мыследействие)?!

Что же тогда есть перемещение с дивана в туалет и обратно?

Сущностная разница между процессом и проектом выявлена в разделе 2.2. Там же (принцип 6) мы наметили траекторию развития бизнес-системы, которую здесь повторим в виде диаграммы.

Напомним, что в процессе мы пытаемся добиться минимальной энтропии – именно пытаемся, поскольку реализация почти любого подпроекта из далеко не полного перечня в третьем блоке на рисунке 12 может вызвать потрясения в виде изменения модульно-функциональной структуры и т. п. А это означает, что энтропия (хорошо, если временно) возрастает[65]. Но мы научились алгоритмизировать управление процессом, – например, как это описано в пункте 2.3.2, а потому сумеем предотвратить рост его хаотичности (стало быть, и рост энтропии). И тут возникает вопрос: а можно ли подобным образом удерживать в приемлемых границах энтропию проекта?

Рисунок 12

Отвечаем на этот вопрос утвердительно и предлагаем два безусловно полезных метода.