/dev/energy

Да там на день работы!

Не так давно я уже писал про когнитивные искажения. И сейчас решил продолжить эту тему, так как довольно часто вижу её в работе.
Сегодня поговорим про такое искажение, как «проклятие знания».

Проклятие знания - это невозможность вернуться в состояние, когда ты чего-то не знал. Как только знание появилось, мозг перестаёт видеть путь, которым ты к нему шёл. Остаётся только результат, и он кажется очевидным. Это одно из самых незаметных, потому что маскируется под экспертизу. Самое неприятное - искажение растёт вместе с квалификацией. Чем ты сильнее, тем хуже представляешь, сколько времени занимает не знать.

Точка напряжения

Это искажение может проявляться в разных местах:

- Оценка. Сеньор называет срок для себя сегодняшнего. А делать будет тот, у кого нет пяти лет контекста по этому сервису. Отсюда и берётся вечная разница между «на день» и неделей.
- Документация. Её пишет человек, который уже внутри. «Просто поднимите окружение» - а за этой фразой три страницы неявных шагов, которые автору давно не нужно проговаривать вслух.
- Ревью. «Тут же очевидно» - очевидно тому, кто писал. Он полчаса думал над этой строчкой и помнит, почему она именно такая. Читающий видит только строчку.
- Собеседования. Мы объявляем базой то, что сами используем каждый день, и спрашиваем не то, что нужно для работы, а то, что нам самим кажется азами.
- Архитектурные решения. Через год документ читает человек, которого не было в комнате. Записано «что», а нужно было «почему». Контекст испарился вместе с людьми, которые его держали в голове.

Ярче всего я это искажение увидел в преподавании. Я веду онлайн-курсы с 2016 года, и когда я готовил лекции для новичков, то очень части ловил себя на мысли: «Вот тут мы применяем цикл с постусловием, потому что… А почему? Ну это же понятно!». Понятно оказывается не всё, потому что у меня уже есть знание, и я не держу постоянно в голове путь к нему. И если я не применю позиционное мышление и не поставлю себя на место студента, то расхождение выяснится на первом же вопросе из зала. 

Что с этим делать.

Для начала проверять свои результаты стоит на коллегах разных уровней. Особенно если это объяснения решения. Если его понял коллега твоего уровня, это ещё не гарантирует, что его поймёт тот, кто пришёл в тему недавно.

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

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

В самой простой версии это работает как «поставь себя на место Васи». Но если идти дальше, то вопрос ставится к роли: что у этой позиции есть в голове, чего у неё нет, какие у неё цели и чем её будут мерить. 

Еще можно применять технику пересказа. Не спрашивай у человека «Тебе понятно?». На этот вопрос всегда отвечают «да». Спрашивай, как человек будет это делать, и слушай, где он спотыкается.

Также как аудит процесса можно использовать онбординг. Новый человек идёт по предоставленной документации буквально и отмечает каждое место, где застрял. Правда, это работает, если у вас есть документация для онбординга. Она же у вас есть, да?)

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

Именно поэтому я всегда очень ценю, если мысли перекладываются в текст. Это невероятно полезное упражнение, так как человек заново продумывает то, что у него есть в голове и кажется ему очевидным.

А в вашей системе есть что-то, что держится на «и так понятно»?

#bias #обучение #когнитивныеискажения

День после Event Storming

Вы провели ES сессию, команда на подъёме, кто-то заскриншотил Miro, кто-то перенёс в Wiki. Но через две недели ничего не изменилось. Через месяц про сессию кто-то даже помнит.
Еще один частый провал ES выглядит не как провал.

Почему так происходит

Стена стикеров - это только аналитический инструмент, но никак не решение. ES помогает сказать: «Мы поняли, как устроен процесс». А вот чтобы сказать «мы знаем, что делать», нужно проделать работу вне сессии. И эта работа скучная. На сессии был драйв, коллективное открытие, споры. Дальше нужно сесть и написать RFC, покрутить архитектуру. Желающих заметно меньше.

Первый шаг: свернуть стену в границы систем

Не надо переносить всё в документацию один в один. Это бесполезно, потому что стена ES - это сырые данные. Их можно хранить, как источник.
Нужно выделить группы событий, которые связаны сильнее внутри системы, чем наружу. Это кандидаты в bounded contexts или, если слово «контекст» вызывает непонимание, просто в границы ответственности.

