Анатолий Левенчук
Образование для образованных. 2021

Полная версия

РАЗБИЕНИЕ ТРУДА НА ОСНОВНЫЕ ЕГО ВИДЫ

И ИХ ТРУДОВЫЕ РОЛИ

Зададим основное разделение труда/проектных деятельностей/практик на его виды и укажем трудовые/деятельностные/проектные роли, которые занимаются этими видами:

• Инженер занимается (системной) инженерией:

• разработчик концепции использования/менеджер продукта занимается разработкой концепции использования,

• инженер по требованиям занимается инженерией требований,

• системный архитектор занимается инженерией системной архитектуры,

• управляющий конфигурацией и изменениями/жизненным циклом занимается управлением конфигурацией и изменениями/жизненным циклом,

• инженер по производству занимается производством/строительством (изготовлением и сборкой)

• инженер по испытаниям/тестированию занимается проверкой и приёмкой

• инженер по эксплуатации занимается эксплуатацией (ремонты и техобслуживание)

• Менеджер занимается (системным) менеджментом:

• Операционный менеджер занимается операционным управлением/цепями поставок/логистикой,

• Финансовый менеджер занимается управленческим учётом и контроллингом,

• Архитектор предприятия занимается инженерией предприятия и архитектурой предприятия/технологическим менеджментом,

• Организатор занимается организационными изменениями/развитием

• Предприниматель занимается (системным) предпринимательством

• Стратег занимается стратегированием

• Менеджер по продажам занимается продвижением продукта,

• Инвестиционный финансист занимается корпоративными финансами,

• Корпоративный гувернор/управляющий занимается корпоративной поднадзорность/governance

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

• Педагог занимается обучением студентов/учеников

• Тьютор/коуч занимается тьюторингом/коучингом. Аналог менеджера по продажам.

• Преподаватель-консультант («предметник») занимается консультациями. Аналог производственного инженера для научаемого мастерства.

• Преподаватель-лидер («вожатый») занимается мотивированием. Аналог производственного инженера для личности студента.

• Методолог занимается методологией (определяет чему учить). Аналог инженера по требованиям для мастерства.

• Методист занимается разработкой курсов (определяет как учить, instructional design). Аналог инженера-архитектора.

Знание этих общих деятельностей/практик и их подпрактик на уровне хотя бы знакомства с одним учебником крайне важно, чтобы понимать интересы и предпочтения людей в их рабочих ролях. Что именно вас спрашивает инженер по требованиям, как ему лучше отвечать? Чем интересуется предприниматель в его подроли стратега? У каких ваших ролей эти добрые люди в их своих таких разных ролях интересуются самыми разными вопросами?

Для получения представления о том, как устроен труд в проектах, нужно проработать понимание трудовых практик инженерии (в их огромном разнообразии), менеджмента, предпринимательства. Что представляет интересы инженера, менеджера, предпринимателя, как они взаимодействуют между собой, каких целей добиваются. Это учебный объём где-то 15 книг обзорного уровня, хотя бы по одной для каждой подспециализации. Предобучение (школа, бакалавриат) должно давать трудовой кругозор, представление о разделении труда, понимание на кругозорном уровне основных трудовых практик, основных видов деятельности! Нужно знать, какие роли играются в театре жизни в каждом из проектов, и не попадать впросак: если вас спрашивают как менеджера, а вы даёте ответ как предприниматель – то вы «не угадали», и наоборот тоже. Более того, если вас спрашивают как одну из подролей, а вы даёте ответ как другая подроль (помним про дантиста и гинеколога!), то вы тоже «не угадали»!

ПРИМЕР ПРАКТИКИ/ДЕЯТЕЛЬНОСТИ ОПЕРАЦИОННОГО

МЕНЕДЖМЕНТА

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

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

• Теория ограничений систем Элияху Голдратта, там течёт inventory, вытекает throughput

• Русская школа управления Алексея Андреева, там течёт сила по жиле⁹¹

• Цепочки приращения пользы/value, там течёт и наращивается польза/value

• Сетевая организация (не структура!), там текут товары (сеть универмагов), знания (сеть аналитических центров).

• Цепи поставок, там текут запасы по складам и местам переработки

• Кооперативные процессы СМД-методологии, там текут продукты деятельностных актов

•…

