Революционный Agile
Agile, слово которое сегодня произносят везде и всюду. Не то чтобы уже из каждого утюга … Но наш главный инноватор Греф пару лет назад вернувшись из США заявил что ТАМ все по Agile и мы от них бесконечно отстаем поэтому. И с тех пор понеслось… К слову, мой хороший знакомый который работает СберТехе рассказал, что у них появился привилегированный народ, избранные творцы, которые работают по Agile, а все остальные утонули в чудовищной бюрократии еще больше.
Возможно недалек тот день, по аналогии с нанотехнологиями, когда Agile “проникнет” в нашу медиа-жизнь настолько, что и Мин. обороны в лице Шойгу тоже будет все делать по Agile. Хотя надеюсь до гос. корпорации по Agile не дойдет. При том что с термином Agile еще больше путаницы чем с нанотехнологиями. Многие люди гордо заявляют что они работают по Agile или даже SCRUM, при этом не могут дать определение - а как это? Что такое работать по Agile? В чем это выражается?
Agile переводится как гибкий, эластичный. Что можно так же трактовать как готовый к изменениям - это подход который объединяет десятки различных методологий реализации проектов. Суть Agile закреплена в Манифесте из 4-х тезисов:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
Данные тезисы каждый толкует в меру своей испорченности. Я слышал например в том виде, что руководитель команды обязан чуть ли не в лобик целовать своих подчиненных и всячески им угождать, чтобы не дай бог не пропала их мотивация. Подрядная организация будет толковать Agile в том смысле что вам нужно купить у них как можно больше услуг - при том что в итоге 70 % их работы не будет иметь к конечному результату никакого отношения.
Однако суть тезисов манифеста возникла на основе анализа ряда системных проблем, болей, которые в принципе проявляют себя из года в год при реализации проектов. Речь не только об ИТ, а вообще о самых разных отраслях. Но в ИТ они всплыли раньше чем у других, чуть ли еще не в 80-х.
Проблема первая. Инициатор проекта часто не просто не знает что конкретно он хочет, он даже цель толком не может поставить. Т.е. ответить на вопросы: зачем этот проект нужен? Что он хочет достичь в итоге ? И как это “достичь” можно будет ощутить, а может даже и измерить? Соответственно в голове у инициатора нет ни то что концепта, на уровне идеи обычно всё мутно и туманно. И даже если все это грамотно описать на бумаге, реализовать буква в букву, то с вероятностью минимум % 70 инициатор заявит что это вообще не то что он хотел, и вообще ему это на хрен не надо и все уйдут на второй круг примерно с теми же результатами.
Проблема вторая. Время. Как известно быстро только кошки родятся. Да и то - не факт. Пока вы что-то делаете - формализуете требования, пишите задани(я), согласуете, планируете, набираете команду, наконец реализовываете, сдаете, устраняете замечания ….. Все (среда, рынок, люди и т.п.) может измениться и вы опять получаете никому на хрен не нужны результат. Время ушло, деньги ушли, результат - баран начихал.
Проблема третья. Никогда невозможно предусмотреть всё. И как говорят - составленный и согласованный план проекта полностью устаревает в момент начала его реализации. В этом на практике убеждался много раз. Это не значит что от планирования нужно отказаться вообще. Нет конечно. Но вот детальное планирование, как это любят некоторые товарищи - диаграмма Ганта, 3-х уровневая, как правило это все время выброшенное в пустую. Не раз от меня требовали план (диаграмму в Проджекте), тратил неделю чтобы её сделать, и сразу забывал о ней навсегда. Потому что план в голове есть и так, там же можно его со скоростью свете актуализировать, а сам комплекс мероприятий в рамках реализации проекта не дает сбиться с истинного пути.
Проблема четвертая. Бюрократия. Это большое искусство не растерять смыл решения в процессе его согласования со всеми заинтересованными сторонами. Обычно каждый согласовант прибывает в своей картине мира и читая присланный документ интерпретирует его по своему. Мало того что эти процедуры согласования занимают уйму времени, потому что у всех всегда есть дела поважней чем читать какой-то присланный бред. Так еще и результат часто можно идентифицировать как смесь бульдога с носорогом и кусочек мамонта.
Последняя проблема, по порядку но не по значимости. Люди. Как правило самому сделать что-то более-менее значимое невозможно. Приходится нанимать помощников. Однако так как в рамках сложившейся общественных отношений каждый сам за себя, то человеку которому вы платите за работу ваш проект как правило по барабану (сроки, качество). Он пришел к вам работать потому, что ему очень нужны деньги. Как следствие из-за человеческого фактора проектов гибнет больше всего. HR бьются с этой проблемой с переменным успехом - запугивать и покупать людей получается, сделать лояльными - нет.
Классический пример. Сидит перед тобой веселая компания: заказчик, проектный менеджер, аналитик, программист, тестировщик. И каждый валит друг на друга почему на выходе получилось говно. Отчасти их работа была похожа на игру, где по цепочке на время передавалось сообщение смысл которого был полностью искажен. С той разницей, что каждый подстраховался на тему как избежать ответственность и перевести стрелки на другого. Задумались над этой проблемой умные люди и выдали решение - Agile манифест:
важнее выстраивать отношения с людьми, чем процессы
важнее результат, чем связанная с ним макулатура
важнее отношения с заказчиком, чем бабло или бонусы
важнее быть готовым к переменам, чем с упираться как одно кудрявое животное
На мой взгляд самая нормальная книжка SCRUM Сазерленда, её пересказывать не буду. В ней концепция гибкого подхода изложена простыми словами на интренсных историях, и про самый популярную Agile-методологию написано. Как выстроить команду, из кого она должна состоять и тому подобное. Все есть в книжке. Пересказывать нет смысла. Интересно поговорить о следствиях внедрения того же SCRUM и о проблемах.
Итак, вот есть agile команда. Допустим великолепная семерка, или семь самураев. Или восемь. Не суть. Вы ее собирали, тренировали год.
Проблема первая. Agile команда - это исполнители. Пусть хорошо мотивированные, но сами они себе цель ставить не будут. Им нельзя сказать: а хорошо бы заработать мне еще миллион-другой … Они скажут: да, милорд и побегут делать вас еще богаче. Т.е. когда работаешь с Agile команда - нужно иметь стратегию, измеряемую цель. И все такое. А это сложно. Напомню, стратегия это путь точки А в точку Б. Если не знаешь, хотя бы примерно, где точка Б - то будешь бродить кругами вокруг А.
Проблема вторая. Будучи начальником, сильной Agile команде придется соответствовать. Это как у викингов - предводитель должен быть самым крутым, сильным, веселым, жестоким, брутальным и т.п. Слабакам, любителям корпоративных игр, хитрожопым, пазерам и т.п. команда просто не будет подчинятся. В таких отношениях люди быстро проверяются, кто есть кто. Если босс из себя изображает Альфа-самца, при этом кланяется впол своему начальству и боиться слово сказать отстаивая интересы проекта и команды, то эффективно управлять Agile - командой он не сможет. Нужно быть первым, среди равных. и никак иначе.
Поясню. В больших (и не очень) корпорациях очень модно нанимать т.н. Agile - коучей. Которые приходят, пляшут с бубнами, ставят методики, которые в принципе довольно простые. Даже на реальных проектах, толкают пламенные речи и сваливают. А дальше команда остается один на один со своим боссом, в той же среде. И так может оказаться, что босс с этой бандой зверей почувствовавших вкус свободы уже справиться не сможет.
Проблема третья. Мотивация Agile - команды строится на том чтобы было интересно. Интересные задачи, возможно даже значимые для социума. Постоянное повышение сложности задач, масштаба. Вот с масштабом и сложностью часто бывают дефицит. Остается бабло. И таким образом Agile - команды неожидано может оказаться дорогим удовольствием.
А вообще, что бы кто что не говорил, современная корпоративная культура, и не только корпоративная, строится на старом добром принципе - разделяй и властвуй. Как указал выше мы живем по принципу каждый сам за себя, точнее нам не оставили выбора. И владелец чего бы то ни было постоянное решает задачу - как бы объединить людей так чтобы они вместе потрудились на его пользу, но при этом не смогли сблизится настолтко что бы начать вместе задумываться на тему кто здесь настоящий хозяин. Придумывают всякие тим-билдинги и прочая чушь, которые почти не работают. А вот Agile-методологии как раз реально работают на объединение в эффективные команды которые могут приносить реальный результат. Но объединившись в эффективную команду через какое-то время, команда обязательно начнет задаваться вопросом, почему результат производят они, а основные блага снимают другие.
Полагаю, если действительно все принципы Agile начать настойчиво воплощать в жизнь, то уже в устройстве организации начнут происходить необратимые изменения. Которые собственникам этих организаций вряд ли понравятся. Поэтому Agile это очень круто. И поэтому истории с внедрением Agile редко заходят далеко. Немного упростят бюрократию, приколотят Kanban-доску, оптимизируют работу и все.
Однако думаю рано или поздно прогресс должен взять свое.