Кто это делает? Не вся группа. Два-три человека после сессии, за пару часов. Дальше следует асинхронный синк с остальными.

Второй шаг: проблемы превращаются в задачи с именами

Каждый розовый стикер - это либо вопрос, на который никто не знает ответа, либо конфликт позиций.
У первых должен появиться человек, который идёт и выясняет к определенной дате. У вторых - человек, который принимает решение, и дата.
Задача без ответственного и сроков не будет сделана никогда.

Третий шаг: решения оформляются в RFC

У меня был отдельный текст про RFC-культуру, и вот тут она стыкуется с ES напрямую.

ES даёт материал: контекст, альтернативы, места неопределённости. RFC даёт форму, в которой решение переживёт смену состава команды.
Без этого шага через полгода придёт новый человек, спросит «почему тут такая граница», и никто не сможет ответить. Стикеры к тому времени отклеятся и опадут, как озимые.

Что не надо делать

Не надо пытаться зафиксировать всю стену в документе. Ценность была в разговоре, а не в стикерах. Документировать нужно решения и границы, а не каждый оранжевый квадратик.

Не надо назначать повторную сессию «чтобы закрепить». Если после первой ничего не сдвинулось, вторая ничего не изменит - проблема не в количестве сессий.

Не надо говорить «у нас это точно не сработает». Попробуйте сделать. А если что-то осталось непонятным - задавайте вопросы мне 😁

#eventstorming #процессы #разработка

Четыре года назад самый солнечный город Земли встретил меня такой же теплой погодой, как сегодня. Поэтому сегодня, даже по результатам позднего вечернего перелета вчера и жуткой лени сегодня, я не изменил своей привычке взять фотоаппарат и поснимать Ереван.

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

А еще я всегда умиляюсь, когда мои близкие спрашивают меня по телефону: "Ты поел?". В Ереване. Не поесть. Разве что во сне 😆

Так что делюсь с вами замечательными фотографиями жизни моего любимого города!

#неформат

/dev/energy pinned «Навигация Постов в канале набежало много. Поэтому собрал для вас пост-закреп с навигацией по темам, а также со ссылками на стартовые посты серий. Старт Зачем канал Процессы / управление Немецкие заморочки Один навык высокоэффективного Саши Удалёнка vs…»

Навигация

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

Старт
Зачем канал

Процессы / управление
Немецкие заморочки
Один навык высокоэффективного Саши
Удалёнка vs офис
Ретроспектива, которая смогла

#процессы #работа #ретро #принципы 

Разработка / архитектура / цена решений
Четыре цены одной фичи
Распределённый монолит
Пусть программисты сразу пишут хорошо

#разработка #архитектура #ценаразработки

Event Storming
Event Storming

#eventstorming

Найм / собеседования / карьера
Как я собеседую инженеров
Как я собеседую руководителей
Испытательный срок
Тестовые задания
Когда купил не ту работу
Вайб-наём

#найм #собеседования #карьера 

Личная эффективность / ToC
Мой мозг не SSD
Инструментарий планирования
У вас достаточно времени

#личнаяэффективность #gtd #toc

Обучение / менторство / мышление
Вещи, которых я не ожидал, начав преподавать
Как рождается курс
Про преподавание
Когнитивные искажения

#обучение #менторство #преподавание

AI / инструменты
Про нейросети в моей работе
Все AI врут
Как я учу армянский с нейросетью

#ai #aitools #нейросети #инструменты

Книги
Книги на лето
Для менеджера
Бизнес-книги

#книги 

Консалтинг
Вам не нужен IT-консалтинг

#консалтинг

Пенсионный скрипт
Год, чтобы довести мечту до прода

#пенсионныйскрипт #подкаст 

Финпросвет
ФинПросвет

#финпросвет

Личное

#неформат

Как провести Event Storming без жертв

Первая сессия, которую я проводил сам, разумеется, не пошла, как нужно. Я показал пример на простом CJM, объяснил правила. Но в какой-то момент (причем, недалеко от старта) мы начали зарубаться на тему того, как же поведет себя система при выполнении определенная кнопка в разных ситуациях.

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

Но теперь разберемся с тем, как же этим всем управлять.

