Как стать автором
Обновить

Новая agile методика разработки софта — AIM

Время на прочтение 6 мин
Количество просмотров 632
Как и ранее, кросс-пост с моего основного блога



<P mce_keep=«true»>AIM — хорошее слово, но это далеко не единственное, что есть в этой новой agile методике разработки софта. Интересная деталь ее состоит в том, что это не придумка, созданная в академической среде, а результат наблюдения над реальными успешными проектами в течении более двух десятилетий. Каким-то мистическим путем все успешные менеджеры софтверных продуктов, за редчайшими исключениями, в той или иной мере всегда повторяли одни и те же шаги, а все неуспешные менеджеры обычно пропускали какие-то из этих шагов. Теперь эта мощная и хорошо работающая методика представляется вашему вниманию.



<P mce_keep=«true»>A.I.M. расшифровывается как Agile Insanity Management. Вообще-то, ее следовало бы назвать Agile Management by Insanity, но маркетинг счел, что такое название вряд ли найдет поддержку в корпоративной среде, к тому же сокращение AIM звучит куда лучше чем AMI или AMbI. Откуда столь своеобразное название станет ясно чуть позднее.

<P mce_keep=«true»>Итак, AIM. Первый шаг всегда состоит из одного и того же — вы создаете сплоченную мотивированную команду, в которой все делают свое дело. Это обычно происходит в то время, когда успех проекта далеко не очевиден и продукт не представляет из себя ничего интересного для корпоративных паразитов. Команда, сплоченная во имя великой цели, работает день и ночь и создает базу — продукт, пусть даже и со множеством недоделок, но нечто, что работает, что можно показывать людям, что имеет лицо, форму и функциональность. И даже более того.

AIM Step 1 

<P mce_keep=«true»>На этой фазе команда — едина, все ее части — менеджмент, менеджмент проектов, разработка и тест работают вместе ради общей цели — создание продукта. Информационные потоки идут свободно сверху вниз и снизу вверх. Девы и тестеры знают, чего хочет от продукта менеджмент, менеджмент в курсе всех проблем, которые испытывают девы и тестеры, а пи-эмы бросаются грудью и закрывают бреши, которые кто-то все равно должен сделать.

<P mce_keep=«true»>Это фаза на которой работает материал ДеМарко. Это фаза на которой реально создается продукт, поскольку на следующих фаза создавать что-либо будет все сложнее и сложнее...

<P mce_keep=«true»>Через некоторое время становится ясно, что проект, пожалуй, получится. На этой фазе команда обычно несколько расширяется, и вместе с полезными членами команды, она набирает также некоторое количество корпоративных паразитов, более-менее равномерно разбросанных по команде.

AIM Step 2

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

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

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

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

AIM Step 3

Эта линия не столь ровная как на картинке и не строго горизонтальная, но она есть. И как любая линия напряжения она привлекает внимание менеджмента. И тут происходит — само собой — очень важное изменение в команде. Дело в том, что по самой своей природе корпоративные паразиты тяготеют к областям, привлекающим внимание менеджмента. Что это означает в данной ситуации? Верно! Корпоративные паразиты стягиваются со всей команды к линии напряжения в команде, поскольку именно к ней приковано внимание менеджмента.

AIM Step 4

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

<P mce_keep=«true»>AIM Step 5

<P mce_keep=«true»>А теперь, представьте себе два куска соединенных вмест и разрываемых в разные стороны все увеличивающейся силой? Учтите, корпоративные паразиты - это не клей, это смазка. Даже если их и не хватило на то, чтобы полностью изолировать две части команды друг от друга, они все равно работают как своего рода перформация на туалетной бумаге. А разрывающая сила и напряжение все растет — срок выпуска продукта приближается, и безобразий в нем… ну. не то чтобы не уменьшалось, но совсем не в том темпе, который нужен, чтобы выпустить его в срок. 

<P mce_keep=«true»>Результат? Вполне предсказуемый. Разрыв команды на две части — менеджмент и собственно команда, создающая продукт.

AIM Step 6 

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

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

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

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

Результат? Увы, опять предсказуемый:

AIM Step 7

Можно ли что-то с этим разрывом сделать? Снизу — нельзя. То есть временно можно, но пожертвовав своей карьерой. А когда с вами «разберутся», все пойдет опять по накатанной колее с незначительной задержкой. А сверху… а почему бы вы хотели бы это предотвратить сверху? Если вы не из породы «железных феликсов» и «железных леди», которые могут пожать плечами и выпустить продукт с вопиющими дырками… как еще вы создадите вокруг себя иллюзию, которая даст вам мужество нажать кнопку «Release»?

Люди слабы.

Начальники удивительно слабы.

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

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

Главная мысль тут, что между общей готовностью продукта, готовностю продукта в голове начальника и «идеальной» готовностью продукта имеются своеобразные «пропасти». Вторую — к «идеальному» продукту — пересечь просто невозможно. Ну, нет таких продуктов, которые это сделали ли бы. Возьмите даже не Windows, а Mac OS X или любой Линакс — никто эту вторую пропасть пересечь не смог. А вот первая вполне преодолима. Результатом является то, что выпуск продукта в какой-то момент обязательно осуществляется по причинам, не имеющим отношения к качесту продукта или его реальной готовности, а исключительно по причинам в виртуальной реальности, созданной для менеджмента корпоративными паразитами. И в конечном итоге является результатом некоторой гранд-иллюзии.

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

AIM Results

<P mce_keep=«true»>О, последняя деталь. Те читатели, которые совсем уж зануды, могут спросить: «Так это настоящая agile методика разработки софт или это ты так подкалывался над корпоративной культурой?» Вы знаете? Я сам до конца не уверен. Нет, честно. Выглядит это и правда как подколка, но я лично наблюдал AIM успешно работающим в течении более двадцати лет в самых различных фирмах и даже в разных странах. Нет, правда. Работает!
Теги:
Хабы:
+1
Комментарии 4
Комментарии Комментарии 4

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн