Алексей Зуев. Чайка-анализ. Колесо баланса и BACCM для сил добра. В докладе два метода: (1) рисуем колесо баланса жизни или работы и (2) применяем модель базовых бизнес-понятий BACCM для принятия личных решений. Кажется, что это интересно, но способ принятия решений до конца не проявлен. Может быть потому, что это был блиц, и просто не успел раскрыть. Если кратко изложить то, что я понял, будет следующее. Модель выявления бизнес-понятий при применении к личным ситуациям позволяет выявить ценности и факторы, которые важны именно для тебя в какой-то области, например, касающихся ведения проектов. И дальше построить в Excel матрицу оценки, применить ее для прошлых проектов и для будущих. Разглядывание матрицы может позволить увидеть корреляцию и сделать кластеризаци.

Например, оценивая свои проекты, он так выяснил четыре типа: чайки, прингвины, тупики и альбатросы. И построил колесо профессионального баланса, а также смог сформулировать ожидания от новых проектов. И это не просто выбор, это как раз типология проектов, которая позволяет ориентироваться на будущее. Алексей применял этот метод не только к проектам, но и к решению о возможном переезде. И вот здесь модель базовых бизнес-понятий BACCM помогла ему выявить ценность "доехать до родителей за три часа", которое неожиданно подсветило вопрос переезда, а при обычных рассуждениях - не проявлялось. В общем, надо будет еще посмотреть на слайды детально. Да, про название. Почему это чайка-анализ я так и не понял. На входе был тезис, что это не про чайка-менеджмент, а ассоциировано с Чайкой по имени Джонатан Лингвистон Ричарда Баха, но деталей я не понял. Может, потому, что давно читал книгу.

Анастасия Прохорова из Райффайзенбанк. Event happens. Переход на Event Driven архитектуру глазами аналитика. Рассказ на простом примере "Хочу пиццу", по которому надо принять оплату, приготовить пиццу и ее доставить. В сервисной архитектуре это отдельные сервисы, которым надо дать команды: Прими оплату, Приготовь, Привези. Но Потребитель не хочет управлять, он хочет сказать "Хочу пиццу" и все. Это одно событие, на которые должны среагировать все сервисы.

Из чего делать событие?
* Разбор процесса от начала и до конца. Для Запрос-ответ мы можем взять кусочек и окружение. А тут надо найти начало, конец и всю цепочку.
* Выделение шагов-задач, необходимых для достижения цели.
* Поиск объектов, участвующих в процессе. Например, Заказ пицц. И изменение состояние объектов связан с процессом.
* Определение зависимостей. Когда повар должен начать готовить пиццу? Когда заказ становится оплаченным.
Важно мыслить не отдельными функциями, а целиком процессом.

Как вести документацию? По стримам разработки - им соответствуют процессы от начала и до конца.
* Бизнес: цели и гипотезы, не требования
* Объекты: жизненный цикл и событийный ряд
* Архитектура: схемы и зависимости
* State machine diagram и sequence diagram
* Документация - не со стороны отправителя, а со стороны получателя, их цели. Страничек - много, но они маленькие.

Как организовать события? Персонаж хочет пиццу. У разных подписчиков - разные вопросы по этому поводу.
* Notification: событие только сообщает про изменении объекта, а дальше потребитель спрашивает что ему нужно. Можно пакетировать - несколько изменений. Нагрузка на источник - повышенная.
* Event-carried state transfer - передача атрибутов в событии. В расчете на то, что их будет достаточно для всех подписчиков.

Правило проектирование
* Одним событием пользуется максимальное количество потребителей - стараемся угодить большинству
* Одно действие - одно событие. Получается не всегда.
* Атрибутов должно быть достаточно, но не избыточно.
Связь кто и что получает - полезно фиксировать.

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

Есть проблема: сервису оплаты не интересно, какую пиццу и куда везти, ему надо их передать дальше, но и только - дублирование данных. И тут схема чуть другая: первоначальное событие получают все, а дальше сервис оплаты дает простую нотификацию "оплачено, действуйте". Большая часть новых потребителей будет подключаться к существующим событиям. Это дает потенциал масштабирования и развития.

