Данные в ДейSTвии

Работа над 3й частью статьи кипит! Так много хочется рассказать, что порой приходится себя останавливать, чтобы случайно не написать производственный роман 😂 #анонс

🔥 Спасибо всем кто поучаствовал в опросе! 🎓Наибольшее количество голосов ( 50% ) было отдано за вариант ответа "Подтвердить каждый пункт презентации данными" - и это кажется очень логичным. Особенно в контексте нашего канала, и тем на которые я пишу. 🤷Но представьте себе такую ситуацию: вы видите по телевизору сюжет в котором показывают графики статистики и говорят: "Инфляция уменьшилась до рекордных 4%! Товары подешевели, жить стало лучше, жить стало веселее!" - а вы смотрите и не верите. Потому что в ближайшем продуктовом магазине день за днем дорожают продукты. Пресловутая гречка подорожала опять, овощи, фрукты.... И вы не узнаете в это сюжете себя и свою ситуацию 👉А в интернете объясняют, что инфляция бывает разной. Есть общая по стране по всем товарам - и она как раз составляет 4%, потому что данные берутся по широкой номенклатуре товаров и скачки сглаживаются. А есть продуктовая инфляция - только на товары питания, и она как раз растет и скачет. И приводят графики скачков цен на гречку, овощи, фрукты по месяцам. 👍И тут у вас паззл сходится: вы узнаете себя и свою ситуацию. И вам, может быть, не так уж важны точность цифр, главное, что все выглядит узнаваемо, и совпадает с вашим личным опытом. То же самое происходит и во время презентации результатов аудита заказчикам. Вы можете приводить сколь угодно точные цифры, но если слушатели не узнают себя и свою ситуацию в вашей презентации - цифры их не убедят. 👊 Это, кстати, является причиной многих конфликтов между бизнесом и IT. IT-шные люди более "цифровые", и часто приводят в качестве аргументов какие-то метрики, цифры, показатели, но бизнес эти цифры не убеждают, потому что они не "бьются" с их реальностью, которую они наблюдают каждый день. 👉Например, у одного клиента, была схожая ситуация, когда IT считал, что он работает четко и быстро, а бизнес постоянно жаловался, что IT работает долго и непредсказуемо. При этом, IT постоянно приводил в качестве аргумента, результаты трекинга времени разработчика - заполненные timesheet'ы, которые показывали, что максимальное время, которое тратится на разработку - 36 часов. Но бизнес эти данные никак не убеждали, потому что не совпадали с наблюдаемой ими реальностью. 👊А так как не было других доступных систем сбора метрик, на основе которых можно было бы перепроверить цифры ITшников, то конфликт был обречен на бесконечное повторение: бизнес жаловался, что IT долго работает, IT в ответ предъявлял свою статистику по учту времени, бизнесу крыть было нечем, но эта статистика их не убеждала. В итоге бизнес на время умолкал, копя обиды, но через некоторое время конфликт разгорался вновь и все повторялось. 👉Разрешился конфликт только когда в ходе аудита, который я проводил, удалось обнаружить самописную систему учета времени, которую вел руководитель одного из IT-отделов, и из нее удалось вытащить данные о датах начала разработки и дате приемки работы заказчиком. И это время было значительно дольше, чем время зафиксированное разработчиками в timesheet'ах. Ведь то, что фиксировали разработчики в timesheet - это чистое время потраченное на разработку, без задержек, ожиданий и прочего. А бизнес видел совсем другое время - от момента когда заявка пошла в разработку, до момента приемки задачи - со всеми ожиданиями, согласованиями, возвратами на доработку и так далее. 🎓Я показал обеим сторонам эту статистику, и обе стороны узнали в этом свою ситуацию, и согласились, что эта статистика отражает реальное положение дел. IT наконец-то понял причину недовольства бизнеса. А бизнес согласился с тем, что в задержках виноват не только IT, но и промедление бизнеса на этапах приемки, согласования, формулирования требований и так далее. 🤌Так что, когда готовите презентацию для заказчика, убедитесь, что хорошо понимаете их ситуацию, и попробуйте посмотреть на нее глазами заказчика, чтобы сформулировать ваш рассказ так, чтобы заказчик узнал в ней себя и свою ситуацию. Иначе вы получите в ответ только скепсис, недоверие и обиду, что вы "потратили столько времени, и рассказываете то, что к нам не относится" #ответ