Фасилитатор

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

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

Внешнему проще задать глупый вопрос. Я такие стартовые сессии провожу как внешний консультант, и чаще всего самое полезное происходит не на самой сессии, а в разговорах, которые она запускает.

Отдельно отмечу, что здесь важен фасилитатор с опытом именно Event Storming. Первые пятнадцать минут стена пустая, все стоят и мнутся. Новичок начинает нервничать и подсказывать: «ну вот например, заказ создан». После этого сессия становится его сессией, а люди дальше клеят то, что он одобрит. Опытный фасилитатор тут будет терпеливо ждать. 

На втором часу стена превратится в бардак: дубли, разный уровень детализации, события не в том порядке. Тянет навести порядок. Рано - беспорядок на этом этапе нормален, а преждевременная уборка выкидывает как раз те дубли, которые и есть расхождение в терминах.

Группа из инженеров через двадцать минут съезжает в проектирование: обсуждает таблицы, очереди, API. Возвращать обратно надо мягко и раз за разом. Это выматывает, и неопытный фасилитатор сдаётся примерно на третий раз.

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

Правило прошедшего времени 

Казалось бы, какая тут польза? Но сам принцип ES регламентирует это правило. «Заказ оплачен» и «нужно сделать оплату заказа» - разные типы высказываний. В первом случае мы обсуждаем было ли событие, в каком порядке. Во втором - это хотелка, которую человек будет защищать. Прошедшее время выталкивает разговор из плоскости «как надо» в плоскость «как есть», где побеждает тот, кто реально знает о порядке вещей, а не старается продавить свой интерес.

Розовые стикеры вместо спора

Главный инструмент фасилитатора. Спор начался - вешаем hotspot и идём дальше.
Это работает по двум причинам. Позиция человека зафиксирована, он не чувствует, что его продавили. И к моменту, когда до hotspot дойдут руки, на стене уже есть контекст, в котором спор часто разрешается сам.

Кого звать
Нужны люди, которые знают, как работает процесс. Не те, кто по должности должен знать.
Не менее важно то, чтобы в комнате не было людей, при которых остальные не будут говорить неудобное. Так ценность сессии падает вдвое. Но вообще, если такие люди есть, это важный повод поговорить про доверие в команде и вспомнить старика Ленсиони.

Тайминг

Чтобы вы понимали уровень нагрузки.

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

#eventstorming #процессы #разработка

Понавыдумывали себе процессов

Одно из основных возражений, которые я слышу, это: «У нас нет DDD, нам это не подходит».
Понимаю, откуда оно. Техника плотно проросла в DDD-сообществе, в статьях про неё сразу идут bounded contexts и агрегаты, а на конференциях её показывают люди, которые пришли туда с докладом про тактические паттерны. Но это заблуждение.

Что ES делает на самом деле

Он не моделирует домен, а вскрывает расхождения между тем, как люди думают о системе. DDD - это один из способов потом эти расхождения оформить: выделить контексты, договориться про ubiquitous language, нарезать границы. Если у вас монолит и вы не собираетесь его резать, ES всё равно покажет, где в этом монолите проходят настоящие швы. Знать про них полезно, даже если резать вы будете через два года или никогда.

ES работает и без DDD

- Разбор инцидента, который повторяется. Если система разрослась, а в команде никто не может на 100% уверенно аллоцировать корень проблемы, ES может помочь его найти. Раскладываем по стене реальную последовательность событий. Не то, как должно быть по документации, а как было на самом деле. Обычно выясняется, что участники разных команд держали в голове разные версии одного и того же процесса, и дырка была ровно на стыке.
- Наследство, в котором никто не разбирается целиком. На самом деле, схожий кейс с первым вариантом. Классика: систему писали N лет, авторы ушли, в команде каждый знает свой кусок. И тут стена стикеров - самый быстрый способ собрать эти куски вместе. Быстрее, чем читать код, и надёжнее, чем читать вики.
- Оценка большой доработки. Прежде чем оценивать, разложите процесс по событиям и отметьте, какие из них меняются. Часто оказывается, что «небольшая фича» задевает четыре команды. Так было и у меня, когда моя команда в легаси системах хотела внедрить новую механику монетизации. Короткое приключение на 20 минут в итоге задевало добрую часть системы, могло приводить к потерям и тд. Хорошо, что мы это выяснили ДО, а не после.

