О видах планирования

Обратил внимание, что люди в комментариях обычно делятся на два типа: «планирование — чушь, теоретизирование» и «нужно все планировать от начала и до конца». И у меня, к сожалению, не получается полностью согласиться ни с теми, ни с другими.

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

Итак, я следую методологии Action Research («исследование в действии»), что означает упор на практику, а не теорию. То есть практика всегда идет впереди, анализируется и на основании анализа делаются следующие практические шаги.

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

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

Ну, подумаешь, полгода назад херней занимались? Сейчас-то у нас все-по другому! И еще через полгода будет «все по-другому»… и еще через полгода…

И именно тут мы видим кардинальное отличие Action Research от Agile: AR делает упор на глубокий анализ своих планов и их результатов, что позволяет эволюционировать быстрее. Реально быстрее.

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

Что такое «копать достаточно глубоко», на самом деле?

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

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

Фактически, Action Research ближе к топ-менеджменту, executive positions, нежели к уровню миддл-менеджмента или даже исполнителям. И в этом — его и достоинство, и недостаток. Практически нереально внедрить AR на низовых уровнях без потери эффективности в краткосрочном периоде, поскольку рефлексия — процесс болезненный и долгий, отнюдь не каждый согласится признавать свои ошибки.

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

Но, когда дело доходит до стратегического менеджмента, Agile уже будет недостаточно. Тут нужна та самая более глубокая аналитика.

Итак, где именно в Action Research находится планирование, и почему нет и не может быть универсального подхода и глобальных планов?

Планирование в AR следует ЗА циклами, а не ПЕРЕД, как это могло бы показаться на первый взгляд. Да, мы делаем диагноз и планирование перед исполнением в рамках каждого из циклов, но предпосылки и к диагнозу, и к плану проистекают из результатов предыдущего цикла. Это важно!

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

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

Планирование тут важно, но только на тактическом уровне, причем планы должны быть очень короткими, исполнимыми, и целиком основанными на результатах анализа предыдущих циклов. Что касается долгосрочных планов, то их нет, от слова «вообще». Есть только «изменения», то есть процесс преобразования компании в некотором направлении получше, чем текущее.

Допустим, «выход на новый рынок», «запуск нового продукта», «переход от работы в одиночку к командной работе» — все это изменения. И уже в рамках этих изменений мы запускаем короткие циклы один за другим, каждый из которых постепенно изменяет компанию.

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

Допустим, лучше разделять «выход на новый рынок» и «переход к командной работе», поскольку там будут разные категории задач. Эти циклы могут и будут выполняться параллельно, и зависеть от предыдущих циклов в рамках своих изменений.

Если мы делаем короткие планы, то планирование и анализ не занимает много времени. И, чем дальше, тем быстрее выполняется анализ, диагноз и планирование со стресс-тестированием. Вопрос практики.

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

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

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

Это — одна из причин, почему AR сложно или вредно внедрять на низовом уровне. Если разработчик придет и скажет начальству, что «мы тут херней занимаемся», ему вряд ли выдадут бочку варенья и ящик печенья. «Самых умных» нигде не любят. И даже просто ощущение того, что «мы занимаемся не тем» может подействовать разрушительно на мотивацию и эффективность команды.

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