Десять лет назад, в 2014, я прочел книгу Спиральная динамика, и она мне дала ответ на вопрос: почему в ИТ появился Agile как особый вид менеджмента, получилась комплексная картина, которую я тогда же рассказал на AgileDays. А через пару лет картину дополнили Бирюзовые организации Фредерика Лалу, об этом было следующее выступление. С тех пор я рассказывал ее много раз для разных аудиторий. Материала стало много, он не помещался даже в большую лекцию, и я написал серию из более 70 статей. А когда в 2022 году делал курс в Новгородском университете для Лидеров России, то собрал статьи в книгу «Менеджмент цифрового мира».

А в этом году меня позвали прочитать курс «Эффективная организация команды» по современному менеджменту для Бюро 1440, инженерной компании, которая создает низкоорбитальную спутниковую систему. И на курсе были не только студенты, но и действующие инженеры и руководители. Курс включал не только материалы книги, там был обзор классического менеджмента, а также модели soft skills, которые легли в основу моей книги «Инженерная модель личности», вышедшей в этом году. Для руководителей слушать было не обязательно, и для меня очень важно, что многие слушали его до конца, все 8 лекций. Слушатели говорили, что много материала было им известно из других курсов, но мой показал комплексную картину, взаимосвязь разных тем, и это дало новый уровень понимания.

Вот отзыв Анастасии Храмцовой, менеджера по развитию академических программ:

Попросили Максима прочитать курс по эффективному управлению командами для студентов старших курсов технического направления специалитета, вместе со студентами курс слушали сотрудники компании. Для студентов материал был немного непонятен из-за их неподготовленности и отсутствия в их системе знаний базовых понятий современных методологий управления командами и процессами. Сотрудники компании не раз отмечали, что материал полезный и интересный. Много уже было в их системе знаний, но подход и систематизация Максима помогла им разложить все по полочкам и усвоить позабытый материал.

Как заказчик, я осталась довольна как работой с Максимом, так и его подходом к подготовке материалов. Слушая лекции, понимала, как переворачивается в голове то, что было когда-то усвоено мной и дополняется новыми знаниями. Хочу отметить глубину знаний Максима и практического опыта. В курсе были освещены многие темы управления, мягких навыков и командообразования:
история ИТ-менеджмента;
причины смены способов ведения проектов в ИТ;
отличие Agile-мышления от классики.
спиральная динамика, как модель работы с культурой и ценностями.
промышленные революции и волны Тоффлера;
подходы классического менеджмента
система Тойоты, бережливое производство;
промышленный lean, подход «Шесть сигм»;
цифровые двойники
модели организаций и команд в них;
методология Agile
сравнение Agile с методами классического подхода
Agile-трансформация – кейсы и способы
самоуправляемые команды и компании
* инженерная модель личности.
Максим охватил все факты, показав, как все связано и как все развивалось во времени, а также обратив внимание слушателей на все аспекты формирования команд через спиральную динамику.

Так что если кому-то интересно - обращайтесь!

Прочитал книгу Саши Бындю "Антихрупкость в ИТ", пару лет она лежала у меня в очереди. Это - очень полезная книга для тех, кто хочет и кому нужно разобраться в устройстве современных ИТ-проектов. А нужно это тем руководителям, которые выступают как заказчики ИТ-проектов или хотят завести у себя ИТ-разработку. Не факт, что они хотят в этом разбираться, но тогда это превращается в игру "повезет - не повезет", которая знакома почти всем, кто искал себе бригаду для ремонта или, что серьезнее, психолога или врача в не очевидном случае. Это не значит, что прочитав книгу, и разобравшись в ней ты сам сможешь делать ИТ-проекты. Но ты сможешь вести квалифицированный диалог с ИТ. При этом в книге - множество ссылок для тех, кто захочет разобратсья глубже в конкретных вопросах. В книге описано множество граблей ведения ИТ-проектов и современные методы. Дальше - читайте у меня на сайте https://mtsepkov.org/ByndyuAntichrupkost, рецензия получилась довольно длинная. А от книге я получил истинное удовольствие, жалею, что так долго до нее добирался.

