Forwarded from ⚡️Лобушкин молнит
Минутка юмора 😂
Изложение Scrum Guide на молодежном 😁
👉Вступление: Чё за Скрам ?
Короче, Скрам — это фреймворк (да-да, не какой-то там процесс), который помогает тебе и твоей тиме разруливать хаос и катать топовый продукт. Это не просто «делай, как сказали», а реальная возможность стать профи по гибкости и креативу. Но не думай, что это всё на изи — освоить Скрам ещё тот челлендж.
👉Как работает Скрам:
Скрам держится на трёх китах, типа:
1. Прозрачность — никто не должен тупо сидеть в неведении, что происходит.
2. Инспекция — регулярно чекаем, как всё идёт, и если что — поправляем.
3. Адаптация — если что-то пошло не по плану, сразу фиксируем баги и меняем тактику.
👉Кто в Скрам Тим:
Скрам Тим — это твоя банда самоорганизующихся бойцов:
- Product Owner (Владелец Продукта) — он шарит, что юзерам нужно, и решает, что делать в первую очередь. Это типа главного продюсера.
- Developers (Разработчики) — это кодеры, дизайнеры, тестеры, в общем, все, кто в итоге вывозит продукт. Они сами решают, как сделать фичу годной.
- Scrum Master — это гуру, который следит, чтобы все не расслаблялись и работали по правилам игры. Он твой главный хелпер.
👉Спринт — это сердце игры:
Спринт — это такой короткий челлендж (макс. месяц), за который ваша тима должна что-то рабочее выкатить. Никаких отходов от плана: что решили, то и делаем, сроки не двигаем, а за качество отвечает каждый.
👉Чё происходит на Спринте:
1. Планирование: решаем, что будем делать. Это как ваш роадмап на ближайшие недели.
2. Ежедневный Скрам: быстрый митинг на 15 минут, чтобы узнать, кто чем занят.
3. Обзор Спринта: показываем, что накодили, и собираем лайки/дизлайки (фидбэк).
4. Ретроспектива: обсуждаем фейлы и как стать круче на следующий раз.
👉Скрам Артефакты:
- Product Backlog — список всех ништяков, которые надо запилить. Это типа ваш wish-list.
- Sprint Backlog — задачи на конкретный спринт. То, что надо зафигачить прямо сейчас.
- Инкремент — готовая часть продукта, которую можно юзать. Это как ваш ранний доступ.
👉Прозрачность — наше всё:
Чтоб не попасть в лужу, нужно, чтобы все были в курсе, что реально происходит с проектом. Тут Скрам Мастер — твой топовый союзник.
👉Итог:
Скрам — это не просто набор правил, а реальная жизнь для твоей тимы. Используй его, если хочешь сделать что-то крутое и не застрять на одном месте. Будь как ниндзя: адаптируйся, реагируй, бей в точку.
Изложение Scrum Guide на молодежном 😁
👉Вступление: Чё за Скрам ?
Короче, Скрам — это фреймворк (да-да, не какой-то там процесс), который помогает тебе и твоей тиме разруливать хаос и катать топовый продукт. Это не просто «делай, как сказали», а реальная возможность стать профи по гибкости и креативу. Но не думай, что это всё на изи — освоить Скрам ещё тот челлендж.
👉Как работает Скрам:
Скрам держится на трёх китах, типа:
1. Прозрачность — никто не должен тупо сидеть в неведении, что происходит.
2. Инспекция — регулярно чекаем, как всё идёт, и если что — поправляем.
3. Адаптация — если что-то пошло не по плану, сразу фиксируем баги и меняем тактику.
👉Кто в Скрам Тим:
Скрам Тим — это твоя банда самоорганизующихся бойцов:
- Product Owner (Владелец Продукта) — он шарит, что юзерам нужно, и решает, что делать в первую очередь. Это типа главного продюсера.
- Developers (Разработчики) — это кодеры, дизайнеры, тестеры, в общем, все, кто в итоге вывозит продукт. Они сами решают, как сделать фичу годной.
- Scrum Master — это гуру, который следит, чтобы все не расслаблялись и работали по правилам игры. Он твой главный хелпер.
👉Спринт — это сердце игры:
Спринт — это такой короткий челлендж (макс. месяц), за который ваша тима должна что-то рабочее выкатить. Никаких отходов от плана: что решили, то и делаем, сроки не двигаем, а за качество отвечает каждый.
👉Чё происходит на Спринте:
1. Планирование: решаем, что будем делать. Это как ваш роадмап на ближайшие недели.
2. Ежедневный Скрам: быстрый митинг на 15 минут, чтобы узнать, кто чем занят.
3. Обзор Спринта: показываем, что накодили, и собираем лайки/дизлайки (фидбэк).
4. Ретроспектива: обсуждаем фейлы и как стать круче на следующий раз.
👉Скрам Артефакты:
- Product Backlog — список всех ништяков, которые надо запилить. Это типа ваш wish-list.
- Sprint Backlog — задачи на конкретный спринт. То, что надо зафигачить прямо сейчас.
- Инкремент — готовая часть продукта, которую можно юзать. Это как ваш ранний доступ.
👉Прозрачность — наше всё:
Чтоб не попасть в лужу, нужно, чтобы все были в курсе, что реально происходит с проектом. Тут Скрам Мастер — твой топовый союзник.
👉Итог:
Скрам — это не просто набор правил, а реальная жизнь для твоей тимы. Используй его, если хочешь сделать что-то крутое и не застрять на одном месте. Будь как ниндзя: адаптируйся, реагируй, бей в точку.
🔥8🗿7👎4🤣1
Ниже холиварный пост от основателя ScrumTrek, Асхата Уразбаева.
Асхат интересную тему поднял, о том что Scrum-мастера часто не несут ответственности за результат, и это вызывает когнитивный диссонанс, когда роль есть, деньги человек получает, а какая с неё ответственность за результат - не понятно.
Во многом я с Асхатом согласен. И кажется, на смену Scrum-мастерам со временем придут Delivery Manager'ы.
Конечная цель работы и у SM и у DM - одинаковая - оптимизировать и ускорить поставку ценности.
Но если SM зажат в рамках Agile/Scrum, то DM может использовать гораздо больший набор инструментов, и влиять на гораздо бОльший периметр, чем SM.
И при этом, DM - лицо ответственное. Его берут именно под задачу оптимизации. И с него будет спрос за это.
Между тем, я вижу на рынке труда необычную ситуацию: параллельно спросу на Scrum-мастеров появился спрос на Delivery Manager'ов. Во многом, его формирует Тинькофф, но есть и другие крупные организации, где уже нанимают на должность DM.
Но общепринятого понимания - а чем занимается DM - на рынке нет.
Тинькофф конечно задаёт тон, но в реальности, диапазон ответственности DM колеблется от "Скрам-мастера под другим названием", до "Оптимизатора Value Stream во всей организации"
Парадоксально, но факт - роль DM есть, но про неё почти никто ничего не знает, и каждый декларирует ожидания от неё по своему.
Раз спрос есть, то нужно формировать понимание - у HRов, как и кого нанимать, и у кандидатов - чего от них будут ждать, и чему им надо учиться.
Если вас эта тема заинтересовала, прошу
вас написать в комментариях, насколько вам созвучна такая точка зрения и почему?
Асхат интересную тему поднял, о том что Scrum-мастера часто не несут ответственности за результат, и это вызывает когнитивный диссонанс, когда роль есть, деньги человек получает, а какая с неё ответственность за результат - не понятно.
Во многом я с Асхатом согласен. И кажется, на смену Scrum-мастерам со временем придут Delivery Manager'ы.
Конечная цель работы и у SM и у DM - одинаковая - оптимизировать и ускорить поставку ценности.
Но если SM зажат в рамках Agile/Scrum, то DM может использовать гораздо больший набор инструментов, и влиять на гораздо бОльший периметр, чем SM.
И при этом, DM - лицо ответственное. Его берут именно под задачу оптимизации. И с него будет спрос за это.
Между тем, я вижу на рынке труда необычную ситуацию: параллельно спросу на Scrum-мастеров появился спрос на Delivery Manager'ов. Во многом, его формирует Тинькофф, но есть и другие крупные организации, где уже нанимают на должность DM.
Но общепринятого понимания - а чем занимается DM - на рынке нет.
Тинькофф конечно задаёт тон, но в реальности, диапазон ответственности DM колеблется от "Скрам-мастера под другим названием", до "Оптимизатора Value Stream во всей организации"
Парадоксально, но факт - роль DM есть, но про неё почти никто ничего не знает, и каждый декларирует ожидания от неё по своему.
Раз спрос есть, то нужно формировать понимание - у HRов, как и кого нанимать, и у кандидатов - чего от них будут ждать, и чему им надо учиться.
Если вас эта тема заинтересовала, прошу
вас написать в комментариях, насколько вам созвучна такая точка зрения и почему?
👍3
Forwarded from Асхат Онлайн
Забавный плач ярославны в linkedin. Bass Vodde, соавтор LeSS жалуется, что во многих компаниях скрам-мастера превращаются в Delivery Managers. Басс говорит, что Скрам-мастер не отвечает за поставку и не является менеджером (как та морская свинка) и следовательно не может быть Delivery Manager.
Кстати, ровно это и бесит страшно менеджмент в организациях. Вроде человек есть, но он ни за что конкретное и измеримое не отвечает. И руками ничего не делает, но и не менеджер. Я кстати тоже не понимаю, как самоорганизация команд уничтожает твою ответственность за итоговый результат, если ты буквально нанят заниматься его улучшением. Типа вы меня наняли наладить поставку, спасибо, только я за это отвечать не буду.
В ответ ему много чего смешного прилетает. Дэвид Андерсон злорадствует, что если ты delivery manager, то ты нанятый, а если скрам-мастер, то безработный, вот так все просто.
Matthew Skelton (это который Team Topology) намекает, что может быть скрам не такой уж универсальный подход и можно использовать другие... (Тут в скобках замечу, что я с ним согласен. Если ты скрам-мастер, а твои команды используют канбан, то получается бред какой-то).
Что вообще происходит? Как так сложилось, что появились отдельные скрам-мастера а не хотя бы аджайл мастера?
Мне кажется, это часть некого естественного исторического процесса. Гибкие подходы были революционными в свое время и авторы Cкрама сделали очень крутой ход, который сильно упростил adoption подхода — он дал особую идентичность апологетам метода. Мы скрам-мастера! Со временем, конечно же, из сакральных знаний скрам превратился просто в набор знаний и навыков, которыми должен (в идеале) обладать каждый руководитель. Более того, никаких других подходов, специфических для софтверных продуктовых проектов, практически и нет — вотерфолл мы убили. Более того, берусь утверждать, что если бы не айдентити скрам-мастера, то никакого развития скрам не получил. Примеров полно — есть подходы типа DSDM, DAD, и проч. Нет айдентити — нет развития.
Вот, набросил опять. Что думаете? :)
Кстати, ровно это и бесит страшно менеджмент в организациях. Вроде человек есть, но он ни за что конкретное и измеримое не отвечает. И руками ничего не делает, но и не менеджер. Я кстати тоже не понимаю, как самоорганизация команд уничтожает твою ответственность за итоговый результат, если ты буквально нанят заниматься его улучшением. Типа вы меня наняли наладить поставку, спасибо, только я за это отвечать не буду.
В ответ ему много чего смешного прилетает. Дэвид Андерсон злорадствует, что если ты delivery manager, то ты нанятый, а если скрам-мастер, то безработный, вот так все просто.
Matthew Skelton (это который Team Topology) намекает, что может быть скрам не такой уж универсальный подход и можно использовать другие... (Тут в скобках замечу, что я с ним согласен. Если ты скрам-мастер, а твои команды используют канбан, то получается бред какой-то).
Что вообще происходит? Как так сложилось, что появились отдельные скрам-мастера а не хотя бы аджайл мастера?
Мне кажется, это часть некого естественного исторического процесса. Гибкие подходы были революционными в свое время и авторы Cкрама сделали очень крутой ход, который сильно упростил adoption подхода — он дал особую идентичность апологетам метода. Мы скрам-мастера! Со временем, конечно же, из сакральных знаний скрам превратился просто в набор знаний и навыков, которыми должен (в идеале) обладать каждый руководитель. Более того, никаких других подходов, специфических для софтверных продуктовых проектов, практически и нет — вотерфолл мы убили. Более того, берусь утверждать, что если бы не айдентити скрам-мастера, то никакого развития скрам не получил. Примеров полно — есть подходы типа DSDM, DAD, и проч. Нет айдентити — нет развития.
Вот, набросил опять. Что думаете? :)
👍7
😁Control Chart – ну что тут сложного? Точки, линии, средняя – и всё, теперь мы можем предсказывать будущее!
🤫Или нет?
😢О, нет, всё не так просто... Потому что никто на самом деле не знает, как правильно строить эту диаграмму и высчитывать сигму. А если честно, её применимость в IT – вообще тот ещё спорный вопрос.
👉Но не переживайте, выход есть. Открываем статью, вздыхаем с облегчением и начинаем разбираться (предупреждение: это лонгрид!):
https://vc.ru/u/2611688-vasilii-savunov/1526247-tretya-kanban-metrika-3-control-chart
Напоминаю, что у этой истории есть начало:
👉Первая часть про Scatterplot - расскажет о том, как видеть тренды и аномалии
👉Вторая часть про Run Chart - расскажет о том, как увидеть сдвиг процесса и ранние сигналы об изменениях
🤫Или нет?
😢О, нет, всё не так просто... Потому что никто на самом деле не знает, как правильно строить эту диаграмму и высчитывать сигму. А если честно, её применимость в IT – вообще тот ещё спорный вопрос.
👉Но не переживайте, выход есть. Открываем статью, вздыхаем с облегчением и начинаем разбираться (предупреждение: это лонгрид!):
https://vc.ru/u/2611688-vasilii-savunov/1526247-tretya-kanban-metrika-3-control-chart
Напоминаю, что у этой истории есть начало:
👉Первая часть про Scatterplot - расскажет о том, как видеть тренды и аномалии
👉Вторая часть про Run Chart - расскажет о том, как увидеть сдвиг процесса и ранние сигналы об изменениях
vc.ru
Третья Канбан-метрика - 3. Control Chart
нужна метрика, которая позволяет это делать
🔥18❤2
STATIK Instructions Kanban+ pdf small.pdf
2.7 MB
Дэвид Андерсон выпустил достаточно компактное описание STATIK (процесса для проектирования Канбан-систем)
🔥11❤4🤔2⚡1
Дайджест полезных материалов этого канала 2024
Захотелось подытожить список материалов, которые я для вас написал в этом году.
Поделитесь в комментариях, какой из материалов зацепил вас больше всего?
Мне важно знать, на чем фокусироваться при подготовке материалов. Помогите мне понять.
👉 1 Как анализировать CFD-диаграмму: PDF
👉 2 Как анализировать LTD-диаграмму: PDF
👉 3 Вебинар "Канбан-метод для руководителей"
👉 4 Любите ли вы аномалии в бизнес-процессах, так как люблю их я? 🙂
👉 5 Элементарно, Ватсон! - PDF моего доклада с IT-merge про RCA и хвосты
👉 6 Третья Канбан-метрика. Часть 1 - Scatterplot
👉 7 Третья Канбан-метрика. Часть 2 - Run Chart
👉 8 Третья Канбан-метрика. Часть 3 - Control Chart
👉 9 Подробный гайд, как построить Cumulative Flow Diagram в Excel
👉 10 Тайна "жирного хвоста" - статья раскрывает смысл числа 5,6 отделяющей "жирный хвост" от короткого
👉 Предыдущий дайджест 2023
Захотелось подытожить список материалов, которые я для вас написал в этом году.
Поделитесь в комментариях, какой из материалов зацепил вас больше всего?
Мне важно знать, на чем фокусироваться при подготовке материалов. Помогите мне понять.
👉 1 Как анализировать CFD-диаграмму: PDF
👉 2 Как анализировать LTD-диаграмму: PDF
👉 3 Вебинар "Канбан-метод для руководителей"
👉 4 Любите ли вы аномалии в бизнес-процессах, так как люблю их я? 🙂
👉 5 Элементарно, Ватсон! - PDF моего доклада с IT-merge про RCA и хвосты
👉 6 Третья Канбан-метрика. Часть 1 - Scatterplot
👉 7 Третья Канбан-метрика. Часть 2 - Run Chart
👉 8 Третья Канбан-метрика. Часть 3 - Control Chart
👉 9 Подробный гайд, как построить Cumulative Flow Diagram в Excel
👉 10 Тайна "жирного хвоста" - статья раскрывает смысл числа 5,6 отделяющей "жирный хвост" от короткого
👉 Предыдущий дайджест 2023
🔥14👍7❤4
Данные в ДейSTвии pinned «Дайджест полезных материалов этого канала 2024 Захотелось подытожить список материалов, которые я для вас написал в этом году. Поделитесь в комментариях, какой из материалов зацепил вас больше всего? Мне важно знать, на чем фокусироваться при подготовке…»
Внезапно 45 🤷
Даже не знаю как на это реагировать.
Так много лет мне еще не было 😁😁😁
В общем - принимаю поздравления и стараюсь осмыслить, как мне теперь жить?
Пакет с пакетами обязательно заводить к этому возрасту? 😁😁
Даже не знаю как на это реагировать.
Так много лет мне еще не было 😁😁😁
В общем - принимаю поздравления и стараюсь осмыслить, как мне теперь жить?
Пакет с пакетами обязательно заводить к этому возрасту? 😁😁
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥32❤8👍8
Ютуб то ли доступен, то ли нет. Заходить на него - то ли законно то ли нет. В такое время живем, что ничего не понятно 🤷
🤫Самые продвинутые, конечно давно нашли возможность через VPN все достать, но согласитесь, порой надоедают все эти танцы с бубном, хочется просто кликнуть в ссылку и смотреть.
▶️ Решил, сэкономить вам пару кликов и перезалил свои видео с объяснением Канбана максимально простым языком в Rutube:
https://rutube.ru/plst/639635/
Сохраняйте в закладки, пока не улетело вверх по ленте 😀
Если вам удобнее в VK - напишите, сделаем и там
🤫Самые продвинутые, конечно давно нашли возможность через VPN все достать, но согласитесь, порой надоедают все эти танцы с бубном, хочется просто кликнуть в ссылку и смотреть.
https://rutube.ru/plst/639635/
Сохраняйте в закладки, пока не улетело вверх по ленте 😀
Если вам удобнее в VK - напишите, сделаем и там
Please open Telegram to view this post
VIEW IN TELEGRAM
RUTUBE
Плейлист Kanban просто – смотреть онлайн все 7 видео от "ScrumTrek" в хорошем качестве на RUTUBE (639635)
Kanban просто подготовил для Вас 7 видеороликов - смотри онлайн бесплатно!
❤10👍5🔥5👎1
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣14
🧠Думанья длинный пост. Дискуссия приветствуется.
🤔А как можно охарактеризовать способ менеджмента на основе инструментов Канбан-метода?
И чем он так уж отличается от обычного менеджмента?
Что там у нас в коробке с Канбан-инструментами?
➡️ Визуализация
➡️ Метрики
➡️ WIP-лимиты
➡️ Каденции
🤫Если менеджер начинает пользоваться этими инструментами, то ведь что-то в его работе меняется? В подходе к работе? В том как решения принимаются?
🤷 Если не меняется - то это,наверно, странно. Зачем тогда Канбан-метод нужен?
❓ А если меняется - то как это можно охарактеризовать и назвать?
Менеджер, который пользуется этими инструментами, осуществляет какой подход к менеджменту?
❓ Информированный?
❓ Основанный на данных?
❓ Доказательный?
❓ .. /еще какой-то вариант/
Мне кажется, что как минимум, менеджмент становится информированным.
То есть в основе принятия решений и оценки ситуации ложатся данные, а не мнения или ощущения.
💪Это само по себе уже большой шаг вперед, как мне кажется.
😢 Но вот если развивать мысль дальше, начинаются проблемы.
🚶♂️ Хотелось бы пойти дальше, и перейти к доказательному менеджменту (по аналогии с "доказательной медициной"), который позволял бы на основе данных не только диагностировать проблему, но и выбирать решение проблемы, и доказывать эффективность этого решения.
🤔Но тут у меня возникают большие сомнения.
🤗 Достаточно очевидно, что имея данные о рабочем процессе можно отследить влияние тех или иных управленческих практик и решений на статистические характеристики производственного процесса, и увидеть, усугубляется проблема 📉, или наоборот, разрешается📈
❓ Но как быть с обратной задачей - когда у нас есть доказанная на основе данных проблема, и надо выбрать управленческий инструмент или решение для устранения этой проблемы❓
И вообще, непонятно на основании чего менеджеру стоит выбирать те или иные управленческие инструменты для решения проблемы в данной ситуации?
💊Если проводить аналогию с "доказательной медициной", то выбор управленческого решения должен осуществляться на основе имеющихся данных научных исследований об эффективности того или иного "лекарства".
😱 Но в реальной практике менеджмента, выбор способа решения проблемы делается совсем не так. Никакой опоры на данные обычно не происходит. Менеджер, как правило, выбирает либо из своего опыта, либо - из того, что сейчас популярно на рынке.
🫡 Тактика, которую чаще всего я наблюдаю у менеджеров: взять готовый популярный подход (Scrum, SAFe, LeSS, Nexus, PRINCE2 и т.д.) и начать это "внедрять" у себя в надежде, что "если сработало у кого-то другого, то сработает и у меня".
Но много ли вы встречали научных исследований того, какую пользу и в каком контексте, приносят эти подходы?
🎉Обычно можно встретить бравурные выступления на конференциях о том как "мы внедрили SAFe/LeSS/Nexus/тд и счастливы".
😭Или наоборот - "как мы внедряли SAFe/LeSS/Nexus/тд и все сломали".
🤷 Ни то ни другое не является научным исследованием, как вы понимаете.
🚜Второй половиной проблемы является то, что все эти "готовые решения" - комплексные и сложные.
То есть они меняют сразу множество аспектов рабочего процесса - ролевую модель, оргструктуру, сам рабочий процесс, способы оценки и так далее и тому подобное. Все это еще влияет друг на друга.
👀 И отследить прямое влияние всех этих изменений на ту проблему, которую мы хотим решить - очень трудно.
А попутно, "внедрение" любого комплексного подхода создаст новые проблемы. И получится "одно лечим - другое калечим".
⁉️ Что делать? Логично было бы отказаться от попыток использовать комплексные решения и пробовать небольшие, атомарные управленческие решения, с доказанным эффектом.
🤝 Если пойти таким путем, то будет легче отследить последствия этого атомарного изменения, и его влияние на динамику проблемы.
😢 Но проблема в том, что с "доказанной пользой" этих атомарных решений, все обстоит примерно так же как и с "доказанной пользой" комплексных решений, которые мы обсуждали раньше.
[продолжение в следующем посте]
🤔А как можно охарактеризовать способ менеджмента на основе инструментов Канбан-метода?
И чем он так уж отличается от обычного менеджмента?
Что там у нас в коробке с Канбан-инструментами?
🤫Если менеджер начинает пользоваться этими инструментами, то ведь что-то в его работе меняется? В подходе к работе? В том как решения принимаются?
Менеджер, который пользуется этими инструментами, осуществляет какой подход к менеджменту?
❓ Информированный?
❓ Основанный на данных?
❓ Доказательный?
❓ .. /еще какой-то вариант/
Мне кажется, что как минимум, менеджмент становится информированным.
То есть в основе принятия решений и оценки ситуации ложатся данные, а не мнения или ощущения.
💪Это само по себе уже большой шаг вперед, как мне кажется.
🤔Но тут у меня возникают большие сомнения.
И вообще, непонятно на основании чего менеджеру стоит выбирать те или иные управленческие инструменты для решения проблемы в данной ситуации?
💊Если проводить аналогию с "доказательной медициной", то выбор управленческого решения должен осуществляться на основе имеющихся данных научных исследований об эффективности того или иного "лекарства".
Но много ли вы встречали научных исследований того, какую пользу и в каком контексте, приносят эти подходы?
🎉Обычно можно встретить бравурные выступления на конференциях о том как "мы внедрили SAFe/LeSS/Nexus/тд и счастливы".
😭Или наоборот - "как мы внедряли SAFe/LeSS/Nexus/тд и все сломали".
🚜Второй половиной проблемы является то, что все эти "готовые решения" - комплексные и сложные.
То есть они меняют сразу множество аспектов рабочего процесса - ролевую модель, оргструктуру, сам рабочий процесс, способы оценки и так далее и тому подобное. Все это еще влияет друг на друга.
А попутно, "внедрение" любого комплексного подхода создаст новые проблемы. И получится "одно лечим - другое калечим".
[продолжение в следующем посте]
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤1
[продолжение предыдущего поста]
🧰Для примера, возьмем Scrum Patterns, которые содержат перечень атомарных инструментов и практик для имплементации Scrum.
📋Просто перечислим некоторые из них:
- Stable Teams
- Standup Meeting
- Definition Of Done
- Definition Of Ready
... (там еще много)
❓ Вопрос - какие научные исследования подтверждают пользу от этих, достаточно атомарных, управленческих паттернов?
Я честно решил поискать такие исследования.
Взял самый известный паттерн - Stable Teams - то есть команды, постоянные по составу.
🔍С помошью Google, Perplexity и такой-то матери, за 2 часа я нарыл два исследования, которые описывали преимущества постоянных по составу команд:
1️⃣раз: https://pmc.ncbi.nlm.nih.gov/articles/PMC9201751/
2️⃣два: https://scielo.org.za/scielo.php?pid=S2222-34362014000100007&noscript=sci_arttext
Только ДВА исследования! Причем одно из них касалось не-IT команд.
🤔Кажется, этого маловато, чтобы принимать обоснованное решение о применении этого паттерна?
То же самое и с другими паттернами - DoD, DoR и тд - найти исследования которые подтверждают эффективность этих управленческих инструментов, не так-то просто.
Может я плохо искал, конечно, но если мне не удалось быстро найти подтверждение эффекта от этого управленческого паттерна, то в точно такой же ситуации окажется любой менеджер, который захочет найти ту же информацию.
😰Напрашивается печальный вывод о менеджменте: при выборе инструментов менеджмента нет никаких объективных источников данных, которые бы подтверждали эффект от того или иного решения🤷
👉Мне могут возразить - есть PMBOK и вот там-то все решения проверенные! А это точно? А вы проверяли? А есть в PMBOK ссылки на научные исследования, подтверждающие эффективность того или иного решения, паттерна, инструмента и тд?
И что нам остается? Ходить на конференции, слушать доклады, и верить, что если у кого-то сработало, то сработает и у нас?
❓ Печальная перспектива. А вы как думаете?
🧰Для примера, возьмем Scrum Patterns, которые содержат перечень атомарных инструментов и практик для имплементации Scrum.
📋Просто перечислим некоторые из них:
- Stable Teams
- Standup Meeting
- Definition Of Done
- Definition Of Ready
... (там еще много)
Я честно решил поискать такие исследования.
Взял самый известный паттерн - Stable Teams - то есть команды, постоянные по составу.
🔍С помошью Google, Perplexity и такой-то матери, за 2 часа я нарыл два исследования, которые описывали преимущества постоянных по составу команд:
1️⃣раз: https://pmc.ncbi.nlm.nih.gov/articles/PMC9201751/
2️⃣два: https://scielo.org.za/scielo.php?pid=S2222-34362014000100007&noscript=sci_arttext
Только ДВА исследования! Причем одно из них касалось не-IT команд.
🤔Кажется, этого маловато, чтобы принимать обоснованное решение о применении этого паттерна?
То же самое и с другими паттернами - DoD, DoR и тд - найти исследования которые подтверждают эффективность этих управленческих инструментов, не так-то просто.
Может я плохо искал, конечно, но если мне не удалось быстро найти подтверждение эффекта от этого управленческого паттерна, то в точно такой же ситуации окажется любой менеджер, который захочет найти ту же информацию.
😰Напрашивается печальный вывод о менеджменте: при выборе инструментов менеджмента нет никаких объективных источников данных, которые бы подтверждали эффект от того или иного решения
👉Мне могут возразить - есть PMBOK и вот там-то все решения проверенные! А это точно? А вы проверяли? А есть в PMBOK ссылки на научные исследования, подтверждающие эффективность того или иного решения, паттерна, инструмента и тд?
И что нам остается? Ходить на конференции, слушать доклады, и верить, что если у кого-то сработало, то сработает и у нас?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍2
UPDATE: конкурс закончился. Ответы после 15 ноября не участвуют в конкурсе
КОНКУРС! С призом!
Два вопроса в зал. ОЧЕНЬ прошу ответить всех, кто может писать. Правильных ответов нет, скорее важно совместно найти инсайт.
Автор самых интересных ответов получит от меня полноценный плакат по способам анализа CFD (смотри фото).
Ответы нужны для будущей статьи, в продолжение темы доказательного менеджмента
Выбор победителя будет сугубо субъективным, никакой объективности, критериев оценки и так далее 😊
Вопрос 1:
Какие вы знаете модели, алгоритмы, циклы которые описывают то, как люди принимают решения?
Вопрос 2:
Что, по-вашему, обязательно присутствует в алгоритме принятия решений опытным человеком (экспертом), и что отсутствует в алгоритме принятия решений дилетантом?
Ответы очень жду в комментариях до 00:00 Пт 15 ноября
КОНКУРС! С призом!
Два вопроса в зал. ОЧЕНЬ прошу ответить всех, кто может писать. Правильных ответов нет, скорее важно совместно найти инсайт.
Автор самых интересных ответов получит от меня полноценный плакат по способам анализа CFD (смотри фото).
Ответы нужны для будущей статьи, в продолжение темы доказательного менеджмента
Выбор победителя будет сугубо субъективным, никакой объективности, критериев оценки и так далее 😊
Вопрос 1:
Какие вы знаете модели, алгоритмы, циклы которые описывают то, как люди принимают решения?
Вопрос 2:
Что, по-вашему, обязательно присутствует в алгоритме принятия решений опытным человеком (экспертом), и что отсутствует в алгоритме принятия решений дилетантом?
Ответы очень жду в комментариях до 00:00 Пт 15 ноября
👍5
😱Кандидатов много, вы накидали столько вкусного и интересного, что выбрать трудно.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6👍4
Так как моей целью было - собрать как можно больше нового материала, который бы расширил границы моих знаний по принятию решений (decision making), и сделать будущую статью еще более полезной и интересной, то места распределились таким образом:
@aleksey_hf - за удивительную теорию Garbage Can Model, о которой я не знал, и которая, на мой взгляд, прекрасно описывает то, что происходит в большинстве компаний, при принятии решений. Это как стартовое состояние, с которого мы обычно начинаем. Спасибо @aleksey_hf - ты помог мне заполнить смысловую лакуну, на которую я давно не могу найти ответа. Очень ценно ❤️
UPDATE: приз доставлен и получен
@Andrey - за цикл OODA. И очень интересные мысли о том, что опытный обязательно учитывает обратную связь, а дилетант часто бездумно делает по шаблону, не думая.
2е место только потому, что цикл OODA мне хорошо известен, но ссылка на него мне кажется очень уместна в контексте разработки IT-проектов, так как здесь, как в воздушном бою - все время все меняется, и все время надо ориентироваться в происходящем, и принимать решения.
Спасибо!
UPDATE : приз доставлен и получен
@Med_d_d - за то, что рассказал, как на основе оценки вероятности успеха, принимают решение трейдеры и за ссылку на Ричарда Вайкоффа с его "композитным человеком". Для меня это было совершенно новым знанием, пусть и не напрямую связанным с областью менеджмента. Спасибо - ты заставил меня задуматься, можно ли использовать "композитного человека" применительно к прогнозированию действий заказчика, или пользователя
UPDATE: приз доставлен и получен
С каждым из вас я спишусь в личке в Пн, чтобы уточнить адрес доставки.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11