Управление в стиле Agile. Как создать самоуправляемую команду в ИТ проекте

Сегодня мы поговорим про гибкие методологии управления. Это сейчас достаточно популярная тема, я бы сказал даже, это «горячий пирожок» на рынке консалтинга, на рынке управления.

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

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

О себе

Пару слов о том, как я попал в эту сферу – как обычно, случайно, «я не хотел, меня заставили».

• Мой первый опыт применения Agile-технологий был стихийный: я в 2003 году управлял сервисным центром и столкнулся с проблемой, что некоторые сервис-инженеры не любят взаимодействовать с клиентами. Они отлично чинят компьютеры, но их сложно заставить перезвонить, пообщаться с клиентом, продиагностировать проблему удаленно. У них все время были причины не звонить: например, «я сейчас занят», «я сейчас на другом объекте» и т.д. У клиентов из-за этого падало субъективное ощущение полезности, им казалось, что мы не работаем, мы не занимаемся их заявками, их проблемами. Было очень много нареканий. Я тогда пытался найти какое-то решение, и неожиданно нашел модель, при которой сервис-инженеры звонили клиентам сами – по факту, эта модель была основана на подходах Agile (правда, я их тогда так не называл). Позже я подробнее расскажу, как это получилось сделать. Но тогда я увидел реальный результат – потому что если раньше клиенты субъективно оценивали нашу работу на 40-60% (что для сервисного центра очень плохо), то после применения Agile-технологий в течение 3 месяцев показатель удовлетворенности клиентов вырос до 90%.
• В дальнейшем я неоднократно применял эту методику в других командах. Преимущественно я работал в ИТ – опыт у меня айтишный. Я работал и на стороне клиента (одно из самых крупных внедрений в компании Мегафон, где я был руководителем отдела автоматизации), и на стороне франчайзи (мы делали проект по автоматизации на 1С для Главстроя).
• Консалтингом по Agile я занимаюсь с 2013 года. Я помогаю внедрять гибкие методологии.

О чем доклад

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

Типы систем управления

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

Что касается иерархической системы, то речь идет о всеми любимой школе научного менеджмента, Фредерика Тейлора (1895 год) – системе, которая дала миру бизнес-процессы, конвейер и все, что мы любим и умеем. Это тогда было изобретено и научно описано.

А гибкие методологии как школа человеческих отношений (так эта тема в научной среде называется), родились чуть позже. Первая научная работа на эту тему была в 1924 году, когда американский ученый Элтон Мэйо с коллегами проводил большой эксперимент (Хоторнский эксперимент) в попытке выяснить, как мотивировать рабочих, от чего зависит производительность. Они тогда нашли приемы, позволяющие повысить успешность в работе с людьми – то, что мы сейчас называем гибкими методологиями. Открытия, которые они сделали (что людей надо мотивировать, включать, следить за тем, чтобы они были заинтересованы), для 1924 года, для тогдашней корпоративной Америки, звучали авангардно, и поэтому это «никто не купил». Продолжение эти методологии получили примерно в 1960 году, когда в мире появилось очень много людей интеллектуальных профессий – инженеры, врачи, дизайнеры – такие направления, где традиционные подходы перестали работать, и капиталистический мир понял, что с этим надо что-то делать. Когда у тебя с проекта уходит ведущий инженер, ты можешь потерять половину бизнеса – это наши современные реалии. В то время и начал появляться спрос на гибкие методологии.

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

Примеры иерархической системы:

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

Все эти системы организации труда, организации людей построены на иерархии.

Гибких систем управления чуть меньше.

• Это социально-сетевая, она же слабо матричная. По этой системе, например, был устроен ранний Facebook и ранний Google. Это очень модная система для западных стартапов, когда есть одна команда, которая делает что-то одно, и есть другая команда, которая делает что-то другое, но вместе эти команды образуют сеть. Если у них есть правильный протокол общения, это эффективно работает. Если его нет, система рушится. Условно говоря, если в иерархии есть руководитель и под ним 5 команд, и он им что-то раздает, в гибких технологиях команды самоорганизованные, у них нет руководителя.
• Модель MLM похожа. Но там, несмотря на иерархию, есть определенные протоколы, и каждое звено в этой сети – самостоятельное.
• Холократическая система управления – на ней работает, например, банк «Точка». У меня было два внедрения холократической системы, это достаточно тяжелый процесс с точки зрения внедрения, но он реально очень эффективный с точки зрения компании.
• Бирюзовая организация – это подвид холократической системы, который основан на работах по спиральной динамике. Это в большей степени методический коммерческий продукт. Но бирюзовая организация, по сути, – организация, которая использует гибкие методологии управления.

