MCDP: Планирование

"Ни один план не переживает встречи с противником."

- Хельмут фон Мольтке

"При подготовке к бою, я всегда понимал, что планы – бесполезны, а планирование – бесценно".

- Дуайт Д. Эйзенхауэр

Введение

В первой статье я описал философию управления Корпуса морской пехоты США. В этой хочу поговорить о тесно связанном с этим явлении - планировании.

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

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

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

В доктрине КМП США "планирование" - это развитие понимания ситуации коллективом вовлеченных людей. Конкретный артефакт на выходе - план - это побочный результат планирования. Главный результат - глубокое и единое понимание ситуации, цели и подхода у всех участников. Это очень важная мысль, я её повторю:

Главный результат планирования остаётся в голове, а не на бумаге.

То, что остаётся в голове у участников планирования позволит им быстро создавать новые согласованные планы по мере необходимости, когда первая версия плана устареет (т.е. сразу после начала его исполнения; иногда - до). То, что в КМП США понимают под "планированием", в нашей епархии называют "problem-solving" и "vision building". Из этого следует важный вывод - нельзя планировать для других. Листочек с планом передать можно, а знание в голове - нет. Те, кому предстоит исполнять планы должны участвовать в их разработке.

Понятие "план" определяется просто - любой артефакт, возникший в результате планирования.

Что у нас?

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

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

Содержание плана.

Согласно "MCDP 5 Planning" план содержит в себе описание:

1. Желаемого результата.
2. Организованных в пространстве и времени действий.
3. Задействованных ресурсов.
4. Процесса контроля и обратной связи.

Интересны первый и последний пункты. О них забывают, сводя план к "кто что делает". 

Описание цели, ожидаемого результата - ключевая часть плана. Она направляет людей, когда им нужно принимать не заложенные в план решения. В публикациях уделяется внимание описанию того, какой должна быть постановка цели. Функция цели - направлять инициативу подчиненных. Цель должна быть широкой ("general"), чтобы оставлять свободу принятия решения. Она должна описывать "что", а не "как". При этом цель не должна быть туманной ("vauge"), она должна быть достаточно конкретной, чтобы ориентировать подчиненных. Хорошо сформулированная цель позволяет оценить степень достижения цели и стать инструментом оценки решения.

Процесс контроля и обратной связи необходим, чтобы понимать, актуален еще план или уже нет. Хороший план имеет в себе механизм коррекции себя. Этот механизм представляет собой зафиксированные ожидания о нормальном исполнении плана, действия по проверке этих ожиданий и действия на случай нарушениях ожиданий ("переходим к плану "Б").

Что у нас?

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

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

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

Иерархия планов.

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

1. Ориентация ("orientation planning") - общий уровень планирования, имеет дальний горизонт и низкую детализацию. На этом уровне планирования проясняются цели и подходы к их достижению. 
2. Планирование вариантов ("contingency planning") - промежуточный уровень. На этом уровне создаются и оцениваются альтернативные варианты действий по достижению цели. На обеспечение будущих вариантов уже могут выделяться силы и средства, но существенно меньше, чем для следующего уровня планирования.
3. Конкретный план ("commitment planning") - близкий по времени, детальный уровень планирования. Выбирается, прорабатывается и исполняется один вариант, на которые выделяются основные силы.

Что у нас?

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

Связность планов.

MCDP 5 вводит понятие "связности плана" ("plan coupling"). Это понятие знакомо программистам и означает вероятность, что изменение в одной части плана повлечет изменения в другой. Сильносвязные планы называются "интегрированными" или "синхронизированными", слабосвязные - "модульными". Нельзя сказать, что одни лучше других. Выбор между модульным и интегрированным планом - это выбор между снижением риска и повышением эффективности использования ресурсов.

Тем не менее, военные любят именно модульные планы. В MCDP 5 дана общая рекомендация - применять модульные планы, если только ограничения ресурсов не вынуждают обратного. Трение и туман войны похоронят любой план. Если план будет интегрированным, они похоронят его целиком. Придется переделывать его полностью с потерей самого ценного - времени и скорости. Это создает риск провала, который сведет на нет попытки оптимизировать за счет интеграции. Модульный план в похожей ситуации потребует переделки части плана. Благодаря этому модульные планы более устойчивы к трению и неожиданности, они проще и быстрее адаптируются к неожиданным поворотам событий. Они способствуют ускорению реакции, что укладывается в принятую в Корпусе морской пехоты философию управления.

Что у нас?

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

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

Организационное планирование

Не всякая организационная структура допускает модульное планирование. Методы организации и методы планирования тесно связаны между собой. 

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

У каждого вида структур есть сильные и слабые стороны. Кроссфункциональные структуры с автономными единицами позволяют планировать модульно и освободить руководство от необходимости координировать действия отделов. Но функции в них "распылены" по всей системе, и при необходимости их концентрированного применения возникают проблемы. Специализированные структуры позволяют сфокусировано применить функцию на одном объекте, но требуют координации.

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

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

Что у нас?

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

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

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

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

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

Некоторые подвижки есть. Например, Антон Волков на AgileDay'13 в своём докладе рассказывает как раз о трудностях функциональной структуры и непростом опыте перехода к проектной схеме организации. Там же он говорит и о том, как упростилась его жизнь с переходом к управлению по целям и модульному планированию.

Заключение

В этой статье я дал выборочный обзор того, как в КМП США смотрят на планирование и как с этим обстоит дело у нас. Естественно, рассказ охватил лишь о несколько заинтересовавших меня аспектов планирования. Для более полного понимания вопроса следует прочитать соответствующую статью из цикла публикаций - "MCDP 2 Planning"

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

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

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