Прикладных знаний в любом деле участвует больше, чем можно получить за три дня

Значительное число нелепостей в работе возникает не от владения натренированной всего за три дня прикладной практики, а от непонимания деятельностной трансдисциплины, общей для многих и многих практик. Скажем, в инженерии требований нет понимания того, что и почему важно в этих требованиях: требования прилетают с самых разных направлений, общаться нужно по поводу требований с самыми разными людьми, и такая прикладная дисциплина как (JTBD) решает отнюдь не все проблемы с требованиями — там не решаются, например, проблемы управления требованиями, задействования требований из стандартов и множество подобных вопросов. На прикладном тренинге, оказывается, говорят правду, но не всю правду. В случае JTBD не рассказали в целом про дисциплину «инженерия требований»[1].

Прикладные практики обычно просты и незатейливы, они конкретны и вроде как легко понимаются, а вот трансдисциплины для своего понимания требуют существенного задействования мозгов, они более абстрактны, более трудны в понимании. Это всёгда так для трансдисциплин. Предобучение всегда неочевидно и дорого по времени и ресурсам. Трёх дней курсов для овладения инженерией требований с профессиональным качеством работы уже не хватит, тут может потребоваться семестр плотной работы в инженерном вузе. Инженеров ведь так и учат их трансдисциплинам — семестрами. И потом они способны за три дня разобраться с прикладной практикой. Откуда берётся уверенность, что трёхдневный курс даст незнакомому с трансдисциплиной человеку нужные умения на уровне вузовского семестра? А если человек знаком с инженерией требований? Сначала нужно понять, когда он ей учился: если это тридцатилетней давности инженерия требований, то нужно перепрошить мозг трансдисциплиной 2020 года, а потом уже знакомиться с JTBD. Ибо с точки зрения старой трансдисциплины JTBD едва ли вообще имеет смысл. А в сегодняшней инженерии требований сегодня это мейнстрим, одна из лучших практик выявления требований как главной практики в инженерии требований.

То же самое обнаруживается с управлением буферами проектов: пока не понял про управление работами в целом (где рассматривается не только тридцатилетней давности голдратовский вариант управления проектами, но и какой-нибудь кейс менеджмент) работа с управлением буферами проекта будет по принципу «пошли дурака богу молиться, он и лоб расшибёт». В результате на хорошей прикладной практике будет поставлен крест (виновата же она, а не недообразованность её применяющего!). Вывод после неудачи с управлением по буферам проекта будет — «давайте попробуем что-нибудь ещё». Вузовского семестра-то по state-of-the-art (сегодняшней, а не, например, конца 20 века!) трансдисциплине управления работами/операционного менеджмента почти ни у кого в мозгах нет, нет даже у «проходивших мимо» этот предмет в вузах. Но именно это «теоретическое» знание оживляет прикладную живую и практичную дисциплину, не даёт делать новичковых ошибок.

Самые опытные (буквально: у кого не столько двадцатилетний опыт деятельности, но хотя бы однолетний опыт, повторённый двадцать раз) могут неожиданно и справиться с приложением материала трёхдневного тренинга: они за много лет повстречались со многими прикладными практиками и могут обойти грабли, полагаясь на часто неосознанное знание более широкой концептуальной дисциплины. Но это знание неосознанное: его нельзя поэтому исправить, обновить, рассказать окружающим, иметь в какой-то форме иной, кроме как рабочей интуиции. А интуиция иногда срабатывает, иногда нет — она не знает границы своего применения. Теория обычно срабатывает всегда, и можно проверить границы её применения. В этом сила теории. Трансдисциплина выглядит как теория, она без прикладной дисциплины непрактична, но именно она уберегает от ошибок, она придаёт смысл прикладному знанию, помещает его в широкий контекст проектной работы.

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

В системной инженерии будет говориться, что требования получаются во многом из результатов дальнейшей работы над концепцией использования (requirements engineering логически следует за практикой concept development), а потом используются в архитектурной работе, а ещё дальше в проверках и приёмках (verification and validation). Огромное число ляпов и проблем проекта возникает из того, что в головах прошедших трёхдневные курсы по крошечному кусочку системной инженерии (JTBD) или системного менеджмента (управление буферами проекта) нет вот этого многоуровневого понимания, как эти работы вписываются в общие работы по проекту в длинных цепочках этих работ.

У менеджеров тоже оказывается, что кроме управления работами (операционного менеджмента) в менеджменте есть много чего ещё, что нужно бы учесть: например, лидерство (не все срочные работы люди бросаются делать, нужно ещё, чтобы они их захотели делать) и финансовый контроллинг (не все срочные работы дают доход). Операционный менеджер без трансдисциплинарного деятельностного кругозора, то есть только с трёхдневным курсом за плечами, очень скоро услышит фатальное «какой ужас вы тут сделали: выкидывайте скорее, и давайте попробуем что-нибудь ещё».

[1]  про проблемы инженерии требований как дисциплины см. в https://ailev.livejournal.com/1425741.html.

Новости по поводу книги/текста появляются в блоге автора, https://t.me/ailev_blog, предложения и замечания присылать автору по адресу ailev@asmp.msk.su

Источник: книга А.Левенчука «Образование для образованных 2020».