Отличия иерархической и гибкой системы

Один из ключевых факторов отличия иерархической и гибкой систем – роль лидера.

• Если мы берем, допустим, отдел разработки, то в иерархической системе есть администратор, который раздает задания и проверяет их статус.
• В гибкой методологии у нас вместо администратора будет модератор, который предлагает взять задачи. Обычно здесь на этапе внедрения возникает больше всего страхов и сопротивления – когда мы начинаем разговаривать про гибкие методологии, руководители чаще всего боятся, что будет сложно договариваться, что никто не согласится выполнить какую-то задачу. Но поверьте, эти страхи не оправданы. Я ни разу такого не видел, так не бывает, чтобы люди, смотря на пул задач, все от всего отказались. Это больше страх, чем реальность. Да, есть нюансы. Например, мы делали так: есть стэк задач, ребята выбирают, кому что нравится, но какое-то небольшое количество задач подвисает. Мы их тоже распределяем, но стараемся не навязывать, предлагаем разобрать оставшиеся задачи добровольно, и объясняем, что иначе у нас будут проблемы. И обычно это всегда работает.

Второй фактор – это ответственность.

• В иерархической структуре ответственность на руководителе – если что-то не получилось, то отвечает за все руководитель.
• В гибкой методологии ответственность на членах команды. С этим тоже много вопросов и проблем. Получается, если кто-то один не сделает, то пострадает вся команда. Да, пострадает вся команда, но есть один нюанс. В гибкой методологии один из ключевых принципов – это распределение информации, и все члены команды знают, что мы делаем и к чему мы идем. Если в иерархии делиться конечной целью необязательно (можно просто поставить задачу, проверить и интегрировать результат в общую цель), то в гибкой методологии все знают, что будет, если общая цель не будет достигнута. К примеру, мы делали автоматизацию, команда очень небольшая – три человека, и у всех было одинаковое понимание, какие у нас дедлайны. И не только менеджер проекта это знал, но и программист понимал, что если не выполнить работу вовремя, то все, что он сейчас делает, бесполезно. И методолог тоже это понимал. Задача руководителя (а здесь, скорее, модератора), заключается в том, чтобы все одинаково понимали сроки и цели. Как ни парадоксально, но когда люди реально понимают ответственность, понимают, что им за это будет или не будет, это давит намного сильнее, чем руководитель проекта, который ходит и всех «пинает». Понимание, осознание того, что «если я подведу, и из-за меня встанет весь проект», оказывает на людей чудовищное давление. Поэтому если говорить про гибкие методологии, это достаточно жесткая система с точки зрения психологического давления. Помимо свободы, она на самом деле сильно нагружает людей.

Про открытость информации я уже немного сказал:

• В иерархии информация может быть и открытого, и закрытого типа – вы можете не делиться с людьми, зачем им это делать, вы просто даете задачу.
• В гибких подходах, если вы не делитесь информацией, у вас проект не взлетит, потому что фактора давления не будет. В практике я часто встречал такой страх: допустим, мы написали огромный список из 300-400 задач, где были даже такие странные задачи, как «купить холодильник в офис», «поставить теннисный стол», «поставить цветы в офисе». Вначале ребятам было страшно, они спрашивали – неужели и эту ерунду тоже надо планировать? Но когда началось распределение задач, и люди начали реально разбирать задачи, то те, что были связаны с цветами и холодильником в офис, никто так и не взял. Потому что одно дело накидывать задачи в общий пул, а когда появляется вопрос ответственности, когда человек понимает, что сейчас на это подпишется, что ему надо будет что-то сделать – это уже сложнее. Это тоже такой интересный момент, которого вначале не видно, но на практике он есть. Мы достаточно сознательно все выбираем, и проблем с выбором у людей никогда не бывает.

Контроль. Принципиальное отличие состоит в том, что

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

Качество систем управления

Зачем внедрять гибкие методологии?

Повышается производительность. Есть такая концепция – High performance teams. Она разработана в 1950 году в одном из британских университетов, которые занимались вопросами человеческой производительности. Ученые проводили определенные измерения относительно того, как повысить производительность команды, за счет чего и т.д. В итоге получилось, что гибкие методологии дают в 2 раза больше производительности, чем иерархические.