Завтра вечером, 10.12 в 19:00 я буду рассказывать о своей книге «Инженерная модель личности» на вебинаре в Книжном клубе проектной асcоциации. Это бесплатно, но только для членов ассоциации, в нее предварительно надо будет вступить. Ассоциация регулярно проводит различные мероприятия, книжный клуб - одно из них, подробности можно посмотреть на сайте.

Вслед за #Teamlead прошел #Highload. 3500 offline участников, 15+ треков интересных выступлений и много общения, так что публиковать заметки в ходе конференции не получалось. Собрал и публикую отчет https://mtsepkov.org/Highload-2024. Отмечу, что презентации всех докладов уже доступны на сайте конференции, надо зайти в конкретный доклад, так что подробности можно смотреть.

Самым интересным для меня докладом было выступление Наиль Миннахметов из МТС про архитектуру: это очень редкий случай, когда большая компания отдает решения по архитектуре на уровень команд, выстраивая федеративную конструкцию. А в целом в отчет попали следующие доклады.
Наиль Миннахметов из МТС. Артефакты архитектуры. Какие, зачем и как их организовать
Владимир Кочетков. Программировать как хакер, защищать — как программист
Алексей Мерсон (Т-Банк). Надежность на масштабе в 45 млн клиентов — инструменты и практики цифрового банка
Алексей Николаевский. Транзакционная работа с топиками. Архитектура и сравнение решений в Apache Kafka и YDB
Григорий Петров. Красота кода глазами нейрофизиолога-программиста
Эмир Вильданов. Движок распределенного SQL в СУБД Picodata: принцип его работы, принятые архитектурные решения и сравнение с аналогами
Евгений Харченко из Райффайзен Банк. Инженерная культура на масштабе: как развивать и оценивать практики
Виталий Исаев. Как объединять данные из разных СУБД и делать это эффективно
Павел Велихов. Стоимостный оптимизатор в YDB — как, зачем и почему?
Ольга Лукьянова. Моментальная навигация по коду для любого коммита. А так можно было?
Екатерина Лысенко. Финтех: причины моей ненависти
Виталий Левченко. Грейды Go-разработчика, или Что отличает сеньора-гофера от остальных
Алексей Обыскалов. Как работать с легаси, чтобы ни вы, ни проект не сгорели
Максим Мирошниченко. Оптимизация конкурентных приложений: паттерны, сравнение и микроархитектура

По горячим следам сделал отчет с #Teamlead https://mtsepkov.org/TeamLead-2024-Msk, пока Highload не стер контекст докладов. Часть заметок я выкладывал в ходе конференции, но доклады Александра Зизы и Анны Обуховой требуют осмысления, их выложить сразу не получилось. Всего в отчете 12 докладов. А еще общее наблюдение, в основном по TechTalks: крупные компании переходят от функциональных подразделений к кроссфункциональным командам, называя это продуктовым подходом, чтобы быть в тренде. Это прогресс, а вот зачем они строили функциональную организацию по учебникам 30-летней давности - неясно. Хотя психологически это понятно.

Вот список докладов в моем отчете.
Максим Цепков. Системное мышление — нужно ли оно в IТ и зачем?
Мария Щекочихина. Делаем происходящее с персоналом предсказуемым
Альберт Степанцев. Законы Мерфи в повседневной работе руководителя
Александра Брызгалова. Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас)
Александр Зиза. 4 стратегии развития управленческого мастерства
Анна Обухова. Как сделать так, чтобы команда наконец признала тебя лидом
Рита Канис. Как убить всех зайцев: про управление знаниями исподтишка
Алена Рыжкова. Как эффективно скоординировать работу 10 разношерстных команд.
Алексей Макаров. Команда разработки за свой счет
Евгений Идзиковский. Legacy-код в психике — как расплатиться со своим техдолгом
Екатерина Шашкова. Как мы перестали говорить «у нас так принято» и стали описывать процесс разработки
Руслан Карманов. Китайские методологии IT-управления

