2023-05-01: Четыре основные роли в компании - статья на vc.ru

Материал из MaksWiki
Перейти к: навигация, поиск
Короткая ссылка: 4orgroles

Анатолий Левенчук на конференции ШСМ говорил о четырех ролях созидателей-инженеров и четырех ролях менеджеров. Если на них посмотреть, то можно увидеть соответствие с ролями в развитии системы разделения труда, которые выделяет Петр Щедровицкий, стилями руководства Адизеса и структурой организации по Минцбергу. Сопоставление представляется интересным, и я написал о нем статью https://vc.ru/hr/681839-chetyre-osnovnye-roli-v-kompanii Думаю, такое сравнение взглядов разных теорий будет полезным. 

Пост на FB

[ Хронологический вид ]Комментарии

В публикации на FB были комментарии от Анатолия Левенчука и Петра Щедровицкого. Переношу их сюда.

Анатолий Левенчук: Вот роли совсем по-другому определяются (и это переопределение произошло за последний пяток лет, раньше всё было бы примерно так, как написано). Подроли инженера разбираются подробней в курсе "Системная инженерия", подроли менеджера -- в курсе "Системный менеджмент". Например, визионер -- это шумпетеровский предприниматель, оценивает прибыльность изготовления и продажи продукта, а бизнесмен -- это шумпетеровский предприниматель, который оценивает прибыльность изготовления и продажи компании. Концепцию использования и концепцию системы делает разработчик, а для организации -- организатор, а вот архитектор -- способ нарезки на модули и коммуникации модулей, а орг-архитектор -- способ нарезки на оргзвенья и коммуникации оргзвеньев. А вот функциональность -- у разработчика и и организатора соответственно. За строительство завода по выпуску продукта отвечает инженер производственной платформы а за строительство "завода по выпуску организации" -- администратор. И там ещё, чтобы разобраться, надо смотреть на более мелкие роли, они у меня в слайде мелким шрифтом, и практики, которые они выполняют, тоже не все очевидны (например, практика оператора эксплуатации продукта соответствует практике операционного менеджера организации). Так что надо бы пройти курс и системной инженерии, и системного менеджмента, чтобы понять, что именно делают указанные роли инженеров и менеджеров. При этом я не сам эти роли, конечно, придумал -- они действительно "взяты из воздуха" (то есть вычитаны в самой разной инженерной и менеджерской литературе, главным образом они соответствуют тем ролям, которые приняты в современной софтверной разработке, которая сформировалась на основе идей platform engineering (это последний извод DevOps и SRE) и нового понимания архитектуры. Подроли менеджмента были взяты "по образу и подобию" (это же инженерия организации, то есть должна быть похожая структура деятельности, но "есть нюансы" -- они и были учтены).

Помним, что материалы наших курсов (включая два помянутых) доступны бесплатно (без возможности выполнения заданий, с заданиями -- по цене трёх чашек кофе в месяц) после регистрации тут: https://aisystant.system-school.ru/ (и помним, что курсы системной инженерии и менеджмента будут непонятны без прохождения курсов-пререквизитов, последовательно изучения вот тут: https://ailev.livejournal.com/1671965.html).

Адизеса и Щедровицкого тут не комментирую, пусть сами разбираются с изложением их идей )))

Максим Цепков: В aisystant я зарегистрировался, учебники буду читать, мне интересно. Но быстрый поиск по курсу системной инженерии однозначных ответов не дает, там надо последовательно погружаться. А пока, с учетом того, что ты написал, картинка не складывается. Поэтому хочу задавать вопросы. Пока берем только инженерные роли. За основу берем V-model - вроде она вполне актуальна как схема верхнего уровня. И в каком-то виде ее можно применять не только для софта.
  1. Верно ли, что Implementation, то есть собственно разработка системы - за рамками ролей, как и последующие этапы? Или Разработчик ее частично/полностью делает?
  2. Верно ли, что Concept of Operations делает Визионер в части использования готового продукта и следующих из этого коммерческих выгод для его создателей, Разработчик - работает с другими аспектами концепции, например, с удобством использования, которое должно быть обеспечено, и так далее - Requirements в терминах V-модели?
  3. Верно ли Architecture в смысле декомпозиции и связей делает Архитектор, а предметную часть, а также Detailed Design - Разработчик? То есть в смысле V-модели получается такой сэндвич: Разработчик по ней работает выше архитектора и ниже него?
