В мае мы провели третью встречу Scrum Master Club. Эта встреча была посвящена работе с культурой компаний. Неисчерпаемая тема. Все мы хотим поменять культуру компаний к лучшему. Но как?

Я провёл воркшоп по системного мышлению, где мы изучали влияние определенных орг структур на образ мышления, поведение сотрудников и в итоге культуру компаний. 

Посмотрите на два приведённых ниже фото - какая культура более гибкая?

Очевидна вторая. Там и столы для парной работы. И стен достаточно для визуализации. Выходит внешняя среда формирует культуру? Так и есть:

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

Три сценария:

Как оказалось, к примеру, выделение платформенной команды (иллюстрация выше) с целью обеспечения целостности архитектуры, экономии средств на разработку за счёт общего функционала и тем самым ускорение выпуска продуктов - не всегда приводит именно к таким ожидаемым результатам.

Зачастую подобная структуру приводит в полностью противоположной динамике:  выделение платформенной команды изолирует их лидеров от целей пользователей и бизнеса, что приводит к тому, что у платформа зачастую начинает восприниматься как "продукт в себе". Это в свою очередь ведёт к тому, что в таком отделе заводится свой "технический продакт оунер" со своим "роудпэмом" и "стратегией развития платформы". А это всё локальные оптимизации, мешающие видеть общую систему и общие бизнес цели. И поэтому зачастую такое орг решение (выделение платформенной команды) приводит к повышению зависимостей между командами, усложняет координацию, приводит к избыточным инженерным решениям, усложняющих общую архитектуру, и всё это удлиняет циклы выпуска продукта с точки зрения конечных пользователей.

Всё это контринтуитивно и зачастую неявно в организации, от этого в первую очередь страдают инженеры и пользователи. Но кто-то ведь принимал подобные решения? Кто-то ведь решил выделить платформу в "продукт" и наделить властью "технического продакт оунера".

Поэтому изучение системной динамики (что от чего зависит и что к чему ведёт) - очень важный навык менеджеров современных компаний. Без этого навыка мы склонны принимать решения, которые лишь поверхностно выглядят разумными, но приводят к совершенно казалось бы неожиданным и случайным последствиям.

Вот пример дебрифа одной из групп:

Другие два кейса, тоже по своему интересны. Эти орг. решения приводят к своей динамике, не менее удивительной, чем при платформенной работе:

Системное мышление и "мудрые" продуманные подходы к организации компаний на мой взгляд лучше всего описаны в литературе по Large-Scale Scrum - методу мышления о применении идей и принципов Скрам ко всей организации. 

Приходите на наши новые встречи Клуба Скрам Мастеров. Анонсы вывешиваются на нашей facebook-странице.

Слайды выступления:

Моё выступление на главной (она же "гнучка") сцене PM Day Kyiv 2016 прошло под знаменем сложности, спагетти и японской поэзии.

Ниже - избранные фото и слайды, ещё ниже - полная презентация. Видео в процессе - ждём с нетерпением.

Мои слайды с воркшопа на AGILEEE 2017 по масштабированию Скрам.

Продолжаю цитировать перевод новой книги по #LeSS:

Избегайте представителей отделов контроля качества, технологических процессов, трансформаций и усовершенствований.

В крупных организациях обычно имеются отделы контроля качества и технологических процессов, сотрудники которых носят черные пояса Шести Сигм и занимаются проектами по усовершенствованию.

Или даже лучше - в некоторых организациях существует отдел трансформаций.

Избегайте их!

Непрерывное улучшение должно осуществляться везде, всеми и постоянно. Наличие одного отдела, отвечающего за улучшения, — это самый верный способ уничтожить как сами улучшения, так и участие в них команд. В место этого пользуйтесь существующими организационными структурами для поддержки внедрения и усовершенствований. 

Законы Организационного Поведения Лармана гласят следующее:

1. Организации неявно оптимизированы, чтобы избежать изменения существующего порядка вещей (статус-кво), сложившегося среди руководителей среднего и нижнего звена, в должностях узких специалистов и во властных структурах.
   