Event storming. Коллаборация бизнес-пользователей и ИТ по исследованию области бизнеса. И помимо разбора бизнес и ИТ вырабатывают общий язык. Там выделяют Событие, Команда, Правило, Агрегат. Начинают с события - что произошло? Дальше команды как реакция на события и агрегаты, с которыми работаем. И в конце - выделяем ограниченные контексты.

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

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

Предыдущий стандарт системного аналитика делала группа под руководством Дениса Бескова в 2014, а новый - группа под руководством Сергея Нужненко, в которой около 140 человек и 40 экспертов. Организует ВНИИ Труда. Ирина в этом активно участвовала, а в докладе - рассказывала об изменениях в стандарте. Основное - изменили содержание работы аналитика, вместо формулировки "Содержание работ: разработки требований" стала формулировка "Миссия: координация на уровне проектных решений". То есть меняется разделение труда. Такое изменение - не их произвол, оно проявлено в индустрии, например, это видно по изменениям требований к позиции на HH. При этом написано разграничение со смежным ролями: бизнес-аналитик проектирует организацию; системный выявляет рамки автоматизации, собирает требования, включая атрибуты качества и проектирует; архитектор создает конструкцию, реализующая атрибуты качества и детальные требования; есть границы с техническим писателем, разработчиком, тестировщиком. Правда, открытый вопрос - отражено ли это изменение в смежных профессиональных стандартах?

Содержание работы системного аналитика определено через трудовую функцию, включающую трудовые действия, необходимые умения и необходимые знания. По сравнению с предыдущим стандартом добавлена защита информации, интеграция и API, распределенные системы - в 2014 это было сильно менее актуально. А также навыки программирования. Доработан и уточнен глоссарий. Уровни квалификации: младший - работа с требованиями, средний - разработка техпроекта, старший - концепция ТЗ и ведущий - управление группой. При этом после среднего уровня - развилка, а не линейное развитие: руководить группой можно без навыков старшего аналитика. Но я подозреваю, что на практике эту развилку не воспримут. По уровням расписаны не только профессиональные компетенции, но и ответственность, работа с неопределенностью и другие, в презентации были примеры. Интересно, насколько это соотносится с аналогичными уровнями в других профессиональных стандартах. На мой взгляд, тут интересен опыт британского стандарта SFIA, где семь уровней определены сквозным образом для всех специализация с точки зрения ответственности, самостоятельности и ряда других характеристик, при этом некоторые специализации заканчиваются на 4-5 уровне, в то время как другие, руководящие - начинаются с 3-4 или выше.

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

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

И они решили, что можно улучшить ситуацию, если поставить процесс онбординга, в котором бы участвовали не только руководители, но и наставники. И они пошли создавать процесс, опираясь на свои профессиональные умения бизнес-аналитика - надо же не просто создать с нуля, а обеспечить встройку в HR-процессы. А еще - команды так или иначе решают задачу онбординга, и есть смысл опереться на их опыт. Поэтому они построили Customer Journey Map по поыту решения задачи в разных подразделениях, а потом - обобщили, консолидировали все материалы, сделали навигацию для наставника и адаптантов.

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

Андрей Бураков. Брокеры сообщений. Основы использования в интеграционных задачах. Основное в докладе следующее: гарантированная однократная доставка сообщения (exactly once) в природе не встречается, брокеры или теряют сообщения (at most once) или могут их дублировать (at least once), в том числе дубль может получить другой экземпляр сервиса-получателя, дублирование будет, если проблемы возникли с передачей квитанции после обработки. И вам надо проектировать системы, устойчивые к возникающим при этом проблемы. Вы не можете от проблем избавиться, но можете выбрать, с чем именно будете разбираться. Как разбираться - тоже немного было. Например, идемпотентная обработка обладает устойчивостью к дублированию. А регулярная отправка, например, биржевых курсов - устойчива к потерям.

Поведение может быть заложено в архитектуру брокера, или управляться настройками для конкретной очереди или подписки. При этом классическая подписка со многими получателями работает как at least once, а в Kafka мы имеем подписку, в которой политикой смещения счетчика (at most once или at least once) вроде может управляться для каждого получателя.

