Максим Цепков - Менеджмент цифрового мира

При этом в самой компании Spotify организационная структура развивается очень быстро. И я хочу интересующимся порекомендовать доклад Yuliya Kurapatenkavaна Saint TeamLeadConf-2018, в котором она рассказывала про логику развития (мой конспект есть в отчете с конференции, а сам доклад по-английски). И вы можете сравнить то, что звучит в докладе с тем описанием фреймворка, которое доступно по ссылке в начале раздела и фиксирует состояние несколько лет ранее.

Пересборка организации.

Здесь стоит рассмотреть практическое применение подобных фреймворков. Один продукт, над которым работают несколько команд, далеко не всегда означает единственный продукт в смысле софта, более того, часто речь идет об одном бизнес-продукте, поддержка которого со стороны софта требует общей серверной части и нескольких приложений на разных платформах – web и мобильных. Естественным образом для того, чтобы какой-то новый функционала стал доступен конечным пользователям, он часто должен быть реализован в серверной части и для каждой из платформ. И тут может быть два подхода: сделать команды, каждая из которых сосредоточенна вокруг каждого софтверного продукта, при этом только она работает с кодовой базой продукта и отвечает за его архитектуру. В этом случае для организации могут применяться фреймворки, подобные LeSS.

Однако, то что задача по реализации нового функционала делится на несколько, каждую из которых выполняет своя команда, сильно увеличивает количество необходимых синхронизаций и время разработки. Поэтому часто применяется и другой способ организации, кросс-функциональные команды, включающие специалистов по всем приложениям и делают все доработки для новой фичи. При этом возникает общее владение кодом, и надо дополнительно принимать меры для удержания целостности архитектуры каждого приложения, а также обучения и передачи опыта, потому что внутри команды такие специалисты не могут учиться. И это получается структура, похожая на клан в Spotify.

Так вот, в зависимости от потока задач и этапа развития компании предпочтительная структура может сильно изменяться. И сейчас IT-компании умеют достаточно быстро и успешно перестраивать свою структуру в зависимости от потребностей развития продукта. Я хочу сослаться на опыт ivi. На TeamLeadConf-2018 Евгений Россинский рассказывалкак они обеспечивали целостность продуктов и поддерживали знания разработчиков при переходе к кроссфункциональным командам от команд, собранных вокруг отдельных приложений. А через год TeamLeadConf-2019 он же рассказывалкак за год они для решения задач реинжиниринга ядра продукта вернулись к командам, организованным по приложениям, провели реинжиниринг, а затем – снова перешли к кросс-функциональным командам. Компания ivi предоставляет чистый цифровой продукт. Однако, похожая бизнес-структура сейчас характерна и для банков и для туроператоров, потому что их продукты сейчас все больше и больше перемещаются в цифровую сферу. Но, насколько я знаю, быстро пересобираться таким образом они еще не умеют, да и для IT опыт ivi является передовым. И, думаю, это может дать хорошее представление о том, какова она – динамично развивающаяся и перестраивающаяся современная цифровая компания, насоклько быстро она умеет изменяться.

Сложные фреймворки – SAFe и Enterprise Scrum

Scaled Agile Framework (SAFe)является самым сложным Agile-фреймворком, но при этом – самым популярным. Это сложная конструкция уровня компании с управлением потоками создания ценности и архитектурой. На мой взгляд, популярность этого фреймворка сродни популярности PMBOKили RUP – в нем есть все и на все случаи жизни, и предлагается просто взять нужное. Кстати, автором фреймворка является Дин Леффингуэлл (Dean Leffingwell), один из авторов RUP.

И, на мой взгляд, это – неработоспособная конструкция, хотя и привлекательная в своем инженерном совершенстве. Фреймворк не будет работать по тем же самым причинам – его сложность превышает разумный предел, при этом обвинить сам фреймворк будет невозможно, всегда окажется, что это вы не смогли его правильно реализовать. И дело не только в сложности фреймворка: SAFe пытается за счет сложных регламентов превратить запутанную область в сложную, а это – невозможно. Подробнее о сложности областей – в описании Кеневин-фреймворка в главе «Место Agile-команд в компании».

Вместе с тем, в силу популярности и привлекательности есть много проектов внедрения SAFe. B эти проекты часто несут позитивный эффект, как и многие проекты внедрения проектного управления. В процессе внедрения компания разбирается с тем, как устроены ее цепочки создания ценности. Таким образом, появляется структурированное описание деятельности компании, при чем не на уровне процессов, а через цепочки создания ценности, что представляет собой значительное методологическое продвижение вперед.

Другая выгода, общая для внедрения большинства Agile-фреймворков – разрушение застывшей бюрократической структуры, разморозка коммуникаций и инициативы в компании. Но она часто уже достигнута, так как до глобальной реорганизации компании через внедрения SAFe следует этап внедрения Scrum или других Agile-методов на уровне отдельных команд. Впрочем, уровень отдельных команд в SAFe тоже специфицирован, там как раз Scrum или Kanban, а вот над ними – несколько уровней управления компанией.

Довольно интересен фреймворк Enterprise Scrumпредлагает переход от создания IT-продукта к поставке ценности, управляемой набором связанных метрик. К сожалению, в отличие от всего остального он не завершен. Его создатель Mike Beedle, кстати, один из авторов Agile-манифеста был, к сожалению убит в Чикаго весной 2018 года, и работа не завершена. Однако, на сайте есть достаточно подробная конструкция системы метрик, совместимая с Agile-методами управления, и, возможно, она вам окажется полезной при конструировании собственной, хотя в готовом виде ее, естественно, брать не стоит.

По опыту лекций об Agile в разных аудиториях, рассмотрение кейсов Agile-трансформации вызывает большой интерес слушателей. В том числе – таких известных, как Agile в Сбербанке или Альфа-банке, хотя, казалось бы, об этом можно найти много публичных материалов. Причина, думаю, в том, что хорошие системные материалы погребены под большим количеством попсовых изложений, которые не раскрывают суть, а иногда ее искажают. Поэтому я начинаю рассказ о кейсах, чтобы в совокупности дать многовариантную картину. Сейчас речь пойдет о трансформации банков, причем не IT-подразделений, а работы бизнеса в целом.