Стратегия изменений. Часть 2
Я напомню, что мы активно меняем подразделение одной организации изнутри.
Было: куча заказчиков, куча менеджеров, одна большая команда
Стало: 2 владелец продукта, 2 скрам мастера, одна большая команда
Изменилось, по-сути, немногое, но не все сразу. Итак, настало время раздербанить большую команду на кусочки. Человек очень много 48 штук. Продукт один, сложный и многоплатформенный.
Мы начали задаваться этим вопросом уже давно, вариантов, предложенных самой командой, было много, но это все были разновидности component team. Я знала только то, что команда должна быть кроссфункциональной, а это значит, что она должна обладать всеми компетенциями, чтобы создавать продукт.
В поисках лучших решений мы стали прибегать к поиску успешных кейсов у коллег по цеху, понятное дело нам надо масштабироваться. Конечно, если смотреть на них, как на одну большую команду из почти 59 человек, они обладают всеми компетенциями, чтобы сделать продукт. Но это мало управляемая толпа, получасовые daily scrum, шестичасовые планирования и неэффективные ретроспективы. Scrum of scrum не спасает, Nexus выглядит непривлекательно. Пока очень круто все учтено у Spotify, но их опыт неповторим, нужно строить что-то свое. Очевидным решением просятся feature teams, а дальше посмотрим.
Как мы живем сейчас
Команды мобильной разработки и тестирования я пока не трогаю. У них там более или менее есть скрам-мастер, владелец продукта, кое-какой scrumbut и отдельный баклог. Единственное, посоветовала им тестировщиков включить все-таки в скрам-команды.
Кстати, от отдельных баклогов мы получаем кучу проблем. Поэтому в ближайшее время я буду заниматься синхронизацией владельцев продуктов, в идеале надо прийти к одному баклогу.
Помимо этого, все команды имеют внешние зависимости, причем друг от друга, потому что привыкли работать в функциональных колодцах :) Красные стрелочки это кто от кого зависит. Красный кружочек, тот, от кого зависят больше всего. Тоже буду работать над этим, но скорее всего пока получится только над стрелочками и то не над всеми.
Еще очень интересное наблюдение, видите большой Component A? По сути, даже если мы разделимся на кроссфункциональные команды, радости особой не получим, потому что монолит невозможно будет разрабатывать независимо. Все-равно будет общий регресс и интеграция. Приходим к тому, что надо провести большую техническую работу по дроблению монолита на мелкие независимые друг от друга кусочки.
Как будет
В первом приближении хочется прийти вот к такой картинке, снять хотя бы часть проблем и начать работать с кроссфункциональными командами. Но мы по-прежнему работаем с монолитом и у нас есть внешняя зависимость у мобильной разработки, хоть она уже и меньше, чем была. Чтобы она уменьшилась, мы договоримся добавлять задачи от мобильной команды в баклог и уделять им периодически время 🙂
Во втором приближении мы планируем начать дербанить Component A на независимые кусочки, которые смогут жить самостоятельно. У нас появится архитектураная команда, которая этим будет заниматься.
В будущем хочется сделать мобильные команды кроссфункциональными тоже и прийти к одному баклогу. Но это реальность будет проверять мой план на прочность :)
Originally published at spotykashka.wordpress.com on August 24, 2017.
