Новая agile методика разработки софта - AIM
AIM - хорошее слово, но это далеко не единственное, что есть в этой новой agile методике разработки софта. Интересная деталь ее состоит в том, что это не придумка, созданная в академической среде, а результат наблюдения над реальными успешными проектами в течении более двух десятилетий. Каким-то мистическим путем все успешные менеджеры софтверных продуктов, за редчайшими исключениями, в той или иной мере всегда повторяли одни и те же шаги, а все неуспешные менеджеры обычно пропускали какие-то из этих шагов. Теперь эта мощная и хорошо работающая методика представляется вашему вниманию.
A.I.M. расшифровывается как Agile Insanity Management. Вообще-то, ее следовало бы назвать Agile Management by Insanity, но маркетинг счел, что такое название вряд ли найдет поддержку в корпоративной среде, к тому же сокращение AIM звучит куда лучше чем AMI или AMbI. Откуда столь своеобразно название станет ясно чуть позднее.
Итак, AIM. Первый шаг всегда состоит из одного и того же - вы создаете сплоченную мотивированную команду, в которой все делают свое дело. Это обычно происходит в то время, когда успех проекта далеко не очевиден и продукт не представляет из себя ничего интересного для корпоративных паразитов. Команда, сплоченная во имя великой цели, работает день и ночь и создает базу - продукт, пусть даже и со множеством недоделок, но нечто, что работает, что можно показывать людям, что имеет лицо, форму и функциональность. И даже более того.
На этой фазе команда - едина, все ее части - менеджмент, менеджмент проектов, разработка и тест работают вместе ради общей цели - создание продукта. Информационные потоки идут свободно сверху вниз и снизу вверх. Девы и тестеры знают, чего хочет от продукта менеджмент, менеджмент в курсе всех проблем, которые испытывают девы и тестеры, а пи-эмы бросаются грудью и закрывают бреши, которые кто-то все равно должен сделать.
Это фаза на которой работает материал ДеМарко. Это фаза на которой реально создается продукт, поскольку на следующих фаза создавать что-либо будет все сложнее и сложнее...
Через некоторое время становится ясно, что проект, пожалуй, получится. На этой фазе команда обычно несколько расширяется, и вместе с полезными членами команды, она набирает также некоторое количество корпоративных паразитов, более-менее равномерно разбросанных по команде.
К счастью, на этой фазе это еще нестрашно, поскольку паразитов мало и из влияние, в силу их разбросанности по команде, не кумулятивно. Конечно, они уже мешают, но несильно. Не более, чем просто дурак или даже просто неопытный член команды.
Но в какой-то момент время начинает поджимать, и тут начинаются изменения, которые придется изложить очень и очень подробно, поскольку именно они критичны. Итак, когда время начинает поджимать, возникают противоборствующие силы, действующие на проект. С одной стороны, менеджмент, которые отвечают за проект головой, стремятся выпустить продукт вовремя или хотя бы с какой-то резонной задержкой, но не более. И их легко понять.
С другой стороны, разработчики и тестеры видят ужасающие и зияющие в продукте дыры, причем часто, в силу специфики своего положения относительно продукта, склонны преувеличивать их размеры. Но даже и без преувеличения, любой продукт всегда имеет какие-то серьезные проблемы. Тем самым "нижние этажи" команды тянут продукты "вниз", в сторону задержки расписания, причем по обьективным реальным причинам.
Результат? Как и в механической системе под воздействием двух сил, действующих на нее на разрыв, где-то посреди команды появляется линия напряжения.
Эта линия не столь ровная как на картинке и не строго горизонтальная, но она есть. И как любая линия напряжения она привлекает внимание менеджмента. И тут происходит - само собой - очень важное изменение в команде. Дело в том, что по самой своей природе корпоративные паразиты тяготеют к областям, привлекающим внимание менеджмента. Что это означает в данной ситуации? Верно! Корпоративные паразиты стягиваются со всей команды к линии напряжения в команде, поскольку именно к ней приковано внимание менеджмента.
В результате, корпоративные паразиты команды выстраиваются вдоль линии напряжения в команде, разрываемой на две части надеждами менеджмента и реалиями, наблюдаемыми людьми "внизу".
А теперь, представьте себе два куска соединенных вмест и разрываемых в разные стороны все увеличивающейся силой? Учтите, корпоративные паразиты - это не клей, это смазка. Даже если их и не хватило на то, чтобы полностью изолировать две части команды друг от друга, они все равно работают как своего рода перформация на туалетной бумаге. А разрывающая сила и напряжение все растет - срок выпуска продукта приближается, и безобразий в нем... ну. не то чтобы не уменьшалось, но совсем не в том темпе, который нужен, чтобы выпустить его в срок.
Результат? Вполне предсказуемый. Разрыв команды на две части - менеджмент и собственно команда, создающая продукт.
При этом, корпоративные паразиты, выстроившиеся "в две шеренги" превращаются в своего рода два "отражающих слоя". Потоки реальной информации снизу отражаются паразитами вниз и не пропускаются в менеджмент. Причина простая - кто ж хочет докладывать начальству неприятные новости? А если кто из членов команды внизу слишком настойчивый, его можно и дискредитировать в глазах начальства, чтобы ему просто не доверяли.
Но просто изоляция от команды не работала бы, поскольку даже очень глупый менеджер может заметить полное отсутствие информации. Вместо этого отражающий слой "прилипший" к менеджменту, отражает ожидания и надежды менеджмента в форме фальшивых потоков информации, данных, которые отражают ожидания менеджмента, а не реальность. Конечно, они обычно не придумываются из пустоого воздуха, а частично базируются на потоках, идущих снизу, но после суровой фильтрации, иногда в несколько слоев, и с серьезным изменением акцентов. А часто и откровенно "глушится" фиктивными, так называемыми "процесс" проблемами.
По сути, менеджмент начинает жить в своеобразной виртуальной реальности, где роль рецепторов и источников информации о реальности выполняют корпоративные паразиты отражающего слоя, кровно заинтересованные в том, чтобы менеджмент слышал то, что он хочет, и в котором роль людей, которые реально разрабатывают и тестируют продукт постепенно сводится если не совсем к нулю, то к чему-то вроде того.
Вот в этой-то виртуальной реальности и принимаются обычно решения о выпуске продукта и обьявлении его успешным. Само решение о готовности продукта в конечном итоге оказывается результатом некоторой гранд-иллюзии, своего рода корпоративной галлюцинации, индуцированной корпоративными паразитами и разрывом в информационных потоках.
Результат? Увы, опять предсказуемый:
Можно ли что-то с этим разрывом сделать? Снизу - нельзя. То есть временно можно, но пожертвовав своей карьерой. А когда с вами "разберутся", все пойдет опять по накатанной колее с незначительной задержкой. А сверху... а почему бы вы хотели бы это предотвратить сверху? Если вы не из породы "железных феликсов" и "железных леди", которые могут пожать плечами и выпустить продукт с вопиющими дырками... как еще вы создадите вокруг себя иллюзию, которая даст вам мужество нажать кнопку "Release"?
Люди слабы.
Начальники удивительно слабы.
Подозреваю, что есть какой-то противоестественный корпоративный отбор, который позволяет только тем стать начальником, кто слаб, кто как глина в руках этой нечеловеческой отвратитетльной системы, кто позволяет делать с собой то, что человек, реальный человек, по Горькому, с большой буквы, никогда не позволит с собой сделать. Впрочем, меня занесло...
Правда как всегда проста. Вы - начальник. Вы - отвечаете. Вы боитесь. Кто-то должен взять на себя "обезболивание". Кто-то должен создать для вас иллюзию, когда вы уже не отличаете реальность от коллективной галлюцинации. В этом отношении находящийся внизу парень, который бубнит о проблемах в продуктах вам только мешает. А вот корпоративный паразит в отглаженном костюме и галстуке, который вешает вам лапшу на уши в духе "все хорошо, прекрасная маркиза..." - это вот то, что надо.
Главная мысль тут, что между общей готовностью продукта, готовностю продукта в голове начальника и "идеальной" готовностью продукта имеются своеобразные "пропасти". Вторую - к "идеальному" продукту - пересечь просто невозможно. Ну, нет таких продуктов, которые это сделали ли бы. Возьмите даже не Windows, а Mac OS X или любой Линакс - никто эту вторую пропасть пересечь не смог. А вот первая вполне преодолима. Результатом является то, что выпуск продукта в какой-то момент обязательно осуществляется по причинам, не имеющим отношения к качесту продукта или его реальной готовности, а исключительно по причинам в виртуальной реальности, созданной для менеджмента корпоративными паразитами. И в конечном итоге является результатом некоторой гранд-иллюзии.
Собственно, я подозреваю, что AIM работает не только в разработке софта, но и вообще в менеджменте чего бы то ни было. Равно как и то, что изобретен он был отнюдь не мной, а десятилетия, если не века назад. Не верите? Взгляните на вот эту вот картинку. Выглядит знакомо?
О, последняя деталь. Те читатели, которые совсем уж зануды, могут спросить: "Так это настоящая agile методика разработки софт или это ты так подкалывался над корпоративной культурой?" Вы знаете? Я сам до конца не уверен. Нет, честно. Выглядит это и правда как подколка, но я лично наблюдал AIM успешно работающим в течении более двадцати лет в самых различных фирмах и даже в разных странах. Нет, правда. Работает!