Собрал свои заметки с #AnalystDays в отчет и дополнил несколькими темами, которые всплыли в обсуждениях в кулуарах, но, мне кажется, будут интересны и за рамками частного разговора https://mtsepkov.org/AnalystDays-2022c Хорошего чтения на выходных! Спасибо организаторам!

Анатолий Левенчук недавно написал два важных и интересных поста, на которые я хочу обратить внимание. Первый https://ailev.livejournal.com/1656653.html - фундаментальное изложение онтологии системного подхода, опираясь на работы современных авторов, со ссылками уровня научной публикации. Там много интересного и глубокого. В частности - мир абстрактных объектов и мир физических объектов, и физические вычислители, компьютеры и люди, которые работают с обоими мирами, создавая новые абстрактные объекты или воплощая их в физическом мире, при этом управляются они во многом как раз абстрактными объектами. Такой дуализм Декарта в современном виде и, естественно, без всяких ссылок на него, это все - современные авторы. И там много еще чего интересного, пересказывать я не буду, это надо вдумчиво читать.

Второй пост https://ailev.livejournal.com/1654601.html включает тему "А чо таково?" - как разбираться с тем, что люди всерьез воспринимают всякую хрень, считая ее равноправной с научными теориями, при этом указания на противоречия на них не действуют, они не считают это основанием для отказа от теорий. Это интересный вопрос, имея ввиду не только астрологию и аналогичную эзотерику, но и имеет практический смысл в современной геополитике и этике - вопрос об основаниях для рассуждений и действий.

Я исторически читаю Анатолия в livejournal, мне там удобнее, но он публикует и обсуждает посты в FB и телеграм, там есть ссылки, так что кому удобны другие площадки - можно читать там.

Конференция Enterprise Agile Russia - истории Agile в крупных корпорациях. Первый доклад Евгения Меньшикова из ВТБ. Журавль в руке: опыт трансформации процессов производства ПО. Вид сверху на трансформацию ВТБ за последние три года с 2019, за которое ИТ увеличилось с 3 до 20 тысяч человек, при этом они сильно ускорились, перейдя от 4 релизов в год с ТТМ 9 месяцев к непрерывной поставки софта и ТТМ около месяца. Для перехода к непрерывной поставки пришлось существенно изменить ИТ-ландшафт: легаси-системы, которые были на входе для этого не пригодны. У трансформации было несколько особенностей:
* Цели - бизнесовые, были поставлены перед банком в 2019 в 1.5 раза розницы, вдвое средний и мелкий бизнес при росте дохода на 15-35% при этом сохранить сегмент крупного бизнеса.
* Команда была уверена, что ключ успеха - в Agile-методах. При этом в банке Agile был дискредитирован предыдущим опытом, били пилоты, которым не удалось взлететь. Поэтому фокус был на бизнес-целях, не на методах.
* Трансформация по площади и на всех уровнях - потому что этап островов уже проходили. При этом идти этапами по полгода, с конкретными целями на каждый этап, и сначала - расшатывание ситуации.
* Принципы, о которых договорились: фокус на создании ценности - поддержке бизнеса; совместная работа; инкрементальность; измеряемость; универсальность; надежность автоматизиции и инфобезопасность.
* Смешанная структура программ и проектов с продуктовыми стримами. Синхронные изменения многими участниками, и синхронизация. На некоторые стримы - 3-4 программы, развитие продукта + технологические изменения и т.п. Стримы вокруг продуктов их удерживают.
* На входе была разобщенность ИТ и бизнеса. Поэтому вместо принципа единственного product owner - правило двух ключей: ИТ + бизнеса. Проследили консенсус, и пропорции в целеполагании: 50-70 бизнес, 30-50 технологические.
* Надо менять не только change, но и run, и единая модель управления для обоих, единый такт работы. По факту run всегда на такт позже, но все равно вместе, вовлечение стримов сопровождения с первого планирования.
* Как вовлекаем? Постоянное общение. Townhall - сотрудники говорят с менеджерами, не в варианте "начальники решили - я делаю". Линия поддержки, включая методологию изменений, регулярные обучающие сессии. Гильдии, сначала SM, потом на остальное. Телега и развлекательно-информационный контент. Активности по рассказу.
* Прозрачность. 3d-мониторинг viewpoint: программа, архитектура, стрим, команда. Все дашборды доступны всем.
* Метрику NPS сотрудников - не вводили, пациента на хирургическом столе глупо спрашивать, доволен ли он, и ориентироваться на его мнение проводя операцию. Но все время спрашивали "что не так", и эту обратную связь обрабатывают.
Команда трансформации: начинали в 2019 15 человек, и команда по методологии продолжает оставаться небольшой. А команда внутренней автоматизации, инженерные практики, мониторинг - около 400.

