Бэклог продукта и его приоритизация в теории и в реальности

Я работаю в компании «С7 Информационные технологии», это одно из ИТ-подразделений S7 Airlines (бренд авиакомпании «Сибирь»). Руковожу командой 1С-разработчиков и являюсь владельцем нескольких 1С-продуктов, которые используются в нашей компании.

В докладе я расскажу, как управлять бэклогом продукта, его приоритизацией в теории и в реальности.

Бэклог – это список задач с приоритетами, это термин Scrum. От плана его отличает то, что там нет дат, есть столько приоритеты и задачи.

В докладе расскажу:

• как планировать бэклог в теории;

• и как планировать в реальности – в чем отличие;

• что для этого нужно делать и почему так сложно;

• постараюсь дать рекомендации, как в реальных условиях планировать работу своей команды, когда вы одни, а заказчиков много, в зависимости от разного соотношение размера команды и количества заказчиков;

• также расскажу, как брать в работу быстро задачи из неухоженного бэклога.

Приоритеты: теория и практика

Как выглядит планирование бэклога продукта в теории?

• У нас есть скорость команды (velocity) известная и постоянная: из месяца в месяц команда перемалывает одно и то же количество story points (тоже термин скрама).

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

• Еще важно, что для каждой задачи однозначно определен приоритет. Можно определять его каким-то экспертным путем вместе с заказчиком, а можно определять его по ценности задачи для продукта в каких-то абстрактных единицах – деньгах или часах. Какие две задачи не возьми, везде понятно, какая из них более ценная, какая должна попасть в бэклог.

В теории планирование спринта команды в Excel занимает 10-15 минут, совсем недолго.

Это можно делать в табличке Excel, как показано на слайде – зная скорость команды на спринт (300 очков), подбираем задачи, чтобы создать максимальную ценность продукта.

Как это выглядит в реальности? Я опишу свою реальность.

• Во-первых, состав команды меняется:

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

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

  • Еще у разработчиков бывает разный уровень скиллов – всегда есть эксперты в каком-то узком направлении, и им лучше всего отдавать задачи по их специализации, потому что другие с такими задачами или не справятся, или будут с ними долго работать – поэтому приходится дожидаться этого эксперта и придерживать задачи на потом. Из-за этих проблем экспертная оценка задачи в сторипоинтах может в разы или в десятки раз отличаться. Это все – проблемы команды.

• Еще есть проблема ухоженности бэклога. Не весь и не всегда он ухожен. Вы можете за ним, конечно, ухаживать, задачи стараться оценивать, но:

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

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

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

В чем отличие этих двух слайдов? На прошлом слайде приоритеты у задач были 1, 2, 3, 4, 5, 6. Ценность какая-то была, и она была сравнимая, можно было две задачи сравнить между собой.

В реальности, с которой я сталкиваюсь каждый день, приоритеты распределяются иначе.

Если заказчиков спросить напрямую, какие приоритеты они выставят своим задачам, очень часто они ставят всем задачам самый высокий приоритет. Кроме, может быть, одной-двух. Пример из жизни: разгребали бэклог, в нем было 150 актуальных задач, около сотен неактуальных. Задачами с приоритетом 1 пять-шесть заказчиков сообща назвали 76 штук. Конечно, с 76-ю максимально приоритетными задачами работать невозможно, команда же не резиновая. И в итоге на входе у нас все задачи приоритетные, кроме двух-трех.

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

Ценность задачи: теория и практика

Хорошо, по приоритетам планировать не получается – все задачи приоритетные, значит приоритетов нет. Давайте попробуем определить ценность каждой задачи.

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

В конце концов все приходят к категорийным оценкам задач.

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

Бывают категории в духе «на контроле у генерального директора». Тоже непробиваемая карта. Кстати, иногда если есть контакт с генеральным директором, можно это уточнить. Я как-то спросил, правда ли, что задача у вас на контроле, на что мне гендиректор ответил, что про нее вообще не слышал. Но, конечно, задач и заказчиков много, а ты один, с каждой задачей не набегаешься.

