Привет, Хабр! Меня зовут Дима, я руковожу отделом в Петрович-Тех. Мы делаем ИТ для строительного ритейла, моя команда занимается поддержкой. В статье хочу рассказать о том, как мы наводили порядок в работе с бэклогом для внутреннего продукта – что делать, когда постоянно много задач, приоритеты меняются, стейкхолдеры недовольны.
Когда речь заходит о продуктах внешних, для такого контекста есть немало полезных подходов и практик: всевозможные Scrum/Kanban, спринты, скоринг и приоритизация бэклога, кросс-функциональные команды из людей с T-shaped навыками и продуктовым образом мышления.
По сравнению с внешними, внутренние продукты зачастую “догоняют”. Для внешних – 2-недельные спринты и разные там CI/CD; для внутренних – непрерывный поток задач, задачи берутся в работу по мере поступления. Работа делается, но сложно давать прогнозы, когда что будет готово — в любой момент времени может прилететь непредсказуемое количество задач, которые поменяют все планы. Не хватает людей на развитие внутренних продуктов – “вот сначала разберёмся со срочными задачами бизнеса, тогда займёмся этим”.
В какой-то момент мы решили, что “хватит это терпеть” – попробовали радикально изменить работу с бэклогом внутренних продуктов. Стали приоритизировать задачи, активнее вовлекли стейкхолдеров в процесс планирования, отфильтровали неважные задачи, наладили процесс работы с багами и инцидентами.
В результате сейчас для каждой задачи из бэклога мы знаем, на кого она влияет, сколько таких людей, откуда задача взялась, какие там ключевые метрики и приоритеты относительно других задач. Очередь из просроченных задач практически сведена на нет.
Давайте расскажу, как мы к этому пришли.