Виктор Редров и Илья Бушмелев из РТ Лабс. Как SAFe помогает выполнять задачи государственной важности и иногда немного спать. РТ Лабс - единственный исполнитель Минцифры по задачам электронного правительства, в котором верхушкой айсберга является портал госуслуг, которые в России реально круты, если сравнивать с другими странами. А доклад по сути был о том, как ковид стимулировал переход от традиционной работы по ежегодным контрактам к гибкому квартальному планированию, при котором команды ответственно берут обязательства исходя из реалистичной оценки возможностей, а потом их выполняют. При этом государство на уровне Министра и его замов - участвует в процессе, принимает объем этих возможностей и учитывает их. И это - новая реальность, в которой ИТ лимитирует скорость изменений в государстве и обществе в целом. Почему государство признало эту реальность? Потому что обычный подход годовых контрактов порождал текучку персонала и перегруз, которую ковид критически обострил. Постоянный подвиг невозможен, и стейкхолдеры от государства это признали. И пошли на изменения. Это - мой взгляд на доклад из более широкой рамки.

А если говорить про детали, то доклад был посвящен устройству процесса планирования на 100+ команд и 2000 сотрудников, при этом между отдельными сервисами в продукте - сильные связи. Это трехдневная сессия, в которой очно участвует 400 человек от компании и Минцифры, и еще 1000 участвует online. Стандартный формат PI SAFe дополнен тактом согласования квартальных планов с министром и заместителями, которое начинается после получения финальных презентаций в 16 часов строго дня и идет вечер второго и третий день. В докладе и презентации этот процесс показан очень детально, с этапами, промежуточными точками и контрольными вопросами по ним. Презентации уже доступны в программе конференции, так что можно смотреть. Что важно, результат планирования - это не просто набор фич у каждой команды, формируются цели и ключевые результаты, в соответствии с подходом OKR и привязка к ним реализуемых фич. Для технической поддержки сделано решение, которое позволяет формировать презентации на основе задач в Jira.

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

Анна Крюкова из Росбанка. Инвестируя в гильдии, инвестируем в развитие всего банка. Росбанк в какой-то момент решил отдать ИТ в бизнес-блоки, и было понятно, что будут побочные эффекты из-за замыкания экспертов в рамках своей команды. Инструмент решения - гильдии, которые попробовали сделать на самоорганизации, за счет инициативы сотрудников, без выделенных деврелов, которые бы курировали каждую гильдию. Ответ - утвердительный, самоорганизация работает, и даже после кризисов движение возобновляется. Анна - единственный человек во всем банке, которая полностью занимается гильдиями, все остальное - на инициативе и добровольном участии. Сейчас 13 гильдий, более 100 сотрудников активно участвуют, не просто приходят на встречи, а создают какие-то продукты.

Принципы
* Гильдия - про самоорганизацию. Не централизованное создание. И на инициативе - не ставят задачи
* Инвестируешь в гильдию - инвестируешь в себя.
* Гильдия - это по любви. И никто не обязан вступать в гильдию.