Когда вы придёте в ту или иную организацию, в тот или иной проект в рамках организации, вы обязательно там встретите человека, который будет играть роль операционного менеджера. Он будет говорить абсолютно разные слова в зависимости от того, чему его учили в той или иной школе менеджмента. Но после хорошего курса менеджерского кругозора под этими словами вами должно сразу распознаваться: «он говорит о потоке, он хочет ускорить его прохождение! Это операционный менеджер!» – и дальше с ним действовать, исходя из этого понимания. И так с каждой практикой, каждой ролью. Проработайте хотя бы 15 книжек, по одной на каждую основную подроль в предпринимательстве, инженерии, менеджменте. Поймите интересы и предпочтения ролей в каждой из описанных там деятельностей. Поймите ключевые понятия каждой из деятельностей. Сделайте это в разбиении хотя бы на один уровень вниз.

При этом трудовой кругозор не ограничивается только основными практиками. Подроли в обучении людей (не только в учебных заведениях, но обучить людей нужно, например, рабочим процессам в организации – это ведь тоже обучение, схема проекта учебного курса тут тоже применима!) мы обсудили. А ведь сфер деятельности много больше. Юриста (использует законодательство) и правоведа (пишет законопроекты) вам тоже хорошо бы различать, это тоже входит в трудовой кругозор.

В практиках, конечно, могут быть и несколько ролей: практика обмена/торговли включает роли продавца и покупателя, медицинская практика роли врача и пациента, обучение связано с взаимодействием студента и преподавателя, а ещё развивающегося и тьютора.

МАСТЕРСТВО ВЫБОРА ДЕЯТЕЛЬНОСТНОЙ РОЛИ

Точно так же «врач» делится на множество ролей в медицине (не путаем дантиста и гинеколога), и во всех остальных деятельностях дела обстоят так же. Иногда это дробление деятельностей/практик и ролей с возможностью отдельных людей и организаций играть всё более и более мелкие и специализированные их части называют разделением труда, а вот этот тренд непрерывного деления ролей на всё более мелкие подроли – углублением разделения труда. Был «врач» – выделилась специализация «врач-хирург» – выделилась подспециализация «кардиохирург». Роль вебмастера выделилась из роли «айтишника» буквально на несколько лет в конце девяностых годов прошлого века, а затем в первое же десятилетие двадцать первого века раздробилась на более мелкие подроли именно в порядке углубления разделения труда: дизайнер веб-страницы (потом – UX специалист), верстальщик, программист фронт-энда, программист бэк-энда, редактор, контент-менеджер, SEO, и это ещё не полный список.

Мастер волен выбирать пути в жизни, но он должен хотя бы понимать на самом общем уровне само наличие этих быстро меняющихся путей – и не на уровне интуитивных представлений, а на осознанном уровне. Мы ведь только что обсудили самое общее устройство карты этих путей, карты человеческой деятельности.

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

Ролевое мастерство, которое нужно получить в ходе предобучения – это

• мастерство выбора новой деятельностной роли,

• мастерство получения навыка в практике этой роли,

• мастерство удержания этой роли и качественного выполнения практики в проекте,

• мастерство оставления этой роли в тот момент, когда она устарела (не нужно держаться за роль извозчика в тот момент, когда вокруг лошади остались только в спорте и очень изредка в парках развлечений).

Надо обязательно проработать (не просто прочесть учебники или материалы курсов: бесполезно ведь читать учебники «как ездить на велосипеде») учебные материалы по всем этим вопросам, потратить год-другой на достижение этого мастерства. Увы, тут как со спортом или игрой на музыкальных инструментах: речь идёт о годе-другом, а не о паре недель занятий. Ролевое мастерство быстро не ставится.

Но как с актёрским мастерством (примерно всё то же самое: умение выучить роль, войти в роль при её исполнении, удерживать роль, безопасно выйти из роли, не путать себя и роль) в театральных вузах, нужно ещё и знать роль, выучить её!

Прикладное мастерство в конкретной проектной роли, а то и мелкой подроли этой роли требует отдельного обучения. Но мы будем считать его прикладным, «подстройкой» – и получать его нужно в магистратуре и на курсах повышения квалификации (хотя самообразование тут, конечно, тоже возможно. Но курсы повышения квалификации – это ведь тоже самообразование, равно как и магистратура!).

Скажем, в большом проекте вы будете не просто системный инженер, а инженер по требованиям, или даже инженер по требованиям в авиастроении. На освоение прикладной практики/вида труда/деятельности придётся потратить год-два, тоже проработать пару десятков учебников, да ещё и попрактиковаться в живых проектах. И это всё через некоторое время устареет, прогресс ведь неостановим, поэтому это нужно будет повторять в жизни снова и снова!