2. Как следствие из первого закона: любая инициатива внедрения изменений будет сведена к переопределению или перегрузке новой терминологии, которая будет, по существу, обозначать то же самое что и существовавший статус-кво.
   
3. Как следствие из первого закона: любая инициатива внедрения изменений будет осмеяна как “пуристская”, “теоретическая”, “революционная” и “требующая прагматичной адаптации под локальные потребности”, что отвлечет внимание от устранения слабостей в сложившем порядке вещей среди руководителей и специалистов.
   
4. Культура следует за структурой.

Предвосхищая ваши мысли, следует также сказать, что и структура следует за культурой, особенно в молодых компаниях - стартапах. Но это утверждение имеет скорее поэтически емкое, чем буквальное значение.

Внедрение LeSS

LeSS внедряется в крупных организация, в которых обычно сосредоточено много умов с глубоко укорененными представлениями о том, как должны работать организации, и как нет. Для успешного внедрения LeSS требуются ломка подобных представлений и упрощение организационной структуры, которая как правило включает много избыточных унаследованных правила, вытеснивших нормальные человеческие отношения  - все то, что встречается в работе больших групп. Внедрение LeSS требует, чтобы каждый начал совершенствоваться, стремясь к общей цели.

...

При масштабировании следует придерживаться такого принципа внедрения: непрерывное улучшение до полного совершенства.

...

Так при внедрении LeSS отсутствует как инициатива изменения, так и группа и менеджеры по реализации изменений. Изменения в LeSS происходят постоянно посредством экспериментирования и совершенствования, и сами изменения являются новым порядком вещей.

Рост - про увеличение в размере, масштабирование - про повышение интеллекта. Рост - о добавлении слоёв иерархии, новых ролей и процедур. Масштабирование - о преодолении сложности её минимизацией.

На первый взгляд, Scrum тяжело уживается с ростом организации, ведь этот фреймворк не поощряет создание дополнительных ролей, увеличение состава команд и тиражирования беклогов. Поэтому в поиске “канонических” решений так легко не заметить весь сокрытый потенциал возможностей Скрам по масштабированию.

Масштабирование организации по Scrum происходит за счёт повышения внутреннего интеллекта системы, позволяя её компонентам работать независимо, но при этом слажено. Это похоже на молекулы воды, которые уничтожают грязь и помогают нам стирать одежду, мыть посуду, машины и даже детей…

Не то, чтобы участники команд буквально уничтожали элементы беклога при планировании спринтов… но ход мысли и общая идея вам должны быть понятны.

Вам не нужно управлять молекулами воды, чтобы они выполняли свои функции. Нужно позволить им сделать свою работу. Именно так и Scrum помогает решать сложные и трудоёмкие задачи: спуская их на уровень команд и конкретных людей, позволяя им самостоятельно разбираться во всех необходимых деталях.

По правде говоря, все Scrum встречи масштабируются настолько просто, что я довольно долго сомневался, писать ли об этом вообще.

Для масштабирования Scrum церемоний фасилитатору необходимо сделать следующее:

• Подготовить место проведения встречи.
• Пригласить нужных людей.
• Прояснить ожидаемые цели.
• Помочь участникам разбиться на меньшие самоуправляемые группы.
• Предоставить достаточные (но не избыточные) рекомендации по дальнейшей работе.
• И, наконец, не вмешиваться, давая интеллекту системы разобраться со сложностью.

Давайте посмотрим на практическое воплощение этих идей.

Преодоление сложности - не про разбивание больших вещей на мелкие элементы: очень надеюсь, что вы не разбиваете тарелки на мелкие кусочки, чтобы их помыть (я уже молчу о мойке машин и купании детей). Вместо этого вы просто подставляете тарелку под струю воды и позволяете молекулам выполнить свою работу на невидимом (неуправляемом вами) уровне.

С продуктами - та же история. Вы не поможете системе преодолеть сложность и трудоёмкость разработки продуктов, если начнёте разбивать их на мелкие под-продукты с множеством мелких беклогов.

