Тимлид Очевидность | Евгений Антонов

Проектов много, а команда одна

Пока выбирал тему для очередного пятничного поста, копался в бэклоге и увидел, как меня полгода назад просили об этом написать, а я то ли забыл, то ли забил 🙁

Команда — заказчик — продукт/проект — сосредоточенная работа
За последнее время ко мне пришло несколько людей, у которых команды имеют четкие границы ответственности и приоритеты. Вот кроссфункциональная команда, вот продукт / модуль / сервис, вот продакт, генерящий идеи, или вот основной заказчик, приносящий хотелки. Там неплохо приживается классический скрам с понятным скоупом, целями спринта, демкой в результате и такой вот методичной итеративной моделью.

Команда — куча заказчиков — куча продуктов/проектов — замес
А бывает и так, что команда одна, а продуктов и разных проектов – больше даже, чем людей в команде. И сейчас мне кажется, что вроде всё понятно, надо просто удачно жонглировать этими горящими бензопилами и никогда не хвататься за лезвие. Но я вспомнил, как это фрустрировало меня раньше, и решил, что надо хоть чего-то полезного написать, что поможет на всех стульях посидеть и не разорваться.

Планирование
Про планирование я отдельно писал тут https://www.group-telegram.com/sg/general_it_talks.com/760. Спойлер: заложить часть на плановую работу, часть – на саппорт, техдолг, возгорания и часть – на человеческий фактор (отпуска, болезни, ротация и прочее).

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

Выявление приоритетов
Заказчиков много, хотелок много, каждый считает, что ему надо ну прям обязательно. Это нормально. И точно так же нормально заколебывать всех вопросами, уточняющими НАСТОЯЩИЙ приоритет. Типа «что будет, если мы не успеем сделать эту задачу?», «что именно для вас блокируется от этой задачи?» и т. д. Тогда может оказаться, что блокер не такой уж и блокер, например.

ЛЮДИ
Написал капсом, потому что нужно прямо очень хорошо понимать своих соколов (кто узнал отсылку к «Кремниевой долине», ставьте молнию). Кто-то умеет забуриться в глубь сложной задачи, вынырнуть спустя неделю со всеми нужными решениями. Кому-то трудно долго вглубь, но вширь на все проекты – легко. Кто-то любит медитативно молотить огромные объемы монотонной работы.

И вот исходя из этого надо понимать, кому какая задача из всей богатой россыпи ваших разных проектов достанется.

А еще надо помнить, что люди и от вышеперечисленного могут устать, демотивироваться, захотеть разнообразия, так что это та еще шахматная партия на N шагов вперед. Но оно того точно стоит. И дела будут хорошо сделаны, и команда довольна.

Скрамбан
Я писал выше, что где-то скрам работает неплохо. Вот в случае, когда 1 команда и много разного замеса со всех сторон, я эмпирическим путем пришел к некоему мутанту скрама и канбана. Я разговаривал с рядом опытных менеджеров из разных компаний от мала до велика. Обычно люди приходят на своем опыте примерно к одному и тому же 🙂

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

Как только ветер начинает дуть в непредвиденную сторону (а мы помним, что чем шире пул проектов и заказчиков, тем это чаще бывает), мы поднимаем приоритеты у определенных задач и не стесняемся их впихнуть в спринт, а что-то выпихнуть. Дальше человек спокойно из этого скоупа тянет задачу, делает, тянет новую и так далее. То есть обеспечена гибкость приоритетов и при этом разработчики не в мыле пытаются сами разобраться, что, как и когда делать.

А тимлид и техлид (или тимлид и ПМ, или кто еще у вас отвечает за технику и за проекты) раз в неделю собираются и причесывают бэклог согласно а) требованиям заказчиков, б) внутренних технических потребностей.

Итог
Я уверен, что что-то я точно забыл, а на что-то мне просто не хватило места в посте. Мне и так 2к символов пришлось удалить.

www.group-telegram.com/sg/general_it_talks.com/811

