🤐 Почему команды берут на себя слишком много
Команды разработчиков от природы оптимистичны и склонны переоценивать свои возможности ещё до того, как руководитель скажет хоть слово. Давление сверху только усугубляет ситуацию, заставляя команду выбирать самый радужный сценарий вместо реалистичного. Лидеры часто создают это давление неосознанно - тоном голоса, вопросом "Как дела?" или даже языком тела. Главный риск не в срыве сроков, а в том, что риски уходят в подполье, а команда перестаёт честно анализировать проблемы.
Ключевое различие, которое должен ввести каждый руководитель: прогноз, план и обязательство - не одно и то же. Прогноз - это предсказание, план - намерение действовать исходя из прогноза, а обязательство - запас прочности. Если вы едете через город за 30 минут - это план. Если вам нужно точно не опоздать - выезжаете за 40. Дополнительное время не пустая трата, а цена уверенности. То же самое с разработкой: гарантированный объём всегда должен быть меньше запланированного.
Самый опасный приём - вопрос с привязкой времени: "Сможете сделать это за три месяца?". Команда слышит желаемый ответ и начинает подгонять реальность под него, вместо того чтобы назвать реальные сроки. Правильная формулировка: "Вот что мне нужно. Когда вы сможете это сделать?". А затем - честный диалог: какие предположения могут оказаться неверными, что сорвёт план, это оптимистичный или наиболее вероятный сценарий.
Планирование не должно быть проблемой одной команды. Когда руководитель просто принимает или отвергает план - это давление. Совместный подход: "Я надеялся на большее. Что я могу сделать, чтобы помочь?". Удалить крупную функцию, сдвинуть менее приоритетный результат, добавить человека, перенести релиз. Цена повторных переработок - потеря доверия. Команда перестаёт верить себе, лидеры перестают верить команде. Лучший ответ на плохие новости - "Спасибо, что сообщили". Так вы получаете правду, а не желаемый ответ.
LinkedIn: Mike Cohn, Scrum Guide Co-author & Owner - Mountain Goat Software
· 21.04
классическая ошибка - задачу оценивают те кто будет её делать, и там автоматически ползёт оптимизм. у нас в командах спасала практика умножить на pi: взял оценку разработчика, умножил на 3.14, получил реалистичный срок. звучит как шутка но работает
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён