Виды потерь

Прошлый пост был про Value Stream Mapping (VSM). Там уже были затронуты потери и их виды. В этом не буду описывать сами виды и их историю. Это например хорошо описано ~тут~ и во многих других статьях. Приведу из своих наблюдений по основным видам.

🗑️ Излишняя обработка

RnD(исследования). “Нам надо поресёрчить”. Нет границ у RnD, если их не ставить заранее. Когда вы поймете, что хватит? Какой ожидаемый результат? Такие исследования могут тянуться из спринта в спринт и потом выбрасываться в мусорку.
Бесконечные совещания. Постоянные встречи без четкой цели и плана могут стать излишней обработкой, отнимая время у команды, которое могло бы быть использовано более продуктивно.
Анализ безрезультативных метрик: Сбор большого объема данных, метрик и опросов, которые не приводят к конкретным действиям или улучшениям в работе команды, становится излишней обработкой информации.
Очень подробные ТЗ. Особенно если в ходе разработки делается не по ТЗ :) Например, user story взяли в спринт. Не успели закончить - перенесли в следующий, потом еще раз. Когда вернулись к ее выполнению, оказалось, что ТЗ уже не везде актуально и его как минимум нужно проверить.
Тестирование без граничных условий: Проведение избыточных тестов без учета граничных случаев и реальных потребностей продукта.

🗑️ Излишняя функциональность

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

Работа без гипотез и прототипов. Если вы каждый раз делаете как в последний, то растет вероятность ненужной функциональности на проде. Выстроенный Discovery процесс, настроенные PBR и обсуждения с командой, приоритизация на основе метрик - все это поможет отсеивать ненужное.

Один известный писатель как-то сказал:

Художник понимает, что достиг совершенства, не тогда, когда уже нечего добавить, а тогда, когда нечего убрать.

Очень сложно настроенный процесс в Jira. Или в другом трекере. Много статусов, правил, которыми не пользуются.
Сложный фасилитационный дизайн встречи. Попытка решить все за раз с жетским таймингом.
Большие сложные презентации. Которые никто не читает.

🗑️ Лишние движения

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

🗑️ Неиспользованный творческий потенциал

Если вы хотя бы раз слышали что-то подобное: «Я не могу выполнять свои основные задачи - мне постоянно нужно делать какие-то выгрузки из Excel, презентации. Работать то когда?», то вы уже знакомы с этим видом потерь 😁.

Несоответствие опыта и задач.Высококвалифицированный сотрудник тратит бOльшую часть времени на низкоквалифицированные задачи.
Неиспользование смежного опыта. Обратная сторона предыдущего пункта - сотрудник со смежным опытом (разработчик, который умеет в QA, дизайнер, который умеет в верстку) не подключается к этим смежным задачам, особенно в критические для продукта моменты. Недостаток вовлеченности сотрудников смежных специализаций в работу над проектом может привести к упущению ценных идей и оптимизации процессов.
Работа с командой в формате “заказчик-исполнитель”. Игнорирование предложений и идей от членов команды по улучшению процесса разработки и продукта. Приносить команде готовые требования без обсуждения. Не спрашивать/не слышать предложения команды по фичам, улучшениям в процессе и т.д.
Игнорирование идей от новичков. Невозможность новичков внести свой вклад и предложить инновационные идеи из-за стереотипов их неопытности. В моей практике частое наблюдение - я новенький, зачем мне участвовать на PBR? При этом часто вопрос "новенького" ставит опытных в тупик (в хорошем смысле) и даже иногда приводит к пересмотру изначального решения.
Отсутствие вовлеченности дизайнера в решение проблем. Не вовлечение дизайнера в решение проблем, связанных с пользовательским опытом, что приводит к упущению ценных идей.
Скрам-мастер - невнимание к обратной связи команды. Неучтенные предложения и замечания от членов команды по улучшению процесса работы, что может привести к упущению возможностей оптимизации.

🗑️ Геройство

Когда команда берет на себя обязательства, которые заранее не могут быть выполнены.

Молчание о проблемах. На Дейли каждый день говорить «нет, у меня все в порядке, помощь не нужна», а потом ночами пытаться победить задачу. И так ее и не выполнить.
Взятие обязательства без возможности выполнения/обсуждения с командой. «Я уже пообещал стейкхолдерам, давайте сделаем максимум!», не обсудив с командой.
Неспособность говорить «нет». Это не всегда происходит из-за геройства, но отнесу сюда. «Нет - продакта ответ».
Бесполезное планирование. Взятие на планировании сильно больше, чем можно сделать. Это отлично видно в Jira на графике Velocity Chart - когда серый столбец всегда существенно больше зеленого. Это еще и формирует иллюзию по возможностям команды, порождает другие виды потерь (незавершенная работа из-за переноса в следующий спринт, переключение между задачами).

Бережливость времени: Работа в режиме "геройства", когда команда постоянно трудится сверх нормы, приводит к беспокойству, и из-за этого могут возникнуть более серьезные ошибки и потери. У меня был пример, когда работал в консалтинге проджектом у крупного заказчика на проектах SAP. В компании была своя первая линия поддержки - запросов было очень много, а сотрудников было всего трое. Для того, чтобы выполнить объем, им всегда приходилось работать в режиме аврала, перерабатывать и т.д. Это так же сказывалось и на качестве решения инцидентов. Команда поддержки могла бы сказать о нехватке ресурсов руководству, но руководство даже не знало об этих проблемах. После того, когда я поднял этот вопрос и обсудил с руководителями - им без проблем выделили дополнительные ресурсы.

🗑️ Дефекты

