Знание «опытного человека» обычно не осознанное: он инстинктивно направляет своё внимание к каким-то объектам в проекте, но не знает типов этих объектов, как они определяются в различных дисциплинах, не знает названий отношений этих объектов между собой. Его мысль скачет, ибо внимание управляется интуицией, при случайном шаге в сторону от удачной мысли назад вернуться уже нельзя, ибо нет какой-то осознанной линии рассуждений, нет «назад». И он легко может ошибиться в своей интуиции, ибо нельзя поправить то, чего не осознаёшь.
Неосознанное применение «опыта» нельзя исправить, обновить, рассказать окружающим, иметь в какой-то форме иной, кроме как рабочей безымянной и безмолвной интуиции, gut feeling. Интуиция иногда срабатывает, иногда нет – она не знает границы своего применения. Теория обычно срабатывает всегда, и можно проверить границы её применения. В этом сила теории. Трансдисциплина/учение выглядит как теория, она без прикладной дисциплины непрактична, но именно она уберегает от ошибок, она придаёт смысл прикладному знанию, помещает его в широкий контекст проектной работы.
Это рассуждение можно повторять по целой цепочке поддерживающих друг друга трансдисциплин/учений. В случае инженерии требований (куда кроме выявления требований входят практики анализа требований, формулирования требований, управления требованиями, валидации требований) это трансдисциплина системной инженерии. В случае управления работами это системный менеджмент.
В системной инженерии будет говориться, что требования получаются во многом из результатов дальнейшей работы над концепцией использования (requirements engineering логически следует за практикой concept development), а потом используются в архитектурной работе, а ещё дальше в проверках и приёмках (verification and validation). Огромное число ляпов и проблем проекта возникает из того, что в головах людей, прошедших трёхдневные курсы по крошечному кусочку системной инженерии (JTBD) или системного менеджмента (управление буферами проекта), нет вот этого многоуровневого понимания, как эти работы вписываются в общие работы по проекту в длинных цепочках этих работ. Важно не только удерживать во внимании (личном внимании, или внимании команды проекта) объекты какой-то прикладной практики, но и понимать место этих объектов в проекте, чтобы не было «одно лечит, другое калечит».
У менеджеров тоже оказывается, что кроме управления работами (операционного менеджмента) в менеджменте есть много чего ещё, что нужно бы учесть: например, лидерство (не все срочные работы люди бросаются делать, нужно ещё, чтобы они их захотели делать) и финансовый контроллинг (не все срочные работы дают доход). Операционный менеджер без полноценного трансдисциплинарного трудового кругозора, то есть только с прикладным трёхдневным курсом объяснения про «буфер проекта» за плечами, очень скоро услышит фатальное «какой ужас вы тут сделали с вашими буферами проекта: немедленно это прекратите, и давайте попробуем что-нибудь ещё!».
ДОБАВЬТЕ К ТРЁХДНЕВНОМУ ПРАКТИЧЕСКОМУ КУРСУ
СЕМЕСТР ТЕОРИИ
В трёхдневных курсах всё хорошо с прикладностью и практичностью, только не хватает фундаментальности и теоретичности: дисциплин не трёхдневного, а семестрового уровня (инженерия требований, управление работами) и трансдисциплин уровня уже магистерской широкой специализации (системная инженерия, системный менеджмент). Именно эти кругозорные трудовые трансдисциплины делают прикладные трёхдневные курсы уместными, помещают изучаемое знание в проектный контекст, позволяют материалу этих курсов стать действительно практичным, полезным в работе.
И это тоже ещё не конец истории! Это просто конец прикладных дисциплин как детализации отдельных трудовых кругозорных трансдисциплин. Очень часто оказывается, что системные инженеры, которые прошли курс (даже вузовский!) системной инженерии или системные менеджеры, которые прошли аналогичный курс общего менеджмента просто не понимают, как устроен труд в целом с учётом разделения труда – как взаимодействуют инженеры, менеджеры, предприниматели во всём многообразии их подролей в крупном или даже мелком проекте. Исполнитель какой-то инженерной роли ещё может как-то понимать, как он взаимодействует с другими инженерами (его же учили системной инженерии!), но теряется, когда встречает несколько разного вида менеджеров и каких-то вариантов предпринимателей, не говоря уже о других проектных ролях. С менеджерами происходит то же самое.
Читать дальше