Великолепная статья. Подписываюсь под каждым словом. Честность и открытость в компаниях - это критический компонент. Если его нет, то движение идёт в обратную сторону
С большими сценариями помогает их разбитие на "пользовательские истории" (в моей интерпретации). Это когда под историей понимается один конкретный альтернативный путь из большого сценария.
Пример из нашей практики.
Большой сценарий: выдача груза Водителем на точке доставки
Основной путь (пользовательская история): Получатель груза на месте и он принимает груз оптом (просто пересчитывая грузовые места)
Альтернативный путь (пользовательская история): Получатель решает принять груз по-коробочно (сверяя номер на этикетке каждой коробки)
Альтернативный путь (пользовательская история): Получателя нет на месте, Водитель отменяет доставку
Альтернативный путь (пользовательская история): Получателя нет на месте, но вместе него получает другой человек.
и т.п.
В таком варианте "истории" получаются не очень большими и вполне помещаются в спринт. И их даже можно выводить по-отдельности в прод.
В новых ситуациях я приму к сведению эти новые возникшие факторы (предпосылки) и буду анализировать условия конфликта с точки зрения этих новых предпосылок.
Что я точно не буду делать — это запихивать их в ту же самую диаграмму грозовой тучи, что описана в примере.
Судя по тому, что Вы описали в комментарии, это больше похоже на новый конфликт с новыми условиями.
Согласен, что для всех ситуаций такой метод может и не сработает. Надо проверять в каждой конкретной ситуации.
Могу сказать только, то в тех ситуациях когда я пробовал его применять, он срабатывал очень хорошо.
Я бы, например, в этой ситуации пошел по пути доработки ПО, чтобы оно не пропускало неверные р/с. По крайней мере, бережливое производство это о том, чтобы одна и та же ошибка не возникала более одного раза за всю жизнь.
И т.о. можно большинство подобных тупых ошибок убрать.
Это моё видение.
Если я правильно понял, то Вы считаете, что проблемой является не ИТ-отдел, а потребители — сотрудники других отделов с низкой квалификацией, которые не могут даже минимально напрячь извилины, чтобы просто прочитать сообщение на экране? Все правильно?
А что бы Вы предложили со всем этим делать?
В теории практика и теория не отличаются, но вот на практике…
Дело в том, что Бережливое производство — это уже давно практика.
Проблема в том, что у людей есть убеждения и эти убеждения довольно трудно изменить. Если я представлю Вам доказательства обратного, то Вы все равно мне не поверите :-) Конечно, у Вас нет оснований мне верить. Вы видите окружающую реальность, которая убеждает Вас, что другие альтернативы не работают.
И у Вас и у меня одна цель — с помощью сервис деска позволить компаниям отработать все обращениями клиентов в срок. Но Вы делаете это своим способом, а я своим. В основе наших действий лежат некие причины, правила или убеждения, не позволяющие нам согласиться друг с другом.
Но на самом деле, если рассмотреть первопричины этих убеждений, оказывается, что можно выработать общее решение, устраняющее первопричину конфликтной ситуации.
Вы навели меня на мысль написать статью на эту тему и разобрать пример с сервис деском и простоями ресурсов.
Для внутреннего ИТ вас будут утилизировать на 100% и это норма, поскольку так Бизнесу выгоднее.
Очень жалко, что я не убедил Вас, что это не так.
Критичные задачи которые могут привести к простою бизнеса
Это типичное возражение, основанное на неподтвержденных данных. В Toyota Production System есть даже специальное понятие — андон. www.up-pro.ru/encyclopedia/andon.html
Полная остановка всего конвейера в случае обнаружения брака или критической ситуации, наоборот, гораздо более выгодна (по деньгам) для компании, чем перепроизводство.
Анализ результатов внедрений полной остановки и простоя бизнеса говорит о том, что компания получает от этого больше прибыль, чем от беспрерывной работы.
Теории Ограничений также говорит, что остановка необходима.
В общем, в комментарии трудно объяснить тему, про которую написана не одна книга. Если интересно, могу порекомендовать прочитать книги Дао Тойота (в 2-х томах), Цель (основы Теории Ограничений), Цель-2 (о том как анализировать процессы производства)
Пожалуйста. Если мне удасться довести дело до конца, то опубликую результаты перестройки. Сопротивление очень большое — люди не хотят меняться, и тем более когда им предлагают то, что полностью противоречит их принципам
Почему метод называется «5 почему»? По имеющейся у меня информации это связано с тем, что в большинстве случаев корневая причина лежит не далее, чем в 5 уровнях глубины.
В большинстве лично моих случаев было достаточно спросить почему около 3 раз.
Это очень хорошо, если решение о начале разработки систем принимаются по результатам mvp, однако в моей практике, например, это встречалось и встречается крайне редко. Часто решение принимается не на здравом смысле и mvp, а по результатам способности одного человека уболтать другого :-)
Великолепная статья. Подписываюсь под каждым словом. Честность и открытость в компаниях - это критический компонент. Если его нет, то движение идёт в обратную сторону
С большими сценариями помогает их разбитие на "пользовательские истории" (в моей интерпретации). Это когда под историей понимается один конкретный альтернативный путь из большого сценария.
Пример из нашей практики.
Большой сценарий: выдача груза Водителем на точке доставки
Основной путь (пользовательская история): Получатель груза на месте и он принимает груз оптом (просто пересчитывая грузовые места)
Альтернативный путь (пользовательская история): Получатель решает принять груз по-коробочно (сверяя номер на этикетке каждой коробки)
Альтернативный путь (пользовательская история): Получателя нет на месте, Водитель отменяет доставку
Альтернативный путь (пользовательская история): Получателя нет на месте, но вместе него получает другой человек.
и т.п.
В таком варианте "истории" получаются не очень большими и вполне помещаются в спринт. И их даже можно выводить по-отдельности в прод.
Одно могу сказать - очень странные скилы.
Особенно sql и hrml
Что я точно не буду делать — это запихивать их в ту же самую диаграмму грозовой тучи, что описана в примере.
Судя по тому, что Вы описали в комментарии, это больше похоже на новый конфликт с новыми условиями.
Хотите разберем какую-то Вашу ситуацию?
Могу сказать только, то в тех ситуациях когда я пробовал его применять, он срабатывал очень хорошо.
Что это была за проблема, если не секрет?
И т.о. можно большинство подобных тупых ошибок убрать.
Это моё видение.
Если нет, то какие проблемы возникают после внедрения?
А что бы Вы предложили со всем этим делать?
Я обдумал Ваши слова и понимаю, что они основаны на опыте, поэтому предыдущие свои ответы сейчас считаю некорректными.
Можете поделится почему Вы считаете, что для внутреннего ИТ утилизация на 100% отдела поддержки выгодна бизнесу?
Дело в том, что Бережливое производство — это уже давно практика.
Проблема в том, что у людей есть убеждения и эти убеждения довольно трудно изменить. Если я представлю Вам доказательства обратного, то Вы все равно мне не поверите :-) Конечно, у Вас нет оснований мне верить. Вы видите окружающую реальность, которая убеждает Вас, что другие альтернативы не работают.
И у Вас и у меня одна цель — с помощью сервис деска позволить компаниям отработать все обращениями клиентов в срок. Но Вы делаете это своим способом, а я своим. В основе наших действий лежат некие причины, правила или убеждения, не позволяющие нам согласиться друг с другом.
Но на самом деле, если рассмотреть первопричины этих убеждений, оказывается, что можно выработать общее решение, устраняющее первопричину конфликтной ситуации.
Вы навели меня на мысль написать статью на эту тему и разобрать пример с сервис деском и простоями ресурсов.
Очень жалко, что я не убедил Вас, что это не так.
Это типичное возражение, основанное на неподтвержденных данных. В Toyota Production System есть даже специальное понятие — андон.
www.up-pro.ru/encyclopedia/andon.html
Полная остановка всего конвейера в случае обнаружения брака или критической ситуации, наоборот, гораздо более выгодна (по деньгам) для компании, чем перепроизводство.
Анализ результатов внедрений полной остановки и простоя бизнеса говорит о том, что компания получает от этого больше прибыль, чем от беспрерывной работы.
Теории Ограничений также говорит, что остановка необходима.
В общем, в комментарии трудно объяснить тему, про которую написана не одна книга. Если интересно, могу порекомендовать прочитать книги Дао Тойота (в 2-х томах), Цель (основы Теории Ограничений), Цель-2 (о том как анализировать процессы производства)
Да, ловля обезьянок из этой серии. Как не называй — работа от этого у них не продвигается.
Решение Ваше интересное. Было бы здорового, если бы вы описали чуть подробнее.
В большинстве лично моих случаев было достаточно спросить почему около 3 раз.
Это очень хорошо, если решение о начале разработки систем принимаются по результатам mvp, однако в моей практике, например, это встречалось и встречается крайне редко. Часто решение принимается не на здравом смысле и mvp, а по результатам способности одного человека уболтать другого :-)