Как раз наоборот - вы добьётесь обратного эффекта - так как кому-то теперь придётся заниматься склейкой всех этих компонентов. Хотя на первый взгляд это выглядит не очевидно, вы должны разок увидеть это своими глазами, тогда вы поймете, о чём я говорю...

Когда мы пытаемся масштабировать разработку продуктов, мы часто обращаемся к совету из Large-Scale Scrum: фокусируйтесь на всём продукте. На этом этапе я обычно помогаю группе стейкхолдеров, визионеров и продуктоводов совместно создать общее понимание “большей картины”, чем те, что есть у каждого. Иногда они приносят свои мини-беклоги, и мы начинаем склеивать продукт по кусочкам. Это зачастую довольно длительный процесс.

В большинстве организаций это процесс создания “большой картины” может занять довольно много времени. Это связано в первую очередь с тем, что практики сегодняшнего продуктового менеджмента (так сказать его статус-кво) как раз поощряют разбиение больших продуктов на мелкие удобоваримые куски. Поэтому у меня всегда при себе, помимо маркеров и стикеров, есть баночка супер клея. Также с её помощью я могу выделывать всякие штуки, но это совсем другая история.

На фотографии ниже группа продакт менеджеров совместно создаёт общую “большую картину” продукта. На доске отображены: общие бизнес цели, цели релизов, “user journeys” и прочее - там также достаточно места для будущего беклога:

Как “большая картина” готова - приглашаем всех в комнату!

После того, как мы всех собрали ("все" - это те, кто может помочь нам разобраться в деталях работы), один из менеджеров продукта объясняет всем собравшимся принципы организации доски: цели, приоритеты, проблемы и задачи, гипотезы и главные общие вопросы.

Пока детский лепет, не правда ли? А вот теперь будет весело!

Один продукт, один беклог продукта, общая работа над беклогом продукта - наша мантра, которую мы используем каждый раз, при работе над продуктом, где задействовано несколько (много) Скрам-команд.

Чтобы упражнение получилось обучающим (и, кстати, встреча для общей работы над белковом продукта - это в первую очередь обучающая встреча), мы перемешиваем всех участников из существующих команд разработки, формируя новые временные группы специально для этой встречи. Мы хотим, чтобы в каждой группе были участники из всех команд.

Благодаря этому упражнению, каждый участник из каждой реальной команды будет знать хотя бы часть беклога, а вместе, как команда, они будут знать обо всех элементах. Это упражнение ускоряет получение знаний, увеличивает их распространение и позволяет менеджерам продукта изменять приоритеты без необходимости помнить о структуре команд и потенциальных пробелах в знаниях.

Это то, что гибкость на продуктовом уровне на самом деле означает (помимо других вещей).

 Когда мы сформировали смешанные группы, наш процесс выглядеть следующим образом:

• Каждая группа берёт непроработанный элемент беклога продукта, приглашает в группу одного из продакт менеджеров и обсуждает эту тему не более 15 минут.
  
• Главной целью обсуждения является выработка общего понимания: в чём заключается проблема, как выглядит “user journey”, … - минимальный, но достаточный объём информации, чтобы можно было сказать можно ли это сделать вообще, и если да - не слишком ли тут много работы. В противном случае - элемент бьётся на меньшие части.
  
• По истечении 15 минут вся группа решает (с помощью быстрого голосования), насколько готов данный элемент и визуально это помечает на карточке (одна точка - недостаточно понимания; две точки - есть вопросы, но в целом понятно; три точки - alles klar!) и переходит к следующему непроработанному элементу.
  
• И, кстати, друзья, наши элементы беклога продукта не хранятся в Jira. На самом деле мы не так давно отменили нашу лицензию Jira, когда перешли к использованию листов A3 для элементов беклога. Эмпирическим путём мы пришли к тому, что этого размера бумаги достаточно для хранения оптимального количество деталей. (И не спрашивайте, как апологеты экстремального программирования умудрялись втиснуть свои истории на пяти-дюймовых индекс-карточках. Получается, размер таки имеет значение).
  