#Teamlead Алена Рыжкова из ИТ-холдинг Т1. Как эффективно скоординировать работу 10 разношерстных команд для успешного закрытия проекта на примере реальных кейсов. Мой личный фреймворк организации проектной работы. Это доклад о конкретном фреймворке, который сложился у Алены для управления проектами, выполняемые сборными командами сотрудников, работающих по совмещению. На мой взгляд, получился хороший легкий фреймворк, которым можно пользоваться. Тем более, что Алена хорошо расскрыла внутреннюю логику. А если представлять его место в других методологиях, то можно и обогощать другими элементами при необходимости - ведь фреймворк должен соответствовать тем проектам, а проекты у всех разные. Об этом я напишу в конце.

Типовая задача у Алены: вывести зи эксплуатации сервис X и заменить на другой сервис Y. Обычно высоконагруженный. Под задачу создается команда из разных специалистов, но ее участники работают не только над этим проектом, а основное подчинение - другое.

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

Из чего состоит инфополе?
1а) 1-страничное описание. Цель, задачи - скоуп, заказчик, карта с вехами, зависимости и риски. Важно: задачи должны быть поняты всей командой. Для этого надо рассказать подробнее. Карта бизнес-процесса с системами и потоками. Формулировка - кратко, просто и понятно. И если спец.термины - нужно толкование, в команде разные участники. В сложных способах - еще и проверять понимание.

Заказчика надо знать в лицо и это тот, кому будем сдавать проект. Форма карты - зависит от проекта - масштаб, насколько проект знакомый, она показывала свой.

1б) Зоны ответственности. Тут могут быть всякие взгляды. Можно начать и пусть само сложится - но проявятся серые зоны, когда никто не ведет. Разработка и девопсы спорили, кто заполнит инвентори параметры, там 20 минут но каждый раз - а спорили 2 дня.

DevOps и сопровождение подключается сразу! А то они могут не принять готовую систему.

По зонам надо предложить свое, собрать предложения, зафиксировать договоренности.

1в) Дорожная карта. Основной вектор развития, связи. Гант: дорожки с вехами. Важно не забыть работы по заказу оборудования и инфраструктурные работы - может быть долго. Не забыть не функциональные блоки - безопасность, надежность.

Получается общее информационное поле. Но просто сказать после этого "поехали" - не достаточно, надо реально стартовать работы. А то приходишь - а оказывается, что все заняты другими делами. Почему? Потому что делают те проекты, по которыем создается информационное давление - на статусах, от менеджеров и так далее.

2) Процессы, которые позволят синхронизироваться, выявлять проблемы и решать. Точка коммуникации.

2а) Основное - статус проекта. 30 минут 2-4 раза в неделю. Прогресс движения к ближайшей контрольной точки.
И открытый микрофон после основной повестки. И надо явно драйвить: какие вопросы, замечания, проблемы.

2б) Рабочие группы по выявленным проблемам. На статусе это не эффективно. Сбор вариантов, проработка и итог. 30-60 минут 2-3 раза в день. Но недолго. Пример. Вендор задержал поставку, которая влияла на старт пилота. И нужен был план-Б, чтобы запустить функционал пилота.

2в) Чат в мессенджере. 20-30 сообщений в дел. Модерация, во-время предложить обсудить на встрече и написать результат.

Статус, рабочие группы и чаты нужны в любых проектах, даже маленьких. Причины факапов чаще не технические, а организационные. Серые зоны ответственности и прочее.

Слайды моего доклада про системное мышление опубликованы на моем сайте https://mtsepkov.org/SysThinkTeamlead Там же ссылки на предыдущие доклады по теме, для которых есть записи.

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

Но увольнять можно. Даже хороших людей - они могут не соответствовать тому, что нужно.

#Teamlead Александра Брызгалова (bryzgalova.ru) Почему ваши очевидно эффективные идеи отвергаются (вероятно, дело в вас). Основной тезис доклада: если ваше замечательное решение отвергается, то причина обычно не в том, что люди глупы или ленивы, или преследуют какие-то личные цели. Обычно есть какие-то аспекты, которые в своем решении вы не учли: оно не решает проблемы, или решает не актуальную проблему, или создает дополнительный урон или риски, которые вы не видите. И надо расширить рамку рассуждения, понять логику тех, кого вы считаете противниками, найти общую цель - и тогда ситуация изменится. Инструмент, которым иллюстрированы кейсы - грозовая туча из TOC (Theory of Constraints) Голдратта. Но это - лишь один элемент теории. и, по сути, он дал понятную схематизацию, визуальный ряд.