Иногда бывает так: одна задача экономит 70 часов бухгалтера и не очень сложная, вторая – огромная задача, которая экономит четыре часа директора. Я сам затрудняюсь сказать, какая важнее. Вроде бы 70 часов больше 4 и дешевле стоит команде – меньше рисков ее не сделать. Но с другой стороны бухгалтеров много, можно еще нанять, это не проблема, а директор всегда один. Поэтому, наверное, лучше разгрузить директора. Я бы, например, сделал задачу для директора. И такая неопределенность в приоритетах всегда есть.

Почему все так сложно планировать и что с этим делать?

Я тут свел все причины на единый слайд «Почему так сложно?».

• Заказчик не любит брать ответственность за определение приоритетов, а любит свалить все свои задачи на команду с высшим приоритетом.

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

• Сложно придумать единую сквозную оценку задач.

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

Что с этим делать? В своей практике я придумал следующее.

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

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

• Когда мы вместо задач приоритизируем бэклоги, нам надо каждому бэклогу сразу выделить ресурс. Дальше я более подробно расскажу, какие способы выделения ресурсов можно использовать. Почему это важно делать? Когда мы не указываем срок задачи или приоритет постоянно меняется заказчик очень негативно воспринимает неопределенные сроки. Гораздо лучше сказать, что сделаешь в течение месяца или указать конкретный месяц, когда это будет сделано, чем что-то неопределенное, типа «когда дойдут руки». Заказчик прекрасно понимает, что важные задачи никогда не кончатся, и времени на его задачи никогда не найдется.

• Еще одна рекомендация: когда мы разбили бэклог на несколько, внутри каждого бэклога приоритизировать отдельно. Потому что в этом процессе будет участвовать меньше заказчиков, мы избавимся от сравнений между собой, заказчик становиться адекватнее, и даже иногда случается маленькое чудо, и заказчик сам выстраивает приоритеты в виде очереди 1, 2, 3, 4, 5, 6, 7. Этого можно на этом этапе добиться. Ну и задач меньше, планирование происходит более спокойно и более продуктивно.

• Еще один важный момент, о котором я уже упоминал: надо следить за сроком ожидания заказчиком исполнения своих задач. Утверждение заказчика: «Вы для меня ничего не делали уже полгода» звучит не очень лестно, не очень хорошо воспринимается. Поэтому надо в какой-то обозримый период сделать что-то для всех, для каждого.

Теперь на конкретных примерах.

Первый пример – самый простой, самый бесконфликтный. Предположим, что команда у нас достаточно большая и заказчиков много (это неизменно). Команда большая настолько, что можно почти каждый месяц задачи каждого заказчика делать. В этом случае:

• Мы под каждого заказчика выделяем свой отдельный бэклог – на слайде представлено примерное планирование в такой ситуации.

• Здесь у меня допускается, что несколько заказчиков все-таки не войдет. Например, в июне у нас много отпусков, и два подразделения не вошли. Но ничего страшного, в следующий месяц они войдут за счет кого-то другого, месяц-другой потерпеть они могут.

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

Следующий случай сложнее. Это когда команда средняя, а заказчиков много. Средняя – значит, что каждому заказчику почти каждый месяц вы уделять внимание не сможете.

Здесь придется заказчиков разбить на две части: важных и не очень. Как понять, что они важные, – это политическая тема. Например, тех, кто скандальный, их задачи в первую очередь стоит брать. Или по какому-то иному принципу выбирать.

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

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

• Когда отчетный период закрывается, команда, которая занимается учетными системами, берется за задачи из бэклога «Очередь без очереди», или например, каждую последнюю неделю месяца.

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

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

• Мы каждому важному заказчику делаем свой собственный бэклог, но привязываем его к какому-то месяцу в году, когда вся команда сосредотачивается на работе с задачами из этого бэклога. Мы составляем своего рода roadmap и по нему работаем. Составить его тоже относительно несложно и бесконфликтно, можно договориться.

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

• Здесь конечная приоритизация бэклога «Очередь без очереди» более конфликтная, более трудоемкая, но все-таки это гораздо реальнее, чем каждый раз смотреть список всех задач и его приоритизировать.

Коллеги, я рассказал о трёх вариантах планирования, все три у нас применяются на практике. Кратко еще раз повторю.

• Когда команда большая, вы задачи каждого заказчика делайте каждый месяц.

• Когда команда средняя, вы, скажем, вторую половину месяца отводите на задачи важных заказчиков, потом делаете общий бэклог.

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