Связь с ценой владения

Не так давно я писал про четыре цены разработки - Build, Run, Change, Exit. ES бьёт по третьей и четвёртой.
Неправильно проведённая граница между сервисами не болит на этапе Build. Она болит потом - каждое изменение задевает несколько сервисов, каждый релиз требует координации, каждая попытка что-то вывести из эксплуатации упирается в чужие зависимости. День работы со стикерами против года распределённого монолита. Арифметика неприятная, но очевидная.

Значит ли это, что ES гарантирует правильные границы? Нет, не гарантирует. Он гарантирует только то, что разговор про границы произойдёт до написания кода, а не после.

Где ES не нужен

ES - дорогой процесс, который требует нескольких часов сосредоточенной работы команды. Если у вас команда из трёх человек, которая пилит несложную систему вместе с фаундером, который берет на себя роль продакта, то это ритуал ради ритуала. Проблема тут будет скорее не в понимании домена, а в гигиенических вещах: например, в отсутствии тестов или в чистоте постановки задач. ES их не вылечит, зато красиво замаскирует под «мы поработали над архитектурой».

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

#eventstorming #процессы #разработка

Event Storming

Еще до работы лидом я столкнулся с проблемой именования разных частей системы между разработкой и бизнесом. Например, думая о сущности «Заказ», я подразумевал процесс оформления покупки на сайте, а мои коллеги из отдела логистики - фактически отправляемую посылку. Те из вас, кто читал книжку про DDD от Вон Вернона, знаю, что есть понятие единого языка (ubiquitous language), которое строго определяет термины внутри ограниченного контекста. Но как прийти к нему так, чтобы все понимали, что не путаются в понятиях? 

Процесс, который может в этом помочь, я встретил намного позже, когда уже работал в Авито. Я познакомился с ним, когда мы разбирали проблемы в архитектуре одного из модулей. Надо было привести его в порядок, но даже разные команды называли одинаковыми именами разные вещи. Именно тогда я увидел подход, когда мы сидели в Miro, накидывали стикеры, зарубались над контекстами и определениями.

Немного истории

Саму технику Event Storming придумал Альберто Брандолини примерно в 2013 году. Он занимался архитектурным консалтингом и устал от того, что моделирование превращается в многодневное упражнение с UML, из которого половина участников выпадает на втором часу из-за обилия информации. Его идея была довольно простой - нужно убрать сложные инструменты, оставить стену, стикеры и людей. Но вовлекаться должны все, а не только архитектор, на которого все смотрят. По итогам получился наглядный командный воркшоп. На нём разработчики, аналитики и эксперты бизнеса вместе выстраивают на доске ключевые процессы системы в виде цепочки значимых событий - их роль выполняют стикеры. Этот метод не только помогает найти ошибки в процессах и спроектировать архитектуру до написания кода, но и выровнять понимание системы со всех участвующих сторон.

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

ES за три абзаца

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

Дальше события выстраиваются по времени слева направо. И вот тут начинается интересное, потому что порядок оказывается спорным. Люди спорят не про модель, они спорят про то, как реально работает бизнес.

Потом добавляются другие цвета: команды, акторы, внешние системы, политики. Немаловажно, что красными стикерами подсвечивают проблемы. Это места, где никто не знает ответа или где ответы противоречат друг другу.

Три уровня

Брандолини выделяет три формата, и их путают чаще всего:

1. Big Picture - вся система целиком, крупными мазками. Цель тут в выработке общей карты и обнаружении границ. Это то, что нужно на старте проекта или при разборе «почему у нас всё сломалось».

2. Process Modeling - один процесс подробно. Меньше людей, больше деталей.

3. Software Design - уже почти проектирование: агрегаты, команды, события. Тут остаются в основном инженеры.

На моей практике большинство провалов ES - это попытка провести Big Picture с целями Software Design. Собрали двадцать человек, включая маркетинг, и пытаемся определить границы агрегатов.

Что получается на выходе

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

Наша первая сессия не закончилась глобальным рефакторингом. Мы всего лишь нарисовали Big Picture и выровняли язык, но это уже существенно упростило общение, потому что мы перестали путаться в терминах! Дальше задача стояла гораздо сложнее. В продукте, где я работал, надо было привести в порядок микросервисы. Так начались долгие недели двух других типов ES.