5.5K viewsMar 7 at 08:06

Проектов много, а команда одна

Пока выбирал тему для очередного пятничного поста, копался в бэклоге и увидел, как меня полгода назад просили об этом написать, а я то ли забыл, то ли забил 🙁

Команда — заказчик — продукт/проект — сосредоточенная работа
За последнее время ко мне пришло несколько людей, у которых команды имеют четкие границы ответственности и приоритеты. Вот кроссфункциональная команда, вот продукт / модуль / сервис, вот продакт, генерящий идеи, или вот основной заказчик, приносящий хотелки. Там неплохо приживается классический скрам с понятным скоупом, целями спринта, демкой в результате и такой вот методичной итеративной моделью.

Команда — куча заказчиков — куча продуктов/проектов — замес
А бывает и так, что команда одна, а продуктов и разных проектов – больше даже, чем людей в команде. И сейчас мне кажется, что вроде всё понятно, надо просто удачно жонглировать этими горящими бензопилами и никогда не хвататься за лезвие. Но я вспомнил, как это фрустрировало меня раньше, и решил, что надо хоть чего-то полезного написать, что поможет на всех стульях посидеть и не разорваться.

Планирование
Про планирование я отдельно писал тут https://www.group-telegram.com/sg/general_it_talks.com/760. Спойлер: заложить часть на плановую работу, часть – на саппорт, техдолг, возгорания и часть – на человеческий фактор (отпуска, болезни, ротация и прочее).

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

Выявление приоритетов
Заказчиков много, хотелок много, каждый считает, что ему надо ну прям обязательно. Это нормально. И точно так же нормально заколебывать всех вопросами, уточняющими НАСТОЯЩИЙ приоритет. Типа «что будет, если мы не успеем сделать эту задачу?», «что именно для вас блокируется от этой задачи?» и т. д. Тогда может оказаться, что блокер не такой уж и блокер, например.

ЛЮДИ
Написал капсом, потому что нужно прямо очень хорошо понимать своих соколов (кто узнал отсылку к «Кремниевой долине», ставьте молнию). Кто-то умеет забуриться в глубь сложной задачи, вынырнуть спустя неделю со всеми нужными решениями. Кому-то трудно долго вглубь, но вширь на все проекты – легко. Кто-то любит медитативно молотить огромные объемы монотонной работы.

И вот исходя из этого надо понимать, кому какая задача из всей богатой россыпи ваших разных проектов достанется.

А еще надо помнить, что люди и от вышеперечисленного могут устать, демотивироваться, захотеть разнообразия, так что это та еще шахматная партия на N шагов вперед. Но оно того точно стоит. И дела будут хорошо сделаны, и команда довольна.

Скрамбан
Я писал выше, что где-то скрам работает неплохо. Вот в случае, когда 1 команда и много разного замеса со всех сторон, я эмпирическим путем пришел к некоему мутанту скрама и канбана. Я разговаривал с рядом опытных менеджеров из разных компаний от мала до велика. Обычно люди приходят на своем опыте примерно к одному и тому же 🙂

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

Как только ветер начинает дуть в непредвиденную сторону (а мы помним, что чем шире пул проектов и заказчиков, тем это чаще бывает), мы поднимаем приоритеты у определенных задач и не стесняемся их впихнуть в спринт, а что-то выпихнуть. Дальше человек спокойно из этого скоупа тянет задачу, делает, тянет новую и так далее. То есть обеспечена гибкость приоритетов и при этом разработчики не в мыле пытаются сами разобраться, что, как и когда делать.

А тимлид и техлид (или тимлид и ПМ, или кто еще у вас отвечает за технику и за проекты) раз в неделю собираются и причесывают бэклог согласно а) требованиям заказчиков, б) внутренних технических потребностей.

Итог
Я уверен, что что-то я точно забыл, а на что-то мне просто не хватило места в посте. Мне и так 2к символов пришлось удалить.

BY Тимлид Очевидность | Евгений Антонов