WIP-лимиты здорового человека и WIP-лимиты курильщика

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

Я и мои коллеги по работе для внутренних сотрудников компании, в которой я работаю, периодически готовим небольшие статьи, где разбираем различные кейсы по гибким подходам, включая и кейсы использования Канбан-метода для совершенствования и управления процессами. Такие статьи мы называем "Agile-shorts". И я подумал, "А почему бы не открывать свои статьи и для более широкой аудитории?" И, вот, сегодня я публикую первую свою статью из этой серии.

Сегодня я расскажу один из кейсов, почему проваливается использование такой практики как «Ограничение количества незавершенной работы» или WiP-лимиты. Оговорюсь, что это не единственная причина, но, на моей практике, очень распространенная. В будущих статьях, я, возможно, раскрою эту тему дополнительными интересными ситуациями.

Мало кто, работающий в ИТ-сфере, не слышал про гибкие подходы к созданию продуктов. Слова Agile, Kanban, Scrum уже крепко проникли в лексикон современных компаний. Кто-то их произносит с гордостью, кто-то с иронией, а кто-то сквозь зубы.

Последние, вероятно, на своем опыте столкнулись с неудачным использованием какого-то управленческого инструмента, и спроецировали свой негативный опыт на все будущие идеи.

Но эта заметка не для них. Эта заметка для вас, тех, кто понимает, что инструменты можно использовать по-разному, а на ошибках готов учиться.

Ограничиваем Пользовательские Истории, а работаем с Подзадачами

Часто, познакомившись с основами практик и методов, которые используются в Agile-культуре, у людей складывается впечатление, что, нажав Ctrl+C и Ctrl+V, они у себя получат ту же замечательную вещь, которую они увидели в учебном кейсе. На деле же оказывается, что «Ctrl+V» приходится, как в анекдоте, тщательно дорабатывать напильником.

Визуализируя работу команды, неофиты часто совмещают на одном уровне задачи, которые несут ценность для Заказчика, с задачами, которые имеют ценность только внутри процесса. Почему, спросите, совмещают? В основном, потому что привыкли работать в парадигме – «мне поставили задачу – я делаю задачу – я сделал задачу», в которой для выполнения не обязательно задумываться о ценности: «Ведь начальник уже об этом сам подумал, раз отдает задачу в работу».

В итоге, на одном уровне управления можно встретить такие задачи:

  • «Сделать MVP Продукта» - задача имеет ценность для Заказчика, так как пользователь получит в руки что-то, что может начать использовать.

  • Провести нагрузочное тестирование – не самостоятельная задача, а нужна для прогресса какой-то другой

  • Заключить контракт с поставщиком ХХХ – не самостоятельная задача, а нужна для старта работ по другой задаче

  • Реализовать функционал голосового ввода – пользователь получит новый функционал для использования

«Так причем же тут WIP-лимиты?», спросите вы. Так вот, новички часто начинают применять этот инструмент на таком, типичном для многих, контексте. Ограничили, надеются, что работы пойдут быстрее, а в итоге, почему-то, получается всё наоборот - работы встают, все запутываются.

Пример работы в такой системе: менеджер говорит, что задача «функционал голосового ввода» приоритетнее задачи «проведение нагрузочного тестирования», поэтому первое берем в работу (включаем в лимит), а второе ждёт. Но в какой-то момент приходит понимание, что реализовать функционал без проведения нагрузочного тестирования нельзя (конечно, ведь это часть работ, которые нужно провести, чтобы сделать функционал), задача блокируется и ждет, когда начнем делать тестирование. Но лимит-то заполнен! Как нам говорит теория - чтобы взять что-то в работу, надо сначала что-то завершить. Текущая задача бросается, внимание переключается на что-то другое, а заказчик, в итоге, не получает никакого результата.

Как следствие - заказчик недоволен, время производства хуже, чем было раньше - практика плохая, инструмент - фигня.

Что же делать, спросите вы? Ответ в том, чтобы разделить разные уровни управления и понимать, какую проблему мы решаем.

Какие бывают уровни:

  • Работа на уровне исполнения задач одним человеком.

    • Для снятия перегруза с сотрудника используются персональные лимиты. В этом случае рассматриваются взгляд исполнителя – на задачи смотрят со стороны сотрудника, который выполняет работу.

  • Работа на уровне команды. Для нормирования работы команды, используются:

    • лимиты на систему/команду/сервис (Бэклог спринта – частный случай лимита на систему)

    • лимиты на тип задач (Квотирование)

    • лимиты на этап (работа с узкими горлами)

    • и другие, более экзотические типы ограничений

В этом случае нужно смотреть на задачи глазами Заказчика работ. Появляется такой объект как Customer recognizable item – задача, смотря на которую, Заказчик понимает, что это именно то, что он заказывал, и видит, что происходит с заказом.

  • Работа на уровне портфеля

    • Для эффективного распределения ресурсов для реализации портфеля инициатив, используются лимиты на объекты портфеля.

Например, лимиты на Эпики, чтобы сфокусироваться на завершении какого-то направления, а не распыляться на всё сразу. Хотя, конечно, это уже вопрос маркетинговой стратегии.  Или на инициативы портфеля инициатив – чтобы сфокусироваться на скорости проверки гипотез и, в свою очередь, выбрать именно те, что дадут нам конкурентное преимущество.

Резюмируя эту заметку, хочется подчеркнуть три вещи, которые помогут вам избежать ошибок и получить положительный опыт:

  • Попробуйте понять, для чего нужен инструмент, и в каком контексте он работает

  • Осознайте проблему, которую вы хотите решить применением инструмента

  • Если что-то не получается, допустите, что это не инструмент плох, а есть что-то, что вы не учли

И тогда, разочарование от того, что «мы потратили кучу времени, а оно не работает», вас обойдет стороной.

Источник: https://habr.com/ru/post/526732/


Интересные статьи

Интересные статьи

Недавно на проекте интегрировал модуль CRM Битрикса c виртуальной АТС Ростелеком. Делал по стандартной инструкции, где пошагово показано, какие поля заполнять. Оказалось, следование ей не гаран...
Herpes Simplex Virus, широко известный как вирус простого герпеса, является коварным микробом. Он попадает в организм через слизистые оболочки – рот, нос и гениталии, – но быстро прячется на...
Периодически мне в разных вариантах задают вопрос, который «в среднем» звучит так: «что лучше: заказать интернет-магазин на бесплатной CMS или купить готовое решение на 1С-Битрикс и сделать магазин на...
Мы публикуем видео с прошедшего мероприятия. Приятного просмотра.
Согласно многочисленным исследованиям поведения пользователей на сайте, порядка 25% посетителей покидают ресурс, если страница грузится более 4 секунд.