• По завершению оценки элемента беклога, участники группы складывают лист A3 и вешают его назад на стену. Таким образом, другим группам тоже будет видно, что этот элемент проработан, так как на нём есть точки.
  
• Обычно за часовую встречу мы успеваем проработать около 12-15 элементов беклога, этого нам как раз хватает на две недели работы всех команд.

Эта встреча выглядит довольно неорганизованной, даже хаотичной, и, если посторонний человек случайно войдёт в середине совещания, то ему, скорее всего, покажется, что совещание просто неуправляемое: некоторые рабочие группы иногда распадаются на ещё более меньшие, кто-то спонтанно подбегает к доске и начинает чертить диаграммы, другие внезапно решают пообщаться один-на-один посреди комнаты…

Но мы то знаем - всё идёт путём..

На самом же деле, хаос - это признак самоорганизации. Сравните, к примеру, солдат, марширующих на параде; и толпу хипстеров, стягивающихся к стадиону на концерт Red Hot Chilly Peppers. Кто из них кажется более организованным, а кто - хаотичным? Кем из них управляют, а кто самоорганизовался?

Так что, на самом деле ничего страшного, если процесс выглядит немного беспорядочным. Более того (и это мой личный вывод) - если Scrum-встреча недостаточно сумбурна - вы что-то явно недоглядели!

Бисексуальность удваивает ваши шансы на свидание в субботний вечер.

Вуди Аллен 

Мне часто задают вопрос: “Ты работаешь Скрам-мастером или agile-коучем”? Слишком часто. А после того, как я сообщаю о том, что работаю независимым agile-коучем, уточняют, работаю ли я как “agile-коуч, “на уровне организации” , или (я так понимаю, имеется в виду “простым смертным” ) Agile-коучем? В таких случаях я тихо ухожу вдаль.

Расскажу вам об одном недавнем случае. Ездил я как-то на open space конференцию (они ещё бывают называются “unconference”, но по-русски это звучит смешно), на которой матёрые agile-тренеры пытались проранжировать все виды agile-коучей: от фасилитатора команды (он же “коуч без власти”) до agile-коуча на уровне организации (он же “agile бог”). Скажем так, дискуссия не задалась. 

Но вот кто обожает играть с этими терминами, так это компании, выдающие сертификаты. Только представьте себе, что они могут продать “обычному” agile фасилитатору команды (мальчику на agile-побегушках) лучшую версию себя - такого себе супер-пупер-эпик-убернагибатора-эльфа-120-уровня-agile-коуча. Ему нужно только заплатить вот туда и получить хрустящую бумажку с печатью и красивой голограммкой... 

Не думаю, что разделение на подобные уровни - хорошая идея. Вообще-то, честно, это весьма плохая идея. Несмотря на то, что, безусловно, есть определённый путь (или пути) самосовершенствования, который каждый нас проходит за время развития в профессии, формальное разделение на уровни agile-коучей уже приносит индустрии больше вреда, чем пользы.

Но фабрики по выдачи сертификатов уже давно печатают сертификаты и их не остановить, так что я не буду бороться с ветряными мельницами. Поэтому я пойду в обход и попытаюсь донести до вас, милый человек, почему это раздвоение личности (фасилитатор команды против Enterprise agile-коуча) не приносит никакой пользы.

Кстати, о ценности...

"Scrum helped us to suck less"

Источник неизвестен

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

Упрощенная схема процесса поставки ценности от идеи у кого-то в голове до кеша на счету компании (также известный как “поток ценности”) в самом простом виде выглядит как-то так:

В реальной жизни, конечно, поток ценности будет выглядеть не так радужно; будут какие-то препятствия, узкие места, задержки, очереди, буферы и прочий кошмар. И всё может усложниться до состояния, близкого к примеру ниже (картинка из статьи Систематизирование Потока Ценности):