А сколько раз у вас на проекте всплывало «а мы это по-другому понимали» - уже после того, как код написан?

#процессы #eventstorming #разработка

Вайб-наём

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

Сами по себе AI инструменты не несут вреда или пользы. Основную проблему здесь я вижу в том, что люди с обеих сторон перекладывают на них обязательство думать. И это уже не помощь, а лень, замаскированная под эффективность.

Глазами рекрутера

Теперь не надо вчитываться в CV. Скрининг резюме через LLM отсекает по ключевым словам, которых кандидат не написал, хотя опыт у него есть. Сильные профили без правильных формулировок отваливаются молча.

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

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

Глазами кандидата

С меня требуют? Ну ок. Привет, Клод! Резюме под каждую вакансию генерится за секунды и часто врет. Чаще всего по мелочи: натянутые метрики, чужие достижения, компетенции «на вырост». На собесе это вскрывается, но время уже потрачено. Сопроводительные - стена нейрослопа.

И главное - лайвкодинг. Я провожу достаточно собеседований, и уже не могу молчать. Тут AI ломает найм сильнее всего. Кандидат решает задачу не сам, а через второй экран или наушник. Ты собеседуешь не человека, а адаптер к модели. И бывает, что понимаешь это только когда он выходит на работу и не может воспроизвести то, что «решал» на интервью.

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

Лично я не запрещаю AI - это бессмысленно и лицемерно, сами будем этим пользоваться в работе. Вместо этого:

- прошу честно пошарить AI тулинг, если он нужен. Я также делал и для гугления - все запомнить нельзя задачу я придумываю каждый раз от искомой позиции. Готового решения в интернете нет, оно собирается из контекста системы
- прошу проговаривать ход мысли до кода, а не после на каждом шаге закидываю «а что если»
- меняю условие так, чтобы сгенеренное решение перестало подходить смотрю не на финальный код, а на то, как человек реагирует на сдвиг вводных.

AI тут не мешает. Кто мыслит, пользуется им как усилителем и все равно виден. Кто прячется за ним, ломается на первом же «а что если».

Более того, я разработал собственную мини платформу для лайв интервью, которая позволяет по открытым из браузера данным анализировать риск применения AI. Я не слежу за личными данными. Я просто смотрю, что человек делает на странице. Любой сайт собирает с человека больше информации. Так что в эту игру можно играть вдвоем.

Кстати, если сейчас тоже нанимаете, приходите - могу организовать доступ к платформе

Образ результата

AI в найме (и не только там) хорошо снимает рутину, а вот мышление ему отдавать не стоит. Рекрутеру можно подготовить черновик вакансии, который можно править под конкретную боль команды. Кандидату помощь в том, чтобы вычистить формулировки в резюме, которое он и так может защитить.

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

А вы как? Ловили у себя вайбкодеров на собеседовании? А нейровакансии доводилось видеть?

#найм #процессы #ai

Ретроспектива, которая смогла

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

Была у комментатора одна фраза: «Ретро - только чтобы обидчивым сделать миф, что их слышат». И в контексте неправильно построенного ретро автор прав. Если оно не приводит ни к одному изменению, команда делает единственный возможный вывод: их не слышат. А если толку нет, то зачем приносить проблемы и стараться?

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

Поговорили и забыли

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

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

Формат

Лично мне больше всего нравится формат ретро «Mad-Sad-Glad», с которым познакомился, начав работать в Авито. Доска для команды делится на три части

- Mad: то, что «бесит, аж печёт!». Здесь пишутся проблемы, которые не терпят отлагательств. Например, раскатка в прод стала занимать несколько часов вместо нескольких секунд.
- Sad: то, что плохо, но терпит. Сюда пишутся пробуксовки взаимодействия, неудобный инструментарий. Плохо, но все понимают, что на исправления нужно время.
- Glad: если писать только то, что бесит, скоро станет казаться, что другого и нет. Поэтому позитивные улучшения лучше сразу отмечать.

После обсуждения прогресса по взятым action item-ам мы переходим к доске. На mad и sad я выделяю минут 10 на накидывание стикеров, после чего минут 20-30 обсуждаем. И тут крайне важная фасилитация, чтобы обсуждение не превратилось в срач. Оставшееся время в таком же формате - про glad.

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