В моей практике был случай, когда мы написали информационную систему, а потом провели бенчмаркинг. К нам пришел человек из конкурирующей компании, где делали то же самое. Мы детально поговорили и поняли, что у нас системы примерно одного порядка. А потом мы говорили про сроки. Я спросил, сколько времени они это писали, оказалось – 5 лет. А мы это сделали за 1,5 года. Это реальный пример. Получается ускорение в 3 с лишним раза по производительности. И это только за счет внедрения гибких методологий.

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

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

У меня был пример – мы запускали систему учета заявок. Ситуация стандартная: клиент накидывает заявки на доработку, ребята распределяют, все хорошо. Но примерно в 30% заявок мы не могли понять, что хочет клиент.

Все знают, как неспециалист пишет заявку. Он пишет, например: «Сделайте так, чтобы у меня тут быстрее обрабатывалось, а здесь выходило какое-то поле». Когда такое читаешь, то просто не понимаешь, о чем идет речь. А поскольку система конвейерная (быстрое производство с очень плотной загрузкой), то получалось, что такие задачи все время выпадали. И это было проблемой, потому что клиенты жаловались, спрашивали, почему одним сделали, а им нет. У них появлялось ощущение, что их специально игнорируют, не хотят заниматься их задачами. Недовольство клиента по этим задачам прилетало мне как руководителю, приходилось периодически ходить на ковер, объясняться, почему мы уже два месяца не можем сделать какую-то простую задачу. Было сложно объяснить, что заявку не берут в работу из-за того, что она плохо сформулирована. Это выглядело как будто «вы сами виноваты», получалось некрасиво.

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

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

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

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

Ключевые факторы успеха при внедрении гибкого управления

Есть несколько ключевых факторов, без которых гибкая методология не будет работать.

• Принцип распределения ответственности. Очень часто есть такой риск: когда мы только начинаем внедрять гибкий подход, это всем нравится, всем интересно, глаза горят. Но как только начинается реальный проект, уже не до гибких методологий – руководитель по привычке распределяет, кому что делать, и система начинает сыпаться. Люди не понимают, почему вчера было гибко, вчера можно было выбирать, а сегодня тебя вызвали на ковер и принудительно дали задачу. Так делать нельзя. От этого система не взлетает. Это уже получится некий гибрид, который по производительности будет как иерархическая система.
• Принцип открытости – когда информация открыта и доступна для всех участников. Иногда это сделать невозможно. У меня было два примера, когда из-за невозможности обеспечить открытость мы понимали, что гибкий подход внедрять не надо.
  • Первый – разработка сетевых анализаторов для госструктур. Весь проект был построен так, что программисты не знали, для чего они ведут разработку, у них было очень узкое функциональное ТЗ. Это было сделано специально – для безопасности, чтобы никто не понимал, как работает вся система в целом. От них был запрос как-то ускориться, добавить чего-то гибкого, чтобы программисты быстрее писали. Но когда мы стали анализировать, то поняли, что не сможем внедрить гибкий подход, потому что не работает принцип открытости. Поэтому они остались в обычной функциональной иерархии.
  • Второй пример – это корпоративный конфликт, когда две группировки внутри компании имели между собой много противоречий. Естественно, две эти группировки друг от друга информацию скрывали, и если на них попадал какой-то сквозной процесс (например, процесс снабжения), то они друг с другом информацией не делились. В таких условиях применять гибкие подходы тоже не получится, потому что в вопросах разрешения конфликтов гибкие методологии не помогают.
• Еще один ключевой фактор, который дают гибкие системы – это снижение нагрузки на руководителя и расширение «узких мест», из-за того, что у нас появляется децентрализация.

Внедрение гибкого управления: циклы

Как внедряется гибкое управление?

Есть два методологических цикла – цикл планирования и цикл контроля исполнения.

Планирование делится на две итерации – в иерархии им соответствует планирование стратегической и тактической целей.

