Продолжаем погружение в аудит рабочих процессов. Во второй части - как именно делать аудит?
Вторая часть пожирнее и подлиннее :)) Получился лонгрид :))
https://telegra.ph/CHast-2-Kak-delat-audit-processov-10-20
#не_просто
Вторая часть пожирнее и подлиннее :)) Получился лонгрид :))
https://telegra.ph/CHast-2-Kak-delat-audit-processov-10-20
#не_просто
Telegraph
Часть 2. Как делать аудит процессов?
Аудит, который я обычно делаю, включает в себя много исследуемых факторов (осторожно, большой список!): Какова стратегия компании на ближайший год? Каковы стратегические цели на квартал? Как устроена система целеполагания? Как стратегические цели каскадируются…
👍5🔥2
Что резко повышает шансы на хорошее восприятие заказчиками результатов аудита?
Final Results
10%
Выспаться, красиво одеться, и выглядеть на все 100%!
50%
Подтвердить каждый пункт презентации данными
0%
Передать прямую речь от респондентов которых вы опрашивали
35%
Чтобы слушатели презентации узнали в ней себя, и свою ситуацию
0%
Быть самым умным парнем в этой комнате
5%
Придумать самое правильное, идеальное решение для данной ситуации
Коллеги, с 3й частью немного дольше получилось. Потерпите.
В ней я расскажу как презентовать результаты аудита заказчикам.
А пока, для разогрева, небольшой опрос, чтобы я лучше статью подготовил
#анонс
В ней я расскажу как презентовать результаты аудита заказчикам.
А пока, для разогрева, небольшой опрос, чтобы я лучше статью подготовил
#анонс
Данные в ДейSTвии
Что резко повышает шансы на хорошее восприятие заказчиками результатов аудита?
🔥 Спасибо всем кто поучаствовал в опросе!
🎓Наибольшее количество голосов ( 50% ) было отдано за вариант ответа "Подтвердить каждый пункт презентации данными" - и это кажется очень логичным. Особенно в контексте нашего канала, и тем на которые я пишу.
🤷Но представьте себе такую ситуацию: вы видите по телевизору сюжет в котором показывают графики статистики и говорят: "Инфляция уменьшилась до рекордных 4%! Товары подешевели, жить стало лучше, жить стало веселее!" - а вы смотрите и не верите. Потому что в ближайшем продуктовом магазине день за днем дорожают продукты. Пресловутая гречка подорожала опять, овощи, фрукты.... И вы не узнаете в это сюжете себя и свою ситуацию
👉А в интернете объясняют, что инфляция бывает разной. Есть общая по стране по всем товарам - и она как раз составляет 4%, потому что данные берутся по широкой номенклатуре товаров и скачки сглаживаются. А есть продуктовая инфляция - только на товары питания, и она как раз растет и скачет. И приводят графики скачков цен на гречку, овощи, фрукты по месяцам.
👍И тут у вас паззл сходится: вы узнаете себя и свою ситуацию. И вам, может быть, не так уж важны точность цифр, главное, что все выглядит узнаваемо, и совпадает с вашим личным опытом.
То же самое происходит и во время презентации результатов аудита заказчикам. Вы можете приводить сколь угодно точные цифры, но если слушатели не узнают себя и свою ситуацию в вашей презентации - цифры их не убедят.
👊 Это, кстати, является причиной многих конфликтов между бизнесом и IT. IT-шные люди более "цифровые", и часто приводят в качестве аргументов какие-то метрики, цифры, показатели, но бизнес эти цифры не убеждают, потому что они не "бьются" с их реальностью, которую они наблюдают каждый день.
👉Например, у одного клиента, была схожая ситуация, когда IT считал, что он работает четко и быстро, а бизнес постоянно жаловался, что IT работает долго и непредсказуемо. При этом, IT постоянно приводил в качестве аргумента, результаты трекинга времени разработчика - заполненные timesheet'ы, которые показывали, что максимальное время, которое тратится на разработку - 36 часов. Но бизнес эти данные никак не убеждали, потому что не совпадали с наблюдаемой ими реальностью.
👊 А так как не было других доступных систем сбора метрик, на основе которых можно было бы перепроверить цифры ITшников, то конфликт был обречен на бесконечное повторение: бизнес жаловался, что IT долго работает, IT в ответ предъявлял свою статистику по учту времени, бизнесу крыть было нечем, но эта статистика их не убеждала. В итоге бизнес на время умолкал, копя обиды, но через некоторое время конфликт разгорался вновь и все повторялось.
👉Разрешился конфликт только когда в ходе аудита, который я проводил, удалось обнаружить самописную систему учета времени, которую вел руководитель одного из IT-отделов, и из нее удалось вытащить данные о датах начала разработки и дате приемки работы заказчиком. И это время было значительно дольше, чем время зафиксированное разработчиками в timesheet'ах. Ведь то, что фиксировали разработчики в timesheet - это чистое время потраченное на разработку, без задержек, ожиданий и прочего. А бизнес видел совсем другое время - от момента когда заявка пошла в разработку, до момента приемки задачи - со всеми ожиданиями, согласованиями, возвратами на доработку и так далее.
🎓Я показал обеим сторонам эту статистику, и обе стороны узнали в этом свою ситуацию, и согласились, что эта статистика отражает реальное положение дел. IT наконец-то понял причину недовольства бизнеса. А бизнес согласился с тем, что в задержках виноват не только IT, но и промедление бизнеса на этапах приемки, согласования, формулирования требований и так далее.
🤌Так что, когда готовите презентацию для заказчика, убедитесь, что хорошо понимаете их ситуацию, и попробуйте посмотреть на нее глазами заказчика, чтобы сформулировать ваш рассказ так, чтобы заказчик узнал в ней себя и свою ситуацию. Иначе вы получите в ответ только скепсис, недоверие и обиду, что вы "потратили столько времени, и рассказываете то, что к нам не относится"
#ответ
🎓Наибольшее количество голосов ( 50% ) было отдано за вариант ответа "Подтвердить каждый пункт презентации данными" - и это кажется очень логичным. Особенно в контексте нашего канала, и тем на которые я пишу.
🤷Но представьте себе такую ситуацию: вы видите по телевизору сюжет в котором показывают графики статистики и говорят: "Инфляция уменьшилась до рекордных 4%! Товары подешевели, жить стало лучше, жить стало веселее!" - а вы смотрите и не верите. Потому что в ближайшем продуктовом магазине день за днем дорожают продукты. Пресловутая гречка подорожала опять, овощи, фрукты.... И вы не узнаете в это сюжете себя и свою ситуацию
👉А в интернете объясняют, что инфляция бывает разной. Есть общая по стране по всем товарам - и она как раз составляет 4%, потому что данные берутся по широкой номенклатуре товаров и скачки сглаживаются. А есть продуктовая инфляция - только на товары питания, и она как раз растет и скачет. И приводят графики скачков цен на гречку, овощи, фрукты по месяцам.
👍И тут у вас паззл сходится: вы узнаете себя и свою ситуацию. И вам, может быть, не так уж важны точность цифр, главное, что все выглядит узнаваемо, и совпадает с вашим личным опытом.
То же самое происходит и во время презентации результатов аудита заказчикам. Вы можете приводить сколь угодно точные цифры, но если слушатели не узнают себя и свою ситуацию в вашей презентации - цифры их не убедят.
👉Например, у одного клиента, была схожая ситуация, когда IT считал, что он работает четко и быстро, а бизнес постоянно жаловался, что IT работает долго и непредсказуемо. При этом, IT постоянно приводил в качестве аргумента, результаты трекинга времени разработчика - заполненные timesheet'ы, которые показывали, что максимальное время, которое тратится на разработку - 36 часов. Но бизнес эти данные никак не убеждали, потому что не совпадали с наблюдаемой ими реальностью.
👉Разрешился конфликт только когда в ходе аудита, который я проводил, удалось обнаружить самописную систему учета времени, которую вел руководитель одного из IT-отделов, и из нее удалось вытащить данные о датах начала разработки и дате приемки работы заказчиком. И это время было значительно дольше, чем время зафиксированное разработчиками в timesheet'ах. Ведь то, что фиксировали разработчики в timesheet - это чистое время потраченное на разработку, без задержек, ожиданий и прочего. А бизнес видел совсем другое время - от момента когда заявка пошла в разработку, до момента приемки задачи - со всеми ожиданиями, согласованиями, возвратами на доработку и так далее.
🎓Я показал обеим сторонам эту статистику, и обе стороны узнали в этом свою ситуацию, и согласились, что эта статистика отражает реальное положение дел. IT наконец-то понял причину недовольства бизнеса. А бизнес согласился с тем, что в задержках виноват не только IT, но и промедление бизнеса на этапах приемки, согласования, формулирования требований и так далее.
🤌Так что, когда готовите презентацию для заказчика, убедитесь, что хорошо понимаете их ситуацию, и попробуйте посмотреть на нее глазами заказчика, чтобы сформулировать ваш рассказ так, чтобы заказчик узнал в ней себя и свою ситуацию. Иначе вы получите в ответ только скепсис, недоверие и обиду, что вы "потратили столько времени, и рассказываете то, что к нам не относится"
#ответ
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥1
Работа над 3й частью статьи кипит!
Так много хочется рассказать, что порой приходится себя останавливать, чтобы случайно не написать производственный роман 😂
#анонс
Так много хочется рассказать, что порой приходится себя останавливать, чтобы случайно не написать производственный роман 😂
#анонс
👍5
Третья часть статьи про аудит.
Поговорим про то, как презентовать результаты аудита заказчику.
Чтобы заказчик аудита прислушался к вашим аргументам и заинтересовался предлагаемыми изменениями, вам нужно знать три вещи:
1) На каком языке результата мыслит заказчик?
2) Что является его настоящей целью?
3) Какие ограничения заказчик не сможет обойти?
[продолжение по ссылке]
#не_просто
Поговорим про то, как презентовать результаты аудита заказчику.
Чтобы заказчик аудита прислушался к вашим аргументам и заинтересовался предлагаемыми изменениями, вам нужно знать три вещи:
1) На каком языке результата мыслит заказчик?
2) Что является его настоящей целью?
3) Какие ограничения заказчик не сможет обойти?
[продолжение по ссылке]
#не_просто
Telegraph
Часть 3. Что рассказывать в итоговой презентации?
Чтобы создать такую итоговую презентацию, чтобы слушая ее, заказчик аудита воспринял найденные вами факты, прислушался к вашим аргументам и заинтересовался предлагаемыми изменениями, вам нужно знать три вещи: На каком языке результата мыслит заказчик? Что…
🔥8
Я задаю мало вопросов в этом канале потому что...
Final Results
21%
Статьи такие длинные что нет сил дочитать, и вопросы задать
0%
Статьи скукота, и вообще канал не понятно о чем
43%
Все так подробно написано что вопросов не остаётся
14%
Все так сложно, что не понятно что и спрашивать
21%
Другое (напишу в комментариях к посту)
Главная способность для консультанта, который проводит тренинги - никогда не теряться и быстро находить выход из любой ситуации.
За время 2хдневного тренинга "Основы Канбан-систем" в Питере я столкнулся с тем, что:
▶️ Ноябрь в Питере: +1 к уровню сложности :)) 🌧💧 💧 ☔💧 💧 💧
▶️ Место проведения - промзона 🏭 на севере города... +1 к сложности найти места, куда надо приехать 🗺 📍 ❓
▶️ Рюкзак 10+кг с реквизитом, и распечатками для игр 🏋️♂️💩 🏋️💩 💪 +1 расход силы (моя спина сказала мне "прощай")
▶️ Забытый реквизит для игры вокруг которой строится программа 2го дня 🥵 🚫 : -3 часа от сна и отдыха вечером, так как я мотался по городу и искал, где можно купить замену
▶️ 50+ листов с распечатками карточек для игр на плотной бумаге: время отхода ко сну смещается на 01:20 ночи 😴 🛏🥱из-за необходимости нарезать листы на карточки
▶️ Отсутствие провода hdmi в аудитории где проводился тренинг: -10 баллов к аккуратности обучающих презентаций, так как на местном Windows нет нужных шрифтов и поплыли позиции иллюстраций... 🌈 🤪🥳
Но все это того стоило, потому что участники были довольны и очень благодарили
Такой результат очень мотивирует все преодолеть и нести дальше свет знаний и помогать клиентам решать проблемы 💡💡💡💡💡💡⚡💡 💡 💡 💡 💡 💡
#жизнь
За время 2хдневного тренинга "Основы Канбан-систем" в Питере я столкнулся с тем, что:
Но все это того стоило, потому что участники были довольны и очень благодарили
Такой результат очень мотивирует все преодолеть и нести дальше свет знаний и помогать клиентам решать проблемы 💡💡💡💡💡💡⚡
#жизнь
Please open Telegram to view this post
VIEW IN TELEGRAM
ScrumTrek
Основы Канбан-систем
Тренинг для тимлидов, менеджеров и руководителей, который научит вас, как прогнозировать сроки реализации задач с достоверностью 80-90%, и как управлять производительностью вашего подразделения используя вероятностные характеристики потока задач (WIP, пропускная…
🔥7
Меня часто спрашивают, какие книги стоит почитать, чтобы лучше анализировать данные. Книг много, и есть на разный уровень, и с разными акцентами. Так что выбрать не так просто.
Я купил несколько книг, которые показались мне интересными.
По мере прочтения буду делится с вами интересностями и обзорами разных книг.
#анонс
Я купил несколько книг, которые показались мне интересными.
По мере прочтения буду делится с вами интересностями и обзорами разных книг.
#анонс
👍6🔥4
Ребята, у меня все хорошо. Читаю книги, чтобы подготовить для вас обзоры. И много работаю 🙂
Не переключайте канал, скоро вернусь к вам с ворохом интересностей 🙂
#анонс
Не переключайте канал, скоро вернусь к вам с ворохом интересностей 🙂
#анонс
👍7
Forwarded from Диаграмма Гатлинга | Управление проектами, Agile, Менеджмент
Здравствуйте, на связи снова Василий Савунов.
Недавно по интернетам пронеслась вот такая вот картинка про то, как по разному мыслят менеджеры и разработчики
Картинка смешная, но лично у меня она навевает печаль и грусть.
Причем грустно мне по двум причинам:
1. Причина для печали разработчика.
Мем явно программистский. Причем от программиста на удаленке.
Как бывший программист, я очень хорошо понимаю боль автора-программиста. Потому что программирование подобно глубокому трансу, или сну. Лучше всех про это написал Яков Сироткин в далеком 2009-м году. И если это знать, то становится ясня боль программиста, который в условиях "удаленки" и так старается не отвлекаться на домашние дела, и хоть что-нибудь напрограммировать, так его еще отвлекают созвонами ср...е менеджера и scrum-мастера. Не совершенно невозможно работать!
2. Причина для печали менеджера.
Как бывший руководитель, который как раз управлял программистами, мне очень хорошо понятна боль менеджера, который в условиях удаленки пытается хоть как-то понять, что вообще происходит с его проектом, и что делают все эти удаленные супер-пупер программисты, по выключенным камерам которых можно догадаться, что в данный момент они, возможно, валяются в постели, едят, смотрят параллельно сериалы, но только не работают. А вся ответственность за результат - на менеджере. А если это Scrum-мастер, то ему прилетит за неэффективность и непрозрачность работы команды, так как обеспечивать и то и другое - его прямая обязанность.
Чья боль мне ближе?
Я побывал во всех шкурах - программиста, тимлида, менеджера, Scrum-мастера. Поэтоу могу выступить адвокатом каждой из этих ролей. Да и прокурором тоже.
Лично мне менеджеров и Scrum-мастеров жаль гораздо больше, чем разработчиков.
А почему так? Читайте по ссылке
#васили_савунов
Недавно по интернетам пронеслась вот такая вот картинка про то, как по разному мыслят менеджеры и разработчики
Картинка смешная, но лично у меня она навевает печаль и грусть.
Причем грустно мне по двум причинам:
1. Причина для печали разработчика.
Мем явно программистский. Причем от программиста на удаленке.
Как бывший программист, я очень хорошо понимаю боль автора-программиста. Потому что программирование подобно глубокому трансу, или сну. Лучше всех про это написал Яков Сироткин в далеком 2009-м году. И если это знать, то становится ясня боль программиста, который в условиях "удаленки" и так старается не отвлекаться на домашние дела, и хоть что-нибудь напрограммировать, так его еще отвлекают созвонами ср...е менеджера и scrum-мастера. Не совершенно невозможно работать!
2. Причина для печали менеджера.
Как бывший руководитель, который как раз управлял программистами, мне очень хорошо понятна боль менеджера, который в условиях удаленки пытается хоть как-то понять, что вообще происходит с его проектом, и что делают все эти удаленные супер-пупер программисты, по выключенным камерам которых можно догадаться, что в данный момент они, возможно, валяются в постели, едят, смотрят параллельно сериалы, но только не работают. А вся ответственность за результат - на менеджере. А если это Scrum-мастер, то ему прилетит за неэффективность и непрозрачность работы команды, так как обеспечивать и то и другое - его прямая обязанность.
Чья боль мне ближе?
Я побывал во всех шкурах - программиста, тимлида, менеджера, Scrum-мастера. Поэтоу могу выступить адвокатом каждой из этих ролей. Да и прокурором тоже.
Лично мне менеджеров и Scrum-мастеров жаль гораздо больше, чем разработчиков.
А почему так? Читайте по ссылке
#васили_савунов
🔥6😢5
Читаю книги по статистике, которые прикупил, и меня терзают смутные сомнения :(
С одной стороны - Канбан без статистики, как пиво без водки(с). Потому что все прогнозирование, выявление аномалий с которыми надо работать, поиск узких мест, отслеживание результатов ограничения WIP - все это строится на статистике.
И тут много нюансов, про которые хочется рассказать, но.... а интересно ли это вам?
Вот вам, например, интересно как интерпретировать "толстый хвост" на диаграмме Lead Time Distribution? И почему в Канбан-методе "урезание хвоста" является одной из главных целей (наряду с ограничением WIP)? Это сложная тема, которая потребует хорошего знания теории вероятности, но и даст вам глубокие знания о том, как управлять бизнес - процессом на основе статистики.
Интересно?
Или может быть стоит акцентироваться на каких-то более простых вещах для начала?
Например, дать пошаговую инструкцию, как строить Lead Time Distribution Chart в Excel?
Или разобрать логику построения разных Канбан-досок? Или дать иллюстрацию того, как WIP-лимит влияет на Throughtput и LT?
Или на том, как реализовывать цикл изменений?
Писать об этом мне кажется "капитанством", потому что для меня эти темы - понятны и очевидны.
Но может быть, это как раз те темы, которые интересны вам, читателям?
Напишите в комментариях, пожалуйста ваше мнение - на чем стоит сделать акцент в следующих постах?
#вопрос_в_зал
С одной стороны - Канбан без статистики, как пиво без водки(с). Потому что все прогнозирование, выявление аномалий с которыми надо работать, поиск узких мест, отслеживание результатов ограничения WIP - все это строится на статистике.
И тут много нюансов, про которые хочется рассказать, но.... а интересно ли это вам?
Вот вам, например, интересно как интерпретировать "толстый хвост" на диаграмме Lead Time Distribution? И почему в Канбан-методе "урезание хвоста" является одной из главных целей (наряду с ограничением WIP)? Это сложная тема, которая потребует хорошего знания теории вероятности, но и даст вам глубокие знания о том, как управлять бизнес - процессом на основе статистики.
Интересно?
Или может быть стоит акцентироваться на каких-то более простых вещах для начала?
Например, дать пошаговую инструкцию, как строить Lead Time Distribution Chart в Excel?
Или разобрать логику построения разных Канбан-досок? Или дать иллюстрацию того, как WIP-лимит влияет на Throughtput и LT?
Или на том, как реализовывать цикл изменений?
Писать об этом мне кажется "капитанством", потому что для меня эти темы - понятны и очевидны.
Но может быть, это как раз те темы, которые интересны вам, читателям?
Напишите в комментариях, пожалуйста ваше мнение - на чем стоит сделать акцент в следующих постах?
#вопрос_в_зал
👍13
"Помогите мне с Excel!!"
Стабильно 1-2 раза в неделю мне в личку прилетает следующий вопрос:
«Здравствуйте, я скачал вашу эксельку
c примером расчета LTD по этой ссылке,
открыл ее и ничего не понимаю.
Помогите пожалуйста разобраться,
почему когда я подставляю свои значения,
то получаю странный результат?»
Дабы не отвечать каждому на один и тот же вопрос, я решил написать пост, который должен был выйти здесь.
Но очень быстро понял, что это должна быть HowTo статья-инструкция, с картинками (блекджеком и гетерами 😂)
Тут очень подробно описаны детальные шаги, которые нужно сделать, чтобы проанализировать выгрузку из таск-трекера, и построить Lead Time Distribution Chart.
Закинул на VC, чтобы там тоже висело по постоянной ссылке, цените:
👉 Читать статью на VC.ru
___
P.S. Ну и там комментов и пальцев вверх на VC-шке накидайте, чтобы он куда-нибудь продвигался.
Скинуть знакомому менеджеру или Scrum-мастеру — тоже приветствуется 💋
#инструменты
Стабильно 1-2 раза в неделю мне в личку прилетает следующий вопрос:
«Здравствуйте, я скачал вашу эксельку
c примером расчета LTD по этой ссылке,
открыл ее и ничего не понимаю.
Помогите пожалуйста разобраться,
почему когда я подставляю свои значения,
то получаю странный результат?»
Дабы не отвечать каждому на один и тот же вопрос, я решил написать пост, который должен был выйти здесь.
Но очень быстро понял, что это должна быть HowTo статья-инструкция, с картинками (блекджеком и гетерами 😂)
Тут очень подробно описаны детальные шаги, которые нужно сделать, чтобы проанализировать выгрузку из таск-трекера, и построить Lead Time Distribution Chart.
Закинул на VC, чтобы там тоже висело по постоянной ссылке, цените:
👉 Читать статью на VC.ru
___
P.S. Ну и там комментов и пальцев вверх на VC-шке накидайте, чтобы он куда-нибудь продвигался.
Скинуть знакомому менеджеру или Scrum-мастеру — тоже приветствуется 💋
#инструменты
👍6🔥5
На что опираться при прогнозировании сроков?
Основы анализ Lead TIme Distribution Chart.
А разбором кейса реального клиента я делюсь на Youtube 🔗
#картинки
#интересно
#инструменты
Основы анализ Lead TIme Distribution Chart.
А разбором кейса реального клиента я делюсь на Youtube 🔗
#картинки
#интересно
#инструменты
👍9🔥4