Анатолий Левенчук: Maxim Tsepkov там начиная с "берём V-model -- вроде как она актуальна" не так. Уже неактуальна, идёт же "непрерывное всё", а V-модель это может быть схема для одной фичи, и то там ну ой сколько оговорок, и в большинстве вариантов там с требований начинается, а их нет, и т.д. В курсах (не учебниках, ибо мой опыт показывает, это только вчера на группе мои студенты обсуждали -- без выполнения заданий содержание текста курса не воспринимается, проскакивает мимо мозга) всё это объясняется. И уж точно там объём изменений такой, что в комментах в фейсбуке не раскрывается!
Максим Цепков: Непрерывное все означает одновременную работу, но не исключает артефакты/фокусы внимания. Те же требования - смерть инженерии требований не означает смерти требований как таковых, потому что требования = описания системы как черного ящика = описание внешних функций системы, и это описание - есть. Другое дело, что оно не всегда может быть на входе, до архитектуры и дизайна, и не всегда живет долго, а возникает как промежуточный этап коммуникации при разработке конструкции. При этом может появляться после конструкции: мы придумали что можно сделать и проверяем. подходит ли это для решения нашего бизнес-кейса.
Понятно, что обсуждение в деталях - точно за рамками комментариев. Но все-таки, ты прокомментировал, я хочу разобраться, потому что мне кажутся вещи не очевидными, и не слишком хочу ошибиться. Сформулировал три утверждения, опираясь на V-модель как известный формализм о том, что мне кажется не очевидным . Можешь ты к ним как-то отнестись коротко, от "совсем неверно" до "похоже, хотя есть нюансы"? Или все-таки конструкция в твоих курсах настолько отличается, что в терминах V-модели это обсуждать невозможно? И аналогичного графического образа нет, только тексты, которые к тому же следует изучать с учителем на курсах проходя задания?
Левенчук позиции - из комментария на FB к статье.jpg
Анатолий Левенчук: Ну вот требования это не только функциональное описание, но и деонтика -- и поэтому их выкинули. Оставили только use cases, которые в разной форме делали до требований, но их делает разработчик, и он же делает концепцию системы (как функции будут поддержаны конструкцией), и он же проектирует и изготавливает. Визионер или соглашается, или не соглашается с тем, чтобы продолжать разработку (смотрит на клиентов и думает о том, заплатят или не заплатят достаточно), ничего не разрабатывает (но участвует в стратегировании). Архитектор работает с модульной структурой и связями модулей, сам беседует с клиентами по поводу ilities и ограничивает разработчиков. Инженеры производственной платформы проектируют и изготавливают платформу разработки, но сами не изготавливают ничего (строят завод, но работают на заводе разработчики). Похожее разделение и у менеджеров. И, конечно, много нюансов.
Есть тексты, в текстах есть разные картинки, после просто прочтения материал не осваивает никто, после прочтения с выполнением заданий и без препода -- такие примеры есть, с преподом -- почти все. Пример картинки из текста. В режиме комментов всё одно ничего не поймёшь )))
Вот пример картинки для организации. Обрати внимание, что разработчика платформы на этих картинках нет (в организации это администратор, кстати) -- он другим озабочен.
Максим Цепков: Спасибо! Картинка существенно прояснила, дает ответ на мои вопросы. Хотя смотря на нее понимаешь, что в тексте первого комментария было написано тоже самое - но такая визуализация дает уверенность в понимании.
Конечно, она вызывает следующие вопрос: какие основания полагать, что слева и справа одна и та же роль Developer, при том в середину ее работы вклинивается область ответственности Архитектора - почему именно она выделена отдельно. Но это уже будет вопрос не на понимание разделения ролей, а об основаниях такого разделения. При том, что в ИТ Developer слева называется аналитиком или бизнес-аналитиком, а Developer справа - именно разработчик, плюс системный аналитик, если эту роль выделяют.
Но это, возможно, особенность ИТ, где ограничения возможности реализации не рассматриваются как существенные, а, например, при проектировании автомобилей, конструкцию надо класть сразу, и там объединение разработчиков слева и справа имеет смысл (хотя там про архитектора - непонятно, принципиальная компоновка автомобилей - устоявшаяся, она не проектируется). Или про производство медиа, например, мультфильмов - там другая ситуация, там есть гипотеза (например. образ персонажа) и ее оценка по критериям, вывести образ из требуемой оценки вообще нельзя. В общем, я тут для начала сам подумаю.


— Максим Цепков • 5 мая 2023 в 12:16 последняя правка 9 мая 2023 в 13:02

