вторник, 24 марта 2015 г.

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 я почерпнул лично для себя несколько полезных идей, которые стал применять на практике. Однако я не призываю бросать всё и бежать читать эти статьи в поисках управленческой мудрости. У нас есть много своих хороших книг, в которых описаны те же самые принципы и идеи. Главное - ощутить необходимость учиться и развиваться.

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

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

среда, 11 марта 2015 г.

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"

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

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

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

пятница, 6 марта 2015 г.

MCDP: Философия управления



Вступление

Военная история и варгейминг - мои хобби. Недавно я прочитал публикации из серии Marine Corps Doctrinal Publications (MCDP). Это набор статей, в которых излагаются основополагающие подходы, принятые на вооружение в Корпусе морской пехоты США. Я не планировал найти что-то за пределами моего хобби, но оказалось, что там затрагиваются такие вопросы, которые интересны мне и с профессиональной точки зрения. Ключевые идеи, заложенные в них, не потрясают новизной или оригинальностью. Тем не менее,  я посчитал эти статьи интересными, так как в них даётся очень простой и конкретный понятийный аппарат, описывающий вопросы управления, планирования и оптимизации операций. Сказать по правде, у меня сложилось такое впечатление, что там простыми и понятными словами описано то, что мучительно открывают и пытаются рассказать миру сторонники agile.

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

Всего я планирую написать три статьи:
  1. Философия управления.
  2. Планирование.
  3. Скорость.

Философия

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

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

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

Корпус морской пехоты США твердо придерживается вероятностного взгляда на войну, и это определяет подходы ко всем аспектам его жизнедеятельности.

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

  1. Бизнес без консультации с разработчиками подписывает контракт.
  2. Составляется План, зачастую без количественной оценки. Очень быстро он теряет связь с реальностью и забывается. 
  3. Кодим-фиксим-кодим-фиксим.
  4. Ближе к дедлайну руководство почти случайно видит систему и устраивает разнос, так как всё не так, как надо.
  5. Кодим-фиксим-костылим-кодим-фиксим-костылим, но теперь по выходным.
  6. Кое-как отчитываемся по контракту, с замиранием сердца ожидая, когда клиент первый раз потыкается в систему.
  7. ... PROFIT??? 
И всё это под флагом Scrum`а. А под капотом старый добрый принцип "копаем от забора и до обеда".
"Agile is like teenager sex. Everyone wants to do it, many say they’re doing it, only some actually are, and very few are doing it right."


Управление

Как сделать децентрализованную систему управляемой? Определяющее свойство такой системы - распределение ответственности за принятие решений по всем уровням. Чтобы  дать подчиненным свободу для проявления инициативы, но при этом оставить их действия согласованными, применяется два метода:
  1. "Mission order" -  ставить подчиненному цель, а не давать инструкции, оставляя выбор конкретного метода решения задачи исполнителю приказа.
  2. "Commander's intent" - ясно раскрывать, общую цель и контекст действий (принцип называется ).
В статьях указывается что любой командир должен хорошо понимать цель и задачи как минимум двух командных эшелонов вверх от него. Командир взвода должен быть в курсе целей и планов роты и батальона. Большое внимание уделяется целеполаганию. Поставленные цели должны помогать подчиненным проявлять инициативу, а не мешать этому. Для этого цели должны быть достаточно широкими ("general"), но не туманными ("vague"). Подробнее о целях в следующей статье.

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

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



А что у нас?

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

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

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

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


Заключение

Судя по тому. что я узнал о КМП США и нашем менеджменте, большинство наших руководителей не годятся по своему уровню подготовки в офицеры Корпуса. Почему так? Менеджмент, который я видел, пытается усидеть на двух стульях сразу, но проваливается между ними. Он не реализует последовательно ни директивный подход, ни адаптивный. Для директивного подхода не хватает обеспечения стабильного окружения и качественных планов. Для адаптивного - качественной постановкой цели и общего контекста для построения децентрализованной адаптивной системы управления.

Впрочем, не везде всё так плохо:

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

Есть о чем задуматься. В следующей статье я хочу осветить подход КМП США к планированию.