Важный момент: во всех этих трех способах нельзя допускать, чтобы чья-либо задача оставалась совсем без движения. Людей это очень нервирует, они обязательно найдут способ донести вашему руководству (или через деньги или административно), что их обижают, внимание не уделяют. Поэтому надо регулярно уделять время каждому.

Как работать с неухоженным бэклогом

Вторая часть моего доклада – как работать с неухоженным бэклогом.

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

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

Первая шкала быстрой оценки трудоемкости – безоценочная шкала noestimates. Она очень простая – в свое время, когда я начинал карьеру программистом, я оценивал задачи по этой шкале, даже не зная, что она существует. Но мне она интуитивно понятна, и надеюсь, что вам она тоже будет полезной. В ней всего 3 пункта, 3 градации:

• 1 – это значит, что задача типовая, с большой вероятностью ее можно сделать в какой-то срок – 1 час, 4 дня, 2 месяца;

• NFC (No Fucking Clue или по-русски ХЗ) – это значит, что задачу точно можно сделать, но то ли за неделю, то ли за месяц. Но сделать ее можно, никаких препятствий, никаких рисков. Может быть, если ее получше рассмотреть, разбить ее на подзадачки, они все легко выполняются;

• TFB (задание из разряда Too Fucking Big, если русифицировать, то «ПЦ!») – это задачи, которые даже на первый взгляд сложные, вообще непонятно, как браться за них, что с ними делать.

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

Вторая шкала – по ценности. На слайде вы видите какие-то непонятные буковки D, A, P, B. Это аналогично традиционному делению задач на 4 подтипа: срочные важные, срочные неважные, важные несрочные, неважные несрочные.

Можно было бы использовать традиционный вариант, но я назвал шкалу по-другому, потому что в двух словах «срочная» и «важная» одно слово имеет объективную оценку (срочная), а второе нет.

• Например, изменилось законодательство, у нас есть какой-то срок для выполнения задачи. Допустим, в приказе каком-то сказано «с 1 августа», это установленный срок, это объективно, и никто с этим спорить не будет.

• А важность – это понятие относительное. За важность как раз споры и идут, я об этом уже рассказывал.

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

Посмотрите на задачу 07. У заказчика приоритет 10, а команда считает, что приоритет у этой задачи – 1, поскольку хотят закрыть технический долг.

Если мы эту задачу перед заказчиком назовем «неважная», заказчик обидится и будет с нами дискутировать, напоминать, что он заказчик и платит деньги. Чтобы снизить эту конфронтацию, я придумал свои буковки для задач.

• D – дедлайн, т.е. это задача со сроком, и даже не принципиально, важная она или нет, у нее есть срок, к которому надо все сделать.

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

• Р – это от слова «политика», т.е. это важно для заказчика. Я думаю, все встречали в своей практике задачи, ценность которых просто непостижима для команды, но заказчик очень настаивает на реализации этой задачи.

• В – это прочие, и до них очередь обычно никогда не доходит.

Шкала DAPB бесконфликтная. Я подсмотрел опыт у ребят, которые продают автомобили. Когда они продают какую-то базовую комплектацию машины, в которой стекла поднимают вручную, они не называют ее «ванна с веслами», они называют ее актив. А какая из комплектаций машины лучше – актив или стайл, не понятно. «Актив» – красивое слово, никому не обидно. Смысл этих букв примерно в этом. Их можно показывать на слайде заказчикам, заказчик посмотрит, решит, что какие-то пометки программистов, но что это такое, непонятно, в глаза не бросается.

Как можно планировать с учетом этих шкал?

Мы вместе с командой проходимся по задачам, ставим оценку по безоценочной шкале (на слайде – столбец «noestimates»). Там, где единички, напомню, эти задачи можно сделать в разумные сроки, которые заранее известны, и получить результат.

• Очень хорошо, когда у задач с дедлайном, помеченных D, по шкале noestimates стоит 1. Если что, навалимся, как-то сверхурочно поработаем, но до дедлайна мы успеем, рисков нет.

• Те задачи, которые и команда, и заказчик оценили как неважные, пометили B, мы откладываем на потом.

