Хаос вместо аджайла

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

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

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

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

Казалось бы, а отчего вообще такие проблемы? Мы же всё делаем правильно, у нас и дэйли, и ретры, и двухнедельные итерации, что вы к нам прикопались? Мы даже перестали таскать всех подряд на все подряд митинги! У нас настоящий аджайл! А паровоз всё не едет. Ну, во всяком случае не едет, если его не пнуть. И так на каждый чих.

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

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

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

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

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

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

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

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

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

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

В топком болоте гибкого микроменеджмента и консалтинг-услуг зачастую вообще сложно понять, за что уплачены деньги. Измеримую ценность представляет собой разве что очень крупный «кирпич», прописанный в договоре, зачастую несовместимый не только с аджайлом, но даже попросту с жизнью. Потому так важно на каждом этапе тщательно артикулировать промежуточное вэлью. Это уже очень непросто. Никакой SMART не объяснит конечному исполнителю, зачем мы делаем вот эту конкретную презентацию. В чем ее инкремент? В чем измеряется ее конечное вэлью?

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

Но если помнить, что само по себе любое действие может и должно оставлять после себя артефакты (иногда это даже простая «минутка» по итогам созвона), и если договориться, что сам по себе никакой артефакт не является вэлью, а может (только может!) быть его носителем, то все встает на свои места.

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

Однако ключевая сложность «поздней поставки» состоит не в том, как своевременно и полноценно выявить вэлью, и даже не в том, что важно быть готовым к тому, что это вэлью может быть в любой момент (и наверняка будет!) переоценено или даже подвергнется сущностной мутации. Это заключено в самой базовой природе вэлью.

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

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

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

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

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

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

Монструозные многостраничные сценарии в терминах BDD и DoD, развернутые мокапы, которые вторую неделю никак не получат аппрув от специалиста по дизайн-коду, многодневное регресс-тестирование взмыленных QA, а на выходе… на выходе проделана туча работы только лишь затем, чтобы в итоге выяснить, что сделано равно не то, что просили. Потому что тут нарушается ключевое правило ранней поставки и позднего принятия решения. Напротив, решение требуется принять максимально рано – иначе не успеть к сроку, а продукт будет поставлен максимально поздно, потому что туча времени ушла на подготовительную работу вместо итеративности. Если ваша цель – максимизировать ущерб, то вы на правильном пути. Традиционно, в сторону вотерфолла.

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

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

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

Худший при этом способ производства бессмысленного шума – это обсуждение самой задачи вместо сути задачи. Ты сделай вот это вот так, а потом вот это и вот так. Иди, исполняй. По сути, именно при таких постановках задач потом преуспевают всяческие генеративные нейросети вроде ChatGPT. Действительно, представьте себе программиста, которому собрали готовые тесты и описали до кучи все алгоритмы, которые тот должен реализовать. Иди да делай. Такого исполнителя в самом уничижительном смысле этого слова можно и должно в итоге заменить детерминированным процессом, проще говоря скриптом. Он не творец, он ничего не производит, он не приносят вэлью, он вообще не в курсе, где тут вэлью, да ему и без разницы.

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

Еще одна немаловажная деталь, ставящая вэлью во главу угла всякой гибкой методологии, лежит в плоскости теории информации. Любой достаточно сложный организационный процесс производит массу шума. Сваленные в кучу в почтовом ящике брифы митингов, вороха разрозненной документации, тонны технических спецификаций и OLAP-выгрузок – мы на самом деле ежедневно утопаем в этом барахле. Большинство из этих документов ни разу не откроет даже их автор. Большинство переписок, в копию которых вас добавили, вам не нужны. Да вы их и не читаете. Все это пухнет как снежный ком, бестолковое сидение на очередном митинге развивает разве что вашу осанку, потому что если вы облокотитесь на стол, вы заснете. Именно отсюда растут ноги всех этих «срочно!» и капслоков в теме письма. Повышая уровень сигнала, до вас пытаются докричаться сквозь шум.

Но обратите внимание, как иногда даже самый скучный митинг вдруг прерывается яростным спором двух обыкновенно тихих исполнителей. Что их привело в столь высокоресурсное состояние? А очень просто. Подобные внезапные споры всегда о сути. Они всегда – о вэлью. Наученный думать в терминах конечной ценности и достаточно осведомленный о проекте участник вашей команды из любого информационного мусора будет легко выхватывать крохи необходимого ему знания, того самого, достижимого, измеримого. Погодите, скажет он, вам на самом деле нужно вот это? Вы уверены? И, жарко поспорив, уйдет делать, спокойно игнорируя все прочие сигналы.

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

Все описанные выше примеры проектного хаоса даже вполне опытным и поднаторевшем в гибких методиках руководителям проектов порой кажутся непреодолимыми, постоянно стимулируя к ползучей вотерфоллизации, когда формальное следование скраму начинает больше напоминать «итальянскую забастовку», которая что угодно может превратить в кучу неработоспособного барахла, исполняемого скорее по привычке и чтобы отстали. Один из наиболее распространенных способов подобной вотерфоллизации – внедрение низового микроменеджмента, который немедленно порождает нечто вроде квантового парадокса Зенона. Чем чаще вы уточняете задачу (в точности соблюдая основные принципы аджайла) , тем выше вероятность того, что задача вообще перестанет двигаться с места, постоянно возвращаясь на исходную, к постановке.

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

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

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

Если же зуд оверконтроллинга в ответ на очередной приступ паники (быть аджайл значит обладать крепкими нервами, вы еще не поняли?) совсем не утихает, то в ход идет самая тяжелая артиллерия из арсенала выпускников MBA. Казалось бы, что плохого может быть в ключевых показателях эффективности? Чем это не вэлью? Достижимое? Измеримое? Амбициозное? Правило 70% подтянем и заживем!

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

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

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

Гибким быть непросто. И быть аджайл – не значит банально ринуться в пучину модной методики, которая кровью и потом, но все-таки доказала свою эффективность в IT, а в наше время все хотят стать немного айтишниками. Особенно замученные начальством и общей беспросветностью нишевые инхаус-разработчики, не получающие от профессии и толики того удовольствия, которое якобы даром достается всяким там хипстерам на кампусах. Более того, и сами нативные айтишники зачастую застревают в производственном аду, причем некоторые из них, повинуясь синдрому утенка, даже получают от всего этого барахтанья некоторое удовольствие.

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

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