• Длинную итерацию планирования мы делаем один раз в 3-6 месяцев – это так называемый «Большой круг», когда мы собираем всех людей, работающих на проекте, выполняющих какие-либо функции, и накидываем задачи. Например, одна наша ИТ-компания 1С-франчайзи для этого выезжала в пансионат, потому что нужно было собрать порядка 200 человек. Понятно, что если просто собрать вместе 200 человек, договориться о чем-либо нереально. Поэтому эти большие круги планирования были разбиты на три секции: продуктовую, по развитию рынков, по эффективности. На каждой секции обсуждались разные вопросы, потом они выносились на общее собрание, и в итоге у нас родился большой-большой стратегический план. Это очень похоже на обычные выездные мероприятия, но на них обязательно соблюдаются принципы, о которых я говорил:
  • К примеру, вопросы и задачи может включить любой человек – не только руководитель. Поэтому списки задач порой получаются очень большие – по 300-400 пунктов.
  • Самое главное – никто никого не ограничивает. Если программист, например, предложил поменять платформу, то даже если мы понимаем, что это неадекватная задача, мы ее все равно записываем. Не факт, что мы это сделаем, но мы ее фиксируем и тем самым разрешаем говорить все, что угодно. Такая ситуация иногда напрягает. В некоторых командах на совещаниях могут начать обсуждать холодильник в офис или теннисный стол. Но, как я уже говорил, бояться этого не надо, потому что примерно 70% задач, которые люди накидали, в работу потом не пойдут. И ничего страшного нет в том, что у нас какие-то гигантские списки задач, и непонятно, кто эти вещи будет делать.
• Когда мы выбрали задачи, мы делаем короткую итерацию. Это производственный этап. Он может длиться месяц-два – это оптимальный период (если слишком длинная динамика, мы забываем, что запланировали, а если слишком короткая, то не успеваем сделать все намеченное). В короткую итерацию мы нарезали задач, накидали, какие именно задачи будем выполнять, люди сами определились, кто какую задачу берет, кто что будет делать. Единственный минус: в отличие от иерархии в итерации нельзя скинуть с себя задачу, нельзя сказать, что не успеваешь, и отдать задачу другому. Потому что плывет вся система, пропадает фактор давления, пропадает плановая четкость, пошаговость. Вот такой небольшой недостаток. Но с учетом выигрышей, которые дает гибкий подход, он нивелируется.
  • Прошла первая короткая итерация, у нас появились какие-то результаты – что-то сделано, что-то не сделано.
  • Начинается новая итерация – в нее мы берем следующие задачи и те, которые остались с предыдущей итерации.
  • Такие короткие итерации мы делаем несколько раз в течение 3-6 месяцев, а затем мы снова собираемся большим кругом, смотрим, куда идем.
• Аналог стратегического планирования в гибкой методологии – это выделение фокуса стратегических задач. Внутри компании есть малый управленческий круг – небольшой экспертный совет из 3-6 человек, определяющих вектор развития. Они смотрят на задачи и отмечают, что для них действительно важно. Например, для компании-франчайзи было важно увеличить прибыль и увеличить выручку за счет выхода на новые рынки – это был стратегический фокус компании. Это не цель, как в иерархии, которой надо добиться любой ценой. Это стратегический фокус – руководство компании хотело бы выйти на новые рынки. Т.е. выделяется набор задач, соответствующих этой стратегической цели, и эти задачи особым образом помечаются, чтобы люди, когда берут такие задачи в работу, понимали, что помогают в продвижении стратегической цели.
• Распределение задач. Есть два механизма, как распределяются задачи.
  • Первый – задачи распределяются через голосование. Представьте, у нас большой открытый список, в котором люди себе выбирают задачи. Но часто бывает конкуренция: одну и ту же задачу могут выбрать несколько человек. Поэтому есть арбитр в лице малого круга, который распределяет задачи, но договорным способом, без назначений, без конфликтов.
  • Второй механизм – корректировка распределения задач. Он удобен, чтобы разрешить конфликт, а также для распределения подвисших задач. Например, осталось несколько важных задач, а их никто не взял. Тогда члены малого круга предлагают их разобрать. В качестве примера я уже рассказывал, как у нас была построена разработка. У нас было порядка 9 программистов и 2 руководителя – один занимался текущей техподдержкой, второй – разработкой. Все задачи скидывались в общую систему, перед началом итерации один день уделялся планированию – ребята отмечали, кто какую задачу возьмет. Потом руководители смотрели, все ли охвачено, нет ли чего-то важного, что мы забыли или не успели сделать в прошлый раз. Если такие задачи оставались, ребят просили их разобрать.

Что касается контроля исполнения, то в процессе это выглядит так:

• Мы собираем статусы по задачам: интересуемся, как обстоят дела у исполнителей, не нужна ли им помощь. Это все устно – подробных отчетов писать не нужно, и нет никакого наказания, если человек скажет, что что-то не успевает сделать.
• Затем мы подводим итоги итерации, смотрим, что сделали.
• Далее начинается следующее распределение задач.

В иерархии планирование может занимать 2-3 месяца, особенно когда нужно собрать 200 человек и все распланировать. В гибком управлении мы это сделали за неделю:

• Большой круг у нас длился 2 дня, мы накидали список задач.
• Еще 2 дня мы этот список структурировали в удобном виде.
• Дальше просто все распределили и приступили к работе.

Представляете, какой это выигрыш!

Где гибкое управление работает

По моему опыту гибкое управление работает в следующих сферах:

1. Разработка и сопровождение 1С, отдел разработки. Я про это рассказывал: когда есть пул задач – люди выбирают, чем займутся, мы следим, чтобы все важные задачи были приняты. Гибкое управление в этом помогает.
2. В группе компаний, проектный отдел. Это кейс с выездом 200 человек – там изначально была задача переформировать проектную организацию в продуктовую. Изначально у нас это не получалось, хотя все осознавали важность задачи – были установлены сроки, назначены ответственные, но почему-то организационно процесс не шел. Гибкие методологии ситуацию изменили.
3. Поставка инженерных систем, дистрибуция, торговля железом. Здесь тоже достаточно хорошо работает.
4. Про внедрение 1С еще один кейс был – там тоже гибкое управление помогло.
5. Еще один интересный кейс, когда выводили ИТ-компанию из группы в отдельный самостоятельный бизнес. Изначально был внутренний ИТ-отдел, который обслуживал холдинг, и решили, что он должен начать зарабатывать. Но что бы они ни делали, ничего не получалось. Гибкое управление помогло.

Частые вопросы

Коротко рассмотрим несколько самых частых вопросов.

1. Как меняется зарплата и премия при внедрении гибкого подхода? Никак. Это вообще не влияет. Когда мы внедряем гибкие методологии, производительность растет всегда независимо от системы финансовой мотивации, которая уже в компании работает. Я внедрял гибкие методологии и в жестких иерархических структурах, где зарплату невозможно выбить (сколько дали – столько дали), и в компаниях, где люди были мотивированы от прибыли. В обоих случаях при внедрении производительность повышается.
2. Когда нельзя внедрять гибкое управление? Я уже рассказывал об этом: когда невозможно внедрить хотя бы один из протоколов – открытость, распределение ответственности или командную работу.
3. Можно ли внедрять в группе, в отделе, в департаменте, если вся компания иерархическая? Можно, это нормально живет. Но наоборот не работает: если вся компания гибкая, что-то иерархическое там не выживает. Но это, скорее, книжный кейс, в жизни такого я не видел. Чаще всего это крупные компании, где какой-то отдел, направление или функция перестраиваются на гибкие методологии.

Вопросы

• Хочу уточнить по поводу распределения ответственности. У меня возникает диссонанс: если мы распределяем ответственность, я предполагаю, что это может отразиться и на зарплате, но на зарплате это никак не отражается. Если это не отражается на зарплате, то это уже демотивирует, причем очень сильно. Или там как-то по-другому ответственностью распределяется?
• Это очень частый вопрос: ответственность распределили, а денег нет. Но тут ответственность в большей степени психологическая, поэтому мы ее от денег свободно отрываем. Когда вы начинаете это пробовать, внедрять, вы видите, что хуже никому не стало, люди мотивируются, у них появляется больше выбора, они выбирают, чем позаниматься, не надо спрашивать ни у кого разрешения. Это сильно мотивирует. А если кто-то спрашивает про зарплату, мы говорим, что здесь действует определенный протокол, в нем есть конкретные правила, и все нормально работает.
• Когда в отдел поступает куча задач от разных департаментов, может сформироваться пул, на выполнение которого потребуется больше 1-2 месяцев. Но заказчики хотят знать конкретные сроки, когда будет сделана каждая задача. Как им ответить?
• Мы в одном из проектов сделали обычный лист ожидания, и в нем были плановые сроки. Но неприятность была в том, что они сдвигались, если в течение итерации мы не успевали.
• Если каждый выбирает то, что ему нравится, то как нам двигать вперед критические проекты?
• Обычно задачи, которые человек выбирает добровольно, делаются быстро. Производительность растёт.
• А если все сломалось, упало, и надо прямо сейчас чинить?
• Внедрение гибких методологий не отменяет обычных процессов поддержки. Наверняка есть кто-то, кто за это отвечает, в чьей это компетенции. Это же не совсем творчество типа «хочешь – ходи на работу, хочешь – не ходи». У нас есть точно такие же процессы, которые надо поддерживать. Но если человек этим занимается, он это добровольно выбирает. Мы исходим из этого.  

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.