Но, в чистом остатке, это всё-равно поток ценности, который, я надеюсь, сквозь все препятствия доходит до конечного заказчика.

Вот почему целью любого agile фреймворка для разработки продуктов (как, например, Scrum) является контролирование (в лучшем случае минимизация) сложности процессов разработки. Это позволяет сфокусироваться на действительно важной вещи - оптимизации потока поставки ценности. Так что, если исходить из этого постулата, главная задача agile-коуча - помощь организации (и её лидерам) в определении потоков ценности и их улучшении … постоянном улучшении.

И, чтобы не быть голословным, приведу вам пример из последнего отчёта State of Agile, который подтверждает, что 60% организаций, переходящих на гибкие методологии, ставят перед собой цель ускорить выпуск своих продуктов.

"Если ваш проект задерживается, вам следовало его раньше начать."

Том ДеМарко и Тимоти Листер, "Вальсируя с медведями"

Постоянное ускорение разработки продуктов и невозможно, если вы работаете только с командами разработки. Разве что они - бесконечный источник проблем, решение которых ускоряет выпуск продуктов, но это, конечно, маловероятно.

Так что, если мы хотим реально ускорить наш поток, - нам нужно держать в уме весь поток и работать на всём его протяжении. Если конкретнее, то нам нужно будет вовлечься намного раньше разработки - на этапе генерации и отбора идей продуктов и фич; во время ранней валидации и отсеивания идей; и на этапах, следующих за разработкой: деплоймент, поддержка и прочее.

К сожалению, я часто вижу примеры Скрам-мастеров, которых организационные структуры загоняют в рамки работы только с процессами разработки. Эти “угнетённые” agile-коучи не имеют полномочий для улучшения потока. Они совершенствуют процесс разработки, как будто это единственное звено в цепочке ... Хотя, конечно же, работать уже давно следует с другими узкими местами потока.

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

Мы используем Скрам в разработке программного обеспечения, но, так как наши команды разработки не контролируют весь процесс создания ПО, то релизами занимаются команда “опсов”. Я коучу команду разработки. А у них там другой коуч, вроде как, они там работают по Канбану” - я слышал подобное, и это меня очень расстраивает.

Динамика таких организаций весьма занимательна (для постороннего наблюдателя на безопасной дистанции). В компании так или иначе проходят улучшения и оптимизации, но так как никто не видит полной картины (и не заинтересован в её улучшении), такая организация - музей локальных оптимизаций и ничего не меняющих компромиссов.

Неудивительно, что некоторые организации вообще упраздняют роль Скрам-мастера. Эта роль и правда не приносит пользы в организации, где никто не работает над целостной картиной. Там улучшения незаметны, и эта роль, естественно, становится просто лишней статьёй расходов. В таких организациях эта роль даже может вредить, так как количество конфликтов и уровень недовольства работой возрастают из-за разницы между возможностями и реалиями. И такие случаи - не редкость. Скрам-мастеров увольняют то тут, то там. И упраздняют как касту.

Дескать, “эта роль не приносит ценности”. Конечно ничего она приносить не будет, если её ограничить “фасилитацией в проведении командных встреч”.

Видеть, понимать и оптимизировать целостную систему (не её отдельные компоненты), исследовать динамику системы. Избегать фокусировки на мелочах и частностях, не заниматься повышением “эффективности” и “продуктивности” отдельных людей или команд. Клиенты заинтересованы в общем цикле “под ключ”, не в отдельных шагах.

Системное мышление, less.works

Так что, если вы заинтересованы в получении настоящих системных улучшений (а не в чем-то эфемерном, как, например, повышении велосити команд), вам нужно в корне пересмотреть своё понимание работы Scrum-мастеров. Они должны работать со всей продуктовой организацией. Иначе, как сказал Тобайас Мейер: "Удалить Скрам-мастера".

Есть и хорошая новость: на самом деле нет никакой необходимости выбирать между фасилитацией команд и коучингом организаций, пытаясь описать задачи настоящего Скрам-мастера. Это не противополжные вещи, не “или-или”. “Это ложная дихотомия” - так говорит Крег Ларман, объясняя Large-Scale Scrum.

