July 9th, 2021

2021 год

Видео вебинара "Что делать программисту, которого жизнь заставляет заниматься менеджментом?"

Вчера провёл полуторачасовой вебинар "Что делать программисту, которого жизнь заставляет заниматься менеджментом?", видео https://youtu.be/_jcvAGqBWzs, слайды https://yadi.sk/i/ucXimmQeK1AImg.

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

Вот что я рассказывал полтора часа:

1. Жизненный путь слишком умного программиста: его проекты становятся всё больше, вовлекают всё больше людей, и он обнаруживает, что должен ставить задачи и проверять их выполнение, но пока это 5-7 человек, всё это ОК. Проблемы начинаются тогда, когда проекты становятся ещё больше и нужно координировать несколько разных групп разработчиков. Наш программист ощущает беспокойство уже не только от багов в коде, но и от людей. Догадка: есть методы работы с людьми, такие же, как методы работы с кодом! Далее идёт менеджерское самообразование программиста [предмет обсуждения на вебинаре], и он становится по факту менеджером проекта, затем директором по развитию сначала всего IT фирмы, а затем и директором по развитию всей фирмы.

2. Программисты бывают разные, и опыт у них самый разный -- разнообразие айтишников уже почти такое же, как разнообразие непрограммистских профессий, опыт у всех самый разный: кровавый энтерпрайз с разнообразием ролей (по факту веб-разработка, разные конвейеры данных, и даже эникейщик), встроенные системы («прошивки»), игры, смартфонные приложения, операционные системы, драйвера, вычисления (статистика, AI), бывает и не совсем программист (инженер по требованиям, архитектор, инженер по тестированию, DevOp, моделирование данных), … [тысячи их]

3. Развитие для программиста идёт в среднем по двум линиям:
-- рост как программиста или "скучно, поменяю-ка я программистскую специальность" (переход на новый язык типа Haskell, Julia, Rust только поначалу кажется "развитием", системная инженерия и программная архитектура уже больше похожи на профессиональный рост, но есть сегодня уже частый ход на шаг назад в математику -- и затем шаг вперёд-вбок в машинное обучение и искусственный интеллект)
-- смена специализации на менеджмент, рано или поздно.

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

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

4. Системная схема предприятия, прямо по учебнику системного мышления: альфы стратегии, собственника, возможности, внешних проектных ролей, альфы особого внимания программиста -- описание системы (код) и воплощение системы (программа на рабочих серверах), альфы особого внимания менеджера -- работы, команда, метод. Частая смена карьеры с программистской на менеджерскую связана со сменой объектов внимания в проекте.



6. Программисты всё-таки во многом одинаковые: поэты!
Особенность работы описана в 1975 году Ф.Бруксом младшим: «Программист, подобно поэту, работает почти непосредственно с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения. Трудно найти другой материал, используемый в творчестве, который столь же гибок, прост для шлифовки или переработки и доступен для воплощения грандиозных замыслов».

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

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

7. Диаграмма сути системного мышления.
На диаграмме изображены два времени: время эксплуатации/run-time целевой системы с подсистемами в составе надсистемы (её окружения). Но главное -- это не менее сложно организованное обеспечение жизненного цикла целевой системы, так называемые цепочки обеспечения, работающие во время разработки, design-time. Сначала программист работает, обращая внимание только на свою программу, но по мере роста сложности проекта он обращает внимание и на людей, которые заняты системой. И эти люди тоже могут быть представлены как системы. Только в run-time мы рассматриваем отношения "часть-целое" между системами, а в design-time основное отношение "система X делает что-то с системой Y". Менеджмент -- это когда основное внимание уходит на происходящее в design-time.