Баги. Особенно - большое количество ошибок без последующего анализа. В моей практике еще не было продукта, в котором каждый баг был бы уникальным и не было бы возможности решить часть их возникновения через новые договоренности, документацию и пр. Каждый баг делает разработку функциональности дороже - команде рано или поздно придется его исправлять или продукту придется испытывать последствия от неисправления.
Возвраты с ревью. Если возвраты с ревью - частая история, то этот процесс точно нужно исследовать. Практически в каждой команде, с которой я работал, проводили ревью. Практически в каждой команде никто не мог сказать, что именно смотрится на ревью. Тем более - не могли описать это одинаково. Часть проверок можно автоматизировать, тем же SonarQube или любым другим подходящим инструментом.
Сделали не то. На обзоре спринта PO/бизнес говорит, что ожидал не того. Такое может случаться, если в вашей команде нет критериев приемки (acceptance criteria), критериев готовности (definition of ready). Несколько лет назад я работал в команде, в которой проблемы с приемкой повторялись практически каждый спринт. Там мы договорились - ни одна user story не может быть взята в спринт без критериев приемки и без прохода через этап PBR. Потом мы развили эту тему подстроили процесс под это, но в начале такой блок позволил готовить только нужные user story. Это кстати помогло снизить количество «влетов» в спринт.

🗑️ Ручная (лишняя) работа

В отличие от излишней обработки, когда мы делаем больше, чем нужно, сложнее - этот вид потерь про то, чего делать не нужно. То, что можно автоматизировать.

Отсутствие автоматизированных инструментов проверки, деплоя и пр. Сапожник без сапог. Каждой команде нужно давать время на автоматизацию своей работы. У них всегда найдутся идеи на этот счет.
Нет автоматизации в трекере на переходы по статусам,связи. Можно настраивать автоматические переводы из одного статуса в другой по триггерам, автоматическую сортировку, представления, фильтры. Сообщения в slack/tg/прочие мессенджеры об изменении статуса. И изменения статусов задач в трекере через чаты.
Сбор метрик продукта/процесса по запросу вручную. Раньше для более глубокого анализа я выгружал все данные в excel, там убирал выбросы, приводил в порядок данные и уже после искал идеи. Сейчас - большую часть гипотез можно проверить или найти через стандартные графики в Jira. К тому же - у нас в компании организован дашборд производственных метрик, это очень упрощает работу агенту изменений.

🗑️ Ожидание

Аналитик написал БТ/ТЗ, которое ожидает взятия в работу (а возможно туда и не попадет - это еще одна потеря).
Ожидание правок после ревью. Часто вижу следующее - разработчик передал задачу/user story на review. Берет новую задачу - в это время приходят правки с ревью. “Переключаться же плохо? Плохо. Доделаю то, что начал - посмотрю правки на ревью. Я же предыдущую задачу уже почти сделал!” Тем самым забивая поток вместо того, чтобы вытаскивать дальше то, что правее.
Изменение состава бэклога спринта. То, что уже запланировано в спринт, может попасть в ожидание из-за срочных влетов.
Зависимости внутри/вне команды/продукта. В результате таких зависимостей задачи ждут.
Ограничение циклом планирования (в этот квартал не брали, может возьмем в следующий. но поймем это на планировании в конце этого квартала).

🗑️ Незавершенная работа

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

Перенос в следующие спринты. Не сделали в этом спринте, вернули в бэклог. А потом забыли. Если команда все же вернется к доработке - то скорее всего начинать придется с нуля. Или потратить больше времени на то, чтобы вспомнить и проверить соответствие. Или еще больше времени на то, чтобы выбрать - писать с нуля или разбираться 🤪.
Неполное завершение. Сделали часть задачи по техдолгу, архитектуре, потом забыли.
Изменение бэклога спринта. Нет, мне не лень писать - я действительно считаю, что систематические изменения состава спринта приводят к большому количеству видов потерь. Если в вашей команде такое есть - стоит продиагностировать эту проблему.

🗑️ Переключение между задачами

"Посмотри вот это, тут 5 минут". На одном проекте на фрилансе в команде было правило - если ты не знаешь, что где искать - иди к Роме. Рома отвечал на все вопросы и в этом плане выдерживал отличный SLA, но каждый дейли он не мог сказать ничего нового по своей задаче - ему просто некогда было к ней приступить.
Возвраты с ревью. Но теперь проблема в другом. Разработчик сделал задачу, передал на ревью. Он же не будет сидеть без дела, пока задача проходит проверку? Конечно нет! Поэтому он берет следующую задачу из бэклога. Вроде нормально. Но через какое-то время с ревью возвращается задача. Часто в таком случае приоритет отдается новой задаче. Но задача после ревью - уже была «правее», прошла больше этапов, у нее больше шансов закрыться раньше - ей и стоит отдать приоритет. Это пример, когда переключение между задачами неизбежно - выбирать стоит наиболее подходящую сейчас.

🧩 Что делать с этой информацией?

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

Попробуй найти похожие пункты в своей команде. Если ты дочитал до конца - скорее всего у тебя в голове уже возникли похожие ситуации и примеры. Их можно просто зафиксировать для дальнейшего анализа.
Проведи ретро с командой на тему потерь. Расскажи кратко (а не как я) про виды потерь и предложи команде набросать примеры. После этого можно сгруппировать/приоритизировать проблемы и составить action plan.
Поищи подтверждения в метриках. Многие виды потерь можно проверить через метрики. Часто меняется состав спринта? Это видно по отчету о спринте в Jira. Много задач в ожидании? ты можешь найти их посмотреть среднее время нахождения. И так далее.

В дальнейшем, если к статье будет интерес, подумаю над чек-листом по видам потерь.

Я точно описал не все примеры. Если у вас есть свои - присылайте, пишите в комменты. Другим читателям это будет полезно.