Этапы жизни гильдии, начинается с запуска.
* Желание сотрудника запустить гильдию. У кого инициатива - пишет. Вопрос - насколько кросскомандная.
* Появляется лидер гильдии - еще до запуска. HR помогают найти экспертов в командах - получается рабочая группа.
* Проводят общую встречу, гильдия появляется.
* Этап строительства. У каждой гильдии есть чек-лист: цели, правила, площадки коммуникации, идентичность, матрица компетенций...
* Этап полета. Регулярные встречи - раз в 1-2 недели
Есть коммюнити лидеров гильдий - для обмена оптом и помощи. Каждая гильдия берет практики, которые важны в моменте. Плюс общее позиционирование гильдий и встраивание в общие HR-процессы.

У гильдий - свои метрики. Есть общие - по долям участников. И Чувство сообщества - оценка, насколько участники оценивают соответствие идеальной картине.

Было три кейса, что может пойти не так.
* Быстро выполнили цель гильдии - что делать? Расширение спектра тем и увеличение числа участников
* Участников много, а активности мало. DevOps - почти все могут вступить. Но при этом оказалось, что devops-инженеры не чувствуют ценности. Ту гильдию оставили, но devops стали 2.0
* Новостная повестка может повлиять на развитие гильдии. Сотрудники могут оказаться слишком занятыми, либо смениться моральное состояние. И в эти моменты надо сделать паузу, а потом вернуться и продолжить идти. Остаются точки оперативной синхронизации статуса. Паузы были с конца феврале до начала июня, и замедление в октябре (слабее - только моральное состояние, а не занятость).

Что сделано? Описание методологии, на новый уровень вышел обмен знаниями и внутренние обучающие курсы - там прикладные конкретные вещи. Вместо бесконечных Excel создания компетенций появился свой инструмент. Есть общее информирование, задача Анны - сделать, чтобы лиды отпускали людей. Гильдии сами определяют правила вступления, и в некоторые, например, девопс - есть входной барьер по профессии или нужна рекомендация.

Евгения Хосейни. Продуктовая экосистема или как получилось строить самолет, летая на нём. Компания разрабатывает решения для видеонаблюдения. И на входе комплексные решения собирали партнеры, которые предлагали заказчикам комплексное решение. Они приходили с запросами на доработки - шло несколько тактов уточнений без прямого контакта с клиентом, в результате вместо 2 месяцев делали за 9 и даже если получалось нужное - это оказывалось специализированное решение под 1-2 клиентов, которое потом надо было сопровождать. Эту ситуацию принципиально изменили, создав отраслевые команды, ориентированные группы клиентов, которые напрямую взаимодействуют, собирают потребности клиентов, делают отраслевую экоситему и пилотируют на небольшой группе клиентов.

Если подробнее, что поменяли
* Сквозные процессы. Экосистема - она из нескольких продуктов, продуктовый хаб. Внутри делание по сегментам.
* Отраслевая команда: Менеджер сегмента + Продукт, который тащит сгенеренные продукты + Исследователь трендов.
* Выделение сегмента рынка - целевые клиенты, их потребности, что удовлетворяем, а что нет. Дальше продавцы по целевым клиентам.
* Отраслевой бизнес-аналитик - отдельная позиция, дало неожиданный результат. Интегрирован в отраслевую команду, и выясняет у целевых клиентов реальные потребности. И собирает задачку внутри команд разработки, она расползается по стримам.
* Целеполагание. Цели на год в деньгах по каналам. Идеи, гипотезы продуктовые, околопродуктовые, непродуктовые. И дальше на квартал получаются задачи по формированию гипотез под идеи, цели в продуктовых и непродуктовых метриках и так далее.

Ошибки
* Избыточная сложность и длительность согласования на этапе разработки, даже для небольших фич - сделали простой процесс
* У них была переоценка собственной продуктовой экспертизы, клиенты используют продукты для других целей и не так как задумывалось - и это надо исследовать
* 100% план на недоукомплектованную команду - не работает, его не выполняют, и надо учитывать реальную комплектацию при планировании
* Не провели аудит инструментов анализа данных - не видели как бежим сразу
* Не зафиксировали метрики рентабельности целевой системы
* Не зафиксировали метрики здоровья

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

