|
This article has been also translated to English.
"You can't always get what you want
But if you try sometimes, well, you might find
You get what you need"
(C) The Rolling Stones
В роли organization agility консультанта мне часто приходится помогать своим клиентам (в частности руководству зрелых организаций) построить правильный организационный дизайн - т.е. подбирать структуру организации под нужды бизнеса. Это очень нетривиальная задача, без правильных ответов. Но что её делает ещё сложнее - так это отсутствие общего базиса, терминологии, вокабюляра.
В этой статье, я хотел бы пояснить основные модели устройства software product development организаций (которые я наблюдал). Но не просто их нарисовать отдельно, а связать их эволюционными связями - то есть показать во времени, как один орг дизайн перетекает в другой, и как и откуда в компаниях появляется нужда "трансформаций".
Так как орг дизайн неотделим от процессов, мы рассмотрим шесть классический организационно-операционных схем:
Я описываю в статье эти шесть моделей управления и устройства, как если бы они вытекали и проистекали одна из другой. Это лишь один из вариантов развития событий. Я это делаю только лишь из целей более когерентного повествования. По сути же - это модели несвязанны между собой, не имеют ничего общего с фазами зрелости организаций и являются свободным выбором управленцев, которые осознанно (или неосознанно, что чаще) делают выборы, определяющие формирующийся орг дизайн. Эта статья про причины и следствия этих выборов.
Это также не статья про "вотерфолл VS. agile" (это слишком очень упрощённый взгляд на вещи, мир цифровых организаций не двоичен). В этой статье вы узнаете о более широком поле решений, которые стоят перед дизайнерами организаций - высшим руководством.
Нельзя рассматривать устройство зрелых организаций, не оговорив то, как формируются стартапы с точки зрения их структуры. Это важно, так как поможет нам понять дальнейшую эволюцию и "качели" в орг дизайне от стартапа к энтерпрайзу и потом опять к стартапу - эти качели, к слову, постоянны в любой организации и провоцируются временными кризисами роста (об этом подробнее ниже).
И так, если в рафинированном виде software product development в стиле "a la startup" - это зачастую кросс-функциональная организация работы небольшой группы людей вокруг определённой бизнес стратегии с ясными портретами конечных пользователей и прямым взаимодействием с ними. В стартапах из-за ограниченности средств и ресурсов присутствует лазерно-узкий фокус на определённом сегменте рынка (на самом деле бюджет ограничен всегда, просто в стартапе это именно бюджет выживаемости, а не искусственный бюджет "проекта"). Такой фокус создаёт ясные цели и понятные всем метрики и майлстоуны.
Первый отдел, который зачастую формируется и начинает отделяться от кросс-функциональной (в будущем R&D) группы продукта - это продажи, sales. Это связано с "шумностью" их работы (постоянные звонки), несколько некомфортной для IT-шников экстровертностью специалистов по продажам и прочими правдивыми стереотипами.
Изоляция отдела продаж приводит к самым плачевным (в долгосрочном плане) последствиям - гонкой за закрытием контрактов в ущерб негативной прибыли, вызванной нереальными запросами на функционал. Такие последствия разгрести через год-два порой уже практически невозможно, и такая компания будет всю свою жизнь "быть в долгу у неприбыльных, но важных клиентов". Не говоря уже о прессинге и атмосфере внутри R&D, который будет всегда "виноват в отставаниях и непопаданиях в оценки и сроки".
Задача орг дизайна компании такой фазы развития - не дать этому расколу случиться, держать всех вместе в одном ритме, с общими целями, вместе общаясь с клиентами, поддерживая общий фокус внимания на поставляемой ценности, а не на оптимизации локальных процессах в ущерб общих. Если менеджмент сможет выстоять этот бой и удержать натурально присущую стартапу продуктовую культуру и нацеленность на клиента, тогда с ростом числа сотрудников организация сможет перескочить через уровни "IT разработки" и "Проектного управления", описанные ниже. Если нет - увы, путь будет тернистым.
Стоит сказать, что шансы на успех построения продуктовой культуры тут не более 2-5% по моим наблюдениям. К несчастью "золотые стандарты индустрии" здесь играют против нас, и copy-paste решения, которые руководство одних компаний перенимают у соседних компаний (которые к слову ни чуть не лучше их собственных, а совместное обучение в школах Executive MBA ещё сильнее укрепляет уверования в коллективной правоте) - так вот, эти copy-paste решения будут приводить к орг дизайну, который лишь изолирует и экранирует IT от бизнеса... Это спираль, уходящая вниз и уводящая IT всё дальше от бизнеса в подвал организации.
На данном этапе начальная бизнес-модель (или её адаптированный и улучшенный вариант) получает подтверждение позитивным откликом рынка. Компания получает первый реальный раунд инвестиций. Растут аппетиты, а с ними и стресс и давление. Начинается найм и "рост" (поголовья).
Возникает первый кризис властного управления. Он виден уже при 30-50 сотрудниках-инженерах. Это кризис роста. Он связан с тем, что личных влияний и связей, которые ранее позволяли функционировать (несмотря ни на что) при меньшем количестве людей, уже недостаточно. Трещины, заложенные ранее, проступают всё отчётливее с каждым дополнительным сотрудником. Execs (директора) отдаляются от реалий работы и начинают заниматься "стратегией" (иногда просто из-за некомпетентности решать реальные проблемы на местах).
Для компенсации невовлечения exec-уровня нанимаются специалисты по выстраиванию процессов с соответствующими навыками (и enterprise культурой). Это новая элита уровня "exec минус 1" - вице президенты. И у каждого отдела он теперь свой.
Так в частности в разработке мы видим становление VP of Engineering. Так появляется IT пузырь с его непрозрачными процессами, негибкостью и всё теми же проблемами "отставания и непопадания в сроки", но теперь с более дорогими оправданиями и видом гордого enterprise.
"Мы переросли стартап, давайте строить процессы" - говорит VPoE, - "Вы хотите чёткие сроки и верные оценки? Не вопрос, я это беру на себя. Но учтите, что нам нужно начать ограничиваться от ваших постоянных изменений и продажников с их хаосом и текучкой, строя инженерные процессы".
С этого момента организация в ловушке. Аппетиты бизнеса будут расти (давление). Маркетинг будет открывать всё новые потенциальные сегменты рынка (расфокус). Но R&D будет и дальше отгораживаться от неудобных "изменений требований" (изменяются, к слову, не требования, а понимание). Это всё будет приводить к взаимной потере доверия между бизнесом и IT. И, конечно же, никакой бизнес стейкхолдер не будет готов рискнуть своей шкурой и возглавить управление продуктом (так, как мы его понимаем в Scrum). И, соответственно, так как больше некому, то управлять разработкой будут директора разработки (инженеры с полномочиями), которые будут сфокусированы на постоянной операционке - латании дыр софта и разруливании бесконечных драм выпуска новых версий (из-за вечной гонки последних нескольких лет, качество, конечно же, страдало), - у них будет мало бизнес-фокуса. И это понятно, их не для него нанимали вообще-то.
Пример компаний, которые находятся на таком уровне: бизнесы, производство софта которых не является их прямым видом деятельности (к примеру e-commerce), а вызвано только лишь суровой необходимостью. Этого самого софта им также нужен весьма ограниченный объём - 20-50 айтишников в целом справляются, плюс 1-2 внешних вендоров.
Уход в работу только с внешними вендорами, к слову, может здесь быть не так уже и вреден, так как по меньшей мере позволяет менеджеру компании научиться реальным хорошим практикам управления разработкой (если, конечно, вендоры им следуют).
Компания может остановиться на этом уровне при отсутствии нужды или возможности роста.
Компонентная разработка - или формирование функциональных инженерных групп вокруг технологических слоёв (базы данных, backend-системы, различные слои интеграций, frontend-каналы).
С ростом IT отдел распадётся на группы, каждая из которых будет владеть своей частью архитектурного слоя. То есть соответствие "компонента программного продукта" и "выделенной группы людей" станет практически однозначно. Так, будет группа "кора", "бекэнда", "фронтэнда", а также функциональные группы "тестирования" и "эксплуатации" со своими линейными руководителями. Так, мы приходим к тому, что часто называется "компонентной разработкой" - это логическое развитие предыдущей модели, которое усиливается и кристаллизируется с ростом сложности систем и количества инженеров. В таком виде организации дизайн программной системы и дизайн самой организации становятся зеркальным отражением друг друга. Этот феномен известен, как закон Конвея, и работает в обе стороны, где одно усиливает другое.
Компоненты могут называться другими словами в вашем домене - платформами, ядрами, шинами, системами, программными комплексами... Суть у них одна. Но как бы они не назывались, они описывают архитектуру системы, внутренние свойства продукта, но не использование её пользователями. Это технические свойства продукта. Именно поэтому в таком орг дизайне вовлечение бизнес стейкхолдеров усложнено, так как есть определённый ментальный барьер между запросами бизнеса (функционалом для клиента) и тем, с чем работают инженеры и их группы (слоями архитектуры). "Зачем мне знать про бизнес нужды, дайте нам задачи на backend!" - говорит программист, работающий full-time с backend внутренностью системы.
Так усиливается раскол двух миров бизнеса и IT, они начинают говорить на разных языках и орудовать различными метафорами. Вспомните модель стартапа выше - тогда мы все говорили общим языком, как же стало, что мы так быстро забыли, что умеем общаться? И тут есть два пути развития орг дизайна - переход на продуктовую разработку (через трансформацию команд, об этом ниже в соответствующей главе статьи) и ввод переводчиков (через ввод прослойки проектных менеджеров, аналитиков и архитекторов)...
Представьте, что приходит бизнес запрос на разработку, а у вас 5 компонентных групп, каждая из которых владеет своей частью системы. Они все должны что-то сделать в коде, чтобы реализовать этот бизнес запрос. Как этим управлять? Вам явно нужна группа людей, которые смогут проанализировать и расслоить бизнес запрос на инжерерные задачи, сформулировать и поставить их исполнителям. Затем регулярно убеждаться, что эти работы делаются, решать конфликты и зависимости между ними. В конце собрать всё воедино. Вы спроектировали сложную систему орг дизайна, которая лишена прозрачности, с низкой адаптивностью, длинными очередями, медленными циклами обратной связи и различными фокусами у разных групп. Этим очень сложно управлять.
Но важно заметить - эта добавленная сложность. Она не вызвана встроенной сложностью разработки цифровых решений. Она вызвана вашим орг дизайном. Всё могло быть по-другому, если бы вы не начали смотреть на вашу организацию, как на зеркало вашей IT системы и не начали строить отделы вокруг слоёв системы. Теперь то, над чем работают инженеры и то, что нужно бизнесу - это ортогональные вещи.
И сложностью нужно кому-то управлять..
Несмотря на постоянную мискоммуникацию между частями организации и вычерпывание воды из дыр (именно поэтому такая организация ещё на плаву), бизнес цели так или иначе удовлетворяются, количество бизнес стейкхолдеров продолжает расти, количество разносторонних запросов, естественно, тоже.
Если ранее директора и линейные менеджеры внутри R&D умудрялись держать наступление и плотину запросов, то сейчас они уже просто не в состоянии этот делать. К слову, усугубляет всё и рост численности IT поголовья, в компании уже 70+ инженеров (и уровень хаоса процессов растёт экспоненциально) и постоянный рост сложности систем. Иронично, что найм растёт, как компенсация низких темпов разработки, а прирост темпа разработки, естественно, тем хуже, чем больше IT отдел, который работает по старинке).
Мы видим следующий (второй) кризис управления - сложность управления зависимостями между частями организации и процесса. Решения? Проектный менеджмент и матричная структура!
Формируется институт PMO. Вводится соответствующий жаргон. Характерно, что процессы разработки практически ничем не отличаются от предыдущей фазы, кроме того, что работы теперь кластеризуются в вымышленные сущности, называемые "проектами", к каждому из которых приставлен толкатель проекта (проектный менеджер). Но то, куда проекты заталкиваются, остаётся без изменений - это IT отдел, такой же как и ранее со всеми теми же подходами и проблемами выпуска и запущенным качества.
Количество проектов растёт. Для того чтобы понимать хоть что-то, заводятся проекты проектов - "программы" и "портфели проектов". Растёт внутренний документооборот и уровень иерархической отчётности. Появляются, соответственно, менеджеры программ и портфелей.
Это ментальная надстройка, overhead. И она не помогает бизнесу и разработке взаимодействовать эффективнее. Несмотря на всю избыточную отчётность, инструменты проектного менеджмента, автоматизацию отчётности и попытки навести порядок, офис проектной разработки (PMO) не становится эффективным интерфейсом коммуникации между бизнесом и R&D. Это боковой отросток организации, мир иллюзий, который притупляет организационную боль. Ведь, согласитесь, когда есть проекты появляется ощущение контроля.
Из хорошего - такая структура может выдержать десятки сотен инженеров (и даже тысячи), и в отличие от предыдущих двух подходов (Стартапа и IT разработки) - она масштабируема, поэтому следующий кризис очень нескор...
Так что в отличие от предыдущих этапов кризисов и дальнейшего развития компаний, этот этап очень стабилен и может длиться годами (в отдельных случаях даже десятилетиями). В частности стабильность этой фазы развития связана ещё и с отсутствием новых взглядов на орг дизайн на высшем уровне руководства - с проектным управлением знакомы все и с пелёнок, так что всё происходящее кажется здравым смыслом без альтернатив. А наличие таких талмудов, как PMBOK и таких стабильных организаций, стоящих за ними, как PMI, придаёт уверенности в выбранном пути.
Пример компаний, которые находятся на таком уровне - бизнесы, которым нужен существенный объём софта (к примеру банки, телекомы), но к софту отношение у них утилитарное, он не поставлен [всё ещё] во главу бизнес модели [возможно из-за медлительности осознания уровня дигитализации мира немолодыми управленцами] и нужен лишь, как сервис для решения бизнес задач.
Всё было хорошо (годами) с точки зрения операционной эффективности, пока конкуренты (будь они прокляты) не стали выпускать "аппы" и конкурировать с нами новыми невиданными бизнес-моделями.
Это кризис инноваций. Как известно оптимизация операционной деятельности противоречит уровню инноваций, креативности, и свободе творчества. Согласитесь, какая к чёрту свобода творчества, если у вас 3 уровня программ в проектном портфеле с пятилетними циклами бюджетирования?...
Но тут недокомпания в гараже размером "два друга и собака" выходит на рынок и начинают отгрызать лояльных клиентов у нашего стабильного бизнеса. При чём реально неясно за счёт чего... Ну и что, что у них аппа, ну и что, что мобильный трафик в стране сейчас 70%, ну и что, что все пользуются Netflix, Zoom, Airbnb и Miro. И тут в головы руководству закрадывается первое минутное сомнение в правильности и непоколебимости выбранного пути развития (но вспомнившееся количество кеша на банковском счету и имейлов в клиентской базе быстро снимают неудобное напряжение).
"Ну ОК. Меняться так меняться - давайте соберём команду из 5 человек, быстро выпустим аппу и забудем. Кстати, мы сможем в этом случае добавить Скрам в перечень инструментов проектного менеджмента, наш PMO уже давно об этом говорят. Скрам - так Скрам. И да, для снижения затрат будем использовать, конечно же, наш текущий редмайн". (внутренний диалог в голове у CIO).
Так рождается то, что я называю сателлитной разработкой. Это как бы продуктовая разработка, но только вообще не она. Это разработка чего-то сбоку, и к сожалению, это что-то сперва (и ещё какое-то время) кажется реальным продуктом.
Это попытка ухода от неизбежной трансформации, попытка оттянуть время. Это пилот без возможности его масштабирования, и соответственно научиться чему-то. Так как, одно дело - написать аппку в сторонке, другое - трансформировать свой взгляд и учиться смотреть на своё "core решение", как на продукт, а не как на набор программных комплексов, сервисов и компонент с такой же зеркальной структурой IT отдела. Это упущенный шанс.
Помните три страницы назад в начале этой статьи (и 5-10 назад лет жизни организации), когда будучи стартапом весь её софт был продуктом, решающим задачи бизнеса?
Об этом уже не только забыли, но уже даже забыли людей, которые это помнили. А наличие инженерных групп, индивидуалистично владеющих "компонентами", "системами" и "платформами" плюс жировая прослойка проектной мифологии [тут копирайт мой, если что] уже никак не позволяет смотреть на всё это хозяйство, как на продукт или хотя бы семейство продуктов, не говоря уже о поиске реального хозяина этого продукта со стороны бизнеса.
Так что единственным возможным экспериментом тут и правда является играться в сторонке с чем-то новым и по-новому (о инновации!); а существующее legacy, на котором основан работающих бизнес, продолжать делать так, как и ранее (ведь оно уже делается высоко-операционно-эффективно). Да и ведь просто страшно поломать что-то работающее!
Но, важно понимать, что iOS App - это не продукт. Это канал, интерфейс, "дополнительная клавиатура" доступа клиента к ценности, которую предоставляет ваш бизнес. Это не сам продукт, это его слой. Такой же, как и "фронтэнд" и "бекэнд". Это по сути ещё один фронтэнд. Nothing more.
При всей кажущейся выгоде пилотирования новой аппы на стороне без ломания существующей функционирующей организации компания словит море тех зависимостей от core систем. А в последствии увидит и встречные зависимости по достижению feature parity - запросы на фичи, которые есть в старом продукте, но их ещё нет в аппе, что ломает user journey.
Стоит сказать, что это не новая модель, это всё тот же проектный менеджмент, так как для проектной организации написание аппы - это просто ещё один проект. Так что не стоит ждать, что в таком подходе компания узнает о себе что-то радикально новое, кроме разве что того, как "сильно у нас всё связано и запущено", что даже "простую аппу мы уже год как не можем выпустить".
Продукт же - это всё то, к чему этот интерфейс предоставляет доступ, плюс сам этот же интерфейс. И если слово продукт кажется каким-то недостаточно крупным или же перегружено в вашей индустрии другими определениями (к примеру "банковский продукт" - это не то, что я имею в виду), тогда можете попробовать использовать термин "бизнес продукт".
Выбор между операционной эффективностью и инновациями - это ложная дихотомия. Здоровой организации, которая осознаёт динамичность мира, нужно и то, и другое. При чём везде и одновременно.
И продуктовый подход - это customer-centric взгляд на product software development, то есть наука формирования орг структуры организации в соответствии с ценностью для клиентов. Это клиентоориентированность сквозь всю организацию. Вертикально.
Помните выше я писал про "качели" организаций от startup к enterprise и обратно. Вот это как раз виток назад - в лоно стартапа. В таком орг дизайне каждая продуктовая вертикаль (а в идеале она всего одна на всю корпорацию - так как бизнес продукт по большей части у всех один) - это и есть по своей структуре стартап - инкапсулированная продуктовая организация со всеми функциями, обеспечивающими успех бизнес кейса.
Переход на вертикальное устройство организации путём построения продуктовых (а ля стартап) групп внутри корпорации, на моём опыте, не случается эволюционно, натурально. Это революция, которую драйвит реформатор изнутри. Это трансформация орг структуры через отбрасывание всего ненужного и наросшего за время. Это упрощение структур и процессов. Это сложная, медленная, вдумчивая и дорогая работа. Но при этом её можно делать без особых рисков и постепенно. К примеру, формируя продуктовые группы одну за одной, постепенно откалывая людей от централизованного IT отдела и формируя из них новые постоянные кросс-функциональные и кросс-компонентные команды с бизнес фокусом. [Это несомненно тема отдельной статьи и это то, в чём у нас в Scrum Ukraine есть глубокая экспертиза - подготовка и проведение продуктовых трансформаций крупных организаций].
Но опытными консультантами тут никак не обойтись - для подобных коренных изменений устойства организации нужна управленческая воля менеджеров компании. И желание глубоко разобраться в причинах избыточной сложности и причинах старения организации. На такие подвиги, по моим наблюдениям, способно 2% организаций. Но, как говорил Деминг: "Вы можете не изменяться. Выживание необязательно".
Но, если вы задумались о продуктовой разработке, то тут важно понимать всю палитру вариантов её организации и ловушек мышления. Определение и нарезка вертикалей продукта - отдельная большая тема, которая тоже очень сильно влияет на орг дизайн. Чаще всего встречаются следующие модели (в порядке уменьшения частоты их использования):
В продукте есть один функционал (feature), связанный с оплатами, другой - с функциями обмена сообщениями между пользователями и третий - с экспортом сложных данных в отчёты? Вы можете попасться на удочку "фичи = продукты" и построить продуктовую организацию из трёх команд, каждая из которых занимается своими фичами.
Чаще всего, в таком орг дизайне каждой команде назначается свой "владелец продукта" (пишу в кавычках и с маленькой буквы, чуть ниже вы поймёте почему), которые каждый имеют свой "бэклог" (тоже в кавычках) и управляют приоритетами разработки внутри своей feature-области. Итого у нас три "владельца продукта" и три "бэклога".
Плюсы такой системы - фокус команд на поведении системы и уменьшении пересечений в коде между ними, так как фичи за исключением редких общих библиотек, - это разные куски кода.
Минусы - 1) низкая адаптивность и 2) завуалированная локальная оптимизация.
Представьте, что со следующего квартала стратегия компании существенно меняется и функции экспорта сложных данных, которые постепенно вырастают в документооборот, становятся в 10 раз важнее других фич продукта. То есть каждый элемент "бэклога" документооборота (даже самый нижний) важнее самого верхнего элемента других "бэклогов". Но каждый продолжает с важным видом месить свой "бэклог" и кормить из него свою команду. Это локальная оптимизация. Так как если бы мы завели один Настоящий Бэклог Продукта (с большой буквы и без кавычек) на всех, то в нём всё стало бы прозрачно ясно. Но такого Бэклога нет, а есть феодализм и междоусобные войны за свои огородики.
Что случится в такой компании? Отдаст ли "владелец продукта" сообщений свою команду "владельцу продукта" документооборота?
На моём опыте - нет. Жажда статуса, страх потерять работу, умение выдумывать фичи, игра в политику - всё это будет работать вопреки здравому смыслу, который кричит: "все должны работать над документооборотом и больше ни над чем!". Так что ничего не изменится и компания будет медленно делать то, что очень важно, параллельно расходуя ресурсы на то, что вообще неважно. Это снижает адаптивность.
Если нарезка по фичам не выдерживает серьёзной критики, то нарезку по конверсиям сложнее оспорить, она звучит бизнесово. Вот у нас есть часть воронки, который нацелен на конвертацию гостей в лидов, вторая часть - лидов в платящих покупателей и третья - возвращающиеся пользователи и повторные продажи.
Давайте же нарежем нашу продуктовую организацию на три "вертикали". И добавим для моды ещё четвёртый более адаптивный и гибкий "growth hacking", потому что, к слову, у всех конкурентов он тоже есть, а значит он нужен (это аргумент!)
Проблема такой нарезки в том, что оптимизация одной конвертации (к примеру гостей в лидов) может негативно сказываться на последующей. Я видел компании, которые закупали базы клиентов или партнёрились с другими ресурсами, создавая много юзеров и лидов, которым никогда не было суждено стать платящими пользователями. Так что в такой схеме мы тоже можем попасться на приманку быстрой локальной оптимизации. Ведь по сути промежуточные конверсии полезны только для анализа потерь, оптимизировать же нужно передвижения пользователя по всей воронке.
Опять таки, в разные периоды жизни продукта, разные воронки могут иметь разный приоритет развития. И тут мы не более гибкие, чем при нарезке по функционалу.
Вот это уже интереснее. Бизнес линии - это вам не вымышленные сущности. Это P&L. И тут как ни крути, кто платит, тот и заказывает музыку (т.е. разработку). Тут, каждая бизнес линия - это продукт со своими командами разработки.
Пример организаций, где это отлично ложится на внутренний мир - сервисные организации, a la банки. Где к примеру отдел кредитов и рисков может вполне легально разрабатывать под себя решение - продукт.
Узким местом такого дизайна будут вечные вопросы: "а кто отвечает за общие модули и инфраструктуру". И заведение отдельной горизонтальной сущности ("платформенной или "core" команды), увы, встречается не так редко, как хотелось бы. Почему "увы"? Да потому что, будучи, центральным звеном они будут собирать на себя все зависимости, иметь свой "платформенный бэклог" и своего "платформенного владельца продукта" (обратите внимание на кавычки). Исходя из каких соображений будет этот т.н. "владелец продукта" приоритизировать свой "бэклог"? Исходя из ROI? Бизнес нужд? А откуда ему их знать, если он месит платформу - замкнутую на себе сугубо техническую сущность... "За шоколадку" - кто попросил (ну или наорал), того задачи мы и делаем в текущем спринте.
Вот и весь орг дизайн. В итоге у нас всё драйвят шоколадные децибелы, а не бизнес линии и их P&Lы. И как ни странно, выглядит всё логично, не придерёшься.
Как я описал выше, модели нарезки продуктовых организаций я перечисляю в порядке уменьшения частоты их использования. Таким образом львиная доля кейсов, которые я встречаю, преподают на предыдущие три варианта.
А жаль, так как этот вариант лишён вышеперечисленных минусов ловушек локальной оптимизации и низкой адаптивности. В этом плане тут всё очень хорошо - есть один общий Бэклог Продукта на всю организацию и им управляет один наделённый властью Владелец Продукта.
Критика такого подхода упирается чаще всего в отсутствии понимания его реализации - как одному Владельцу Продукта работать со всеми командами разработки, которые есть в организации? Может ли он(а) драйвить десятки разработчиков одновременно? Как при этом выглядит процесс? Как управлять персоналом, загрузкой, командами и процессом?
Ответ здесь: "да". Этому можно научиться. Это непросто. И вам нужны мега-опытные процессные эксперты, фасилитаторы и Скрам Мастера, практикующие практики Масштабного Скрама. Благо, вся информация открыта, описана в книгах и кейсах реальных компаний, которые так работают.
Это расширение предыдущего кейса, только команд у вас не пяток, а десятки. В этом случае вам, хотите вы или нет, а придётся нарезать идею "Один бизнес = один продукт" на подпродукты или как мы их называем "области продукта". И, очевидно, важно это делать не попадая в ловушки описанных выше "нарезки по функционалу", по "воронке продаж" и "бизнес линиям".
Но как же? Динамические области продукта - решают эту дилемму. Да, людям нужен фокус и некоторая нечасто меняющаяся доменная область, разобраться в которой занимает время. Поэтому области продукта - это рамки различных доменных знаний вашего бизнеса. К примеру, работа с крупными клиентами так сильно разнится от более мелких, что войти в эту область - это месяцы. Тогда, естественно, мы хотим чтобы те, кто уже разобрался, оставались в этой области какое-то время, разрабатывая продукт на благо этих пользователей. Но это не бизнес линия. Это всё - один бизнес, просто мы не можем знать всё и вход в области требует инвестиций.
Но мир меняется, стратегия компании и продукта должна адаптироваться под реалии, поэтому эти области динамические, то есть растут и сужаются (команды могу переключаться между ними), и назначение конкретных целей продукта на области тоже может адаптироваться.
Тогда мы получаем адаптивную организацию, которая постоянно учится искать и поставлять ценность клиента. При этом она имеет чёткую структуру и не нуждается в трансформациях и реорганизациях для изменения курса - изменение стратегии делается Владельцем Продакта постоянно по мере переприоритизации элементов единого общего Бэклога Продукта.
Звучит, как фантасмагория или может, как путь развития?
Мы рассмотрели шесть совершенно разных орг дизайнов компаний. Мы прошлись с вами по истории компании и увидели во времени, как типично развиваются структуры и процессы.
Какой-то орг дизайн есть всегда. Но не всегда он осмыслен и не всегда отвечает нуждам бизнеса. Соответственно, ключевая задача менеджмента - формирировать осмысленные структур и процессы, регулярно пересматривать их, следя и замечая кризисы роста.
Также важно не идти на поводу у моды и "школ управления", а критично смотреть на текуший орг дизайн и кардинально пересматривать его по мере роста компании, изучая альтернативы и экспериментируя.
Без вовлечение сотрудников, которые понимают реальные проблемы на местах, и без углубления менеджерами в реалии компании (практика "Go See", Gemba) осмысленный орг дизайн невозможен.
Благодарю за ревью статьи Ярослава Новосёлова и Дмитрия Незабытовского.
Зустрічі у компаніях, які займаються розробкою програмного забезпечення, часто визнаються найважливішою складовою успішного продукту (чи проєкту). Однак, їх вартість і вплив на бізнес часто залишаються недооціненими. Проведення зустрічей вимагає великих витрат часу і ресурсів, і саме тому …
Я проводжу ретроспективи досить часто, близько сотні на рік, а почав уперше це робити майже 10 років тому. У цій статті я хочу відповісти на Top 5 із питань про Ретроспективи, які найчастіше задають учасники тренінгів та Agile-ком'юніті.
Однією з основних функцій сучасного менеджера лідера є розкриття потенціалу кожного учасника команди для досягнення максимальної ефективності та реалізації цілей. Scrum Masters, Product Owners, Facilitators та інші лідери й керівники можуть використовувати коучинговий підхід для підвищення …