Вместо того, чтобы приставлять Скрам-мастеров к конкретным командам (тогда у них не будет достаточного понимания целостной картины) и запускать agile-коучей в стратосферу (они тогда отрываются от реалий работы организации), попробуйте представить свою компанию как набор отдельных продуктовых организаций (разделённую по потокам поставки ценности заказчикам или, просто говоря, разделите компанию по продуктам). Тогда, соответственно, Scrum-мастера могут работать группами внутри этих продуктовых организаций, каждый с несколькими командами, фокусируясь и коуча отдельный поток “от А и до Я”.

Этим новообразованным командам и продуктовым организациям в первое время потребуется больше коучинга на уровне команд (командная фасилитация). Но со временем у Скрам-мастеров будет появляться время и необходимость работать и с другими частями процесса, переходя от одного узкого места к другому -  как показано на картинке ниже.

Чтение “для души”: Описание роли Scrum-мастера с точки зрения целостного продукта.

Знаете ли вы этих людей?

Подсказка есть в моей статье "Битлз и самоорганизация".

Они – менеджеры. Оба управляли ливерпульской четвёркой. Одного из них даже называли “пятым битлом”. Но немногие меломаны знают их. Почему так?

Да и зачем группе нужно было целых два менеджера? Да ещё и такой непростой группе с двумя яркими соперничающими лидерами? Не много ли менеджеров и лидеров на команду из четверых человек?

Допустим, что вы работаете в команде разработки в крупной продуктовой организации.

Скорее всего, у вас и ваших коллег есть несколько менеджеров.

И это всё ещё будет Agile. Не верите? Смотрите.

В проекте есть три зоны ответственности:

1. Зона бизнеса – что делать?
2. Зона технологий – как делать?
3. Зона процесса – каким образом подружить "что" с "как"?

Если мы рассматриваем отдельно взятую Скрам-команду из трёх-десяти человек в вакууме, то тут будут ярко выражены два типа менеджеров:

В задачи менеджера-предпринимателя входит весь тот набор, который в Скраме мы обычно предписываем роли Product Owner:

В задачи менеджера-фасилитатора (в Скраме это Скрам-мастер) входит:

Выше я сказал, что у каждого члена команды должно быть три типа менеджеров.

Так вот, в крупном проекте возникает ещё один – менеджер-профессор – тот, кто заботится о том, чтобы  работа выполнялась профессионально, а также поддерживает производственные процессы.

Эти менеджеры-менторы обычно фокусируются внутри специальностей: архитектура и проектирование; тестирование и автоматизация; дизайн и UX и т.д.

Члены кросс-функциональных Скрам-команд (т. н. “feature teams”) посещают различные мероприятия, организованные этими менеджерами, где обсуждаются конкретная специфика и тонкости специальности: как рефакторить код, как автоматизировать приёмочное тестирование, как улучшить дизайн и прочее.

Часто такие кружки называют “communites of practice”  или сообщества практик.

Итак, в крупной компании у каждого члена самоорганизующейся Скрам-команды будет три менеджера:

Brian Epstein – менеджер группы the Beatles, который успешно занимался вопросом прибыльности группы, организовывал выступления, занимался контрактами со студиями грамм-записи и паблишерами.

George Martin – продюсер группы, который проводил с группой месяцы в студии, записывая дубли и экспериментируя с новыми звучаниями и экзотическими инструментами.

Скрам-мастера у группы, по факту, не было! =) 

Самая большая ошибка менеджеров – попытка управлять людьми.

Управлять нужно продуктом, технологиями и процессом.

Люди же умеют самоорганизовываться и самонаправляться.

Статья переопубликована с http://scrumguides.com.ua

Если вы помните, первая часть статьи Новейшая история менеджмента компаний: от эры стагнации к Ренессансу закончилась стремительным ростом нашей компании. Она пополнилась менеджерами, теми кто призван исправлять проблемы и выстраивать процессы.

