🧩 Зачем агенту изменений системное мышление?
Формулировка «системное мышление» поначалу может вводить в ступор. В голове сразу возникают образы чего-то сложного, а для кого-то и вовсе пугающего. Но не спешите с выводами, ведь #системное_мышление — это прежде всего прикладной навык. И при желании его можно освоить так же, как и навык вождения автомобиля или новый иностранный язык.
Системное мышление помогает агенту изменений лучше понять условия и ограничения, в которых он работает, а также сместить акцент с лечения симптомов на работу с корневыми причинами проблем. И в качестве примера сегодня я расскажу одну историю из своего опыта.
🦸 Спасти мир за 60 минут
За окном глубокая кипрская ночь, на часах три утра, а мой телефон на прикроватной тумбочке разрывается от безостановочной вибрации уведомлений. Кое-как проснувшись, я листаю ленту чата в Slack и понимаю: наш продукт снова «лёг» и недоступен для пользователей. Рабочий день в регионах, где сконцентрированы наши крупнейшие сегменты пользователей, начнётся уже через час, а мы до сих пор не можем понять, в чём причина неполадки. Единственное, что мы можем сделать сейчас, — это применить «костыль» и перезапустить деплой наших сервисов вручную. О чём я и прошу нашего DevOps-специалиста, разбудив его своим звонком. Продукт снова доступен, мир спасён и может спать спокойно. Точнее, просыпаться.
🕵️♂️ «Элементарно, Ватсон!»
Утро рабочего дня мы встречаем в забитой переговорке, где собрались ключевые эксперты из разных команд. Одни наперебой выдвигают свои гипотезы о причинах неполадки, другие целиком погрузились в экраны ноутбуков и увлечённо обсуждают аналитические графики и отдельные куски кода. Атмосфера в комнате напряжённая, но на первый взгляд кажется продуктивной.
Всё резко меняется спустя полчаса: выясняется, что причиной инцидента стал вчерашний релиз одной из команд. Вперемешку со здоровым сарказмом тут же начинают звучать откровенные претензии к представляющему её разработчику. Находясь в комнате, я решаю принять на себя роль спонтанного фасилитатора и пытаюсь обуздать происходящее.
Группа быстро договаривается копнуть глубже и изучить отчёт о релизе. Когда становится понятно, что команда принудительно пропустила часть автоматических тестов, комната взрывается. В этот раз даже самые сдержанные коллеги не скрывают своих эмоций. Кое-как успокоив группу, я задаю вопрос:
— Окей, теперь мы знаем, что инцидент случился из-за этого релиза. Почему это произошло?
— Ну всё же элементарно, Ватсон! — раздражённо ответил Миша, один из разработчиков. — Команда Clever решила показать, что они умнее всех, и скипанула часть тестов!
— Спасибо, Миша, это я понял. Но почему команда Clever решила «скипануть часть тестов»?
— …
🐄 Почему коровы не летают?
Как и подразумевает название, техника «Пять “почему?”» заключается в том, чтобы пять раз задавать вопрос «Почему?» и тем самым добраться до корневой причины проблемы. Именно в этом и заключалась моя цель. Неловкое молчание длилось недолго:
— Почему-почему… А почему коровы не летают? — первым отозвался всё тот же Миша. — Какое нам дело? Пусть сами разбираются со своими косяками!
— Вообще-то нам пришлось это сделать, — робко вмешался Костя, представитель той самой команды.
— ???
В течение следующего часа мы выяснили, что причиной поступка команды была отнюдь не халатность, а цепочка накопившихся системных проблем. Причём сталкивалась с ней хотя бы раз едва ли не каждая команда компании, но об этом никогда не говорили вслух. Стало очевидно, что недавняя попытка оптимизировать расходы на инфраструктуру ставила их перед сложным выбором: либо рисковать и выпускать не до конца проверенный продукт клиентам, либо затягивать простую, на первый взгляд, работу на несколько спринтов.
Так стандартная техника «Пять “почему?”» помогла нам докопаться до корневых причин инцидента, оказывавших влияние на всю организацию на системном уровне. В следующий раз я расскажу, как мы визуализировали эту причинно-следственную связь и принимали решение, что нам делать как организации.
Денис 💚
Формулировка «системное мышление» поначалу может вводить в ступор. В голове сразу возникают образы чего-то сложного, а для кого-то и вовсе пугающего. Но не спешите с выводами, ведь #системное_мышление — это прежде всего прикладной навык. И при желании его можно освоить так же, как и навык вождения автомобиля или новый иностранный язык.
Системное мышление помогает агенту изменений лучше понять условия и ограничения, в которых он работает, а также сместить акцент с лечения симптомов на работу с корневыми причинами проблем. И в качестве примера сегодня я расскажу одну историю из своего опыта.
🦸 Спасти мир за 60 минут
За окном глубокая кипрская ночь, на часах три утра, а мой телефон на прикроватной тумбочке разрывается от безостановочной вибрации уведомлений. Кое-как проснувшись, я листаю ленту чата в Slack и понимаю: наш продукт снова «лёг» и недоступен для пользователей. Рабочий день в регионах, где сконцентрированы наши крупнейшие сегменты пользователей, начнётся уже через час, а мы до сих пор не можем понять, в чём причина неполадки. Единственное, что мы можем сделать сейчас, — это применить «костыль» и перезапустить деплой наших сервисов вручную. О чём я и прошу нашего DevOps-специалиста, разбудив его своим звонком. Продукт снова доступен, мир спасён и может спать спокойно. Точнее, просыпаться.
🕵️♂️ «Элементарно, Ватсон!»
Утро рабочего дня мы встречаем в забитой переговорке, где собрались ключевые эксперты из разных команд. Одни наперебой выдвигают свои гипотезы о причинах неполадки, другие целиком погрузились в экраны ноутбуков и увлечённо обсуждают аналитические графики и отдельные куски кода. Атмосфера в комнате напряжённая, но на первый взгляд кажется продуктивной.
Всё резко меняется спустя полчаса: выясняется, что причиной инцидента стал вчерашний релиз одной из команд. Вперемешку со здоровым сарказмом тут же начинают звучать откровенные претензии к представляющему её разработчику. Находясь в комнате, я решаю принять на себя роль спонтанного фасилитатора и пытаюсь обуздать происходящее.
Группа быстро договаривается копнуть глубже и изучить отчёт о релизе. Когда становится понятно, что команда принудительно пропустила часть автоматических тестов, комната взрывается. В этот раз даже самые сдержанные коллеги не скрывают своих эмоций. Кое-как успокоив группу, я задаю вопрос:
— Окей, теперь мы знаем, что инцидент случился из-за этого релиза. Почему это произошло?
— Ну всё же элементарно, Ватсон! — раздражённо ответил Миша, один из разработчиков. — Команда Clever решила показать, что они умнее всех, и скипанула часть тестов!
— Спасибо, Миша, это я понял. Но почему команда Clever решила «скипануть часть тестов»?
— …
🐄 Почему коровы не летают?
Как и подразумевает название, техника «Пять “почему?”» заключается в том, чтобы пять раз задавать вопрос «Почему?» и тем самым добраться до корневой причины проблемы. Именно в этом и заключалась моя цель. Неловкое молчание длилось недолго:
— Почему-почему… А почему коровы не летают? — первым отозвался всё тот же Миша. — Какое нам дело? Пусть сами разбираются со своими косяками!
— Вообще-то нам пришлось это сделать, — робко вмешался Костя, представитель той самой команды.
— ???
В течение следующего часа мы выяснили, что причиной поступка команды была отнюдь не халатность, а цепочка накопившихся системных проблем. Причём сталкивалась с ней хотя бы раз едва ли не каждая команда компании, но об этом никогда не говорили вслух. Стало очевидно, что недавняя попытка оптимизировать расходы на инфраструктуру ставила их перед сложным выбором: либо рисковать и выпускать не до конца проверенный продукт клиентам, либо затягивать простую, на первый взгляд, работу на несколько спринтов.
Так стандартная техника «Пять “почему?”» помогла нам докопаться до корневых причин инцидента, оказывавших влияние на всю организацию на системном уровне. В следующий раз я расскажу, как мы визуализировали эту причинно-следственную связь и принимали решение, что нам делать как организации.
Денис 💚
🧩 Системное мышление на практике (часть 2)
🖼 Визуализируй это!
В прошлый раз мы познакомились с инструментом «Пять “почему?”», который помогает осуществить анализ корневых причин (root cause analysis) проблемы. Но поскольку #системное_мышление подразумевает работу со сложными, а порой и запутанными системами, возникающие в них проблемы часто вызваны целым набором факторов.
Одним из способов упростить понимание системы и сформировать единый контекст в группе является визуализация. С использованием таких инструментов, как диаграммы и блок-схемы, мы можем отобразить работу системы, как мы её понимаем, и затем уже перейти к поиску решений. К их числу относится диаграмма Исикавы, или fishbone-диаграмма. #техника
🤷♂️ На этом наши полномочия всё!
Группа стояла перед доской, где была изображена схема, напоминающая скелет рыбы. Возле каждой из «костей» были выписаны проблемы, заставившие команду пожертвовать частью тестов ради релиза. Венчала эту конструкцию системная проблема, на которую сместился наш фокус в ходе обсуждения инцидента: «Команды скипают часть тестов, чтобы успеть в релизное окно».
— Окей, вроде теперь картина проясняется, — сказал Миша, сменивший гнев на милость и активно включившийся в работу. — Давайте решим, что с этим дальше делать!
— На какие из этих причин мы можем влиять на уровне команд? — спросил я.
— Мы можем прикинуть критический путь, чтобы сократить время прогона тестов, — предложил Костя. — Но это вряд ли сильно поможет: тесты-то всё равно кривые. Остальное вне нашей власти. На этом наши полномочия всё!
— Окей, а как быть с остальным? — не отставал я.
— Решить это можно только уже с Виктором.
Виктора, СТО компании, ребята побаивались, несмотря на его добрый нрав и открытость. Желанием общаться с ним напрямую, особенно после инцидента, никто не горел. Но упускать удачный момент для обсуждения проблемы не хотелось. Я предложил группе сделать небольшой перерыв, а сам отправился в дальний угол опенспейса, к столу СТО. К моему счастью, у Виктора как раз отменилось интервью и он был на месте.
🐟 Хороший улов!
— Виктор, привет! — поздоровался я. — Мы тут с ребятами обсуждаем ночной инцидент. Найдёшь полчаса к нам присоединиться?
— Привет-привет! А что, надо кого-то уволить? — Виктор вопрошающе поднял бровь, но тут же улыбнулся: — Шучу. Ну давай попробуем.
…
— Ого, какая большая рыба! Хороший улов! — воскликнул он, зайдя в комнату. — Давайте, рассказывайте, что у вас тут происходит.
— Привет! В общем, мы с ребятами проанализировали ночной инцидент и поняли, что причина была во вчерашнем релизе clever’ов, — начал Костя. — Но затем Денис предложил нам копнуть глубже, и в итоге мы пришли к следующему списку причин.
Забегая вперёд, скажу, что провести с нами в комнате Виктору пришлось больше обещанного получаса. Но оно того стоило. Пройдясь с ним по нашей «рыбе» и ответив на его вопросы, мы перешли к брейншторму возможных решений.
В итоге мы смогли сформировать план действий, реализовать который без его участия было бы невозможно. Но это уже совсем другая история…
💊 Лекарство может быть хуже болезни
Если scrum-команда постоянно не достигает своих целей, системный мыслитель предложит рассмотреть систему целиком, чтобы идентифицировать корневую причину. Возможно, команда не справляется с оценкой своей работы или не управляет зависимостями должным образом. Но в некоторых случаях причина проблемы может лежать далеко за пределами команды.
Именно так было в случае с неудачным релизом команды Clever. Хотя сам инцидент произошёл из-за проблемы технического характера, вызвавшие её причины не могли быть решены на уровне отдельно взятой команды. Инструменты системного мышления, такие как диаграмма Исикавы, помогают выявить глубинные причины происходящего и сфокусироваться на самом важном.
Лишь определив причину болезни, агенты изменений и лидеры могут предложить устойчивые решения, которые улучшат всю систему, будь то отдельная команда, отдел или вся организация, а не просто устранят симптомы.
Ведь порой лекарство может быть хуже болезни.
Денис 💚
🖼 Визуализируй это!
В прошлый раз мы познакомились с инструментом «Пять “почему?”», который помогает осуществить анализ корневых причин (root cause analysis) проблемы. Но поскольку #системное_мышление подразумевает работу со сложными, а порой и запутанными системами, возникающие в них проблемы часто вызваны целым набором факторов.
Одним из способов упростить понимание системы и сформировать единый контекст в группе является визуализация. С использованием таких инструментов, как диаграммы и блок-схемы, мы можем отобразить работу системы, как мы её понимаем, и затем уже перейти к поиску решений. К их числу относится диаграмма Исикавы, или fishbone-диаграмма. #техника
🤷♂️ На этом наши полномочия всё!
Группа стояла перед доской, где была изображена схема, напоминающая скелет рыбы. Возле каждой из «костей» были выписаны проблемы, заставившие команду пожертвовать частью тестов ради релиза. Венчала эту конструкцию системная проблема, на которую сместился наш фокус в ходе обсуждения инцидента: «Команды скипают часть тестов, чтобы успеть в релизное окно».
— Окей, вроде теперь картина проясняется, — сказал Миша, сменивший гнев на милость и активно включившийся в работу. — Давайте решим, что с этим дальше делать!
— На какие из этих причин мы можем влиять на уровне команд? — спросил я.
— Мы можем прикинуть критический путь, чтобы сократить время прогона тестов, — предложил Костя. — Но это вряд ли сильно поможет: тесты-то всё равно кривые. Остальное вне нашей власти. На этом наши полномочия всё!
— Окей, а как быть с остальным? — не отставал я.
— Решить это можно только уже с Виктором.
Виктора, СТО компании, ребята побаивались, несмотря на его добрый нрав и открытость. Желанием общаться с ним напрямую, особенно после инцидента, никто не горел. Но упускать удачный момент для обсуждения проблемы не хотелось. Я предложил группе сделать небольшой перерыв, а сам отправился в дальний угол опенспейса, к столу СТО. К моему счастью, у Виктора как раз отменилось интервью и он был на месте.
🐟 Хороший улов!
— Виктор, привет! — поздоровался я. — Мы тут с ребятами обсуждаем ночной инцидент. Найдёшь полчаса к нам присоединиться?
— Привет-привет! А что, надо кого-то уволить? — Виктор вопрошающе поднял бровь, но тут же улыбнулся: — Шучу. Ну давай попробуем.
…
— Ого, какая большая рыба! Хороший улов! — воскликнул он, зайдя в комнату. — Давайте, рассказывайте, что у вас тут происходит.
— Привет! В общем, мы с ребятами проанализировали ночной инцидент и поняли, что причина была во вчерашнем релизе clever’ов, — начал Костя. — Но затем Денис предложил нам копнуть глубже, и в итоге мы пришли к следующему списку причин.
Забегая вперёд, скажу, что провести с нами в комнате Виктору пришлось больше обещанного получаса. Но оно того стоило. Пройдясь с ним по нашей «рыбе» и ответив на его вопросы, мы перешли к брейншторму возможных решений.
В итоге мы смогли сформировать план действий, реализовать который без его участия было бы невозможно. Но это уже совсем другая история…
💊 Лекарство может быть хуже болезни
Если scrum-команда постоянно не достигает своих целей, системный мыслитель предложит рассмотреть систему целиком, чтобы идентифицировать корневую причину. Возможно, команда не справляется с оценкой своей работы или не управляет зависимостями должным образом. Но в некоторых случаях причина проблемы может лежать далеко за пределами команды.
Именно так было в случае с неудачным релизом команды Clever. Хотя сам инцидент произошёл из-за проблемы технического характера, вызвавшие её причины не могли быть решены на уровне отдельно взятой команды. Инструменты системного мышления, такие как диаграмма Исикавы, помогают выявить глубинные причины происходящего и сфокусироваться на самом важном.
Лишь определив причину болезни, агенты изменений и лидеры могут предложить устойчивые решения, которые улучшат всю систему, будь то отдельная команда, отдел или вся организация, а не просто устранят симптомы.
Ведь порой лекарство может быть хуже болезни.
Денис 💚
В прошлых постах про #системное_мышление мы уже поговорили об инструментах, позволяющих произвести анализ причин конкретной проблемы. Но что делать, если проблема, с которой мы столкнулись, оказывается более сложной и запутанной? Что, если она возникает вновь и вновь? В такой ситуации мы можем говорить уже об определённом паттерне поведения и нашей целью становится анализ его причин.
🦔 День сурка
— Мы не можем работать в таких условиях — задачи приходят к нам не готовыми для разработки! — упорно твердил голос Миши из динамика.
— Да как так-то?! — воскликнул Симон, находившийся в одной комнате со мной. — Ахмет и так пихает в описание тикетов всё подряд! Если он будет прописывать там ещё больше деталей, то зачем нужны мы?
Шёл второй час общей ретроспективы с представителями команд. Я ощущал себя героем фильма «День сурка»: тема бэклога поднималась каждые два-три спринта, и достичь консенсуса с каждым разом становилось всё сложнее. Миша был негласным лидом аутсорс-команды из Кракова, а Симон — разработчиком в нашем берлинском офисе.
— Михаил, мы уже три раза пересматривали наш Definition of Ready, — включился Ахмет, владелец продукта. — Я трачу больше половины своего времени на описание тикетов, вместо того чтобы общаться с клиентами и заниматься стратегией!
— Ахмет, да не вопрос. Просто не надо потом обвинять нас, что мы неверно оценили размер задач и не смогли сделать всё за спринт! — отрезал Миша.
— Миша, спокойно, никто никого не обвиняет. Мы пытаемся найти тот уровень детализации, с которым будет комфортно всем сторонам, — вставил я, стремясь вернуть обсуждение в конструктивное русло.
☕️ Разговор за кофе
— Симон увольняется, — как бы между делом бросил Фридрих, наш CTО, пока мы стояли в очереди за кофе. — Говорит, не видит смысла работать в условиях, когда всё решается без участия команды.
Я невольно вздохнул. Это был уже третий подобный случай за восемь месяцев. Мы продолжали терять ребят, которые закладывали фундамент нашего продукта.
— Что думаешь делать? Снова затыкать дыры аутсорсом? — спросил я.
— А что ещё остаётся? Клиенты уже видели роадмап. Хотя инвесторы явно не обрадуются — эти ребята дорого нам обходятся...
Я снова вздохнул. Каждый раз, теряя кого-то из команды, мы добавляли людей на аутсорсе. В итоге Ахмет и берлинские ребята оставались в меньшинстве, а бэклог обрастал всё большим количеством деталей.
— Давай попробуем проанализировать эту проблему системно, — предложил я.
🛠 Петли и рычаги
Мы стояли перед диаграммой причинно-следственных циклов (CLD), описывающей взаимосвязь качества нашего бэклога и проблемы с увольнениями. Из неё исходило, что наше стремление как можно быстрее закрывать пробелы в штате аутсорсом создавало усиливающую петлю, которая только усугубляла ситуацию с мотивацией оставшихся сотрудников. Ведь чем больше разработчиков со стороны мы привлекали, тем больше было давление на владельца продукта с их стороны.
— Кто бы мог подумать, что эти две проблемы связаны между собой! — озадаченно протянул Фридрих.
Из модели мы поняли, что рычагами, которыми мы сможем повлиять на ситуацию, являются наш Definition of Ready и политика комплектования продуктовой группы. В результате мы решили откатиться к версии DoR, составлявшейся до подключения внешних специалистов. В долгосрочной же перспективе нам следовало зафиксировать идеальное соотношение in-house- и outsource-специалистов и постепенно снижать долю последних в нашей продуктовой группе.
Использовать данный инструмент можно не только к проблемам на уровне всей организации. Например, чтобы проанализировать повторяющиеся паттерны в жизни вашей команды на ретроспективе.
Денис 💚
🦔 День сурка
— Мы не можем работать в таких условиях — задачи приходят к нам не готовыми для разработки! — упорно твердил голос Миши из динамика.
— Да как так-то?! — воскликнул Симон, находившийся в одной комнате со мной. — Ахмет и так пихает в описание тикетов всё подряд! Если он будет прописывать там ещё больше деталей, то зачем нужны мы?
Шёл второй час общей ретроспективы с представителями команд. Я ощущал себя героем фильма «День сурка»: тема бэклога поднималась каждые два-три спринта, и достичь консенсуса с каждым разом становилось всё сложнее. Миша был негласным лидом аутсорс-команды из Кракова, а Симон — разработчиком в нашем берлинском офисе.
— Михаил, мы уже три раза пересматривали наш Definition of Ready, — включился Ахмет, владелец продукта. — Я трачу больше половины своего времени на описание тикетов, вместо того чтобы общаться с клиентами и заниматься стратегией!
— Ахмет, да не вопрос. Просто не надо потом обвинять нас, что мы неверно оценили размер задач и не смогли сделать всё за спринт! — отрезал Миша.
— Миша, спокойно, никто никого не обвиняет. Мы пытаемся найти тот уровень детализации, с которым будет комфортно всем сторонам, — вставил я, стремясь вернуть обсуждение в конструктивное русло.
☕️ Разговор за кофе
— Симон увольняется, — как бы между делом бросил Фридрих, наш CTО, пока мы стояли в очереди за кофе. — Говорит, не видит смысла работать в условиях, когда всё решается без участия команды.
Я невольно вздохнул. Это был уже третий подобный случай за восемь месяцев. Мы продолжали терять ребят, которые закладывали фундамент нашего продукта.
— Что думаешь делать? Снова затыкать дыры аутсорсом? — спросил я.
— А что ещё остаётся? Клиенты уже видели роадмап. Хотя инвесторы явно не обрадуются — эти ребята дорого нам обходятся...
Я снова вздохнул. Каждый раз, теряя кого-то из команды, мы добавляли людей на аутсорсе. В итоге Ахмет и берлинские ребята оставались в меньшинстве, а бэклог обрастал всё большим количеством деталей.
— Давай попробуем проанализировать эту проблему системно, — предложил я.
🛠 Петли и рычаги
Мы стояли перед диаграммой причинно-следственных циклов (CLD), описывающей взаимосвязь качества нашего бэклога и проблемы с увольнениями. Из неё исходило, что наше стремление как можно быстрее закрывать пробелы в штате аутсорсом создавало усиливающую петлю, которая только усугубляла ситуацию с мотивацией оставшихся сотрудников. Ведь чем больше разработчиков со стороны мы привлекали, тем больше было давление на владельца продукта с их стороны.
— Кто бы мог подумать, что эти две проблемы связаны между собой! — озадаченно протянул Фридрих.
Из модели мы поняли, что рычагами, которыми мы сможем повлиять на ситуацию, являются наш Definition of Ready и политика комплектования продуктовой группы. В результате мы решили откатиться к версии DoR, составлявшейся до подключения внешних специалистов. В долгосрочной же перспективе нам следовало зафиксировать идеальное соотношение in-house- и outsource-специалистов и постепенно снижать долю последних в нашей продуктовой группе.
Использовать данный инструмент можно не только к проблемам на уровне всей организации. Например, чтобы проанализировать повторяющиеся паттерны в жизни вашей команды на ретроспективе.
Денис 💚
🤔 «Как мне объяснить в компании, что и зачем я делаю?»
Я не раз сталкивалась с этим запросом от моих менти и коллег скрам-мастеров.
🗣 Дебаты о том, как оценить работу скрам-мастера и понять, что он делает нефигню, ведутся уже очень давно в профильных чатах и комьюнити, на конференциях и митапах.
Потребность оценить, что и зачем делает агент изменений, связана с непрозрачностью причин изменений, которые он запускает. Гораздо проще, если видна прямая связь: вот проблема, а вот очевидное решение этой проблемы. Но чаще скрам-мастера внедряют изменения, которые играют вдолгую, и причины этого внедрения не сразу очевидны команде или менеджменту.
🔥 Ещё не пожар, ещё не горит, так зачем мы это делаем?
Тут мне на выручку приходит Causal Loop Diagram (CLD) — инструмент системного мышления.
Вообще CLD — это инструмент групповой работы, и его лучше использовать всей командой. Но также я использую CLD, чтобы объяснять логику своих решений.
🧩 Вот один из кейсов, которые мы сейчас разбираем с моим менти:
Его команда некоторое время назад перешла на канбан-метод, чтобы обеспечить себе предсказуемость поставки и нужную скорость выпуска задач. Провели STATIK, собрали доску, выбрали каденцию пополнения, договорились о WIP-лимитах, а предсказуемости как не было, так и нет 😕 Если смотреть на диаграмму распределения времени, то она пугает колоссальным разбросом срока выполнения — до 30 недель.
Несмотря на то что договорённость по WIP-лимитам есть, каждый раз на встрече по пополнению мой менти сталкивается с сопротивлением команды.
🤷♂️ Почему так важно брать одно и то же количество задач?
Как можно грамотно аргументировать и объяснить команде своё решение?
Я в таких случаях рисую CLD!
Вот как я бы объясняла команде ход своих мыслей:
Чем больше разброс в количестве задач, которые мы берём в работу, тем ниже консистентность данных. Чем она ниже, тем меньше точность статистики. Чем ниже точность статистики, тем меньше предсказуемость. А чем она ниже, тем больше тревожность бизнеса. Чем больше тревожность бизнеса, тем ниже его удовлетворённость. Ну а чем менее удовлетворён бизнес, тем меньше мотивация команды поддерживать одинаковое пополнение и тем меньше вероятность, что команда будет брать в работу каждый раз одно и то же количество задач.
👀 Как эта диаграмма выглядит, вы можете посмотреть на картинке внизу.
🖍 Как именно я создавала диаграмму?
1️⃣ Сначала выписала максимум понятных мне элементов системы, или переменных: предсказуемость поставки, стабильность количества задач, точность статистики, удовлетворённость бизнеса и так далее.
2️⃣ Потом проставила связи между этими переменными.
Важно помнить, что и переменные, и связи — нейтральные, их нейтральность помогает правильно читать CLD и видеть именно систему, а не набор случайно связанных друг с другом единичных событий.
3️⃣ Дальше я проверила, что CLD читается правильно и логично и действительно образует замкнутую систему. Для этого прочитала диаграмму сначала с условием, что команда пополняет систему каждый раз на одно и то же количество задач, а потом ещё раз перечитала при условии, что команда пополняет систему каждый раз по-разному.
4️⃣ Последним шагом я рассказываю команде эту логику на совместной встрече и отрабатываю возражения. Это я и предложила проделать моему менти.
Для того чтобы ваша логика была понятна команде и менеджменту, можно использовать и другие способы аргументации, но мне неизменно помогает Causal Loop Diagram. Этот инструмент помогает поднимать прозрачность и повышает осознанность команды.
#системное_мышление
Наташа 💫
Я не раз сталкивалась с этим запросом от моих менти и коллег скрам-мастеров.
🗣 Дебаты о том, как оценить работу скрам-мастера и понять, что он делает нефигню, ведутся уже очень давно в профильных чатах и комьюнити, на конференциях и митапах.
Потребность оценить, что и зачем делает агент изменений, связана с непрозрачностью причин изменений, которые он запускает. Гораздо проще, если видна прямая связь: вот проблема, а вот очевидное решение этой проблемы. Но чаще скрам-мастера внедряют изменения, которые играют вдолгую, и причины этого внедрения не сразу очевидны команде или менеджменту.
🔥 Ещё не пожар, ещё не горит, так зачем мы это делаем?
Тут мне на выручку приходит Causal Loop Diagram (CLD) — инструмент системного мышления.
Вообще CLD — это инструмент групповой работы, и его лучше использовать всей командой. Но также я использую CLD, чтобы объяснять логику своих решений.
🧩 Вот один из кейсов, которые мы сейчас разбираем с моим менти:
Его команда некоторое время назад перешла на канбан-метод, чтобы обеспечить себе предсказуемость поставки и нужную скорость выпуска задач. Провели STATIK, собрали доску, выбрали каденцию пополнения, договорились о WIP-лимитах, а предсказуемости как не было, так и нет 😕 Если смотреть на диаграмму распределения времени, то она пугает колоссальным разбросом срока выполнения — до 30 недель.
Несмотря на то что договорённость по WIP-лимитам есть, каждый раз на встрече по пополнению мой менти сталкивается с сопротивлением команды.
🤷♂️ Почему так важно брать одно и то же количество задач?
Как можно грамотно аргументировать и объяснить команде своё решение?
Я в таких случаях рисую CLD!
Вот как я бы объясняла команде ход своих мыслей:
Чем больше разброс в количестве задач, которые мы берём в работу, тем ниже консистентность данных. Чем она ниже, тем меньше точность статистики. Чем ниже точность статистики, тем меньше предсказуемость. А чем она ниже, тем больше тревожность бизнеса. Чем больше тревожность бизнеса, тем ниже его удовлетворённость. Ну а чем менее удовлетворён бизнес, тем меньше мотивация команды поддерживать одинаковое пополнение и тем меньше вероятность, что команда будет брать в работу каждый раз одно и то же количество задач.
👀 Как эта диаграмма выглядит, вы можете посмотреть на картинке внизу.
🖍 Как именно я создавала диаграмму?
1️⃣ Сначала выписала максимум понятных мне элементов системы, или переменных: предсказуемость поставки, стабильность количества задач, точность статистики, удовлетворённость бизнеса и так далее.
2️⃣ Потом проставила связи между этими переменными.
Важно помнить, что и переменные, и связи — нейтральные, их нейтральность помогает правильно читать CLD и видеть именно систему, а не набор случайно связанных друг с другом единичных событий.
3️⃣ Дальше я проверила, что CLD читается правильно и логично и действительно образует замкнутую систему. Для этого прочитала диаграмму сначала с условием, что команда пополняет систему каждый раз на одно и то же количество задач, а потом ещё раз перечитала при условии, что команда пополняет систему каждый раз по-разному.
4️⃣ Последним шагом я рассказываю команде эту логику на совместной встрече и отрабатываю возражения. Это я и предложила проделать моему менти.
Для того чтобы ваша логика была понятна команде и менеджменту, можно использовать и другие способы аргументации, но мне неизменно помогает Causal Loop Diagram. Этот инструмент помогает поднимать прозрачность и повышает осознанность команды.
#системное_мышление
Наташа 💫
🚀 Атмосфера стартапа
«Привет! Есть время созвониться?» — гласило всплывающее сообщение в углу экрана. Оно было от Лёши — разработчика, одновременно выполнявшего роль менеджера команды. Мы вместе работали в департаменте, где пилотировались идеи новых продуктов. «Да, не вопрос», — быстро ответил я и сразу же получил ссылку на Zoom.
— Ден, привет! — поздоровался как всегда воодушевлённый голос. — Есть одна тема, хотел обсудить с тобой и послушать твоё мнение.
Поблагодарив его за доверие, я постарался заглушить посторонние мысли в своей голове и сфокусироваться на разговоре.
— Понимаешь, такое дело, — начал он. — Ты, наверное, знаешь, что часть ребят недовольны последним перформанс-ревью. Не все получили повышение зарплаты, а промоушенов не было совсем.
— Да, слышал от ребят.
— Так вот, мы же тут запускаем «корабли в космос»… Мне кажется, я знаю, как дополнительно замотивировать ребят!
Мне хотелось узнать больше про его предложение:
— Слушай, круто, что ты думаешь об этом. А как именно?
— Ну смотри: у нас же тут атмосфера стартапа, все дела, — увлечённо продолжил он. — Почему бы нам не фиксировать долю от прибыли, на которую мог бы претендовать каждый из ребят в случае успеха?
Пока всё выглядело стройно, но меня не покидало ощущение, что Лёша видит ситуацию не до конца.
— А напомни, сколько у нас человек работают над этими продуктами? — спросил я.
— Около пятнадцати.
— А сколько всего разработчиков у нас в организации?
— Ну, где-то 350, — ответил Лёша после небольшой паузы.
— Как ты думаешь, как такую идею воспримут те 330 разработчиков, которым не повезло попасть в наш департамент?
— Ну-у-у… Думаю, что у них могут возникнуть вопросы, почему кто-то работает только за зарплату, а кому-то ещё и приплачивают… — протянул резко погрустневший Лёша. — Наверное, стоит ещё докрутить эту идею...
— Да, мне тоже так кажется. Хотя сама идея классная!
На этом мы разошлись. Но я ещё не раз мысленно возвращался к нашей беседе.
🔧 Локальная оптимизация
#Системное_мышление называет подобные ловушки локальной оптимизацией. Очень часто, когда мы приходим в организацию, в структуре и процессах которой невооружённым взглядом видно множество потерь и неэффективностей, они являются следствием накопительного эффекта подобных решений.
Часто причиной локальной оптимизации является чрезмерная фиксация на своей части системы. Это туннельное видение может быть продиктовано организационной структурой. Конечно, далеко не всегда последствия какого-то решения будут носить такой глобальный эффект. Также важно отметить, что в большинстве случаев подобные решения принимаются из самых добрых побуждений и призваны решить проблему, возникшую в какой-то из частей организации. Как и было в случае Лёши.
🔍 Польза от агента изменений
Способность подняться на несколько уровней выше в понимании окружающей среды требует не только навыка, но и привычки. Ожидать этого от всех по умолчанию было бы заблуждением. Именно поэтому от агента изменений часто требуется способность помочь окружающим разглядеть подобные риски под увеличительным стеклом.
Справиться с этой задачей поможет ряд контрольных вопросов.
Например:
— Какую проблему мы решаем?
— Как мы поймём, что это работает?
— Какие метрики могут нам помочь отследить улучшения?
— На кого ещё повлияет это решение/изменение?
— В чём именно может проявиться это влияние?
— К чему это может привести через N недель/месяцев/лет?
— Как мы можем снизить эти риски?
— Насколько эти риски оправданны?
Такие вопросы призваны снизить риски локальной оптимизации. В крайнем случае сделать её очевидной для всех, чтобы принятое решение было максимально осознанным.
Денис 💚
«Привет! Есть время созвониться?» — гласило всплывающее сообщение в углу экрана. Оно было от Лёши — разработчика, одновременно выполнявшего роль менеджера команды. Мы вместе работали в департаменте, где пилотировались идеи новых продуктов. «Да, не вопрос», — быстро ответил я и сразу же получил ссылку на Zoom.
— Ден, привет! — поздоровался как всегда воодушевлённый голос. — Есть одна тема, хотел обсудить с тобой и послушать твоё мнение.
Поблагодарив его за доверие, я постарался заглушить посторонние мысли в своей голове и сфокусироваться на разговоре.
— Понимаешь, такое дело, — начал он. — Ты, наверное, знаешь, что часть ребят недовольны последним перформанс-ревью. Не все получили повышение зарплаты, а промоушенов не было совсем.
— Да, слышал от ребят.
— Так вот, мы же тут запускаем «корабли в космос»… Мне кажется, я знаю, как дополнительно замотивировать ребят!
Мне хотелось узнать больше про его предложение:
— Слушай, круто, что ты думаешь об этом. А как именно?
— Ну смотри: у нас же тут атмосфера стартапа, все дела, — увлечённо продолжил он. — Почему бы нам не фиксировать долю от прибыли, на которую мог бы претендовать каждый из ребят в случае успеха?
Пока всё выглядело стройно, но меня не покидало ощущение, что Лёша видит ситуацию не до конца.
— А напомни, сколько у нас человек работают над этими продуктами? — спросил я.
— Около пятнадцати.
— А сколько всего разработчиков у нас в организации?
— Ну, где-то 350, — ответил Лёша после небольшой паузы.
— Как ты думаешь, как такую идею воспримут те 330 разработчиков, которым не повезло попасть в наш департамент?
— Ну-у-у… Думаю, что у них могут возникнуть вопросы, почему кто-то работает только за зарплату, а кому-то ещё и приплачивают… — протянул резко погрустневший Лёша. — Наверное, стоит ещё докрутить эту идею...
— Да, мне тоже так кажется. Хотя сама идея классная!
На этом мы разошлись. Но я ещё не раз мысленно возвращался к нашей беседе.
🔧 Локальная оптимизация
#Системное_мышление называет подобные ловушки локальной оптимизацией. Очень часто, когда мы приходим в организацию, в структуре и процессах которой невооружённым взглядом видно множество потерь и неэффективностей, они являются следствием накопительного эффекта подобных решений.
Часто причиной локальной оптимизации является чрезмерная фиксация на своей части системы. Это туннельное видение может быть продиктовано организационной структурой. Конечно, далеко не всегда последствия какого-то решения будут носить такой глобальный эффект. Также важно отметить, что в большинстве случаев подобные решения принимаются из самых добрых побуждений и призваны решить проблему, возникшую в какой-то из частей организации. Как и было в случае Лёши.
🔍 Польза от агента изменений
Способность подняться на несколько уровней выше в понимании окружающей среды требует не только навыка, но и привычки. Ожидать этого от всех по умолчанию было бы заблуждением. Именно поэтому от агента изменений часто требуется способность помочь окружающим разглядеть подобные риски под увеличительным стеклом.
Справиться с этой задачей поможет ряд контрольных вопросов.
Например:
— Какую проблему мы решаем?
— Как мы поймём, что это работает?
— Какие метрики могут нам помочь отследить улучшения?
— На кого ещё повлияет это решение/изменение?
— В чём именно может проявиться это влияние?
— К чему это может привести через N недель/месяцев/лет?
— Как мы можем снизить эти риски?
— Насколько эти риски оправданны?
Такие вопросы призваны снизить риски локальной оптимизации. В крайнем случае сделать её очевидной для всех, чтобы принятое решение было максимально осознанным.
Денис 💚