Коллеги, с 3й частью немного дольше получилось. Потерпите. В ней я расскажу как презентовать результаты аудита заказчикам. А пока, для разогрева, небольшой опрос, чтобы я лучше статью подготовил #анонс

Продолжаем погружение в аудит рабочих процессов. Во второй части - как именно делать аудит? Вторая часть пожирнее и подлиннее :)) Получился лонгрид :)) https://telegra.ph/CHast-2-Kak-delat-audit-processov-10-20 #не_просто

Как и обещал, начинаю рассказывать про то, как я делаю аудиты рабочих процессов. В ходе написания "собачка немного подросла" и пришлось разбить статью на несколько частей. Буду выкладывать каждую часть каждые 1-2 дня, чтобы у вас было времени осмыслить и задать вопросы https://telegra.ph/CHast-1-Zachem-delat-audit-rabochih-processov-10-18 #не_просто

Простите коллеги, на этой неделе поста не будет 🙁 Сложная командировка в другой город выбила меня из колеи. Обещаю на следующей неделе рассказать, как я делаю аудит рабочих процессов: - проверка озвученных клиентом проблем - выявление узких мест - ревью Upstream и Downstream - вероятностные характеристики рабочего процесса и выводы которые можно из них сделать #анонс

Выше я давал тест про разделение рабочих процессов на Downstream - реализацию задачи, и Upstream - фильтрацию и подготовку задачи к реализации. ❗️Настало время праивльного ответа на вопрос "Откуда растут корни разделения потока работ на Upstream и Downstream?" 🔖Правильный ответ: Корни разделения на Upstream и Downstream лежат в реальном производстве и сопутствующем ему процессе Supply Chain Management - процессе поставки сырья для производства. Патрик Стюарт в своей книге Upstream Kanban лишь использует устоявшуюся в производстве терминологию. ❓Почему же так получилось? Причём здесь река и течения? 🤷 Если вспомнить физический смысл этих слов и наложить их на любой поток поставки ценности, то все быстро встает на свои места. 🚰Физический смысл слов “upstream” и “downstream” означает разные части течения реки. “Upstream“ означает поток выше по течению - то есть река течет К нам, а “downstream” - это поток ниже по течению, то есть река течет ОТ нас. Если перенести это на язык Канбан-метода, то относительно точки начала производства у нас есть поток ценности выше по течению - до начала производства, и ниже по течению - когда продукт уже пошел в производство. Что это за два потока ценности? Давайте разберемся 👉 [продолжение] #не_просто

Небольшая разминка перед серией материалов про Upstream Kanban. #анонс

Привет! 🕕 18-я конференция AgileDays состоится уже в марте следующего года 🎉 Начинаем серию постов для знакомства с командой Программного Комитета конференции👋 Именно эти люди отвечают за то, чтобы после посещения конференции, каждый из участников вышел с новым багажом знаний и инсайтов✨ Итак, первые три представителя Программного Комитета: 🟢 Артемий Анцупов — продюсер конференции и лидер команды Программного комитета, Agile Coach и тренер, в прошлом менеджер проектов; 🟢 Иван Дубровин — CEO ScrumTrek и Agile Coach, эксперт в области гибкого портфельного управления. Продюсер трека «Управление изменениями»; 🟢 Евгений Родионов — Agile Coach и управленческий консультант, эксперт по масштабированию Agile и трансформации операционных моделей. Продюсер трека «Фреймворки и практики». Подробнее о конференции и команде ПК 🔗

