Комментарии 37
Ну как-то сомнительно... Если задача была создана значит она была нужна кому-то когда-то. Если ее постоянно откладывают значит она не так и нужна, и то что она висит чертову тучу времени в бэклоге косяк тимлида - потому что он или не добился того чтобы задача попала в разработку, или пролюбил момент когда задача стала не актуальна и ее можно реджектнуть описав причину.
То ли я чего-то не понимаю, то ли проблема какая-то синтетическая.
Задача откладывается не потому, что она "неважная", а потому что в моменте в очереди есть задачи, дающие бизнесу больше отдачи. Приоритет - оценка выхлопа, а точнее соотношения выхлопа к сложности.
Периодически пересматривать приоритеты и проверять актуальность надо - это очевидно, нет?
Я могу вам только позавидовать, если вы с таким не встречались. Видимо вы, или тот кто отвечает за бэклог, следит за ним. То что в моменте может что-то более важно - это нормально. Но типичный кейс, с которым я сталкивался, когда брал команды - это тонна задач либо лежащая на дне бэклога. При этом, вновь и вновь возникает "момент", что что-то важнее. Либо совсем крайний случай, в спринт добавляется такая задача "на всякий случай" и переносится из спринта в спринт. Ее даже никто не читает, если спросить, команда даже не знает о чем она. Но менеджер упорно переносит ее из спринта в спринт.
Очень сомнительный аргумент про "если задача нужна, её заведут снова с новым контекстом". То есть мы получим а) дубль, б) потеряв половину контекста.
Я в целом вижу категорию задач - выпрямить какой-то косяк в системе, который приводит к периодическому ручному труду. Если бросаться сразу всё автоматизировать - задачи с большим выхлопом пострадают, если ничего не записывать (и не делать периодически) - система обрастает такими "ручниками". Я с ними работаю следующим образом - записываю с низким приоритетом и потом каждый раз, когда занимаюсь таким "ручником" и это бесит - добавляю комментарий "снова выползло тут", по возможности пополняя тот самый контекст. Как только комментариев становится больше трёх, возвращаем "нормальный" приоритет и задача как правило захватывается в следующем спринте, если нет чего-то прям нереально горящего.
Аргумент про "команда не доверяет бэклогу" тоже какой-то натянутый. Сравнительно самостоятельной команде от бэклога нужна линейная сортировка в порядке взятия в работу, кончились задачи - взял одну из 3-5 задач сверху, с которой можешь справиться. Способов реализации такой сортировки полно: очереди (а-ля месяц-квартал-год-потом), матрица Эйзенхауэра, ручками, случайно перемешивая, просто по приоритету, по (про)сроку итд. Если сверху ещё и фильтры накинуть (специализация работника + незаблокированные ничем задачи), вопрос его самостоятельного выбора следующей задачи при исчерпании задач в спринте - выеденного яйца не стоит.
Вот если заведённые сотрудником задачи удаляют - это как раз отличный повод перестать доверять бэклогу, как ненадёжному хранилищу, а также в случае с категорией задач, описанной выше, перестать их откладывать и хвататься за всё и сразу, забивая на приоритеты и текущую задачу.
Возможно, наши мнения не конфликтуют - если вы имеете в виду осознанную отмену задачи её же автором, я целиком согласен. Видишь, что не делается и впереди туча других задач - тогда отмена вполне легальна.
Олег, мне нравится ваш системный подход к определенному типу проблем. Я только не пойму из контекста вопроса вашу специализацию. Вы больше инженер или менеджер? Если вы говорите про себя как хорошего технического специалиста, то да, ваш собственный бэклог управляется очень хорошо. Мои топовые ребята-разработчики примерно так и делают. Они держат в голове, что такие-то задачи заведены и могут их найти. Сложнее когда таких крутых спецов несколько. Каждый держит свой контекст. Он часто не пересекается. И там где он не пересекается и возникает проблема. А если команд несколько, то это становится еще сложнее. Так что если вы с позиции менеджера, то очень интересно узнать про ваш опыт, как обеспечивается такой шаринг информации?
Обратите внимание, я не говорю удалять, я призываю во встречах 1 на 1 более подробно их обсуждать. Либо обеспечивать хорошие и прозрачные правила по которым задача получит приоритет. Моя статья больше про такие задачи, которые никак не могут получить приоритет и уже давно.
И да, конечно же с автором задачи надо поговорить. Просто молча удалять - это дичь.
Просто тимлиду нужно отрастить яйца и начать записывать задачи в спринт не спрашивая мнения бизнес-менеджмента и ПМ. Тимлид это начальник разработки, если он считает что в этом спринте необходимо выделить 20ч на бэклог, значит так надо.
Покуда у вас задачи на спринт заводит не команда разработки и руководство команды, а менеджеры всех пошибов и аналитики, то у вас и уровень разработки будет тяп ляп хуяк и в продакшен.
Тимлид не всегда является верховным руководителем разработки, и во многих организациях над ним могут стоять вышестоящие технические руководители, такие как начальники разработки или CTO.
У нас, например, с января практически ни одной фичи не написали и это стоило немалых усилий. Приходилось общаться, договариваться и объяснять. Ключевое - договариваться и продавать важность изменений, объяснять их с точки зрения бизнеса.
Если же возникает мысль о необходимости полного игнорирования мнений других и одностороннего принятия решений, это может быть сигналом к переосмыслению своего места в компании и поиску более подходящей рабочей среды, где будет цениться совместное принятие решений и командная работа.
Есть роли и ответственность. Есть RACI матрица - кто-то принимает решения, кто-то исполняет, кто-то информирован и т.д. Есть процессы, например Scrum, там тоже есть роли. Например, DevTeam, которая принимает решения внутри спринта единолично без каких-либо руководителей сверху, сбоку и т.д. По крайней мере так _работает_ Scrum. Поэтому нет "игнорирование мнений других" и "одностороннее принятие решений" не одно и тоже. В командной работе у каждого есть своя зона ответственности для "одностороннего принятия решений".
Если автор комментария имел в виду, что у тимлида есть право принимать решения, то согласен. Но даже это право требует учета множества факторов, в том числе мнений коллег. Комментарий создает впечатление описания токсичной атмосферы "менеджеры против разработчиков". Был в такой ситуации как со стороны менеджмента, так и со стороны разработчика и понял: это неприятно. Больше не хочу в этом участвовать и не советую другим.
Периодически (при том в разных компаниях) случается мне разгребать такие вот задачи. Обычно большинство из них закрываю т.к. это либо баг который уже исправлен попутно с другими изменениями, либо фича которая уже совершенно не актуальна. Либо проблема с качеством кода, которая тоже уже решена в рамках другой задачи потому как препятствовала ей. Еще часто встречается забавный вариант бага, когда идешь в код и видишь что так было сделано специально, начинаешь выяснять и действительно так и надо, просто ТЗ (или другая документация согласно которой тестируют продукт) не актуально.
Еще существуют циклические правки, когда один и тот же аспект системы меняется по кругу между двумя-тремя вариантами с лагом в пол года. Выявляется такое либо личной памятью, либо анализом истории изменений. После такого "акта саморефлексии системы", ПМу сообщается об истинном корне проблемы и уже начинается поиск настоящего решения. Поэтому стоит иногда сесть и внимательно разгрести все эти задачи, залезая попутно в документацию, код и историю его изменения.
Сомнительно.
Если речь идёт о задачах на спринт, и всегда остаётся такая висячая задача, то получается что спринт всегда с долгом.
Если мы говорим в целом о бэклоге, то естественно там есть огромная кипа задач внизу. Какие-то действительно становятся неактуальны, и их нужно отправлять в "Отменено" или в архив. Но часть задач все ещё актуальна, просто менее приоритетна
Вы смешали два статуса.
Беклог - вроде полезно и даже кому-то нужно, но не приоритетно. Может откладываться годами, это нормально.
Отменено - уже никому не нужно и делаться точно не будет.
Про два статуса я не до конца понял, что вы имеете в виду. Если вы про "не приоритетно" и про "отмену", то статья скорее про то, что то, что не приоритетно, периодически надо переводить в "отмену". Это важно с позиции управления ожиданиями. Я тут привёл пример про то, как это влияет на команду, но с другой стороны есть бизнес. У него тоже свои ожидания. Если нет прозрачной системы, которая позволяет предсказать, будет ли выполняться задача и если будет, то когда, то представители бизнеса, например сейлзы, тоже замучают вопросами. И вместо работы менеджер, как савраска, будет весь в совещаниях. Т.е. есть категория задач, которая да, нужна, но делать не будем.
У любого продакшен проекта с историей есть куча всего что хорошо бы сделать как-нибудь. Проект будет работать и без этого, но с этим лучше. Вот это беклог. Пусть там лежит. Можно почитать или поискать при случае. Половина гениальных идей разбивается как раз о беклог. Было предложено три года назад и отложено потому-то.
А отмена это именно отмена. Не будет делаться в таком виде никогда. Обстоятельства изменились или просто неактуально стало.
Оч хороший тейк, буду внедрять в сознание своих ПМов, спасибо)
(Я разраб)
А я всегда записываю внутренние задачи в бэкдог. Например увидел точку оптимизации кода и записал. В приоритете всегда задачи бизнеса, но если спустя три месяца разработчик выполнил задачи спринта раньше времени, то я даю ему задачу внутреннюю.
Очень хороший способ. Где ведете этот список задач?
В бэклоге со всеми остальными. Инициатор задачи я, по этому полю и могу все их поднимать и помнить. А ещё частенько делаю так, что подвязываю свою задачу к задаче бизнеса если они хоть как то связаны. И пишу, что они неразделимы. Конечно время реализации обоих складываю и говорю общее время бизнесу. Тогда старая задача реализуется, а бизнес и начальство не вдаются в подробности доверяя мне.
Есть задачи низкоприоритетные, но для которых нужна "муза". И ее удаление приведет к тому, что о ней просто забываешь. А вот пока она болтается внизу списка и сойдутся звезды с музой - вот тогда наступает ее звездный час. Но у всех конечно разные приколы с организацией задач.
Я бы дал два лайка, если бы это было возможно! Да, я действительно стараюсь поступать так и учу этому своих ребят. Иногда понимаешь, что решать задачу напролом — неэффективно или слишком затратно. Но проходит месяц, а то и неделя, ты читаешь статью или что-то ещё, и вдруг — бац! — приходит идея. И оказывается, что проблему можно решить гораздо проще или как-то иначе. Правда, по моему опыту, ОБЩИЙ бэклог для таких случаев не подходит. А вот личный — да, тот самое то.
ну дык тут вроде про личный в основном и было повествование :))
просто подобный подход обычно программерский. Ну то есть пишешь пишешь код... встрял... не идет... мучаешься мучаешься - не получается. Плюнул, лег спать.... только засыпать начал и осеняет идея :) идешь дописываешь и все работает.
если админ и не кодил никогда (что удивительно) - то такое случается значительно реже. К тому же постановки задач бывают "принудительные, отсюда и до заката" :))
вот у меня сейчас задача висит довольно нетривиальная... я знаю как ее решать, я даже знаю что у меня на это уйдет ну часов 6... но она у меня уже два месяца висит. Потому что мне что-то подсказывает что надо дождаться более менее подходящего этапа проекта чтобы не делать лишнего :)))
Я вот большой фанат Максима Дорофеева и его "Джедайских техник". Там одна из важных идей: из 2 задач, важной и срочной, человек выбирает понятную. Если обе задачи непонятные - всегда есть опция смотреть котиков в ютубе. Как следствие: если задача долго не делается - возможно, это не потому, что она не нужна, а потому, что оне непонятна. Надо или более четко сформулировать, что именно надо сделать и что будет видимым результатом. Может быть, отделить от задачи первый шаг, который понятен и который приближает к решению. Иначе говоря, один из вопросов, который стоит задавать на груминге: "эта задача не делается. Может, ее надо иначе сформулимровать?" Ну а только если это не помогло, включать вариант "Неуловимого Джо": раз не делается, это не то чтобы никому не нужно, но как минимум при имеющихся ресурсах без этого можно обойтись.
Если в бэклоге систематически появляются задачи, которые потом висят месяцами, значит проджект-менеджер недостаточно хорошо владеет навыком постановки задач. Либо недостаточно хорошо понимает клиента. Если требования клиента неясны, значит их нужно уточнить, возможно с привлечением разработчика. Часть задач после таких уточнений действительно можно закрывать. Но вообще-то, все эти уточнения всегда нужно делать сразу, как только задача была создана, а не когда она покроется мхом в бэклоге.
Привет. Как такой подход будет работать в долгоживущих проектах, обросших техдолгами? Когда ни один техдолг не закрыть за пару спринтов. Для упрощения будем считать, что техдолги оформлены понятными задачами, а приносимые техдолгами проблемы реальные и измеримые.
Привет! В проектах важно планировать на будущее и быть предсказуемыми. Простое добавление задачи в бэклог не решает проблему. Нужно либо выполнить задачу, либо решить не делать её вовсе. Если задача важна, но не выполняется, следует обсудить отмену, повышение приоритета или необходимость дополнительных ресурсов. Все задачи в бэклоге должны быть рассмотрены, так как их добавление изначально подразумевало важность. Обсуждение отмены может выявить ранее незамеченные аспекты задачи. Возможно, то что кажется важным кому-то, после прояснения потеряет свою важность. Тот кто заводит задачу, может просто не знать весь контекст. Я ответил на вопрос?
Правила работы с задачами, до которых не доходят руки