Comments 6
Интересно. Полезно. Жду продолжение ?
Откуда приходят планы?
Ну, если более точно, то в идеале:
формируется понимание to-be организации
детализируется стратегия достижения
определяется список проектов, которые должны обеспечить достижение стратегических целей
...
каждый проекь планируется отдельно
...
и где-то тут появляется тим-лид
Но это не важно
Идеальный процесс планирования: миф или реальность
Вот тут совсем не так. Хотите вы или нет, планирование проекте происходит не так. Независимо от методологии, у проекте есть:
некий вижин, что из себя будет представлять продукт
ключевые milestones (когда выйти на UAT, когда начать бету, когда начать запускать пользователей) и промежуточные (часто привязаны к функционалу)
То что вы пишете, уже настолько "тактическое" планирование, что его-то и планированием назвать сложно. Это скорее уже циклическая работа по внедрению. Я понимаю, что вы видите планирование спринтов - но объективно, это не слишком относится к планированию в целом :)
Давайте попробуем разобраться, а что же может сделать тимлид, благодаря чему он может положительно влиять на процесс планирования?
В контексте того, о чем вы пишете, что должен сделать тим лид. Все очень просто:
прочитать задачи, которые принесли на планнинг (не надо делать из планинга внеклассное чтение и вообще, приходить на такого рода встречи как в первый раз)
задать вопросы, чтобы для себя понять сложность задачи и помочь понять сложность задачи другим
указать, что задачи имеют блокеры или иные причины, почему их точно не стоит делать в этой итерации
не задавать тупые вопросы, которые не влияют на оценку, вроде цвета кнопочки
быть готовым дать оценку, либо в случае "скрам покера" быть готовым к дискуссии
донести остальной команде, что надо делать тоже самое и проводить профилактическую работу, с теми, кто не хочет так делать
Я прошу прощения, но вы написали очень много, но я нашел достаточно мало того, что тим лид должен привнести в то планирование, куда его зовут.
За чем должен следить тимлид в команде?
За выполнением задач своей командой. Метрики можно распечатать на шершавой бумаге, свернуть в трубочку и использовать в случае, если что-то пошло не так. Я совершенно серьезно. Тимлид == прораб, только более технологичный. Он отвечает за эффективность команды в целом и за каждого по отдельности.
Если есть лоу перформер и его выявили до того, как это выявил тим лид
Если команда не справляется, а тим лид рассказывает про метрики, методологии и вообще
Если через голову тим лида надо решать проблемы команды
...
Этот тим лид первый кандидат на вылет.
Все очень просто. С тим лида спрашивают за результат команды. Если метрики помогают - ОК. Но результат - это не метрики. Это некий, и не всегда точный способ измерения эффективности команды. А результат, это выполненные сторьки с минимальными багами, найденными после того.
«То что вы пишете, уже настолько „тактическое“ планирование, что его‑то и планированием назвать сложно. Это скорее уже циклическая работа по внедрению. Я понимаю, что вы видите планирование спринтов — но объективно, это не слишком относится к планированию в целом»
Вот же, в самом начале указан уровень оценки "планирования":
"Планы бывают разного уровня. Самые верхнеуровневые я бы назвал стратегией. В большинстве случаев проработка и рождение стратегии продукта происходит на уровне CPO и директоров. Множество факторов влияет на представление о том, куда необходимо двигаться. Много умов задействовано в этом процессе, и только благодаря прозорливости и инициативности наших лидеров мы понимаем, что нам делать и куда двигаться. Считайте, что сверху сидит генератор мыслей или стартапов, который умеет представить стратегию инвесторам"
Это какая-то деградация (начиная с подмены Аджайл голимыми скрамом и канбаном с джирой в придачу). Тут бы и ЧатХХХ справился лучше.
А система сообщений как специально сделана отвратительной.
Не специально же, не?
Полагаю, что каждый из пункта подготовки задачи, можно расписать на отдельные статьи. Мне как продакту очень интересно, как тим-лид видит как появляется "защищённый, описанный эпик, декомпозированный на понятные и короткие пользовательские сценарии, выстроенные в цепочку и уложенные в примерные слоты по кварталам".
Сколько итераций технической реализуемости проекта на текущем этапе должно пройти, прежде, чем проект дозреет до описанного состояния.
Руководство для тимлидов: планирование, Agile и вот это всё