8. Системное мышление подразумевает разные способы деления на части: по функциональности в момент работы системы, по конструкции в момент сборки системы из частей, по размещению частей где-то в пространстве, по потребности в разных ресурсах. Программисты особо плохи в разбиении системы по функциональности, они плохо видят предметную область клиента, предпочитают свои собственные понятия (не "расчёт зарплаты", а просто "расчёт", ибо всегда ж можно поставить "любую" формулу!). И тут могут быть серьёзные ошибки. Пример ножниц: они состоят функционально из режущего блока и ручки, а конструктивно -- две половинки и винтик. Заказать на заводе изготовление режущего блока отдельно и ручек отдельно нельзя, заказывать нужно две половинки. А работать ножницами нельзя двумя половинками, нужно работать ручкой и ножевым блоком. Если не понимать разницы функционального и конструктивного разбиений, можно наделать ошибок в ходе как эксплуатации, так и изготовления системы.

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

И в основе менеджмента, и в основе инженерии лежит системное мышление, а у программистов с ним плохо: они с ним по факту не знакомы (только слышали о нём).

9. Для быстрого освоения менеджмента нужно усилить интеллект. Интеллект понимаем как умение быстро разобраться в новой предметной области. Менеджмент -- это новая предметная область, требующая внимания к совсем другим объектам. Предлагается такой же ход, как "возврат в бакалавриат для освежения знаний по математике, чтобы потом пойти в машинное обучение и искусственный интеллект", только возвращаться нужно для выучивания системного мышления, онтологики и других подобных предметов, поднимающих интеллект в целом (как нужный для программирования, так и для менеджмента, впрочем и для всего остального).

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

По факту образование -- это способ настроить внимание, чтобы в каждой предметной области выделять важное, а на неважное не обращать внимание. Это верно и для инженерии, и для менеджмента.

