Воскресный лонгрид, сегодня о преодолении chaos management в планировании продуктовой команды.  Меньше задач — крепче нервы или WIP-лимиты как орудие борьбы с хаосом  Задач развития продукта всегда намного больше чем доступных ресурсов для разработки и внедрения. Бизнес требует от команды разработки всего и сразу: все задачи максимального приоритета, сроки, как всегда, позавчера.  Сыпятся на меня градом: "надо", "надо", "надо"! Я на это ваше "надо"… (с)  В ситуации хаоса, отсутствии понимания velocity (производительности команды в условных единицах) и отсутствии приоритизации задач, начать стоит с двух вещей:  1. с приоритизации задач, сегодня о ней говорить не будем;  2. стабилизации потока задач в команду - об этом далее.  Действенный метод — WIP-лимиты, ограничение работы в работе, как бы странно это ни звучало (Work In Progress Limit). Ограничивая количество задач, которые команда может брать в работу одновременно, мы фокусируем усилия и даём каждой задаче больше шансов на завершение, а не на вечный процесс переключения между задачами застрявшими между доской и продом.  Кейс из личной практики  Дано:  - кроссфункциональная команда: бэк, фронт, тестировщики и продакт.  - около 100 эпиков в бэклоге;  - 50-70 задач в каждый релиз с каденцией в 2 недели;  - постоянные срывы сроков и задержки релизов;  - люди в раздрае от прилетающих со всех сторон задач, замечаний к ним и постоянно сорванных сроков.  Найти:  Способ стабилизировать каденцию поставки функциональности и предоставить Бизнесу визуализацию бэклога в виде роадмапа, включающего все задачи.  Решение:  1. беглый анализ производительности команды в условиях хаоса показал, что в месяц мы выпускаем 3-4 фичи, но при этом работаем одновременно над 8-10;  2. на основе этого анализа была выдвинута гипотеза, что одновременно, в рамках одного спринта, мы можем одновременно делать 4 фичи + отрабатывать "фасттрек" - баги и хотфиксы;  3. исходя из предположения был введен WIP-limit = 4, который был использован при планировании задач спринта. Естественно мы это обсудили с командой и участники команды были склонны довериться этой умозрительной оценке пропускной способности;  4. Начали работать по-новому.  Ответ:  за 4 месяца с внедрения WIP-лимитов при планировании и реализации, произошло:  1. выпущено 10 фич;  2. 3 срыва сроков: 2 из-за некорректной оценки внутри команды, 1 из-за масштабного сбоя, который повлиял на весь продукт и все команды;  3. 1 задержка релиза (из-за сбоя);  4. появился роадмап на 5 лет вперед (Бизнес увидел, что они горшочек из той сказки);  5. объем задач в спринте стабилизировался на отметках 30-35шт на релиз;  6. люди стали улыбаться (или мне показалось и до этого они тоже улыбались?..).  FAQ (которые никто не задавал)  Как установить WIP-лимиты?  Когда нет никакой точки отсчета, умозрительно оцените и предположите, обсудите с командой и примите совместное решение. Для старта возьмите число из диапазона 3-5 задач на участника команды на спринт или 3-5 эпиков/фичей одновременно реализуемых.  Важно помнить, что слишком низкий WIP-лимит может привести к простоям, а слишком высокий — не решит исходных проблем с хаосом в задачах. Угадать с первого раза будет сложно, вносите корректировки в соответствии с вашей ситуацией.  Как построить стратегию управления нагрузкой?  Как только WIP-лимиты будут внедрены и заработают, продакт может начинать анализ данных по завершённым задачам. Постепенно сформируется статистика, которая позволит понять velocity команды, и на её основе скорректировать и управлять нагрузкой. Появится возможность планировать спринты и прогнозировать сроки более точно. WIP-лимиты при этом остаются тем инструментом, который стабилизирует процесс и даёт команде уверенность в своих возможностях.  Вывод: WIP-лимиты — эффективный способ стабилизировать процесс планирования и контролировать нагрузку на команду.  Продакт! Помни, нужно начинать завершать, а не продолжать начинать!