Русский
Русский
English
Статистика
Реклама

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: habr.com
К списку статей
Опубликовано: 06.11.2020 12:09:31
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Управление разработкой

Agile

Управление продуктом

Kanban

Канбан-метод

Канбан

Wip

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru