Комментарии 11
"Перестроить процессы: перейти на Scrum и SAFe"
- про Scrum увидел, а про SAFe...? Можно здесь поподробнее?
Спасибо за вопрос. Цитата взята из первой части статьи. Ниже, где описание масштабирования, подробнее есть и про SAFe. Если кратко, то scrum - это про одну команду. Когда мы говорим о контуре из шести, то нам уже нужно выбирать фреймворк масштабирования. Для Тикетленд выбор был простой: в продуктовой модели МТС используется SAFe, более того, MTC Live, с которым у Тикетленда тесные связи, также "живёт" по SAFe.
Спасибо за уточнение, о том, что SAFe используется при работе с многими командами одновременно, это ясно, вопрос скорее касается деталей оптимизации именно по SAFe в данном примере.
Если говорить о деталях, то это скорее тема отдельной статьи.
Действительно было не просто, но интересно и по имплементации и по тому, как, например, проходят события SAFe.
PI планирование мы проводим в очном формате вместе с командами МТС Live.
Если есть такой запрос, мы с удовольствием напишем об этом более подробно.
Спасибо за развёрнутую, но не перегруженную статью. Пара вопросов от меня:
1) Правильно ли я понял, что в Тикетленде сейчас несколько команд и один коуч? Который поочерёдно работает с отдельными командами? Или же коуч делит своё время между всеми командами?
2) В начале статьи говорилось, что старая организация команд была ориентирована на приложения, а сейчас команды кросс-функциональные - а в чём разница?
3) Переводятся ли в итоге строи поинты в человекочасы? Со временем производительность команды выравнивается и по итогу X дней спринта равны Y сторипойнтам. Перейти в мир "реальных" величин кажется логичным шагом. Или же вы продолжаете использовать строи пойнты?
Добрый день!
Спасибо)
Ответы на вопросы:
1. Да, все верно. Несколько команд и один коуч.
Я сейчас помогаю коллеге на уровне взаимодействия с бизнесом.
Коуч работает по общему построению взаимодействия со всеми командами (в основном через лидов направлений, PO и тим лидов), а также каждый квартал берет на сопровождение по 1 команде.
У нас есть собственный внутренний чек лист по понимаю зрелости команд. Мы замеряем по нему что у нас есть на старте работы, далее коуч работает с командой квартал, затем сверяемся по чек листу. Если есть еще какие-то не закрытые области, то коуч продолжает работу в этой команде.
Конечно, хотелось бы выращивать каждую команду дальше, но физически пока возможности нет. Поэтому закрываем базовые обязательные вещи, передаем полномочия и идем в следующую команду. В какую команду идти - определяется коллегиально вместе с СТО и другими лидами.
2. В начале статьи шел разговор об МТС Live.
В нем по-прежнему, есть мобильные приложения на IOS и Android и веб сайт.
Команды в Live и ранее были кросс функциональные, но изменился подход к выстраиванию пользовательского пути в сторону обеспечения бесшовности.
Ранее была комана Web и мобилки, стало - все вместе, чтобы выстраивать единое восприятие продута пользователем.
В Тикетленд основная точка контакта с пользователем - это сайт (если мы не говорим про B2B) и также команды кросс функциональные.
3. Стори поинты в часы не переводим, потому что стори поинты - это не абсолютная, а относительна мера оценки. И включает в себя учет нескольких моментов - сложность, риски, объем - все это закладывается в оценку.
Поэтому 1 SP не равно 1 час.
И да, сейчас продолжаем использовать SP, сравнивая задачи между собой учимся не только давать оценку, что помогает прогнозированию.
Но и дискутировать, обсуждать, если оценки разнятся между собой.
К часам не хотелось бы приходить, потому что в часах сложно оценивать командой, обычно в часах каждый член команды оценивает только свою работу, а значит мы привязываемся к оценке конкретного человека.
И прогнозировать в часах, сравнивать сколько закладывал и реально потратил каждый конкретный член команды - это уже какая-то бухгалтерия, основанная на утилизации ресурсов, как по мне.
По третьему пункту.
Мы живём в реальном мире и, к сожалению или к радости, используют эти самые часы. Сложно продать заказчику контракт на Х стори пойтов, если ты аутсорс и работаешь по T&M контракту. Сложно доказать эйчару, что тебе в команду нужен дополнительный разработчик, потому что тебе нужно увеличить производительность на Х стори пойнтов.
Безусловно, стори пойнты рабочий инструмент. Про то, что 1 SP должен быть равен 1 часу вообще речи не идёт. И любая оценка, хоть в стори пойнтах, хоть в часах, хоть в попугаях, должна оценивать риски, сложность и т.д.
Мой вопрос вытекает из того, что по мере того, как разработка перестаёт быть "вещью в себе" и должна быть вписана в другие процессы компании, кому-то и как-то придётся делать эту "бухгалтерию".
Картинки не в том масштабе. Хотелось бы ещё и надписи подробно рассмотреть.
Взболтать, но не смешивать. Рецепт успешной продуктовой трансформации