11. В книге/курсе "Образование для образованных 2020" (курс https://system-school.ru/uptodate, книга https://ridero.ru/books/obrazovanie_dlya_obrazovannykh/, чат поддержки https://t.me/odo_course) рассказывается про интеллект-стек разных дисциплин, поддерживающих мышление одного человека, а затем и коллективное мышление. Вот современный интеллект-стек (звёздочка у тех дисциплин, по которым есть курсы Школы):
-- глобальная производственная культура
-- культура эко-системы
-- культура предприятия
-- культура командной работы
-- прикладное мастерство в проекте
-- кругозоры: предпринимательский, менеджерский (*), инженерный (и в том числе информатики)
-- системное мышление (*)
-- коммуникации (объяснение и убеждение) (*)
-- праксеология и экономика
-- онтология (*), эпистемология/научное мышление (*), логика и вычисления
-- собранность ума и тела (*)

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

12. Пример из системного мышления: чеклист (список вопросов, направленных на контроль того, что в суете проекта вы не забыли подумать о самом важном) системного мышления, в котором внимание довольно быстро переходит от целевой (например, программной) разрабатываемой системы к людям, которые разрабатывают эту систему -- и это уже должно быть предметом менеджмента:
-- Определён системный уровень, на котором ведётся разговор и уровень ближайшего системного окружения
-- Определено, что меняем в физическом мире (воплощение целевой системы).
-- Формулируем требования и потребности в формате, допускающем проверку и приёмку
-- Определяем цепочку обеспечения
-- Определяем наши роли, командные роли и внешние проектные роли
-- Определяем нашу систему по отношению к целевой.
-- Имеем архитектурные идеи для реализации возможности (нет идей – full stop)
-- Делаем минимально три описания того, что хотим изменить, используем явные методы описания.
-- Имеем ресурсы для выполнения, включая команду с ролями инженера, предпринимателя, менеджера
-- Проверяем, что все проектные роли в согласии по поводу того, что делаем
-- …

13. Для каждой крупной практики есть роль, которая занимается этой практикой. Если практики рассматриваем на основе системного мышления, то называем эту практику системной. Вот основные роли предприятия (театральная метафора, говорим о ролях/действующих лицах и исполнителях) и их практики в разбивке на один уровень вниз:
-- Инженер: системная инженерия (разработка концепции использования, инженерия требований, инженерия системной архитектуры, управление конфигурацией и изменениями/жизненным циклом, проверка и приёмка). Подроль: айтишник: системная информатика (информация и суперинформация, архитектура вычислителей, алгоритмика фон Неймана/Кнута, алгоритмика AI/Домингоса, инженерия данных)
-- Менеджер: системный менеджмент (операционный менеджмент/цепи поставок/логистика, управленческий учёт и контроллинг, инженерия предприятия и архитектура предприятия/технологический менеджмент, корпоративные изменения/развитие и системное лидерство)
-- Предприниматель: системное предпринимательство (стратегирование, продвижение продукта, корпоративные финансы, корпоративная поднадзорность/governance)

На примере вот этой диаграммы смотрим, чем в организуемом предпринимателем проекте занимаются эти разные роли (сначала все роли играет один человек, потом каждую роль может играть один человек, потом каждую роль может играть по нескольку человек. CTO и CIO занимаются производством/заводом, а системный инженер -- продуктом):



14. Программа кругозорного курса системного менеджмента в 2021 году (искать на сайте Школы https://system-school.ru/, курс есть в виде онлайн-курса и в составе онлайн-программы "Системный менеджмент и стратегирование 2021", и в составе одноимённого шестидневного тренинга с участием преподавателя). Именно такой менеджерский кругозор (включающий, кстати, материал по цифровой трансформации, цифровому двойнику и цифровой нити) надо пройти или перед прикладными менеджерскими курсами по отдельным дисциплинам менеджмента, или даже после них (люди, получившие MBA, после этого курса говорят, что "наконец-то поняли, чему нас учили"). Курс показывает не только, как связаны между собой разные практики менеджмента, но и как менеджмент связан с предпринимательством и инженерией. В курсе есть и авторские методы (не только «гармонизация западных методов», как в курсе системного мышления): у автора три десятка лет опыта управленческого консультирования и стартап-менеджмента. В курсе более двадцати часов только видеолекций, не считая дополнительной литературы и заданий:
1. Системный менеджмент и системное мышление
-- связь системного менеджмента и системного мышления

2. Практика как объект первого класса
-- понятие практики
-- связь системных уровней целевой системы и практик обеспечения
-- практики системного менеджмента
-- моды и поветрия в практиках
-- цифровая трансформация
-- практики, как объекты первого класса

3. Управление жизненным циклом
-- чеклисты в управлении жизненным циклом
-- управление конфигурацией
-- цифровая нить
-- цифровой цифровому двойник

4. Операционный менеджмент
-- проектное, процессное, программное управление и управление кейсами
-- предварительное планирование работ
-- полномочия по распоряжению ресурсами: DEMO
-- литература после Голдратта

5. Управленческий учёт и контроллинг

6. Архитектура предприятия
-- инженерия предприятия
-- понятие архитектуры предприятия
-- хорошая модульность предприятия
-- архитектурные методологии
-- формализм архитектурных описаний предприятия
-- практические советы по архитектурному моделированию предприятий

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



16. Но нужно ещё и от кругозорного разбирательства в менеджменте перейти к реальным менеджерским компетенциям. Чтобы выучиться менеджменту профессионально, нужно пройти и прикладные курсы (обычно их много в программах MBA, но нужно помнить – это «клочки», целостной картинки менеджмента в них нет, и набор таких курсов не отменяет необходимость в кругозорном курсе). Школа системного менеджмента не планирует пока проведение прикладных курсов, но каждый её выпускник может сам составить себе образовательную траекторию по подобным курсам: организационная инженерия и архитектура предприятия, лЛидерство и оргизменения, … их множество, в самых разных книгах, в самых разных вузах.

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

Делайте шаги, увеличивающие число возможных выборов после них, то есть поднимайте интеллект! Программистам тут уже легче, когда-то они сделали правильный выбор: из программистов или инженеров в менеджеры – можно, из менеджеров в программисты или инженеры обычно уже поздно.
А кто хочет попроще? Что с ними делать? Ничего! Делать без них!

UPDATE: обсуждение тут -- https://www.facebook.com/groups/771940449578453/posts/3851841598254974/ и тут https://www.facebook.com/ailevenchuk/posts/10221354560267541

Иван Метёлкин предлагает развитие темы для архитекторов (и по факту для любых инженеров): https://www.facebook.com/mochalki/posts/2292096930922570