Обсуждение блога:Максима Цепкова/2023-05-01: Четыре основные роли в компании - статья на vc.ru/c000223
В публикации на FB были комментарии от Анатолия Левенчука и Петра Щедровицкого. Переношу их сюда.
Анатолий Левенчук: Вот роли совсем по-другому определяются (и это переопределение произошло за последний пяток лет, раньше всё было бы примерно так, как написано). Подроли инженера разбираются подробней в курсе "Системная инженерия", подроли менеджера -- в курсе "Системный менеджмент". Например, визионер -- это шумпетеровский предприниматель, оценивает прибыльность изготовления и продажи продукта, а бизнесмен -- это шумпетеровский предприниматель, который оценивает прибыльность изготовления и продажи компании. Концепцию использования и концепцию системы делает разработчик, а для организации -- организатор, а вот архитектор -- способ нарезки на модули и коммуникации модулей, а орг-архитектор -- способ нарезки на оргзвенья и коммуникации оргзвеньев. А вот функциональность -- у разработчика и и организатора соответственно. За строительство завода по выпуску продукта отвечает инженер производственной платформы а за строительство "завода по выпуску организации" -- администратор. И там ещё, чтобы разобраться, надо смотреть на более мелкие роли, они у меня в слайде мелким шрифтом, и практики, которые они выполняют, тоже не все очевидны (например, практика оператора эксплуатации продукта соответствует практике операционного менеджера организации). Так что надо бы пройти курс и системной инженерии, и системного менеджмента, чтобы понять, что именно делают указанные роли инженеров и менеджеров. При этом я не сам эти роли, конечно, придумал -- они действительно "взяты из воздуха" (то есть вычитаны в самой разной инженерной и менеджерской литературе, главным образом они соответствуют тем ролям, которые приняты в современной софтверной разработке, которая сформировалась на основе идей platform engineering (это последний извод DevOps и SRE) и нового понимания архитектуры. Подроли менеджмента были взяты "по образу и подобию" (это же инженерия организации, то есть должна быть похожая структура деятельности, но "есть нюансы" -- они и были учтены).
Помним, что материалы наших курсов (включая два помянутых) доступны бесплатно (без возможности выполнения заданий, с заданиями -- по цене трёх чашек кофе в месяц) после регистрации тут: https://aisystant.system-school.ru/ (и помним, что курсы системной инженерии и менеджмента будут непонятны без прохождения курсов-пререквизитов, последовательно изучения вот тут: https://ailev.livejournal.com/1671965.html).
Адизеса и Щедровицкого тут не комментирую, пусть сами разбираются с изложением их идей )))
- Максим Цепков: В aisystant я зарегистрировался, учебники буду читать, мне интересно. Но быстрый поиск по курсу системной инженерии однозначных ответов не дает, там надо последовательно погружаться. А пока, с учетом того, что ты написал, картинка не складывается. Поэтому хочу задавать вопросы. Пока берем только инженерные роли. За основу берем V-model - вроде она вполне актуальна как схема верхнего уровня. И в каком-то виде ее можно применять не только для софта.
- Верно ли, что Implementation, то есть собственно разработка системы - за рамками ролей, как и последующие этапы? Или Разработчик ее частично/полностью делает?
- Верно ли, что Concept of Operations делает Визионер в части использования готового продукта и следующих из этого коммерческих выгод для его создателей, Разработчик - работает с другими аспектами концепции, например, с удобством использования, которое должно быть обеспечено, и так далее - Requirements в терминах V-модели?
- Верно ли Architecture в смысле декомпозиции и связей делает Архитектор, а предметную часть, а также Detailed Design - Разработчик? То есть в смысле V-модели получается такой сэндвич: Разработчик по ней работает выше архитектора и ниже него?
- Анатолий Левенчук: Maxim Tsepkov там начиная с "берём V-model -- вроде как она актуальна" не так. Уже неактуальна, идёт же "непрерывное всё", а V-модель это может быть схема для одной фичи, и то там ну ой сколько оговорок, и в большинстве вариантов там с требований начинается, а их нет, и т.д. В курсах (не учебниках, ибо мой опыт показывает, это только вчера на группе мои студенты обсуждали -- без выполнения заданий содержание текста курса не воспринимается, проскакивает мимо мозга) всё это объясняется. И уж точно там объём изменений такой, что в комментах в фейсбуке не раскрывается!
- Максим Цепков: Непрерывное все означает одновременную работу, но не исключает артефакты/фокусы внимания. Те же требования - смерть инженерии требований не означает смерти требований как таковых, потому что требования = описания системы как черного ящика = описание внешних функций системы, и это описание - есть. Другое дело, что оно не всегда может быть на входе, до архитектуры и дизайна, и не всегда живет долго, а возникает как промежуточный этап коммуникации при разработке конструкции. При этом может появляться после конструкции: мы придумали что можно сделать и проверяем. подходит ли это для решения нашего бизнес-кейса.
- Понятно, что обсуждение в деталях - точно за рамками комментариев. Но все-таки, ты прокомментировал, я хочу разобраться, потому что мне кажутся вещи не очевидными, и не слишком хочу ошибиться. Сформулировал три утверждения, опираясь на V-модель как известный формализм о том, что мне кажется не очевидным . Можешь ты к ним как-то отнестись коротко, от "совсем неверно" до "похоже, хотя есть нюансы"? Или все-таки конструкция в твоих курсах настолько отличается, что в терминах V-модели это обсуждать невозможно? И аналогичного графического образа нет, только тексты, которые к тому же следует изучать с учителем на курсах проходя задания?
- Анатолий Левенчук: Ну вот требования это не только функциональное описание, но и деонтика -- и поэтому их выкинули. Оставили только use cases, которые в разной форме делали до требований, но их делает разработчик, и он же делает концепцию системы (как функции будут поддержаны конструкцией), и он же проектирует и изготавливает. Визионер или соглашается, или не соглашается с тем, чтобы продолжать разработку (смотрит на клиентов и думает о том, заплатят или не заплатят достаточно), ничего не разрабатывает (но участвует в стратегировании). Архитектор работает с модульной структурой и связями модулей, сам беседует с клиентами по поводу ilities и ограничивает разработчиков. Инженеры производственной платформы проектируют и изготавливают платформу разработки, но сами не изготавливают ничего (строят завод, но работают на заводе разработчики). Похожее разделение и у менеджеров. И, конечно, много нюансов.
- Есть тексты, в текстах есть разные картинки, после просто прочтения материал не осваивает никто, после прочтения с выполнением заданий и без препода -- такие примеры есть, с преподом -- почти все. Пример картинки из текста. В режиме комментов всё одно ничего не поймёшь )))
- Вот пример картинки для организации. Обрати внимание, что разработчика платформы на этих картинках нет (в организации это администратор, кстати) -- он другим озабочен.
- Максим Цепков: Спасибо! Картинка существенно прояснила, дает ответ на мои вопросы. Хотя смотря на нее понимаешь, что в тексте первого комментария было написано тоже самое - но такая визуализация дает уверенность в понимании.
- Конечно, она вызывает следующие вопрос: какие основания полагать, что слева и справа одна и та же роль Developer, при том в середину ее работы вклинивается область ответственности Архитектора - почему именно она выделена отдельно. Но это уже будет вопрос не на понимание разделения ролей, а об основаниях такого разделения. При том, что в ИТ Developer слева называется аналитиком или бизнес-аналитиком, а Developer справа - именно разработчик, плюс системный аналитик, если эту роль выделяют.
- Но это, возможно, особенность ИТ, где ограничения возможности реализации не рассматриваются как существенные, а, например, при проектировании автомобилей, конструкцию надо класть сразу, и там объединение разработчиков слева и справа имеет смысл (хотя там про архитектора - непонятно, принципиальная компоновка автомобилей - устоявшаяся, она не проектируется). Или про производство медиа, например, мультфильмов - там другая ситуация, там есть гипотеза (например. образ персонажа) и ее оценка по критериям, вывести образ из требуемой оценки вообще нельзя. В общем, я тут для начала сам подумаю.
