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