С ролями разобраться важно: нужно всегда знать, с кем говоришь, чтобы его понимать и давать правильный ответ. Ответ Принцу Гамлету или Васе? Ответ Принцу Гамлету или тени отца Гамлета? Ответ архитектору проекта или Васе?
Вот реплика старшего программиста на совещании: «когда я вчера смотрел на график нашего проекта, то понял, что нам может не хватить времени на тестирование, поэтому неплохо бы озаботиться контрактацией дополнительных серверов для этой работы».
Какой выберете вариант продолжения беседы?
• Инженерный: какие ошибки требуют дополнительных серверов для их тестирования? Можем ли мы уменьшить объём тестирования?
• Менеджерский: у нас предусмотрено это бюджетом, или как всегда? У вас есть проект контракта? Кто найдёт поставщика?
Можно ли верить, что «старший программист» желает обсудить свои, инженерные аспекты дела, исполнитель этой роли и вправду выступил как инженер-программист? Или он выступил как операционный менеджер? Или его вопросы риторические, то есть он знает ответы, но строит какую-то интригу и занимает какую-то другую роль?
Вы бы сами какую линию разговора повели: чем бы озаботились, о чём спросили? Как кто бы вы поступили в этом разговоре, то есть какое бы своё мастерство вытащили в качестве основного? Где и как вы учились этому мастерству, или «самоучка, в разговорах нахватался»?
Вспомните, когда последний раз в разговоре вы проводили такой анализ «кто и о чём говорит – кто и о чём должен бы ему отвечать»? Не путали «действующее лицо» и «исполнителя» (Принца Гамлета и Васю Пупкина, инженера по требованиям и Дарью Михайловну)?
Отслеживаете ли вы смену предметов разговора, когда и роль тоже меняется, и используемая ролью дисциплина – вдруг начинают звучать совсем другие слова, другие термины? Как долго можете удерживать внимание на диалоге – в любой момент понимая «кто говорит – кто отвечает – предмет обсуждения»?
Приобрести ролевое мастерство сразу не получится. Этому нужно целенаправленно учиться. Хорошо бы ещё в школе, и уж точно в бакалавриате.
Кругозорные («как устроена жизнь») трансдисциплины
Инженерия, менеджмент, предпринимательство
и другие основные деятельности
А. Тюков выделял в 1997 году 16 сфер деятельности[62 - http://psyhoinfo.ru/programma-sozdaniya-obshchestvennoy-professionalnoy-sfery-prosveshcheniya (http://psyhoinfo.ru/programma-sozdaniya-obshchestvennoy-professionalnoy-sfery-prosveshcheniya)]: политика, религия, философия, искусство, наука, образование, здравоохранение, физкультура и спорт, технология, проектирование, коммерция, финансы, право, армия, материальное производство и «пока неоформившееся просвещение». В основу выделения этих сфер А. Тюков ставил некоторые укрупнённые деятельности как идущие в этих сферах основные процессы. Для здравоохранения/медицины это лечебная деятельность, для армии – защита границ и государственного устройства. Такое структурирование деятельности, основанное на сферах (часто ассоциируемыми с организационными структурами: бизнес-экосистемами, министерствами с подведомственными им предприятиями) широко обсуждался в кругах СМД-методологов, и мы возьмём его за основу, чтобы не сочинять что-то самим.
Этот список укрупнённых практик/деятельностей (будем считать «деятельность» и «практика» синонимами) сегодня можно задать, начиная со встречающихся в каждом проекте трёх: инженерии, менеджмента и предпринимательства в их системном (трансдисциплинарном[63 - https://en.wikipedia.org/wiki/Transdisciplinarity (https://en.wikipedia.org/wiki/Transdisciplinarity)], «по ту сторону от прикладных дисциплин», использующихся во множестве прикладных дисциплин, пересекающих границы своей дисциплины) варианте.
Посмотрите ещё раз на системную схему проекта из предыдущего раздела. Там три зоны ролевых/деятельностных интересов: предпринимательская, инженерная, менеджерская. А дальше могут быть и интересы других деятельностей, но эти три в том или ином виде встречаются практически в каждом проекте.
Зададим этот список деятельностей/практик, раскрыв каждую из них на один уровень:
• системная инженерия (разработка концепции использования, инженерия требований, инженерия системной архитектуры, управление конфигурацией и изменениями/жизненным циклом, проверка и приёмка)
• системный менеджмент (операционный менеджмент/цепи поставок/логистика, управленческий учёт и контроллинг, инженерия предприятия и архитектура предприятия/технологический менеджмент, организационные изменения/развитие и системное лидерство)
• системное предпринимательство (стратегирование, продвижение продукта, корпоративные финансы, корпоративная поднадзорность/governance)
• … остальные деятельности (политика и политэкономия, религия, искусство, наука/исследования, образование и просвещение, медицина, спорт, право, армия, частная жизнь/семья)
Но обратим внимание, что практики – это деятельность каких-то деятельностных ролей (в проекте – проектных ролей), и мы можем дать то же самое деление практик как деление ролей.
Системной инженерией занимается системный инженер. Но так же, как врач, это слишком общая роль (вы же не путаете дантиста и гинеколога?). Системный инженер в жизни существует как собирательное имя для множества его подролей. Системный инженер как роль исполняется одним человеком только в очень маленьких проектах, как «врач» по всем вопросам существует только в очень маленьких организациях (скажем, на подводной лодке, или в далёкой деревне). Про врача можно сказать, что он лечит людей, но разные врачи лечат разное. Системный инженер занимается системной инженерией, то есть создаёт успешные системы. Но разные системные инженеры принимают в этом разное участие. Скажем, инженерией требований занимается инженер по требованиям, инженерией системной архитектуры занимается инженер-архитектор, иногда его называют системным архитектором.
То же самое с менеджерами. Менеджеры как слишком общая роль следят за тем, чтобы организация работала: все люди знали, чем они занимаются, инженеры имели ресурсы для выпуска продукта или оказания сервиса, предприятие выполняло полученную ими от предпринимателя стратегию, запуская проекты развития и совершенствования. Это может быть один человек в маленькой организации, но как только людей становится больше, то сразу выделяются исполнители подролей, как и в случае инженеров. Например, операционный менеджер следит, чтобы через организацию шёл максимально быстрый и мощный поток продуктов, работ, информации – от их поставщиков к потребителям. Если где-то на пути этого протока есть затор, он принимает меры к его устранению, добавляет туда ресурс. Встречным потоком за выпущенную продукцию или оказанный сервис идут деньги, и максимизация потока к потребителю оказывается и максимизацией потока денег в обратном направлении. Это чисто логистическая задача, там есть своя математика, свои принципы работы. И эта работа операционного менеджера существенно отличается от работы архитектора предприятия, который разрабатывает принципы того, как должно работать предприятие, чтобы суметь выпустить продукт или оказать сервис. А ещё есть менеджер-организатор, который должен обеспечить организационные изменения: сделать так, чтобы люди начали работать по-новому, с учётом предлагаемой архитектуры предприятия. И ещё нужно, чтобы люди сотрудничали, поэтому менеджеры-организаторы занимаются также лидерством.
Знание этих общих дисциплин и их поддисциплин на уровне хотя бы знакомства с одним учебником крайне важно, чтобы понимать интересы и предпочтения людей в их рабочих ролях. Что именно вас спрашивает инженер по требованиям, как ему лучше отвечать? Чем интересуется предприниматель в его подроли стратега? У каких ваших ролей эти добрые люди в их своих таких разных ролях интересуются самыми разными вопросами?
Нужно проработать для понимания инженерии, менеджмента и предпринимательства где-то 15 книжек. Бакалавриат должен давать деятельностный кругозор! Лучше знать, какие роли играются в театре жизни, и не попадать впросак: если вас спрашивают как менеджера, а вы даёте ответ как предприниматель – то вы «не угадали», и наоборот тоже.
Пример деятельности операционного менеджмента
Эти же роли (практики этих ролей) нужно знать, чтобы дальше в них специализироваться. Вы стали операционным менеджером. Какой школы проектного управления, управления программами, процессного управления, управления кейсами вы придерживаетесь? Один учебник-то вы прочли, но если вы решили специализироваться, то вам в магистратуру, и нужно прочесть ещё десяток учебников по этой дисциплине, и дальше в вашем конкретном предприятии выбрать вариант практики, который удовлетворит вас как операционного менеджера и все остальные роли, с которыми вы там будете иметь дело.
Вот только небольшое число примеров вариантов деятельности/практики операционного менеджмента, дающих похожие, но всё-таки разные способы работы с потоком работ-комплектующих-информации через предприятие:
• Теория ограничений систем Элияху Голдратта, там течёт inventory, вытекает throughput
• Русская школа управления Алексея Андреева, там течёт сила по жиле[64 - https://www.litmir.me/br/?b=116477&p=83 (https://www.litmir.me/br/?b=116477&p=83) Итак, предприятие – это большая Жила, по которой течет сила, питающая нас, дающая жизнь всем, кто работает на этом предприятии, и тем, кто вокруг. Мы, в силу слабости видения, воспринимаем лишь внешнее, «съедобное» проявление этой силы жизни – деньги. Неважно. Пусть так. Если тебе сложно все время прозревать сквозь пену, просто прими это и помни о том, что деньги мчатся по этой жиле твоего предприятия, как пена на потоке силы. И поскольку пена от потока неотделима, следи за движением силы по движению денег. Что для этого надо? Надо увидеть свое предприятие как цепочку последовательных шагов, которые необходимо сделать, чтобы сила-деньги пришла к людям. А себя – как чистильщика потока, который держит источники силы, проливающейся в наш мир, открытыми. Тогда сведения с мест, которые соответствуют шагам достижения силы, будут сведениями о заторах в жиле, сведениями о том, где образовался разрыв тока силы.]
• Цепочки приращения стоимости, там течёт и наращивается польза
• Сетевая организация (не структура!), там текут товары (сеть универмагов), знания (сеть аналитических центров).
• Цепи поставок, там текут запасы по складам и местам переработки
• Кооперативные процессы СМД-методологии, там текут продукты деятельностных актов
•…
Когда вы придёте в ту или иную организацию, в тот или иной проект в рамках организации, вы обязательно там встретите человека, который будет играть роль операционного менеджера. Он будет говорить абсолютно разные слова в зависимости от того, чему его учили в той или иной школе менеджмента. Но после хорошего курса менеджерского кругозора под этими словами вами должно сразу распознаваться: «он говорит о потоке, он хочет ускорить его прохождение! Это операционный менеджер!» – и дальше с ним действовать, исходя из этого понимания. И так с каждой практикой, каждой ролью. Проработайте хотя бы 15 книжек. Поймите интересы и предпочтения ролей в каждой из описанных там деятельностей. Поймите ключевые понятия каждой из деятельностей. Сделайте это в разбиении хотя бы на один уровень вниз.
Этот раскрытый на один уровень список инженерных, менеджерских, предпринимательских ролей, конечно, не исчерпывающий. Так, если вы попали в какую-то деятельность из четвёртой позиции этого списка (где медицина и правоохрана), нужно тоже понимать, на какие практики они разделяются и какие роли будут выполнять эти практики. Это в списке не показано, но юриста (использует законодательство) и правоведа (пишет законопроекты) вам хорошо бы различать, это входит в деятельностный кругозор.
В практиках могут быть и несколько ролей: практика обмена включает роли продавца и покупателя, медицинская практика роли врача и пациента.
Пример деятельности образования
Для показа этой тесной связи ролей и деятельностей/практик сделаем список некоторых (не всех! Например, не покажем роль студента) подролей в образовании и поясним, что делает каждая роль, какую практику/деятельность она исполняет:
• методолог разрабатывает содержание образования, то есть разрабатывает учебные стандарты, опираясь на SoTA (state-of-the-art – лучшее, что известно на сегодняшний момент) в какой-то рабочей практике, которая станет после появления этого стандарта учебной дисциплиной.
• разработчик курса/instructional designer разрабатывает содержание курса (учебник, упражнения, методические рекомендации преподавателю). Это содержание курса соответствует учебному стандарту. Разработчик курса умеет хорошо объяснять и понимает, как тренировать учеников. Это совсем другое умение, нежели умение методолога вытащить и документировать SoTA какой-то практики (практики системного мышления, или практики обучения нейронных сетей, или практики социальных танцев, или практики наладки автоматизированной линии выпуска полупроводниковых чипов).
• преподаватель имеет две подроли:
а) лидер, чья задача обеспечить мотивацию учеников выполнять задания. Труд ученика – рабский, он не получает за свой труд вознаграждения. Труд ученика нельзя автоматизировать, хотя даже труд преподавателя автоматизировать можно. Полпланеты изучает «геймификацию» как раз один из вариантов безлюдной технологии лидерства, это прямая автоматизация одной из подролей преподавателя. У хорошего преподавателя-лидера ученики радостно выполняют рутинные и скучные упражнения, и им не скучно.
б) консультант, чья задача провести ученика через множество проектных ситуаций, чтобы связать знания из учебника-задачника с ситуациями в жизни, то есть перевести теоретические знания и отрывочные умения ученика в его мастерство в изучаемой деятельности. У хорошего консультанта ученики не столько хорошо сдают экзамены, сколько потом могут выполнять изученную практику в живых проектах, творчески её адаптируя к проектной ситуации – в том числе решая задачи, о которых не знал сам консультант в момент обучения.
• тьютор/коуч занимается общим образовательным маршрутом ученика, помогает ему выйти на бесконечное развитие. Для него все учебные курсы и проекты – кирпичики на длинном жизненном пути его подопечного.
• организатор образования тоже имеет много подролей (и обычно эти подроли исполняет много людей-исполнителей):
а) стратег определяет, чему и кого учим
б) операционный менеджер учебного процесса составляет расписание занятий, следит за тем, чтобы всё было быстро-вовремя и обеспечивалось ресурсами, не вылезая за рамки бюджета.
в) архитектор обучающей организации со всеми вышеупомянутыми ролями. Он говорит, что нужно делать для отличных результатов образования: прежде всего как все практики и требуемые этими практиками роли поручить какой-то организационной структуре.
г) Организатор занимается управлением оргизменениями и лидерством. Ему нужно организовать учебный процесс, объяснив каждому человеку его роль, катализировать сотрудничество между всеми сотрудниками учебной организации.
Если у вас учебная организация из одного человека, то вам придётся играть все эти роли. Если у вас большой университет, то там множество исполнителей каждой из ролей. Если вы пошли в какой-то образовательный проект, то лучше бы вам иметь тут какой-то кругозор и прочесть хотя бы один учебник по практике каждой роли.
Мастерство выбора деятельностной роли
Точно так же «врач» делится на множество ролей в медицине (не путаем дантиста и гинеколога), и во всех остальных деятельностях дела обстоят так же. Иногда это дробление деятельностей/практик и ролей с возможностью отдельных людей и организаций играть всё более и более мелкие и специализированные их части называют разделением труда, а вот этот тренд непрерывного деления ролей на всё более мелкие подроли – углублением разделения труда. Был «врач» – выделилась специализация «врач-хирург» – выделилась подспециализация «кардиохирург». Роль вебмастера выделилась из роли «айтишника» буквально на несколько лет в конце девяностых годов прошлого века, а затем в первое же десятилетие двадцать первого века раздробилась на более мелкие подроли именно в порядке углубления разделения труда: дизайнер веб-страницы (потом – UX специалист), верстальщик, программист фронт-энда, программист бэк-энда, редактор, контент-менеджер, SEO, и это ещё не полный список.
Мастер волен выбирать пути в жизни, но он должен хотя бы понимать на самом общем уровне само наличие этих быстро меняющихся путей – и не на уровне интуитивных представлений, а на осознанном уровне. Мы ведь только что обсудили самое общее устройство карты этих путей, карты человеческой деятельности.
Ролевое мастерство тем самым оказывается практикой навигации среди множества деятельностных ролей (распознавание роли и понимание того, о чём с этими ролями можно говорить, исходя из своей собственной роли). И ещё ролевое мастерство даёт возможность качественно удерживать внимание на выполнении своей роли.
Мастерство, которое должно быть у бакалавра – это мастерство выбора новой деятельностной роли, мастерство обучения практике этой роли, мастерство удержания этой роли в проекте, мастерство оставления этой роли в тот момент, когда она устарела (не нужно держаться за роль извозчика в тот момент, когда вокруг лошади остались только в спорте и очень изредка в парках развлечений). Надо проработать (не просто прочесть: бесполезно ведь читать учебники «как ездить на велосипеде») два десятка учебников, потратить на достижение этого мастерства год.
Магистерское мастерство – это прежде всего прикладное мастерство в конкретной проектной роли, а то и мелкой подроли этой роли. Скажем, не просто системный инженер, а инженер по требованиям, или даже инженер по требованиям в авиастроении. На освоение прикладной практики нужно тоже потратить год-два, тоже проработать пару десятков учебников, да ещё и попрактиковаться в живых проектах.
Ролевое мастерство, которое должно быть у каждого человека, устроено явно избыточно с прикладной точки зрения: оно никак не отвечает требованию чисто прикладного образования: когда «что потребуется, то и выучим – тогда, когда потребуется». Это ведь явно «образование впрок»: зачем знать, что существует здравоохранение и чем оно там занимается, если все жизненные планы, например, пока в инженерии? Затем, чтобы вообще ориентироваться в жизни: строить планы в инженерии, зная о существовании здравоохранения. Можно озаботиться тем, чтобы сделать это знание деятельностного кругозора максимально компактным и согласованным между собой, для этого по максимуму задействовав понятия более фундаментальных трансдисциплин – системный подход, научное мышление и т. д. Так что перед годом обучения деятельностному кругозору нужно будет потратить ещё год на фундаментальные трансдисциплины.
Все эти деления деятельностей, конечно, очень и очень условны и существенным образом могут различаться в зависимости от того, для чего эти деления используются. Мы тут приводим деление, удобное для целей системного развития личности, обучения ролевому мастерству в части деятельностного кругозора.
Почему не работают трёхдневные курсы ни для менеджеров, ни для инженеров
Трёхдневные курсы, где никакой теории, только практика
Практически все сегодняшние анонсы прикладных тренингов содержат фразу о том, что содержание исключительно практично – никакой теории, чистые приёмы работы, «сразу бери – и в дело». И это чистая правда. Эти тренинги так и устроены: сугубо прикладные объяснения, рассказывающие какие таблички в каких формочках заполнять, какие кнопки в каких софтах нажимать.
Скажем, берём практику Jobs-To-Be-Done (JTBD)[65 - https://medium.com/no-flame-no-game/что-такое-jobs-to-be-done-и-job-stories-4c57c1dc84cf (https://medium.com/no-flame-no-game/%D1%87%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-jobs-to-be-done-%D0%B8-job-stories-4c57c1dc84cf)] из инженерии требований или практику управления буферами проекта в голдраттовском варианте управления проектами. Вас научат последовательности шагов, покажут какие таблички заполнять, какой софт использовать.
Но когда вы попробуете всё это применить в работе, то ничего не получится: всё будет почему-то совершенно не так, как описывалось на курсах. И дело не в том, что вы что-то забыли или пока медленны во всех показанных вам действиях. И ведь так было после каждых трёхдневных курсов, нет?
Неважно, инженерные практики изучаются, менеджерские, предпринимательские, образовательные или ещё какие-то: «три дня чистой практики – и в продакшн» оказывается недостаточно для реального дела, результаты трёхдневных «чисто практических» обучений разочаровывают, и разочаровывают сильно. Прикладные трёхдневные тренинги безуспешны.
Успех мы определяем тут как в системной инженерии: как учёт интересов внешних проектных ролей проекта. Эти самые внешние проектные роли почему-то оказываются крайне недовольными, в деятельности «по методе из тренинга» вдруг обнаруживаются мириады ошибок, если не в самой этой деятельности, так на всех стыках с остальными работами проекта.
Всё, что можно в трёхдневном курсе неправильно понять или пропустить мимо ушей, будет понято неправильно или пропущено мимо ушей. Но не это «неправильное понимание» и «невнимательность учеников» основная причина неуспеха.
Прикладных знаний в любом деле участвует больше,
чем можно получить за три дня
Значительное число нелепостей в работе возникает не от владения натренированной всего за три дня прикладной практики, а от непонимания деятельностной трансдисциплины, общей для многих и многих практик. Скажем, в инженерии требований нет понимания того, что и почему важно в этих требованиях: требования прилетают с самых разных направлений, общаться нужно по поводу требований с самыми разными людьми, и такая прикладная дисциплина как (JTBD) решает отнюдь не все проблемы с требованиями – там не решаются, например, проблемы управления требованиями, задействования требований из стандартов и множество подобных вопросов. На прикладном тренинге, оказывается, говорят правду, но не всю правду. В случае JTBD не рассказали в целом про дисциплину «инженерия требований»[66 - про проблемы инженерии требований как дисциплины см. в https://ailev.livejournal.com/1425741.html (https://ailev.livejournal.com/1425741.html).].
Прикладные практики обычно просты и незатейливы, они конкретны и вроде как легко понимаются, а вот трансдисциплины для своего понимания требуют существенного задействования мозгов, они более абстрактны, более трудны в понимании. Это всегда так для трансдисциплин. Предобучение всегда неочевидно и дорого по времени и ресурсам. Трёх дней курсов для овладения инженерией требований с профессиональным качеством работы уже не хватит, тут может потребоваться семестр плотной работы в инженерном вузе. Инженеров ведь так и учат их трансдисциплинам – семестрами. И потом они способны за три дня разобраться с прикладной практикой. Откуда берётся уверенность, что трёхдневный курс даст незнакомому с трансдисциплиной человеку нужные умения на уровне вузовского семестра? А если человек знаком с инженерией требований? Сначала нужно понять, когда он ей учился: если это тридцатилетней давности инженерия требований, то нужно перепрошить мозг трансдисциплиной 2020 года, а потом уже знакомиться с JTBD. Ибо с точки зрения старой трансдисциплины JTBD едва ли вообще имеет смысл. А в сегодняшней инженерии требований сегодня это мейнстрим, одна из лучших практик выявления требований как главной практики в инженерии требований.
То же самое обнаруживается с управлением буферами проектов: пока не понял про управление работами в целом (где рассматривается не только тридцатилетней давности голдраттовский вариант управления проектами, но и какой-нибудь кейс менеджмент) работа с управлением буферами проекта будет по принципу «пошли дурака богу молиться, он и лоб расшибёт». В результате на хорошей прикладной практике будет поставлен крест (виновата же она, а не недообразованность её применяющего!). Вывод после неудачи с управлением по буферам проекта будет – «давайте попробуем что-нибудь ещё». Вузовского семестра-то по state-of-the-art (сегодняшней, а не, например, конца 20 века!) трансдисциплине управления работами/операционного менеджмента почти ни у кого в мозгах нет, нет даже у «проходивших мимо» этот предмет в вузах. Но именно это «теоретическое» знание оживляет прикладную живую и практичную дисциплину, не даёт делать новичковых ошибок.