Теперь коридоры компании полны вывесок вроде: Integration Manager, Iteration Manager, Quality Manager,

Development Manager, Account Manager, Change Manager, Crisis Manager, Retention Manager и т.д. Похоже, что наша компания отлично укомплектована и готова к дальнейшему развитию!

Но позвольте спросить: "Насколько место, изображенное на фотографии, приведённой ниже, безопасно?

Должно быть, это самое безопасное место на планете, ведь его охраняют так много специалистов, готовых отдать свою жизнь за безопасность.

Когда мне говорят: "У нас работают отличные менеджеры по удержанию сотрудников!", или "У нас самый сильный отдел архитекторов!", я про себя думаю: "Хм, наверное у них немало проблем с удержанием и архитектурой…".

Недавно, к слову, одна компания громогласно хвасталась в соцсетях о том, что её HR-специалисты – самые привлекательные девушки в индустрии. Интересно, что в этой компании призван компенсировать такой необыкновенный бонус? Надеюсь, что не высокую текучку кадров из-за убогости проектов.

Так или иначе, в нашей компании становится всё больше менеджеров на любой вкус. Они заточены под решение любых проблем: от создания сладкой жизни для сотрудников до управления проектными рисками и удовлетворения заказчиков.

А что происходит в голове человека, чья должностная инструкция называет его «менеджером»? 

Всё просто – он начинает "менеджерить"!

Он начинает использовать свой молоток для забивания всего, что похоже на гвозди. Становится аккумулятором знаний по решению проблемы в своей области экспертизы, для чего он, собственно, и был нанят. И когда таких проблем вдруг становится мало, он начинает их создавать.

А когда начинается кризис, тот самый, под который он заточен, он автоматически начинает раздавать указания. Ведь он эксперт в этой области!  Ведь нет времени объяснять…

Что происходит в тот самый момент, когда менеджер дал инструкции и указания? Он затоптал на корню всё то, что agile призван бережно культивировать и оберегать, а именно: автономность команд и их самоорганизацию.

Не нужно менеджерить проблемы!

Делая это, вы автоматически начинаете менеджерить людей. А этого делать ни в коем случае не нужно, так как это деструктивно для всех. И для вас не в последнюю очередь. Вместо этого нужно делать нечто большее.

Но что?

Об этом чуть позже.

А для начала давайте посмотрим, как себя чувствует наш CEO: штат вырос вместе с расходами на его содержание, ожиданиями инвесторов и клиентов, но процессы существенно эффективнее не стали. С чего бы?

И тогда наступает момент прозрения: нам нужны метрики!

Давайте найдем слабое звено и оптимизируем его!

Звучит прекрасно.

На деле же это обычно сводится к следующему захватывающему шоу.

К примеру, у вас в компании четыре отдела.

И KPI выявили страшную неэффективность второго отдела (читай: "Там работают лузеры!").

Что вы будете делать?

Не спешите ломать себе голову. Упростите себе задачу. Представьте, что вы далеки от высокотехнологических бизнесов, и готовите блюдо из картофеля. Постоянно. Пять дней в неделю. Ну, такой у вас бизнес (не всем же писать стартапы).

Первый отдел, к примеру, чистит картошку. Второй – режет. В третьем её варят. В четвертом, ну скажем, давят на пюрешечку. Нормальный такой конвейерный процесс.

Вы - менеджер второго отдела (вам не повезло). Вы – самое слабое звено, ваши KPI ни к чёрту.

Что делать? Как оптимизировать нарезку картофеля? Что вам подвластно? Насколько вас интересует общая эффективность фабрики?

Помните: ваша карьера под угрозой! Самый лёгкий способ – изменить стандарты нарезки картофеля. Всё просто: режем крупнее, выпускаем быстрее!

Решение найдено! KPI ползут вверх. Ваш менеджерский бонус тоже!

Правда, в третьем отделе теперь как-то не очень. Но это уже не ваша проблема.

И вообще, улучшения – это  поступательный процесс. Сначала одно слабое звено, потом второе…

