Anna Vasilyeva

+1
с 2019
0 подписчиков
26 подписок

На планировании мы вообще не обсуждаем что (точнее как) надо делать фичу, мы просто распределяем задачи в спринт, обсуждаем что было сделано, какие есть проблемы. Для обсуждения конкретно функциональности у нас есть короткие кикоф встречи. 

Поэтому у менеджера хорошо получается держать как раз фокус именно на целе встречи.

Других задач, кроме как следить за фокусом, у нас на встречах с командой для фасилитатора обычно нет, поэтому его роль берет на себя собственно менеджер. Чтобы максимально упростить все :) 

В неделю, когда нет демо, на встречи мы тратим меньше часа времени всей командой. На неделе, когда демо есть — 1.5 часа или около того. В неделю.
До того как мы пришли к таким правилам, встреч было в 2 или 3 раза больше. Если хотите — пользуйтесь :) 

Именно так мы и делаем, и это пока хорошо работает. Но пока мы наблюдаем — вдруг мы что-то упустили и нужны будут изменения процесса.

1

На самом деле если оставить несколько менеджеров, которые будут вести синки, то проблема балагана останется. В этом фишка кросс-командного проекта. Очень редко в проектах есть задачи, которые затрагивают только одну команду. Поэтому когда разработчик задает вопрос по фиче, велик соблазн начать высказываться всем менеджерам. Поэтому он один :). И уже он, если нужно, будет переадресовывать вопрос кому-то другому. По сути менеджер является здесь и ведущим, и фасилитатором встречи, не позволяет ей уходить в другое русло. Если назначить отдельного фасилитатора, он может выглядеть как надсмотрщик. Такое в команде нам не нужно.

Любые вещи, которые хорошо работают, часто кажутся элементарными тем, кто не пришёл к ним сам. Мы общались с другими компаниями и читали про создание кросс-команд: многие сталкиваются с проблемами, и то, что наши правила кажутся простыми, как раз говорит о том, что мы наконец нашли рабочий вариант.

Кросс-команда объединяет разработчиков не только из разных платформ (iOS, Android, Web), но и других частей компании — команды рекомендаций, поиска, рекламы. Это ключевой момент.

О причинах, почему не надо менять структуру компании и разбивать всех сразу на команды, есть в тексте, но проговорю еще раз:
- чтобы каждый раз не нанимать новую команду под проект,
- чтобы не менять структуру компании под проект,
- чтобы можно было одинаково легко и собрать команду, и разойтись, если решим свернуть проект.