Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 20
Как по мне в статье, как и во многих других статьях на тему проектной деятельности, слишком много воды и мало фактуры. Если опустить все лишнее, то единственная мысль автор статьи: на основе отзывов команды сократил количество созвонов, все стали довольны. Каких созвонов, почему они были неэффективны (хотя наверное должны хоть чем-то быть полезны, раз из вводили когда-то), сколько людей участвовало на созвонах (может нужно было просто убрать лишних людей с созвонов, а не убивать его полностью?)... Все это останется за рамками статьи, хотя именно в этом могла быть истинная ценность. В общем не хватило деталей и фактуры, потому что без этого статья - набор общих фраз и мыслей.
Я так понимаю что главное изменение - это переход от команд "фронтендеров"/"бекендеров" к фиче-командам, где собираются все кто нужен чтобы втащить нужную фичу. Уменьшение дозвонов - это уже следствие того что коммуникация стала локальной для команды и все глубже погружены в контекст.
@Mox, «В точку! Вы считали самый главный "двигатель" этой трансформации.
Переход от функциональных колодцев (когда бэк, фронт и QA живут в разных мирах) к кросс-функциональным фиче-командам — это и был фундамент. Когда все компетенции для поставки ценности собраны в одной команде, 80% внешних зависимостей и бесконечных согласований между отделами просто отмирают за ненадобностью.
@martopt, Спасибо за честный фидбек! Попробую добавить конкретику. Вводили эти созвоны потому что так было описано в фреймворке, но как я говорил в статье скрам это не панацея и его можно и нужно адаптировать под реальный контекст. Статья — это скорее обзор трансформации системы. Если интересны еще детали — пишите, разберу тут или в следующих постах)
На старте внешние консультанты приглашали на общие синхронизации слишком широкий круг людй, включая тех, кто не имел прямого отношения к текущим задачам. В начале мы конечно же сузили состав участников до тех, кому этот контекст важен/необходим. После этого мы поработали над регулярностью.
Со временем стало ясно, что на некоторых встречах ценность просто не рождается. Например, еженедельный общий синк. После перехода к кросс-функциональным командам все вопросы стали решаться локально внутри них. На общем созвоне нам банально стало нечего обсуждать и мы его либо завершали за 5 минут, либо переносили.
Отмена встреч произошла только после сбора обратной связи и наших наблюдений, когда команда прямо сигнализировала о перегрузе. Не было такого, что мы просто в моменте решили всё отменить.
Ну вообще как по мне ценность и не должна рождаться на каждом созвоне. Тот же самый синк, который вы привели в качестве примера, самим своим названием намекает, что он существует для синхронизации, то бишь для передачи информации о ходе разработки между командами/сотрудниками, сугубо в целях того, чтобы все были более менее в одном информационном поле. Это так-то тоже ценность.
На счёт кросс-функциональных команд честно говоря тоже не очень понял. Вы замешали как-то команды, и теперь у вас бывший лидер фронтэнда, например, руководит командой, где есть и фронт, и бэк, и qa, да и ещё в довесок пара аналитиков? Как он может адекватно руководить кем-то, кроме фронтэндеров? Он же банально стэк можно не знать, или знает, но не настолько глубоко, чтобы корректно ставить задачи, верьюить код и т.д. Ну или у вас в компании все руководители по умолчанию фулстэк и могут одинаково во все...
В общем извините, пока не особо убедили. Может я чего-то не понимаю.
@martopt давайте разберем по пунктам.
"Это так-то тоже ценность."
Согласен, синхронизация это тоже ценность. Но вопрос в её стоимости и целесообразности. Мы для себя решили, что нету целесообразности."Вы замешали как-то команды, и теперь у вас бывший лидер фронтэнда, например, руководит командой, где есть и фронт, и бэк, и qa, да и ещё в довесок пара аналитиков?"
Здесь важно разделять роли. У нас нет лида фронтенда, который внезапно стал командовать бэкерами. Командой лидит ProductOwner. Его главная задача — не в том, чтобы корректно ставить технические задачи, а определять цели и приоритеты для бизнеса. За качество кода отвечают сами эксперты. Как я уже говорил, у нас круговое ревью между командами. Фрон ревьювит фронта, бэкер ревьювит бэкера.
Есть TechLead, который отвечает за общую архитектуру и инструменты, и я как Delivery Manager, отвечающий за людей и эффективность потока.
Суть кросс-функциональности не в том, чтобы сделать всех фулстеками, а в том, чтобы собрать в одной команде всех специалистов, необходимых для поставки фичи от идеи до прода.
Хм у меня скорее вопрос а зачем тим лиду досконально знать суть работы всех членов команды вне зависимости от роли? Звучит как что то напоминающее микроменеджмент. Ну и мне скорее сложнее представить как может нормально работать структура где у команд жесткое функциональное разделение.
Собственно кросс функциональные команды, которые самостоятельно способны "довозить" изменения до релиза это основа scrum, то что команды в скрам должны быть кросс функциональные это прямо написано в скрам гайдах. Другой вопрос, что такой подход не всем может подходить или не всем нравится. Но если судить по вашему комментарию, у вас сама идея кросс функциональных команд вызывает вопросы. Что странно в статье про скрам )
Хороший кейс - круто, что показал не только результат, но и весь путь: сопротивление, перегруз по созвонам, ошибки и постепенную стабилизацию. Особенно откликнулась мысль про то, что сначала нужно чинить доверие и контекст, а не процессы.
Из того, что можно усилить, как мне кажется - это увидеть больше конкретики по метрикам и решениям: какие именно изменения дали наибольший эффект и какие практики в итоге «не взлетели».
Но в целом видно системный подход и реальное влияние на бизнес. Респект.
@rasullx, Спасибо за комментарий. Рад, что тезис про "доверие и контекст" отозвался — для меня лично это был один из самых важных инсайтов на этом проекте. Процессы без доверия в команде просто превращаются в саботаж и реальных результатов либо не будет либо будут через большие потери.
да это же нейронка
@ivanopulos, а как вы это определили? Сходили и прочли оригинал? или по какому-то другому критерию?
Как слесарь, по первой специальности, хочу сказать, что в вашем новом процессе у вас шестерни в зацепление не входят
@mazdai19, пока все путем;)
Но если по сути, то статья выглядит немного странно. С одной стороны подаётся как пример успешного внедрения скрам. С другой такое ощущение что все изменения инициализировать и проводились сверху, менеджером и тех льдом и консультантами. Не до конца ясно какую роль в этом играли сами команды, кроме выдачи фидбека. И тут есть два момента на мой взгляд, можно ли такое в принципе считать scrum или agile. А второе, не один раз видел в подобных ситуациях картину, когда сверху командам прилетает какое то требование по изменению процессов, которое члены команды не понимают зачем нужно, и в итоге люди продолжают работать по старому посылая наверх фидбек, что все теперь хорошо, или проводя формально какие то ритуалы просто потому что "так надо" не видя в них реально никакой ценности.
@mazdai19 С одной стороны подаётся как пример успешного внедрения скрам. С другой такое ощущение что все изменения инициализировать и проводились сверху, менеджером и тех льдом и консультантами.
Вы правы, изменения инициировались сверху, но не просто потому что захотели шороху навести. Это реакция на конкретные проблемы, которые я описывал в статье.
Когда бизнес видит, что деньги сгорают в бесконечных согласованиях, внедрение изменений — это вопрос выживания, а не каприз. Спустя n-e время такого темпа работы более бизнесОриентированные компании подвинут с рынка.
Вы как владелец бизнеса/топ менеджер в такой ситуации оставили бы все как есть надеясь на то, что все само собой наладится?
Также не очень понимаю когда везде лезут со словами "ИНИЦИИРОВАЛИ СВЕРХУ", что не правильного в том, что топ менеджмент думает о будущем компании и не хочет чтобы в один день все сотрудники вместе с ними оказались на улице? Да, возможно бывают задачи, которые спускаются сверху ради галочки, но лично с этим еще не сталкивался и я не сторонник изменений ради изменений если все работает, если работает как нужно.Не до конца ясно какую роль в этом играли сами команды, кроме выдачи фидбека
КОманды влияли на результат. Когда консультанты пытались навязать нам по их мнению "оптимальные" для нас недельные спринты, именно команды первые возразили потому что понимали (потонем в созвонах и не останется времени на код). Мы их поддержали и отстояли 2х недельный цикл. Это не формальное выполнение ритуалов, а активное участие в настройке процессов под свои нужды. На этом этапе для того чтобы сделать эффективный и удобный процесс кроме фидбека какое еще участие они должны были принимать? Фидбек это одно из главных вещей, которое требовалось от команд.
@mazdai19, А второе, не один раз видел в подобных ситуациях картину, когда сверху командам прилетает какое то требование по изменению процессов, которое члены команды не понимают зачем нужно
Не спорю, был и такого рода фидбек, но тут нужно учитывать контекст всего продукта, а не одной конкретной функции. Команду в целом может устраивать то, как все работает здесь и сейчас.
Архитектурный комитет 7 дней, Системный комитет 20 дней, Дизайн и Аналитика 4 дня, Бэк 6 дней, фронт 3 дня, тестирование бэка и фронта 2 дня. В конце все равно переделки, не соответствие т/з и прочее. В сумме 42 дня ТТМ (офигенно).
Все цифры и ситуация абстрактная для примера. члены команды не понимают зачем нужно, и в итоге люди продолжают работать по старому посылая наверх фидбек, что все теперь хорошо, или проводя формально какие то ритуалы просто потому что "так надо" не видя в них реально никакой ценности.
Судьба сотрудника, который сознательно и скрыто саботирует изменения, известна. Даже когда ему предоставили полный контекст, выделили время и пространство для обратной связи, публично заверили в готовности выслушать и доработать процесс под его потребности.
Смотрите, я не пытаюсь сказать, что то, вы делали плохо или неправильно. В статье описаны вполне разумные вещи, и кросс функциональность, и DoD и пр. Просто в описаниях скрам обычно пишется (например в гайде на скрам орг), что речь идёт о том что команда должна быть "self-managing, meaning they internally decides who does what, when, and how". А то что описываете вы на это описание не очень похоже
Ну собственно ваша следующая фраза про судьбу сотрудника, она по моему явно показывает что о селф менеджменте речи не идет
@mazdai19, По моему мнению это высказывание "self-managing, meaning they internally decides who does what, when, and how", не относится к тому типу сотрудников, которых я перечислил Даже когда ему предоставили полный контекст, выделили время и пространство для обратной связи, публично заверили в готовности выслушать и доработать процесс под его потребности.
К великому сожалению не все работает так как описано в учебниках. Нужно учитывать большое количество деталей (менталитет, зрелость команды и прочее).
Спасибо за ваши комментарии, так или иначе каждый комментарий дает по другому посмотреть на ситуацию и раскрывает новые детали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прыжок веры, или «Синхронизационный ад». Как мы внедряли Scrum в крупном маркетплейсе и выжили