Они там ниже по потоку что-то придумают. Не зря же у них работает самый толковый менеджер по варке!

Узнаёте ситуацию?

В третьей части статьи вы узнаете о формальных и неформальных структурах вашей организации. О том, как функционировала «ливерпульская четверка». И о трёх типах менеджеров, которые по-настоящему смогут улучшить ситуацию в компании.

С 2008 года я в качестве консультанта и бизнес тренера посещаю различные IT компании. В некоторых провожу день-два, с другими работаю довольно долго. В последнее время я плотно работаю с 10-15 компаниями в год.

Недавно у меня появилось новое хобби – угадывать основные проблемы, с которыми сталкиваются проекты в таких компаниях, по описанию структуры компании.

Я не гений и не пророк. Далеко нет. Просто мне кажется, что я нашел некоторую очень типичную линию развития компаний (pattern, если хотите), которая позволяет довольно точно воспроизводить текущую фазу развития компании со всеми присущими характеристиками.

В 2012 году я осмелился обобщить свои наблюдения в виде доклада, с которым выступил на нескольких крупных конференциях. В частности, на Agile Eastern Europe, Agile Turas и PM Conf. Доклад, к моему удивлению (он несколько упрощенно представляет мою модель), был хорошо принят аудиторией и привлек довольно много  дискуссий после конференций.

Эта статья – не слайд-каст, а скорее описание моих наблюдений о типичной эволюции компаний с использованием иллюстраций из доклада.

Чем интересна эта команда?

Во-первых, структурой.

Эта команда объединяет все роли и все виды специальностей, которые совместно могут реализовать идею в продукте – “from concept to cash”.

Во-вторых, своей близостью к основателям, которые ежедневно вдохновляют всех своей личной верой в успех.

В-третьих, как следствие из предыдущего, своей когерентностью.

Все настолько сильно объединены общей идеей, что работают как единый организм. И обычно по много часов в сутки. И при этом без выделенного менеджера, который бы раздавал задачи, контролировал прогресс и замерял мотивацию персонала.

Идеальная Скрам-команда, не правда ли?

Так обычно продолжается до тех пор, пока главный аналитик и руководитель программистов начинают не выдерживать.

И ведь правда – они были взяты на работу в “dream team” в первую очередь благодаря своим профессиональным навыкам. Они были первоклассным аналитиком и супер-программистом. А теперь всё, чем они занимаются – это менеджмент своих подчиненных.

Первые люди уходят из компании, сетуя на то, что “она уже не та, что была раньше”. Или же само-понижаются от руководителей до инженеров – туда, где работа в кайф (пример всем известного Стивена Возняка из Apple).

Тут-то и начинается поиск и найм менеджеров, которые “придут и все исправят”.

Устранит ли привлечение новых менеджеров причины проблемы?

Поможет ли найм новых менеджеров решить проблему отсутствия вовлечённости сотрудников, которые не видят основателя, не знают стратегию и цели компании?

Смогут ли менеджеры компенсировать нехватку синхронизации между растущими отделами?

Я считаю, что зачастую найм менеджеров призван лечить симптомы, а не глубинные причины, вызванные ростом компании. Это всё равно, что вычерпывать воду из дырявой лодки.

И сказать, что стало сильно лучше, нельзя. Ведь теперь обычные работники ещё больше отдалены от основателя, менеджеры заняты микроменеджментом своих отделов, а работники – своими узкопрофильными задачами.

Компания начинает стареть. Ведь она все дальше и дальше уходит от своей начальной успешной структуры – самоорганующейся высокомотивированной команды первоклассных специалистов, верящих в идею и совместный успех.

Во второй части статьи я покажу, как в компаниях типично внедряются процессы оптимизации, основанные на метриках. И к чему это обычно приводит.

А в третьей части мы попробуем омолодить компанию, перестроив её по первоначальному принципу цельных команд.

Но сначала подбавим кризиса метриками…

Не переключайтесь!

Статья переопубликована с http://scrumguides.com.ua