• Посмотрите на задачи, которые помечены буквой P. Мы их получаем от заказчика, помечаем этой буковкой. Напомню, для команды ценность такой задачи не ясна, но заказчик ее очень хочет.

  • Если по шкале noestimates у нее невысокая ценность, мы ее делаем.

  • Проблема возникает, когда задача получает оценку Р (политическая, важная), и у нее оценка по шкале noestimates «ПЦ!» – что-то ужасное, непонятное. Здесь, конечно, требуется какое-то отдельное обсуждение, может, заказчика удастся уговорить не делать ее, отложить на потом. Но пока не выясним детали, не берем в работу.

  • Есть еще задачи, которые помечены Р и довольно дорого стоят команде – есть риск не уложиться в сроки, долго провозиться с ней (ХЗ по шкале noestimates). С этими задачами мы работаем так: мы берем одну такую задачу, а остальные не делаем. Заказчику объясняем, что уже одна задача в работе, другие позже сделаем.

• Задач, которые помечены по шкале noestimates буковкой А (команда считает, что их нужно сделать), мы стараемся делать максимально много.

Итак получается, что:

• мы берем в работу максимальное количество задач с буковкой А;

• все задачи с буковкой D;

• какую-нибудь задачу Р – те, которые политические и очень трудоемкие, требуют отдельного обсуждения, отдельного внимания.

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

Вопросы

• Что вы принимаете за один story point, и знает ли заказчик эти понятия? От себя сразу добавлю вопрос, знает ли вообще заказчик расшифровку твоей шкалы?

• Нет, заказчик не знает, и смысл в том, чтобы он этого не знал. Что касается story point, этим заказчика тоже не грузим. Честно говоря, измерять команду в story point – это здорово, но я перестал это делать. Потому что есть отпуска, больничные, и story point по одной задаче одного разработчика с одними скиллами отличается от story point другого.

• А дедлайнами не манипулируют?

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

• Сколько времени занимает оценка? Кто именно делает оценку?

• Мы сейчас вообще не делаем оценку времени, только очень приблизительно. В презентации я привел story point только для иллюстрации. Почему так? В моем понимании оценка нужна для того, чтобы заказчик узнал, сколько это стоит часов, потребовал назвать дату сдачи, а потом он будет этой датой стучать по голове команде. При этом тот же заказчик может перед этим попросить сделать другие задачи. Поэтому я всячески стараюсь не давать оценку во времени и не оценивать задачу в часах. По-моему, это бесполезно. Для меня важно понять, эту задачу брать в работу сейчас или нет.

• Используете ли вы какой-то таск-трекер и если да, то какой?

• Jira.

• Бывают заказчики с задачами «ПЦ!», с которыми трудно договориться и легче отказаться от заказчика. Как грамотно их от себя отводить?

• У меня только внутренние заказчики, и этот вопрос немного не ко мне. Но в принципе я постарался рассказать в докладе, что делать, когда в таких условиях приходится работать. Но я не могу отказаться.

• Сколько эффективных часов из рабочего времени сотрудников учитывается при планировании спринта?

• Я практически не парю команду большими собраниями или чем-то таким. Я прихожу, прошу оценить задачи по шкале noestimates, это очень просто делается.

• Тут вопрос немного в другом. Как бы мы не назвали шкалу оценки, у людей есть столько-то часов рабочего времени. Даже для быстрой прикидки, сколько времени твои сотрудники эффективно работают? Я так понял, что вопрос именно в этом. У сотрудника 8 часов рабочего времени, и все 8 он работает?

• Действительно, все работают. Сейчас немного непонятно, я не всех вижу каждый день, но уверен, что все выкладываются. Я просто стараюсь не грузить людей совещаниями – пускай все время, которое у них есть, они поработают. Но кто-то 12 часов поработает, кто-то не в настроении и только 5 часов. Но они работают все время, а я стараюсь сделать их работу комфортной и не грузить.

• Что делать, если во время спринта вы обнаружили, что идете неверным путем?

• Начинаем идти верным путем.

• А если вы, например, оценили задачу на 1 час, но в процессе оказалось, что не 1 час, а ХЗ и ПЦ! и надо полгода. Задача из спринта выкидывается?

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

*************

Данная статья написана по итогам доклада (видео), прочитанного на INFOSTART MEETUP Новосибирск.