Официально внутри моих команд тимлиды/техлиды не были предусмотрены, и часто PO в devteam как раз берут на себя эту роль. Я лидировала свои несколько команд как РО, при этом организовывала еще одного неформального лидера-заместителя в каждой команде для подстраховки. Как неофициальная доп роль на сотрудника, который уже был в команде
Спасибо вам за комментарий, очень хорошие вопросы!
Если говорить про делегирование определения сроков разработки команде, то на моей практике перетекание из спринта в спринт и снова в новый спринт и т. д. как раз получалось, когда сроки ставили сверху от руководства, потому, что сроки были заведомо невыполнимые и не было мотивации в них попасть.
Контроль все равно у меня был, но по результату спринта и квартала - донесли цель/нет, без микроменеджмента. Если какая-то задача у команды не получилась или получилась недостаточно хорошо, можно обсудить на ретро что в следующий раз надо сделать по-другому, чтоб такого не было. И тут важно продакту именно задать вопрос команде, чтобы они сами накидали этот action plan, а не говорить как надо было. Чтобы сами осознали, так лучше в голове отложится.
Как понять не раздувает ли команда сроки искусственно?
1) Если команда уже работала какое-то время со сроками извне то у нее есть показатель капасити сколько сторипойнтов или мандеев сколько в нее влезает за период. Можно сравнить план, который сделала команда сама, с этими показателями.
2) Еще помогает просто опыт, мне примерно уже понятно где они могли недооценить риски, а где наоборот перестраховались, на других проектах уже сталкивалась (но это не значит что я буду строить план за них, буду задавать наводящие вопросы).
3) Еще если есть сомнения в оценках команды, можно проконсультироваться техлидом/ит лидом или синьером по компетенции (если к оценке конкретного например фронта вопрос).
4) Конечно на 100% ты не проверишь, и за спиной у разработчика не постоишь, не посмотришь что он делает 8 часов. Поэтому еще важен качественный найм, больше контроля на испытательном сроке чтобы не нанять себе в команду человека, кто на 3 проектах втихую числится, или просто неэффективен. И важно, чтоб команда была именно сплоченной командой, а не набором компетенций, о чем я писала в статье выше.
И на моей практике, чаще команды недооценивают сроки и бывают слишком оптимистичны чем наоборот.
Но так как они сами назвали сроки, то у них есть мотивация и где-то подольше поработать допом но, уложиться в срок. Тут такой баланс у команды со временем вырабатывается, чтобы без перекосов переоценку и недооценку.
Вовлеченность - да, очень важна. Без нее самостоятельности не будет. Ее можно растить. Если нужно вовлечь именно в задачу планирования, то тут через объяснение выгоды для разрабов - не бегать в конце квартала в агонии горящих сроков, а все правдоподобно спланировать и спокойно сделать. В первый раз будет скепсис, но в процессе реализации станет доходить и следующий квартал уже сами захотят спланировать.
Это самое главное при работе руководителя с командой на мой взгляд - пропускать окружающий рабочий хаос через себя и упорядочивать его для своей команды. Лайк??
Да, хороший прием! Последний спринт в квартале полезно оставлять незапланированным - на случай багов, влетов, подводных камней, и т.д.
Особенно если проект для команды достаточно новый и много неизвестных
Официально внутри моих команд тимлиды/техлиды не были предусмотрены, и часто PO в devteam как раз берут на себя эту роль. Я лидировала свои несколько команд как РО, при этом организовывала еще одного неформального лидера-заместителя в каждой команде для подстраховки. Как неофициальная доп роль на сотрудника, который уже был в команде
Спасибо вам за комментарий, очень хорошие вопросы!
Если говорить про делегирование определения сроков разработки команде, то на моей практике перетекание из спринта в спринт и снова в новый спринт и т. д. как раз получалось, когда сроки ставили сверху от руководства, потому, что сроки были заведомо невыполнимые и не было мотивации в них попасть.
Контроль все равно у меня был, но по результату спринта и квартала - донесли цель/нет, без микроменеджмента. Если какая-то задача у команды не получилась или получилась недостаточно хорошо, можно обсудить на ретро что в следующий раз надо сделать по-другому, чтоб такого не было. И тут важно продакту именно задать вопрос команде, чтобы они сами накидали этот action plan, а не говорить как надо было. Чтобы сами осознали, так лучше в голове отложится.
Как понять не раздувает ли команда сроки искусственно?
1) Если команда уже работала какое-то время со сроками извне то у нее есть показатель капасити сколько сторипойнтов или мандеев сколько в нее влезает за период. Можно сравнить план, который сделала команда сама, с этими показателями.
2) Еще помогает просто опыт, мне примерно уже понятно где они могли недооценить риски, а где наоборот перестраховались, на других проектах уже сталкивалась (но это не значит что я буду строить план за них, буду задавать наводящие вопросы).
3) Еще если есть сомнения в оценках команды, можно проконсультироваться техлидом/ит лидом или синьером по компетенции (если к оценке конкретного например фронта вопрос).
4) Конечно на 100% ты не проверишь, и за спиной у разработчика не постоишь, не посмотришь что он делает 8 часов. Поэтому еще важен качественный найм, больше контроля на испытательном сроке чтобы не нанять себе в команду человека, кто на 3 проектах втихую числится, или просто неэффективен. И важно, чтоб команда была именно сплоченной командой, а не набором компетенций, о чем я писала в статье выше.
И на моей практике, чаще команды недооценивают сроки и бывают слишком оптимистичны чем наоборот.
Но так как они сами назвали сроки, то у них есть мотивация и где-то подольше поработать допом но, уложиться в срок. Тут такой баланс у команды со временем вырабатывается, чтобы без перекосов переоценку и недооценку.
Вовлеченность - да, очень важна. Без нее самостоятельности не будет. Ее можно растить. Если нужно вовлечь именно в задачу планирования, то тут через объяснение выгоды для разрабов - не бегать в конце квартала в агонии горящих сроков, а все правдоподобно спланировать и спокойно сделать. В первый раз будет скепсис, но в процессе реализации станет доходить и следующий квартал уже сами захотят спланировать.
Мне с моими командами такое помогло.
Это самое главное при работе руководителя с командой на мой взгляд - пропускать окружающий рабочий хаос через себя и упорядочивать его для своей команды. Лайк??