Agile как IT-форма современного менеджмента
Прошедшая конференция AgileDays-2012 естественным образом сфокусировала мои мысли на теме Agile-практик как таковых, их развития и соотнесения с традиционным менеджментом.
Практики менеджмента безусловно следует рассматривать в контексте тех способов производства, тех организаций, на основе которых они выработаны. При этом надо понимать, что это естественным образом реактивный процесс. То есть сначала некоторые практики складываются, потом — анализируются и описываются, потом они транслируются и применяются более осознанно. Но при этом за время анализа и описания жизнь уходит вперед.
Так вот, традиционный менеджмент вырос в условиях больших предприятий, в которых путь наверх был статистически доступен немногим. Соответственно, этот шаг делали люди, имеющие достаточно высокие способности в том, что составляло суть менеджмента. Такие люди достигали успеха, за ними наблюдали другие люди, учась у них непосредственно или публикуя книги, предназначенные для тех, кто хочет стать успешным менеджером. И сами успешные менеджеры тоже писали книги — как был достигнут успех. Таким образом формировался стереотип успешного менеджера, по которому производился отбор, и к которому стремились желающие, вырабатывая у себя соответствующие качества.
Однако, важным является тот факт, что способных успешных менеджеров, а также желающих, готовых на достаточно большие усилия чтобы стать успешным менеджером было не так много. И пока организация производства могла обходиться таким количеством менеджеров, система более-менее работала. Это, по моим ощущениям, 60-70-е годы. А затем произошло следующее. Повышение потребности в квалифицированном труде позволило достаточно большому количеству людей подниматься вверх альтернативным путем. Не стремясь стать успешным менеджером ценой больших усилий. В ответ на это — появилась идея обучения регулярным образом, без существенных затрат собственной энергии, которая, в конце концов, вылилась в идею MBA. Теоретически там учат тех же самых успешных менеджеров на основе анализа опыта и методов. Но практически тех самых менеджеров, которые служили образцом — не получается, потому что составляющие самомотивации и самореализации в должной мере не присутствуют у всех обучающихся. Хотя тем, у кого он присутствует в силу личных склонностей такое обучение безусловно помогает.
Аналогичная проблема, кстати, с воспроизводством советских управленцев, которые проводили развитие промышленности и науки. Эти руководители формировались в условиях жесткого давления при Сталине. Когда давление упало, то процент людей, избиравших такой путь и шедших по нему с большими личными усилиями — сильно уменьшился. И хотя ряд механизмов, обеспечивающих давление, таких как конкуренция нескольких предприятий в каждой из оборонных областей, сохранился, следствием стала общее снижение уровня руководителей. Были попытки изучить стиль работы управленцев и на основании его выработать методы работы. которые затем сознательно применять. К ним относится и СМД-подход. Но, несмотря на построение теории, практическое восприятие такого подхода среди руководителей — невелико. Оно определяется количеством людей, для которых достижение целей является важным с точки зрения самореализации, и которые согласны на большую внутренюю работу ради этого. А их количество при отсутствии большого внешнего давления — невелико.
Возвращаемся в область IT. Она отличается от других материалом, из которого изготавливаются конечные изделия. Он имеет преимущественно нематериальную природу, так как изделие — исполняемая программа, написанная на некотором языке. В этом смысле IT ближе к научной области — НИР и НИОКР, однако требуется от нее производственная деятельность. Менеджмент пытался решить эту потребность через все большую и большей регламентацией. К началу 2000-х этот путь достиг своего апогея в виде unify process, но требуемый результат в виде гарантированного завершения, пусть даже ценой больших денег — достигнут не был.
А сама потребность — многократно возросла с наступлением эры персональных компьютеров. Все-таки, до 80-х годов нематериальная природа компьютерных кодов, отличающая отрасль, нивелировалась тем, что для кода нужен-таки был материальный носитель в виде компьютера, который присутствовал только в достаточно крупных организациях. Персоналки качественно изменили ситуацию, потребность в реализации IT-проектов с их распространением выросла многократно. И выработка способа управления ими, обеспечивающая результат стала насущной необходимостью. Это был вызов эпохи.
Ихв 90-х решение было найдено — Agile-технологии. Возникнув первоначально как протест против доведенных до абсурда процедур регламентации в виде XP, они с появлением SCRUM дали легкий и эффективный способ управления IT-проектами, обеспечивающий приемлемое качество и при этом сделавший управление IT-проектами доступным достаточно широкому кругу людей в отрасли без чрезмерных усилий по освоению. И этот способ завоевывал мир де-факто. При этом первоначальная цель XP — вытеснить за рамки IT процедурное администрирование и вообще классических управленцев — также была во многом достигнута за счет внедрения собственной, оригинальной терминологии и практик. В результате IT-шники получили возможность самостоятельно управлять своими проектами или, во всяком случае, обрекли менеджеров на разбор со спецификой отрасли. Хотя сами практики, если разобраться внимательнее, впитали в себя позитивный опыт «обычного» менеджмента который тоже интенсивно развивается.
После успеха де-факто началось признание де-юре. Артефактами этого являются SWEBOK 3 версии (2004) и PMBOK 4 версии (2008) в которых явно упоминаются agile- методологии и сделана оговорка, что структура самого документа повторяет стадии классической (водопадной) модели лишь по совпадению. PMBOK-4 читать особенно забавно — итеративность новые веяния вписаны в книгу явно на живую нитку, точки сшива и провалы целостности, возникшие из-за этого — видны. И этот процесс завершается сейчас понятийной сшивкой с менеджментом вне IT, которая необходима для Agile-управления IT-проектами в мегакорпорациях. Проявления этой сшивки — доклад Dan Rawsthorne. Scrum: the Big Picture на AgileDays-2012, в котором показана реализация в Agile «общепринятой» иерархии уровней Software Development — Product Development — Project Management — Portofolio Management. И доклад Джефа Сазерленда на SECR-2011, в котором правильный SCRUM позиционирован как высшая и последняя стадия CMMI-5.
Если же говорить о широких массах, то IT-шники относятся к управлению так же как к технологиям. Они знают, что серебряных пуль — нет. Они знают, что новые идеи могут давать много полезного, и за ними надо следить. И чтобы их использовать вовсе не обязательно углубляться в теорию — можно применять на практике и без этого. Хотя если интересно — то почему бы не разобраться в теории — это прикольно, полезно и поучительно. Но во всей теории разбираться — никакого времени не хватит. Поэтому новые идеи вспыхивают, оказавшись удачными — распространяются, становятся общеизвестными, в их ограничениях разбираются, после чего они осыпаются в багаже полезнымии практиками. Так же и в технологиях: вспыхивает функциональное программирование, F# и Haskel, обретает последователей, интенсивно развивается, а потом опадает новыми элементами в C# или занимает подобающую, хотя и неожиданную нишу как Erlang. И практики управления и технологии по пути могут обрастать евангелистами и ярыми сторонниками. А сам цикл от прихода до обретения места — стремителен, порядка полутора лет.
Как я уже говорил, оригинал управленческих практик часто приходит извне. Но попав в IT — он сильно изменяется. Например, Канбан в IT обернулся тремя практиками ведения проекта: доска, ограничения на ней, измерение скорости потока. Который сосуществует в сознании с «большим» Канбаном как методом оптимизации процессов. Схема формирования команды — стадии Storming-Forming-Norming-Performing тоже стали более простыми и формальными, скрестившись по пути с IT-командами. Поэтому многие говорят об отсутствии принципиально нового или искажении оригинальных, якобы правильных идей и процессов. Но это неправильно. Потому что реально процессы впитывают специфику IT-разработки. А еще — приобретают нужный уровень легкости и схематичности, который и обеспечивает их успешное применение в проектах.
Ну и в заключении — отрасль меняется очень быстро. Тезис о том, что «в ней надо очень быстро бежать, чтобы оставаться на месте» — уже давно является самоочевидным. И использование схем, облегченных практик там, где они подходят, без вникания в теоретические детали как раз и обеспечивает способ быстро бежать, оставляя время для того, что интересно — для решения сложных задач и создания новых проектов. На мой взгляд, это — данность, объективная реальность. И если ее игнорировать — то тебя обгонят.