Action Items

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

Не менее важна и формулировка, по которой понятно, сделано или нет.

«Улучшить коммуникацию» - плохая формулировка, потому что она не говорит, как мы поймем, что коммуникация улучшилась. Хорошим вариантом тут будет «Описать правило коммуникации в ситуации Х и отслеживать его соблюдение в Q4 2026» - SMART тут отлично подходит.

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

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

Ведущий

Если ретро всегда ведёт лид, то решения лида на нём не обсуждаются никогда. Дело даже не в том, что люди боятся. Ведущий просто управляет повесткой, чаще всего сам того не замечая. Я стараюсь передавать эту роль по кругу, заодно команда учится фасилитации.

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

Фокус на проблемах

Разбираем мы проблемы системы, а не людей. Тут возвращается фундаментальная ошибка атрибуции из первого поста. «Вася не успел» - тупик, с этим ничего не сделаешь. «Задача ушла в работу без критериев приёмки, и это прошло мимо всех» - вот отсюда уже можно чинить.

Позитивная мотивация

Ретро только после провалов приучает команду, что это разбор полётов. Тогда на него приходят подготовленными в плохом смысле. Но после хорошего спринта вопрос «что здесь сработало и как это повторить» даёт не меньше, чем очередной разбор факапа.

Возвращаясь к комментарию. Ретро, где не проверяют прошлые действия, где нет владельцев и сроков, а ведёт его начальник, действительно не работает. 

Когда у вас последний раз проверяли на ретро, что из прошлого списка реально сделано?

#ретро #команда #обучение

Как ловить когнитивные искажения

В прошлом посте я разобрал живой пример: «у меня не работало, значит инструмент плохой». Теперь про то, как такие штуки замечать.

Наш мозг устроен так, что полностью от искажений не избавиться. Это не баг мышления, это его фича. Мозг экономит ресурсы и подсовывает готовые ответы. Задача не в том, чтобы отключить механизм, а в том, чтобы вовремя его подловить. Это как раз идея Канеманна о быстром и медленном мышлении.

Искажение почти всегда чувствуется как облегчение. Вывод, который делает тебя правым и снимает ответственность, будет первым подозреваемым. Если объяснение приятное, это не значит, что оно ложное. Но проверить стоит именно его.

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

Дальше можно применить технику «а что бы убедило меня в обратном?». Берёшь свой вывод и спрашиваешь: какие данные заставили бы меня передумать? Если ответ «никакие», то ты не проверяешь гипотезу, а защищаешь. Это самый быстрый способ поймать себя на confirmation bias, когда ты собираешь только подтверждения и не замечаешь опровержений.

Дальше стоит отделять «не сработало у меня» от «не работает». Первое - это факт про личный опыт. Второе - утверждение про все вокруг, и оно требует доказательств посерьёзнее одного прецедента. Каждый раз, когда собираешься сказать второе, спроси: у скольких ещё не сработало и почему?
Ищи тех, кто думает иначе. Если инструмент, который ты хоронишь, у кого-то работает, то это данные. Разница в контекстах между вами и таит ответ. Обычно она в том, как готовили, а не в самом инструменте.

С первого раза инструменты часто не взлетают. После одного захода часто появляются ошибки исполнения, которые искажают результат. Поэтому тут надо разбирать не результат, а решение. Кстати, для такого решения ретроспектива работает просто на «ура». Ведь можно спокойно разобраться по шагам, что пошло не так.

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

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

Ещё в своих командах я пользуюсь правилом «руководитель говорит последним». Я стараюсь не фреймить на решение, не схлопывать дискуссию. Сначала должны высказаться люди из команды.

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

Идеальной защиты нет. Есть привычка тормозить на удобных выводах и спрашивать: а я точно проверяю гипотезу, или уже подгоняю? Ни одна практика не убирает искажение. Они все делают одно - вставляют паузу между импульсом и выводом. Искажение живёт в скорости. Всё, что заставляет притормозить и проговорить логику вслух, работает против него.

Какой ваш последний вывод «это не работает» выдержал бы такую проверку?

#bias #обучение

Суббота. Время прыгнуть в машину и ехать навстречу новым впечатлениям!

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

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

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

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

#неформат