Конференция Enterprise Agile была очень динамичной, поэтому публиковать заметки у меня получилось только по части докладов. Компенсирую это, выкладывая отчет по горячим следам https://mtsepkov.org/AgileEnterprise-2022, дополнив его общими впечатлениями. И я хочу обратить внимание: эта конференция не про то, как используются Agile-методы в ИТ-разработке, хотя такие доклады были. Она о том, как с помощью Agile-методов организовывать деятельность крупной корпорации или банка, где работают тысячи сотрудников. Или изменять ее, координируя несколько десятков программ, в которые так же вовлечены тысячи человек. И это - интересно.

Сегодня на Highload. Круглый стол по инженерной культуре вызывал интересные мысли. Был тезис, из википедии: культура - это предписанный набор правил поведения с присущими переживаниями и мыслями, которые оказывают управляющее воздействие. Но вот потом разговор уходит именно в область правил, а мысли и переживания упускаются. А ведь именно это - принципиальный вопрос.

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

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

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

#Highload Слушая выступление Александра Зиза по мышлению и реплики слушателей, зафиксировал интересный конфликт школ. Есть школа СМД-методологии, которая говорит, что мышление возникает в ситуации, когда у вас есть проблема, с которой надо что-то делать, а вы не знаете, что именно. И есть школа нейрофизиологии, которая говорит что в стрессе блокируется поступление дофамина (и еще каких-то важных веществ) в кору головного мозга, что выключает возможность сложного мышления, остаются только типовые реакции. понятно, что противоречие не фатально, ты просто должен сначала И специально говорят о том, что сначала надо выйти из стресса, уже потом запускать мышление. Но при этом, получается, выйти из стресса надо, сохранив представление о проблемности ситуации - иначе мышления не будет.

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

На прошедшей Highload у меня практически не получалось публиковать заметки с докладов. Но у мсебя на ноуте я их делал, и сейчас собрал отчет и опубликовал https://mtsepkov.org/Highload-2022b. В отчете не только Highload, но и DevRelConf, которая была сразу после Highload.

Прочитал книгу Марка Розина «Восхождение по спирали», публикую свои заметки https://mtsepkov.org/RozinClimbSD и рекомендую книгу к прочтению! В ней — интерпретация Марком Спиральной динамики применительно к культурам организаций, основанная на его опыте. В книге теория обильно подкреплена историями из опыта, но вместе с тем соблюдается строгость и точность рассказа. Отмечу, что именно Марку принадлежит применение Спиральной динамики для организаций и описание культур Принадлежности, Силы, Правил, Успеха. Это было сделано задолго до выхода книги Фредерика Лалу, который также активно опирался на Спиральную динамику при построении своей классификации организаций.

За долгую практику работы в ИТ меня всегда удивляло внимание к требованиям, стремление к их тщательной проработке. Я лично предпочитал быстро переходить к моделям и работать с ними, рассматривая требования как промежуточный этап. Сейчас задумал статью с размышлениями на эту тему, но она получилась слишком большой, так что читайте пока первую часть https://habr.com/ru/company/custis/blog/703758/ Продолжение следует.

Самоопределение в этом году стало актуальной темой, особенно в ИТ. И у меня было несколько докладов, а сейчас я решил опубликовать их в виде серии статей. Первая статья https://vc.ru/hr/562279 посвящена созданию образа будущего. Продолжение следует.

Опубликовал вторую статью по схемам самоопределения https://vc.ru/hr/565896, в которой разбирается важный вопрос: человек для компании или компания для человека? Являются ли сотрудники лишь материалом, из которого построена компания?

Статья https://habr.com/ru/company/custis/blog/705958/ Domain Driven Design: модели вместо требований продолжает тему работы с постановками, начатую статьей https://habr.com/ru/company/custis/blog/703758/ Какие нужны требования: развитие концепта. Здесь рассказывается альтернативный классическим требованиям подход, когда очень быстро переходят к моделям и именно они становятся предметом обсуждения с заказчиком.

Опубликовал очередную статью по самоопределению https://vc.ru/hr/573995 – о создании аватара, который пойдет в будущее. Публикация перед самым Новым годом, но, думаю, это будет востребовано – ведь длинные новогодние каникулы для многих – время подумать о планах на будущий год, А если нет – можно вернуться к этому позднее, а пока – праздновать. С наступающим Новым годом!