MCDP: Скорость

Введение.

В предыдущих двух статьях я рассказал об общей философии руководства и о подходе к планированию, принятым в Корпусе морской пехоты США.  Эта заметка завершает цикл, и в ней я хочу поговорить о скорости. Феномен скорости описывается в 4-ой главе статьи "MCDP 1-3 Tactics".  В современной маневренной войне скорость - это ключевое преимущество, необходимое для победы. Задача любого военной организации быть быстрее, чем противник, чтобы захватить инициативу, застать противника врасплох. В конкурентном бизнесе, да и в любом проекте с дедлайном, скорость тоже - необходимый фактор успеха.

Что такое скорость? Понятие скорости более емкое, чем, собственно, скорость передвижения войск по местности. Танковый батальон, который заправляет свои машины за час, быстрее, чем тот, который тратит на это два часа. Моторизованная часть, которая может пройти пятьсот километров без поломок быстрее той, которая может пройти лишь двести. Подразделение, которое способно развернуться из маршевого построения в боевое за пять минут быстрее того, которое тратит на это десять. Звено самолетов, способное совершить пять вылетов за сутки быстрее того, которое совершает только три. Дивизия, штаб которой тратит на обработку новых разведданных и изменением планов час быстрое той, у которой штабу требуется два. Полк, который сам принимает решение об изменении направления удара быстрее того, который ждет для этого решения штаба дивизии. Рота, чей командир способен в бою договориться с соседними ротами о плане совместных действий за минуту, быстрее роты, чьему командиру требуется на это пять минут.

На войне все очень просто. Но самое простое оказывается наиболее сложным.

- Карл Клаузевиц

Карл Клаузевиц писал, что на войне вещи, простые в теории, совсем не просты на практике. Причины этой сложности две - трение ("friction") и туман войны ("fog of war").

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

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

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

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

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

Стать быстрее

Какие методы повышения скорости предлагаются в описываемой статье?

1. Простота

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

Есть другая сторона вопроса - организационная. Процессы и регламенты тоже могут служить источником трения. Это случается, когда ими слишком увлекаются, считая их панацеей от всех бед в разработке. Жизненный цикл требования из 11 состояний или DoD на несколько десятков пунктов - вот примеры такого увлечения, с которыми я сталкивался на практике.

2. Децентрализация и управление по целям.

Краеугольный камень всей философии управления, на котором строятся методы руководства и планирования. Децентрализация позволяет сократить цикл принятия решения, который активизируется при изменениях в обстановке. Военные называют его цикл "OODA" (Observation, Orientation, Decision, Action). Чем чем больше людей задействовано в этом цикле, чем сложнее правила его регулирующие, тем дольше он будет проходить. Чем более централизованная система, тем уже зона самостоятельности у каждого уровня, и "выше" по иерархии эскалируется каждая проблема.

Например, планировалось сделать систему диагностики ошибок. Неожиданная проблема привела к тому, что пользовательскую историю нельзя выполнить так, как задумано изначально. В централизованном цикле исполнитель не обладает правом принятия решения и качественным пониманием цели (как это описано в статье про планирование), поэтому вопрос эскалируется до product owner`а. Если он перегружен или недоступен, то реализация может быть заблокирована. 

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

3. Горизонтальные коммуникации ("lateral communications")

Очень тесно связанная с предыдущим пунктом тема. Если изменения в планах затрагивают соседние подразделения, то запрос к ним может пойти либо через начальство (вертикально), либо напрямую (горизонтально). В описанном примере, может потребоваться дополнительная работ от дизайнеров, которым надо будет перепроектировать интерфейс. Вместо того, чтобы "забрасывать" им новую задачу через руководство, можно привлечь их напрямую. 

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

4. Неявные коммуникации ("implicit communications")

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

Хорошим примером из нашей области является практика внедрения стандартов: стандарты кодирования, definition of done, процедуры и процессы, ролевые модели, уставы проектов. Здесь, главное, не перегнуть палку. Слишком сложные стандарты и процедуры сами собой становятся источником трения: либо они приводят к итальянской забастовке, либо просто игнорируются и перестают приносить пользу.

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

5. Опыт и тренировка.

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

6. Командир в точке наибольшего трения.

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

7. Хорошая умственная и физическая форма.

Здесь сложно что-то добавить. Хорошая форма позволяет дольше оставаться сосредоточенным и активным.

Заключение.

Этой заметкой я завершаю цикл "военных" статьей в моем блоге. В своих статьях я рассказал о том, что мне показалось интересным: о том, как люди из совершенной другой области решают проблемы, удивительно похожие на наши, и о том, как они это делают. Читая заметки из цикла Marine Corps Doctrinal Publication я почерпнул лично для себя несколько полезных идей, которые стал применять на практике. Однако я не призываю бросать всё и бежать читать эти статьи в поисках управленческой мудрости. У нас есть много своих хороших книг, в которых описаны те же самые принципы и идеи. Главное - ощутить необходимость учиться и развиваться.

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

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