Я хочу отметить, что доклад по сути борется с основной ошибкой атрибуции, в просторечии "все уроды, а я д'Артаньян". Корень этой ошибки в том, что модель самого себя и модели других людей в мозгу разделены и слабо связаны.

А теперь - кейсы из доклада. Они - про ситуации, когда конфликт - это не отвлеченный спор, а когда в результате спора вам нужно что-то вместе сделать. И тут метафора деления пирога: все, что досталось ему - отнято от меня. Но часто есть возможность не делить маленький пирог, а найти пирог побольше. Всегда есть win-win. Выгодно в это верить. Потому что если верим - пойдем договариваться. А если не верим - то вообще не пойдем. А могут быть варианты.

1. Самый умный разработчик. Который, как казалось руководству не тщательно тестирует код, выкатывает с багами, пользователи жалуются. Итого, мы хотим, чтобы тестировал, а он - нет. А не хочет он потому что хочет быть самым умным. Но решили разобраться. И, оказывается, ему когда-то сказали, что самое важное - скорость выкатки фичи. Я проверяю основное, пользователи быстро ищут ошибки, мы исправляем. Скорость - важная. Но жалобы - тоже. И выяснили, что жалуются одни и те же - и из них сделали команду ранних последователей - и они перестали жаловаться, их замечаниям был другой статус.

2. Я хочу. чтобы начинали большие тикеты с важными задачами, а они - берут малые. Кричать надо. А он - ленивый. Пошли разбираться. Оказалось, что большие проекты плохо описаны, клиент не понимает что хотел, тянет. Если тянем время - все сговорчивые, и все проще, и меньше лишней работы. Общая цель - есть, меньше работы. Решения: пересмотреть способ описания, менять описания.

3. Жадный собственник. Было двое, один вышел. Виктор Петрович, надо больше денег нанять больше людей. А он - не дает, потому что жадный и не думает про завтра. Конфликт: мы хотим бюджет. а он не дает потому что жадный. А дело было не в жадности. Если вдруг у компании есть деньги - мы можем в теории нанять людей. Но, скорее всего, есть проблемы со старым. Норма прибыли - малая, и нет впечатление, что оно возрастет. Больше фич - не значит больше денег. И надо с этим разбираться - что ждут, и почему не работает.

4. Глупый начальник. Надо автоматизировать тестирование, а начальник не дает. Я хочу - потому что хочу повысить качество. А он - просто не хочет напрягаться. А реально: компания получала деньги за время, которая потратила. Автоматизация - уменьшение выручки. А затраты - меньше. Повышение качества тестирование - не факт, что повысит выручку. И надо менять модель.

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

Внедрение наполовину - какой-то компромисс, мы улучшили на половину, а риск не убрали. А еще хуже - заметание под ковер, просто редко здороваемся и забываем.

Мысль: люди - хорошие. Голдратт настолько верил, что написал это на надгробном камне. Хотя жил в Израиле в реальной ситуации. Это не романтизм, это прагматизм. У людей нет цели сделать плохо. Брак получается, его не делают сознательно.

На вас можно повлиять.
Изолировать от другой точки зрения: не ходите к этому, он не решает. Если не изолировать, то дискредитировать - он не решает, дурак, некомпетентен.
Подмена свидетелей. Негатив вычеркиваем, позитив лайкаем и добавляем от себя
* Создание информационного фона. Много каналов - с анонсы, и иногда там крупицы золота. Никто не комментирует. А в два ночи - 70 комментариев. А потом - 50 к другому. И это - один человек, к нему идут. Он пришел из губернаторской команды и принес культуру с командой поддержки. И это - способ воздействия на убеждения.
Манипулируют все. родители детьми, супруги друг другом и так далее. И когда приходите со своей системой - она влияет на интересы и весь спектр может быть применен.

Был еще пятый аспект, но я не записал. Над будет посмотреть презентацию и запись...