❓Всем кто пользуется JIRA и знает Канбан-метод рано или поздно приходит в голову вопросы: - А как сделать WIP-лимиты на человека? - А можно ли сделать единый WIP-лимит на несколько колонок (CONWIP)? - И как сделать WIP-лимит на беговую дорожку, чтобы классы обслуживания ограничить? - А как построить Lead Time Distribution Chart? - А симуляцию Монте-Карло для прогнозирования проекта можно в JIRA сделать? 🥲Увы и ах, но "из коробки" JIRA так делать не умеет 🙁 Она вообще много чего не умеет, но мы ее любим. Как старого коня, который борозды не испортит, но и рекордов на ипподроме от него ждать не стоит. ❓Как же быть, если все перечисленное попробовать хочется, а у вас JIRA? 🔥Выручают плагины. Причем, как ни странно - плагины не к JIRA, а к Google Chrome. 1️⃣Например, можно поставить плагин Jira Helper для Google Chrome, например - и все перечисленные трюки с WIP-лимитами становятся доступны - персональные WIP, CONWIP, WIP на беговую дорожку, и так далее. Просто при заходе в JIRA с включенным плагином, вы сможете все это делать. JavaScript - и никакой магии :)) 2️⃣Второй плагин - Jira Flow Companion - позволяет строить нормальные графики Cumulative Flow Diagram, Lead Time Distribution и даже делать симуляцию Монте-Карло. Всем JIRA-водам - приятного использования! Не благодарите :)) #инструменты

Первый день тренинга "Масштабирование Канбан-систем" Подробно разобрали что такое Upstream 🥲Печально, но факт - во многих компаниях процесс подготовки требований, и валидации идей поставлен из рук вон плохо. Я уж молчу про Технико-финансовое обоснование.... Как итог - производственные подразделения (Downstream) молотят работу и днем и ночью, пар от них валит, люди падают с ног... 📉А прибыль не растет, продуктовые метрики падают, и к целям компании мы не приближаемся. Почему? Потому что нет регулярного процесса Upstream, задачей которого является выбор, валидация и подготовка именно тех задач, которые принесут наибольшую выгоду, и которыми действительно стоит загружать наши производственные подразделения (downstream) 🚧Ведь мощности Downstream - всегда ограничены. А придумывать новые идеи - всегда проще, чем их реализовывать. Придется соразмерять частоту генерации новых идей с возможностями к их производству. В реальном производстве эти ограничения обусловлены возможностями станков, а в интеллектуальном труде подобных ограничений не видно. Но они есть - это физические возможности людей работать. В сутках только 24 часа, рабочий день 8 часов, и бесконечно заполнять это пространство задачами - не получится 🔦Чтобы опрозрачить эти ограничения в интеллектуальном труде (программирование, аналитика, юристы и тд) надо визуализировать поток работ и на Upsttream и на Downstream, чтобы привести их к балансу. Тогда можно увеличивать прибыль и продуктовые метрики, не перегружая производство, предсказуемо и с нужным уровнем качества #upstream #просто

🎓 Канбан-доска - это совсем не то, что вы думаете! Меня недавно позвали провести тренинг по Канбан-методу для известной российской соцсети И чтобы понять, кто придет на тренинг, я решил провести небольшой опрос, для самооценки участников в их знании Канбан-метода. ❓Голоса распределились таким образом: 10 % - Канбан? А что это такое? Впервые слышу 80% - Канбан - это когда мы клеим стикеры на доски и наступает счастье! 0% - Умею делать вероятностные прогнозы с помощью метрик Канбан-метода 0% - Я знаю что такое WIP-лимит, зачем он нужен и как работает 0% - Я улучшил бизнес-метрики моего подразделения с помощью Канбан-метода 🔭 Очень характерные результаты. Видимо, стикеры и доски- самые запоминающиеся артефакты Канбан-метода, поэтому подавляющее большинство ассоциирует метод именно с ними. И с одной стороны, это безусловно важные элементы метода. 🛠Но с другой стороны - это лишь инструмент для кое-чего большего! 🛫Хорошая Канбан-доска, это приборная панель для менеджера. Так же как пилоты самолета могут вести воздушное судно "по приборам", так же и менеджер может с помощью Канбан-доски в каждый момент знать, что происходит с его подразделением и с каждым проектом или продуктом, за которое оно несет ответственность. 📈Имея продуманную, хорошо спроектированную Канбан-доску, менеджер получает возможность измерять работу своего подразделения вдоль и поперек, и в результате - прогнозировать его работу с вероятностью 80-90%! 👉 Продолжение в моей статье "Канбан-доска, это не то, что вы думаете!" https://scrumtrek.ru/blog/kanban/4827/kanban-doska/ #просто #доска

