Технология поддержки практики
Технология хорошо видима (это ж «станки и инструменты», при этом современные станки --- это главным образом софт, заметить технологию просто, она не «в голове», а «развёрнута на местности»). Тем не менее, хорошо видимая технология без понимания поддерживаемой ей дисциплины мертва. «Ружьё в руках дикаря --- кусок железа», это можно сказать про любую технологию. Традиционный капитал (средства производства) мёртв, если он не поддержан человеческим капиталом --- образованными в части дисциплины и натренированными на владение конкретным вариантом инструментария данного предприятия сотрудниками.
Если есть какой-то станок, приспособление, или программное обеспечение, то они обязательно поддерживают какую-то дисциплину/теорию. Не знаешь этой дисциплины --- неминуемо будешь микроскопом гвозди заколачивать, обращаться с ружьём как с куском железа, чисто в силу неведения.
Так, программы проектного управления могут поддерживать самые разные дисциплины проектного управления, которые определяют самые разные наборы подальф альфы «работы». Например, управление проектами может быть классическим с альфой критический путь (critical path), но теория ограничений Голдратта критикует использование альфы «критический путь» и предлагает другую альфу: критическая цепь (critical chain)[1] и управление проектом основывается на отслеживании исчерпания буферов проекта[2]. Если вы не понимаете связи между инструментами (в данном случае софт управления проектами) и разными вариантами дисциплин/теории проектного управления с их специфическими понятиями для отслеживания/альфами и подальфами, а купите просто какую-нибудь «популярную программу управления проектами», то вас может ожидать сюрприз: программы будут развёрнуты, кнопки на них будут как-то нажиматься, формы заполняться, но практика управления проектами выполняться не будет, проектам лучше не станет!
В программе классического управления проектами на рисунке нет никаких буферов проекта, поэтому она не поддерживает мышление согласно дисциплине управления проектами теории ограничений:
А вот эта программа поддерживает, «светофоры» управления буферами хорошо видны на её скриншотах:
Если не владеть каким-то менеджерским кругозором в части дисциплин проектного управления, то можно вообще не понять, почему так различается инструментарий для вроде бы одной и той же практики, а «светофоры буферов» будут казаться особенностями интерфейса программы, а не варианта дисциплины проектного управления.
Инструментарий различается не столько удобством в использовании, сколько поддерживаемыми дисциплинами этой практики: тем, какие понятия в мышлении инструментарий способен отразить.Удобный в использовании негодный для дела инструментарий помочь не может, а неудобный в использовании, но годный для дела --- плохо, но поможет. Вы сможете различить эти две ситуации, если кроме технологии обратите внимание на поддерживаемую ей дисциплину. Она невидима, но вы можете научиться о ней думать. Практики определяются по своим дисциплинам, носят названия дисциплин, а не технологий.