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

А еще надо обеспечивать прозрачность и управляемость бизнеса, который разворачивается в такой неоднородной структуре. И тут на помощь приходит Kanban, который не только организует работу отдельных команд, но и позволяет оркестровать работу компании. Но об этом мы поговорим в следующей статье.

Проектируем Agile-трансформацию компании

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

На что опираться в таком решении? Как раз на анализ ситуации компании и ее окружение на рынке и сложность деятельности. При этом надо помнить, что мы работаем с запутанной (по Кеневин, смотри предыдущую главу) социальной системой, поэтому тот образ перестройки компании, который мы получим в результате анализа является не более, чем гипотезой, подлежащей экспериментальной проверке. Гарантированного результата тут получить невозможно. Именно поэтому Kanban вообще предлагает начать стартовать с существующей организации компании, сделать прозрачным поток создания ценности и запустить эволюционный процесс перестройки. Правда, есть опасность, что этот эволюционный процесс увязнет в привычной рутине, и поэтому данный путь сложнее, чем революционная реорганизация.

В любом случае, бывают ситуации, когда переход к кросс-функциональным командам для определенных участков компании является достаточно очевидным решением, исходя из анализа деятельности или просто с учетом сопротивления преобразованиям. В этом случае надо организовать будущие команды. При этом опыт IT однозначно говорит, что их недостаточно организовать логически, просто собрав людей и объявив, что они теперь будут работать одной командой, как иногда делают при организации проектных групп. Надо провести физическую реорганизацию, объединив людей одной команды в единое физическое пространство. Разумеется, сейчас есть техники работы распределенных команд, но, во-первых, они сложнее, а, во-вторых, сохранение привычного окружения надежно останавливает любые новшества. Фраза Питера Друкера, «культура ест стратегию на завтрак» к этой ситуации тоже вполне применима. Должен ли сотрудник работать только в одной команде? Ответ из опыта IT – это крайне желательно. У любой команды должно быть ядро сотрудников, у которых команда является единственным местом работы. Может быть некоторое количество специалистов, занятых частично, и участвующих в 1—2 командах. Но не больше, во всяком случае, сотрудник, разрывающийся между 5—10 проектами – пример вопиющей неэффективности, потому что, как правило, он не помнит ни об одном. Разумеется, бывают исключения, и я сам знаю таких людей, но это – крайне редкие случаи, а обычно такие ситуации возникают потому, что руководители не знают, кем бы сейчас заткнуть дыру в деятельности, и нагружают сотрудников, которые в результате ни с чем не справляются, выгорают и уходят. И в большинстве случаев это все равно иллюзия решения проблемы.

Инфраструктура компании.

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