Петр Щедровицкий Для организации понимания важна установка. В текстах и действиях акторов можно искать совпадения, а можно фокусироваться на различиях. Я хочу выделить три группы таких различий.

  • Во-первых, в СРТ я выделяю «позиции», а не «роли». Позиционный анализ позволяет ввести специфические «цели» и «средства». В том числе выделить конституирующие данную позицию типы знаний и способы их употребления. В пределе «позиция» задается культурной нормировкой: ценностями, подходами и онтологией. «Роли» [в отличие от позиций] задаются социальными, а не культурными нормами.
    Анатолий Левенчук Петр Щедровицкий а у меня "роли" -- культурно-обусловленные, прямо написано (задаются мемомом, воспроизводящем практику/деятельность/метод). Но они и не совсем "позиции", конечно. То есть на уровне "просто слов" -- не бьётся.
  • Щедровицкий- позиции. Из комментария на FB к статье про 4 позиции.jpg
    Во-вторых, на мой взгляд архитектура современной СРТ определяется позицией «технологического предпринимателя». Все остальные уровни СРТ можно «вывернуть» через эту позицию. «Инженерная» позиция появляется в рамках СРТ, создаваемой технологическим предпринимателем. Возможно, это изображение текст «вокруг этой "связки>> складывается ряд поддерживающих и обеспечивающих ее инфраструктур институциональных решений деньги институты, обеспечивающие производство, накопление, обращение, освоение новых знаний институты, обеспечивающие, возникновение поддержание "спонтанного порядка>> инженер предприниматель технологии мышления социально- профессиональная организация структура общества экономическое разделение труда между фирмами города и системы расселения <железные>> технологии пространственная организация территории: размещение промышленности и инфраструктур»
  • Щедровицкий- позиции-2. Из комментария на FB к статье про 4 позиции.jpg
    В-третьих, по мере развертывания больших волн развития=промышленных революций позиция «инженера» усложняется и дифференцируется. В ходе первой промышленной революции, наряду с «проектировщиком» в инженерном модуле СРТ появляется позиция «организатора=менеджера». В своих лекциях я подробно разбираю какова базовая функция этого типа деятельности и как, по мере общего усложнения СРТ, происходила дифференциация данной позиции. Возможно, это изображение 1 человек и текст «<о-я> пр 1550-1700 |пр 1700-1850 предприниматель Il пр 1850-20 III пр 2000+ инвестор менеджер технология мышления исследование проектирование исследователь проектировщик инженер»
  • В-четвертых, в своих лекциях последних лет я подробно разбираю устройство «инженерного» модуля СРТ. Однако, нужно понимать, что СРТ, сфокусированная вокруг технологического предпринимателя, не сводится к нему. В последний год я начал более подробно разбирать «денежный» модуль СРТ. На схеме можно увидеть одну из позиций, конституирующих этот модуль: позицию «инвестора».
Максим Цепков Петр Щедровицкий большое спасибо за комментарии! Что в центре развития СРТ - Предприниматель или Инженер, с моей точки зрения - открытый вопрос. Точно они оба нужны, а схему можно рисовать по-разному. И понятно, что картина усложняется, выделяется позиция организатора=менеджера, которая для предпринимателя - часть исполнительной машины, то есть в инженерном блоке, а для инженера - наоборот, часть предпринимательской машины, обеспечивающей его труд. Но важно, что отдельные позиции - есть, они различаются.
По поводу Предпринимателя и Инвестора мне тут пришла мысль, что это - отражение перехода от Товар-Деньги-Товар к Деньги-Товар-Деньги, от промышленного к финансовому капитализму. Но произошел ли этот переход, или можно говорить о симбиозе, существовании обоих форм, которые двигают СРТ, требует обдумывания. Еще раз спасибо за комментарии!
Петр Щедровицкий: Максим Цепков Ваше право не прислушиваться к моим аргументам:)) но за социальные последствия отвечать Вам
— Максим Цепков • 9 мая 2023 в 13:01

Антон Кобельков в комментарии на vc.ru написал: мне видится, что Предприниматель и Интегратор соответствуют Визионеру и Архитектору, а Производитель и Администратор - Бизнесмену и Орг-архитектору. Думаю, так даже точнее: у Адизеса только стили руководства, а не вся деятельность.

— Максим Цепков • 9 мая 2023 в 13:03

Войдите, чтобы комментировать.

— Максим Цепков • 12:08, 1 мая 2023 • 3 комментария
Источник — «https://mtsepkov.org/index.php?title=Блог:Максима_Цепкова/2023-05-01:_Четыре_основные_роли_в_компании_-_статья_на_vc.ru&oldid=7401»