❓Как Scrum-команде давать оценки с вероятностью 85% и не тратить на это много времени? 📈2 года назад я выступал на конференции TeamLead Conf, где рассказывал про то, как тимлиду прогнозировать срок выполнения задач, и не привлекать внимание санитаров отвлекать сотрудников от работы. 👏Доклад был воспринят очень хорошо и после него, в коридоре, десяток тимлидов целый час бодро закидывали меня вопросами по нюансам прогнозирования. 🤔 И тут один парень сказал: "Скажите как мне быть? У меня в подчинении несколько тимлидов, и когда я пытаюсь заговорить с ними о том, чтобы проанализировать сколько нас самом деле занимают задачи по времени, они не хотят ничего слышать! Они считают, что в IT самый правильный способ оценки - это Story Points. При этом, мы даже не работаем по Scrum! Как мне убедить их, что нужно анализировать реальное время, которое их команды тратят на задачи?" 😵 Я был так удивлен! Буквально 5-7 лет назад разработчики воротили нос от всего этого Agile, а кое-где могли послать на йух, стоило тебе произнести слово "Story Point". За слово "Scrum" можно было получить вечный бойкот от коллег-разработчиков. Я знаю, о чем я говорю - я сам был разработчиком. 🌀И вот прошло несколько лет, и все пользуются относительными оценками в Story Points, а про реальное время забыли! ❓Но что такое на самом деле Story Points? И какое отношение они имеют к сроку выполнения задачи? Об этом читайте ниже 👇 https://telegra.ph/Prokachivaem-ocenku-Scrum-komandy-08-31 #просто #прогнозирование

🔫 Как выстрелить себе в ногу, собирая и анализируя данные о рабочем процессе ☝️ Измерять отдельных людей в команде и их производительность. Совершенно бесполезная деятельность, которая ничего кроме тревоги, страха и недоверия не вызовет. В большой компании человек - часть рабочей системы, в которую он встроен. Если система не позволяет ему работать хорошо, и у него нет харизмы Майка Тайсона, то он смирится и будет работать на том уровне, на котором ему позволяет работать система. Например, если каждый шаг требует согласований, то это будет влиять на работу всех сотрудников. И как бы мы не измеряли производительность отдельного человека - она будет лежать в определенном коридоре значений, который обусловлен тем, как устроена рабочая система. ✌️ Метрики тщеславия Это метрики которые интересно рассматривать, и хвастаться ими, но они не несут никакой практической пользы. Например метрика "сколько разработчиков приходят на работу вовремя, минута в минуту". На что она влияет? Что она улучшает? В современном мире, особенно после covid'а, когда всех загнали на удаленку, всем стало ясно, что главное - результат, сделанный в срок, а не сколько времени ты на работе просиживаешь. Избегайте таких метрик. Как говорил Даниэль Ваканти, нужно собирать те метрики, которые подсказывают вам, как действовать, чтобы улучшать бизнес-показатели. 👌 Превратить метрику в KPI с денежным поощрением Самое худшее что может сделать менеджер, который начинает изучать процессные метрики, это механически зафиксировать какую-то метрику как ключевую, и ввести денежные поощрения за ее превышение и поддержание. Метрики сами по себе - это индикаторы состояния всего рабочего процесса. Это сигналы для менеджера о том, где требуется его внимание. А для этого метрики должны показывать правдивую картинку. Но как только соблюдение метрики становится финансово выгодно, ее тут же начнут подделывать, подкручивать, накручивать и менеджер будет видеть искаженную картинку, на основе которой никакие управленческие решения не возможны. 🌟 Удивительно, но такие ошибки порой совершают даже опытные менеджеры. Будьте умнее. Думайте о последствиях, когда выбираете ту или иную метрику #просто #как_не_надо

Не слишком сложно написал? Я старался максимально просто изложить. Если остались вопросы - лучше их задать 🙂 #вопрос_в_зал

🎓Обратился давний клиент с запросом: - Если нас есть входящий бэклог работ из, например, 1000 задач, и то как сделать прогноз того, за какой срок команда его сделает с большой долей вероятности? - А зачем это надо? - спрашиваю - Бизнес свои планы долгосрочные хочет создавать на основе этой метрики. И по этой метрике будет видно, нужно ли еще ресурсов добавить, или всего достаточно? 🤔И тут я задумался... Как это сделать, с большой долей вероятности прогноза? ❓И есть вопрос на засыпку... Относительно чего этот срок рассчитывать? 👉[Читать дальше]👈 #не_просто #прогнозирование