Продолжаем тему почему иногда мы получаем в задачах не то, что заказывали. Смотреть задачи с командой - это один из инструментов по получению желаемого результата. Как я и писал, разница между тем, что ты хочешь и тем, как тебя поймут и сделают бывает большая. Поэтому ваша задача сделать так, чтобы вас поняли правильно. Лучшего способа, чем сесть и пройти все с командой или хотя бы их лидером - нет.
Многие ИТ-лидеры скажут, что для для бизнеса (ПО и БЗ) то да, но я та говорю с ребятами на одном языке, у меня проблем не будет. Заманчивая точка зрения, но в корне неверная. Возьму себя и одну из своих задач 2024 года по внедрению автоматического регрессионного тестирования. Я поставил задачу, мы нарисовали дорожную карту, со всеми договорились и пошли делать. Отклонений по дорожной карте особо не было и я посмотрел демо того, что сделано уже ближе к концу. И все было бы хорошо, только я ожидал, что мы делаем регресс всего продукта, а мы сделали регресс отдельных частей (по сути поделив по командам). И это решает часть проблем, но не все, которые ожидалось.
Можно много кого обвинять, но правильнее посмотреть на себя, лучше ставить задачи и разбираться поняли ли их также, как понимаете их вы.
Всегда старайтесь убедиться правильно ли вас поняли и не экономьте время на это, иначе вы будете неприятно удивлены по итогу, когда задачу придется частично или полностью переделывать в дополнительное время.
Подробнее, как проводить подобные встречи с командой, мы писали в нашей
книге "Гибкие методологии на практике" . Там вы найдете все необходимое про работу с задачами и процессами в своей команде разработки, в том числе описание всех церемоний, которые помогут вовремя отследить разницу в понимании задач.