Ролевое мастерство, которое должно быть у каждого человека, устроено явно избыточно с прикладной точки зрения: оно никак не отвечает требованию чисто прикладного образования: когда «что потребуется, то и выучим – тогда, когда потребуется». Это ведь явно «образование впрок»: зачем знать, что существует здравоохранение и чем оно там занимается, если все жизненные планы, например, пока в инженерии? Затем, чтобы вообще ориентироваться в жизни: строить планы в инженерии, зная о существовании здравоохранения. Можно озаботиться тем, чтобы сделать знание трудового/деятельностного/практического кругозора максимально компактным и согласованным между собой, для этого по максимуму задействовав понятия более фундаментальных мыслительных практик типа семантики, онтологии, системного мышления, которые собираются в интеллект-стек как некоторое базовое, фундаментальное умение культурного человека разбираться с разными предметными областями, встречающимися в самых разных проектах. Так что перед годом получения трудового кругозора нужно будет потратить ещё год на обучение мыслительным практикам интеллект-стека (об этом мы расскажем подробней, но чуть позже).

Все эти деления деятельностей и ролей, конечно, очень и очень условны и существенным образом могут различаться в зависимости от того, для чего эти деления используются. Мы тут приводим деление, удобное для целей системного развития личности в части ускоренного (а не через годы работы в разных местах) получения трудового кругозора. И, конечно, мы тут не настаиваем на точной терминологии, все названия видов труда/деятельностей/практик и ролей тут условны (тем более, что есть определённый произвол при переводе названий с английского, например corporate governance традиционно переводят как «корпоративное управление», но мы предлагаем более точно отражающий суть практики перевод «корпоративная поднадзорность» (governance это не «управление», это присмотр/надзор). Так спорить можно почти по каждому термину, но мы даже спорить не будем. Используйте те термины, которые более вам привычны. Но будьте осторожны, ибо при замене терминов можно незаметно подменить и само рассуждение, которое мы тут приводим.

Почему не работают трёхдневные курсы ни для менеджеров, ни для инженеров

ТРЁХДНЕВНЫЕ КУРСЫ, ГДЕ НИКАКОЙ ТЕОРИИ,

ТОЛЬКО ПРАКТИКА

Практически все сегодняшние анонсы прикладных тренингов по повышению квалификации содержат фразу о том, что содержание исключительно практично – никакой теории, чистые приёмы работы, «сразу бери – и в дело». И это чистая правда. Эти тренинги так и устроены: сугубо прикладные объяснения, рассказывающие какие таблички в каких формочках заполнять, какие кнопки в каких софтах нажимать. Скажем, берём практику Jobs-To-Be-Done (JTBD)⁹² из инженерии требований или практику управления буферами проекта в голдраттовском варианте практики управления проектами. Вас научат последовательности шагов, дадут названия этих шагов, покажут какие таблички заполнять, какой софт использовать. Объяснений причинно-следственных связей, почему это всё работает – это «сложно», этого не будет, «чтобы водить автомобиль, необязательно знать, как работает бензиновый, дизельный, или даже электродвигатель».

Но когда вы попробуете всё это знание трёхдневного тренинга применить в работе, то ничего не получится: всё будет почему-то совершенно не так, как описывалось на курсах. И дело не в том, что вы что-то забыли или пока медленны во всех показанных вам действиях. Просто всё идёт не так, и непонятно почему. И ведь так было после каждых трёхдневных курсов, нет?

Неважно, инженерные практики изучаются, менеджерские, предпринимательские, образовательные или ещё какие-то: «три дня чистой практики – и в продакшн» оказывается недостаточно для реального дела, результаты трёхдневных «чисто практических» обучений разочаровывают, и разочаровывают сильно. Прикладные трёхдневные тренинги безуспешны, ибо если не понимать причинно-следственных отношений в изучаемой практике и их природы, нельзя будет подстраивать практику под обстоятельства конкретного проекта. Нельзя «просто подставлять в формулу», например в E=mC² нужно перед применением формулы хорошо понимать, что такое E (энергия в её разнообразии видов), что такое m (масса, её отличие от веса и т.д.), скорость света (в том числе как она меняется в разных средах), и много чего ещё. Это много-много текста помимо краткой формулы. В трёхдневных курсах формулы дают, а вот эти «много-много текста» с объяснениями опускают, ибо «никакой теории, чистая практика». И объяснениями называют не объяснения причинно-следственных связей в изучаемой предметной области, а объяснения по пользованию рецептами: что куда надо подставить, чтобы «получилась магия». А магия, увы, иногда в проекте получается, а иногда не получается. Для понимания и коррекции тут требуется знание объяснений-теории, чего в трёхдневных тренингах не дают.

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

Всё, что можно в трёхдневном курсе неправильно понять или пропустить мимо ушей, будет понято неправильно или пропущено мимо ушей. Но не это «неправильное понимание» и «невнимательность учеников» основная причина неуспеха, а непонимание того, как вписывается «работа по рецепту» в остальные работы проекта.

ПРИКЛАДНЫХ ЗНАНИЙ В ЛЮБОМ ДЕЛЕ УЧАСТВУЕТ БОЛЬШЕ,

ЧЕМ МОЖНО ПОЛУЧИТЬ ЗА ТРИ ДНЯ

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

Скажем, в инженерии требований нет понимания того, что и почему важно в этих требованиях: требования прилетают с самых разных направлений, общаться нужно по поводу требований с самыми разными людьми, и такая прикладная дисциплина как (JTBD) решает отнюдь не все проблемы с требованиями – там не решаются, например, проблемы управления требованиями, задействования требований из стандартов и множество подобных вопросов. На прикладном тренинге, оказывается, говорят правду, но не всю правду. В случае JTBD не рассказали в целом про дисциплину «инженерия требований»⁹³, поэтому будет даже непонятно, как выбрать именно JTBD из многочисленных других аналогичных конкурирующих с JTBD практик инженерии требований, а не только непонятно, что ещё нужно знать-уметь, чтобы выполнить полностью работу инженера по требованиям «под ключ». Впрочем, и при рассказе об инженерии требований тоже не всё говорят! Ведь инженер по требованиям общается и с другими ролями в проекте, выполняя свои практики: и с менеджерами (работы по инженерии требований должны быть проведены вовремя и стоить они должны не дорого, сами требования должны быть такими, чтобы разработка системы не шла бесконечное время и система не стоила бесконечных денег), предпринимателями (требования должны соответствовать стратегии и согласованы с тем, что говорят занимающиеся продвижением люди), и с архитекторами (требования описывают какова система, а архитекторы для удовлетворения требованиям описывают как система устроена, и требования не должны быть невыполнимыми), и с инженерами по испытаниям (систему будут испытывать/тестировать на соответствие требованиям). Так что нужно бы рассказать и про системную инженерию, и про менеджмент, и про предпринимательство, иначе работа по JTBD будет не очень вписана в общие работы по проекту, проблемы будут, как всегда, «на стыках».

Прикладные практики обычно просты и незатейливы, они конкретны и вроде как легко понимаются, а вот трансдисциплины для своего понимания требуют существенного задействования мозгов, они более абстрактны, более трудны в понимании. Это всегда так для трансдисциплин, они менее похожи на быстроприложимые к жизни «рецепты», «лайфхаки», «приёмы работы».

Предобучение всегда неочевидно, всегда дорого по времени и ресурсам. Трёх дней курсов для овладения инженерией требований с профессиональным качеством работы уже не хватит, тут может потребоваться семестр плотной работы в инженерном вузе – и помним, что вузовский семестр (полгода учёбы) это 900 учебных часов⁹⁴. Инженеров в вузе учат трансдисциплинам семестрами, а не «трёхдневками» тематических семинаров по отдельным прикладным практикам! А потом – после фундаментального образования, а не после «знания многих лайфхаков» они, конечно, становятся способны за три дня разобраться с какой-то прикладной практикой в рамках их уже имеющегося трансдисциплинарного мыслительного мастерства.

Откуда берётся уверенность, что трёхдневный курс по какой-то микропрактике даст незнакомому со многими и многими мыслительными практиками (семантика, онтология, системное мышление, практики трудового кругозора и т.д.) человеку нужные умения на том же уровне, какой даёт полный вузовский семестр? Откуда уверенность, что три дня равны полугоду обучения? Это же надежда на чудо! Если вы отправите себя, или своего сотрудника на трёхдневный курс по абсолютно неважно, какой дисциплине, вы уверены, что вы или он вернутся значимо поумневшими, что вы или он научитесь что-то делать, а не просто узнаете несколько новых слов?! Уверенность может быть, но только в случае сильного интеллекта, обеспеченного хорошей трансдисциплинарной подготовкой, если у вас или у посланного сотрудника достаточен для быстрой прикладной учёбы калибр личности, достаточное для этого скоростного понимания предмета мыслительное мастерство!

ТРАНСДИСЦИПЛИНЫ ИЛИ СВЕЖИЕ, ИЛИ ЗАБЛУЖДЕНИЯ.

Осетрина бывает или первой свежести, или не осетрина. Так и трансдисциплины. Если какая-то теория/объяснения/дисциплина «свежая», например, теория флогистона в 18 веке (термин был введён в 1667 году)⁹⁵, то это нормально. Если дисциплина и основанные на ней практики устарели, то это лучше бы считать заблуждением.

Это верно и в естественных науках (физике, химии, биологии), и в науках об инженерии, менеджменте, предпринимательстве и остальным деятельностям (медицине, спорту, образованию и т.д.). Если вы до сих пор считаете, что разработка может вестись каскадно/водопадно в части её жизненного цикла, то есть сначала разрабатываются требования, потом инженеров по требованиям можно уволить, а дальше начинают работать инженеры-архитекторы, потом их тоже можно уволить, работают проектировщики, а потом начинают работать производственники, а испытатели включаются в самом конце – вы заблуждаетесь, в жизни так не бывает, хотя «народные» представления об инженерии именно таковы, особенно часто эти заблуждения встречаются у плохо знакомых с инженерией исполнителей роли менеджеров. Эти заблуждения вредны для проекта! Это было теорией 20 века, в 21 веке уже никто из образованных людей так не думает, думают только неучи!

Предположим, что человек, который пошёл на JTBD уже знаком с инженерией требований. И тут сначала нужно понять, когда он учился инженерии требований: если это версия тридцатилетней давности инженерии требований (скажем, это выпускник вуза 2000 года, тогда вполне вероятно, что его там научили версии 1990 года, вот и набралось тридцать лет до текущего момента!), то нужно перепрошить мозг трансдисциплиной текущего (когда пишутся эти строки, то 2021) года, а потом уже знакомиться с JTBD. Ибо с точки зрения старой трансдисциплины тридцатилетней давности сегодняшняя JTBD едва ли вообще имеет смысл, это «игрушка этих молодых выскочек». А в сегодняшней инженерии требований сегодня это мейнстрим, одна из лучших практик выявления требований как главной практики в инженерии требований.

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

Современное «теоретическое» объяснительное знание оживляет прикладную живую и практичную дисциплину, не даёт делать новичковые ошибки: рецепты берутся из трёхдневного курса, а объяснения – из трансдисциплинарного знания, которое было получено на других курсах, не слишком очевидно связанных с практикой. Как именно управлять буфером проекта в каком-то прикладном софте проектного управления, используемом в конкретном проекте, будет понятно из трёхдневного курса, а вот почему это всё вообще работает и какие могут быть проблемы «на стыках», будет понятно из теоретического курса планирования работ, где будет в том числе даваться и необходимая математика (статистические расчёты, а не просто «нажмите вот эту кнопку, получите результат». Будет рассказано, как именно считается результат! Работы то оканчиваются не точно в запланированные сроки, и нужно понимать статистические закономерности в потоке работ!).

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

Знание «опытного человека» обычно не осознанное: он инстинктивно направляет своё внимание к каким-то объектам в проекте, но не знает типов этих объектов, как они определяются в различных дисциплинах, не знает названий отношений этих объектов между собой. Его мысль скачет, ибо внимание управляется интуицией, при случайном шаге в сторону от удачной мысли назад вернуться уже нельзя, ибо нет какой-то осознанной линии рассуждений, нет «назад». И он легко может ошибиться в своей интуиции, ибо нельзя поправить то, чего не осознаёшь.

Неосознанное применение «опыта» нельзя исправить, обновить, рассказать окружающим, иметь в какой-то форме иной, кроме как рабочей безымянной и безмолвной интуиции, gut feeling. Интуиция иногда срабатывает, иногда нет – она не знает границы своего применения. Теория обычно срабатывает всегда, и можно проверить границы её применения. В этом сила теории. Трансдисциплина/учение выглядит как теория, она без прикладной дисциплины непрактична, но именно она уберегает от ошибок, она придаёт смысл прикладному знанию, помещает его в широкий контекст проектной работы.

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

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

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

ДОБАВЬТЕ К ТРЁХДНЕВНОМУ ПРАКТИЧЕСКОМУ КУРСУ

СЕМЕСТР ТЕОРИИ

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

И это тоже ещё не конец истории! Это просто конец прикладных дисциплин как детализации отдельных трудовых кругозорных трансдисциплин. Очень часто оказывается, что системные инженеры, которые прошли курс (даже вузовский!) системной инженерии или системные менеджеры, которые прошли аналогичный курс общего менеджмента просто не понимают, как устроен труд в целом с учётом разделения труда – как взаимодействуют инженеры, менеджеры, предприниматели во всём многообразии их подролей в крупном или даже мелком проекте. Исполнитель какой-то инженерной роли ещё может как-то понимать, как он взаимодействует с другими инженерами (его же учили системной инженерии!), но теряется, когда встречает несколько разного вида менеджеров и каких-то вариантов предпринимателей, не говоря уже о других проектных ролях. С менеджерами происходит то же самое.