Когда Agile — это ошибка.
Мнение руководителя проектов

Начать хочется с того, что я не против Agile. Но я сильно удивлен тем, что Agile пытаются внедрить не только куда можно, но ещё и куда только возможно. Ещё меня смущает, что я чаще вижу Agile doing, чем Agile being, но это уже мелочи.

Ну и конечно, меня раздражает формулировка «этот ваш вотерфольный PMBOK» от людей, которые при этом не столько даже Agile doing, а иногда даже просто HZing.

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

До того, как обсуждать ошибки, мы быстро посмотрим, где Agile использовать удобно и круто.

Тезисы «ошибок» после этого я хочу разделить на две основных группы.
1. Использование Agile – это ошибка выбора
2. Использование Agile – это лекарство от менеджеров (ошибок их работы, если быть точнее)

И это немного разное, на мой взгляд.

1. Создание IT-продуктов для широких масс

То, для чего этот самый Agile и придумали, если вдуматься. И почему я делаю акцент на широких массах?

Посыла два:
а) с малым количеством проще договориться, требует меньше итераций;
б) малое количество, не увидев результата в адекватные сроки, более вероятно разочаруется в продукте.

И хорошим примером такого рода продукта может быть Notion (или аналоги), различные высоконагруженные сервисы типа сервисов Яндекса или Авито или приложение для вашего телефона (вставьте ваше название).

P.S. Кроме итераций, иногда вам могут помочь инкременты. И это таки две большие разницы.

2. Тестирование гипотез или создание MVP

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

Создание MVP – с оговоркой, что отсутствует внятная задача и чёткое понимание итогового вида продукта. Собственно, именно поэтому я объединил гипотезы и MVP (да, можно кидать в меня за это разное).

Примеров – тысячи. И даже те самые лендинги на Тильде, которые делают наши предприниматели, прежде чем пытаться что-то продать (два в одном – и гипотезу протестировали, и MVP сайта).

Внезапно, если у вас уже контракт на всю работу – вряд ли это стоит называть MVP. Ну просто потому, что от него решение Go/No go уже не зависит.

3. Создание продуктов или реализация проектов в постоянно меняющейся среде

Важно! Это редко когда создание информационных систем при наличии ТЗ и нормативки.

Почему? Даже не из-за снижения затрат на планирование (неожиданно, но в классическом Project-менеджменте есть такие инструменты как Rolling wave planning, а ещё короткие циклы перепланирования), а из-за восприятия данного перепланирования людьми. В этом есть какая-то магия, но изменить бэклог проще, чем изменить план, даже очень короткий.

В общем-то, это почти как первый пункт, но только не для широких масс. Ну например, делали вы приложение, которое планировалось работать с 1С и «внезапно» заказчик ушёл на SAP (очень внезапно, за годик-два, сарказм).

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

4. Реализация НИРов

Возможно, это спорно. Я долго думал, выделять ли этот пункт (ведь это можно рассматривать как гипотезу или MVP), но решил, что всё же НИР –это шире, и оно того стоит.

Нет, НИР тоже планируют. Но я почему-то вижу, что когда у людей ПЛАН (именно так), то они редко когда останавливаются, если внезапно, на ранних этапах они достигают успеха. Они видят своей целью проверить всё, что есть в плане, и это ведёт к потерям времени и денег, если там нет человека, который адекватно видит задачу (и многие там – натуры увлечённые). А может быть, не столько увлечённые, сколько переживающие за свои рабочие места?

У меня будет не совсем научный пример, но он тонко намекнёт, откуда растут ноги. Клиент искал подходящую железку. Подошла первая же. Причём как по цене, так и по параметрам (избыточным, к слову). НО… Сотрудники пошли проверять ещё 2 и потеряли на этом больше месяца. Потому что им сказали посмотреть «штуки три».

Так вот, при отсутствии формального плана quick win воспринимается проще. И я уже говорил, что, на мой взгляд, это какая-то магия?

Вероятно, каждый может предложить ещё минимум 300 уникальных сценариев, которые я не перечислил, но я не претендую на единственно верное и абсолютно полное мнение.

А теперь – ошибки.

1. Повсеместное внедрение Agile

Вы будете бесконечно круто выглядеть, поставив доску Kanban в отделе продаж, но, правда, на этом стоит остановиться. Клиент не ждёт 200 показов (THIS IS SPARTA), чтобы снять офис или выбрать машину. Он ждёт 3, максимум 5 крутых вариантов, дальше он устает.

И уходит к другому. Возможно, к вашему бывшему сотруднику.

2. Объяснение неправильного понимания или одних и тех же вопросов по 5 раз внедрением Agile. Аналитика по Agile.

«Я вас переспрашиваю один и тот же вопрос, потому что мы внедрили Agile».

Звучит круто? Нет. Просто ведите записи встреч – это будет выглядеть даже больше Agile.

Встречаться 30 раз, чтобы обсудить раздел ТЗ или постановку – бывает, но плюсов вам не добавляет.
Я думаю, любой хороший продакт скажет вам, что если приходить слишком часто и без результата, вас рано или поздно пошлют. Сделать 3-4 итерации – это нормально.

Нет, правда, я бы не вставил это сюда, если бы не встречался с этим.

P.S. Возможно, что риэлторы из этой секты. «Вы точно не хотите офис 300м2, хотя вы просили 100м2?».

3. Внедрение «типовых» продуктов по Agile

Я тут с удивлением стал видеть на сайтах многих вендоров или интеграторов внедрение коробочных решений по Agile. На сайтах, в разговорах.

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

Если в итоговой форме перед приёмкой надо поправить 2-3 поля – это НЕ Agile.

Я с ужасом представляю внедрение 1С по Agile:
Итерация 1: Мы вам поставили коробку, можете вводить данные.

Итерация 2: Мы обновили формы под ваши требования, но теперь надо забить данные по отсутствующим полям снова.

Итерация 3: Мы добавили аналитику, но надо перепровести все документы.

Итерация 4: Вы дали нам обратную связь, что в форме из итерации 2 ошибка, мы её переделали и откатились на месяц назад.

Два вопроса:
1) Когда вас пошлют?
2) Сколько вы потратите на адаптацию сотрудников?

И это я молчу про обучение и трудозатраты. Или надо кричать?

Вопрос – кто из вас увидел в этой картинке заказчика «банкоматом»?

И кстати, предварительное знакомство клиента с результатом работы – это тоже НЕ Agile. Это здравый смысл.

4. Agile процессы

Возможно, это пересекается с прошлыми пунктами. Но вы уже слышали про отчётность внутри компании по Agile? Или вообще, желательно, чтобы это была отчётность в налоговую (любой контролирующий орган).

Нет? Почему бы и нет, ведь это прикольно – сдать часть информации, потом дослать уточнённую, потом исправить (нет, ну многие так и работают, даже не зная про Agile).

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

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

Признаться честно, именно этот раздел и заставил меня написать всю заметку. Я тут сидел, «курил» в Agile свежим (почти) взором, и меня знатно прострелило. Меня прострелило, что таким образом люди хотят меньше зависеть от м… уверенных в себе менеджеров.

В каком смысле? А кто из вас не сталкивался с проблемами на работе из-за руководителя? Так вот, в некотором смысле Agile – это лекарство от такого менеджера.

Я всегда говорил, что инструменты Agile не новы, но такими популярными стали именно сейчас:
● Kanban-доска – 1960 годы
● Покер планирования – 1940 годы, метод Дельфи
● Теория Х и У – снова 1960 годы

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

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

1. Сотрудники не хотят работать с менеджерами, или же самоорганизующиеся команды

Тут у меня две мысли:
а) очень большое число сторонников теории Х среди менеджеров,
б) непринятие неформальных лидеров.

Ну, кто из вас не сталкивался с этим в той или иной степени?

Когда начальник постоянно пытается поймать за «ничего-не-деланием»? И ему плевать, что у тебя закончилось «мыслетопливо» (спасибо, Максим Дорофеев).

А сколько хороших специалистов ушло просто потому, что менеджер не считается с мнением лидеров, а тем более и просто членов команды... Я был свидетелем такого неоднократно.

И это правда большая ошибка многих руководителей. Забить на мнение члена команды, потому что он в компании 3 месяца? Ок, отсчёт пошел. Жди, Agile-десант уже выдвинулся.

2. А давай сегодня сделаем еще №№ задач, или WIP (Work-in-Progress) лимиты

И снова у меня две мысли:
а) желание сделать работу качественно,
б) Work-life баланс.

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

Касательно work-life баланса, в общем-то это про «впихивать невпихуемое». Или не ставить сроки «вчера». Картинка, как руководитель пришёл с совещания по обсуждению маленькой проблемы, и теперь у вас много работы по переделыванию всего UI... до конца этой недели, бывала?

Кто из вас, после пары заходов руководителя со словами «а ещё вот это» сидел до ночи? Я сидел. И это сильно… Демотивирует, как минимум. Особенно, когда ты сидишь и «а с чего бы начать-то, а?».

WIP решает этот вопрос. Да, можно пытаться ускорять выполнение задач, но точно не брать триста задач разом.

3. Servant лидер (он же прислужник, лидерство-служение, слуга как лидер или лидер как слуга)

И вновь два пункта:
а) люди устали от «начальников»,
б) так надо.

Почему устали? Так каждая вторая статья в интернете, где упоминается начальник, так или иначе намекает на неумение сторон договариваться и обсуждать. И, внезапно, я согласен, что это вина начальника. Его ответственность за решение проблемы выше, чем вина исполнителя.

Ну и так правда надо. Возможно, не всегда, но часто. Собрав команду, ей надо верить и её надо поддерживать, помогать, а не РУКоводить. А ещё иногда полезно побыть этим самым Servant'ом. Это может помочь во многом, и не только по работе. Но не все справляются с таким вызовом. И в этот момент ваши сотрудники начинают тихо скандировать 12 принципов. Пока что – just for lulz. А что будет дальше?..

4. Ограничение спринтов по объёму

Я бы сказал, что это почти что те же WIP'ы, в контексте данного диалога. Но тут есть классный посыл. WIP – он всё же про объём работы в моменте, а вот ограничение спринта – оно не менее полезно.

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

5. Неумение планировать

Это никак не связано с Agile, это просто проблема.
И сюда стоит добавить немного юмора:

Проблему я тоже вижу из двух частей:
а) нежелание перепланировать,
б) нежелание планировать.

Первое – неотъемлемый атрибут адекватного менеджмента. Вы не в вакууме, уточнять и корректировать план – это нормально. Но я часто вижу, как план живёт сам по себе, а работа – сама по себе.

Второе иногда выходит из первого. Раз всё всё равно не по плану, то зачем планировать, говорят они.
Как бы это не было грустно, но так тоже думают.

Результат плохой – а что ещё вы хотели, когда нет цели и сроков… И нет, сроки не обязательно забитые гвоздями. А вот внятные цели без плана появляются редко. Или остаются верхнеуровневыми и малопонятными сотрудникам.

Закончить хочется позитивно. Agile – это не плохо. Просто надо его правильно готовить.

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

Считаете, что заголовок не подходит? Исправим в следующей итерации.

Автор:
Михаил Белов, PMP, ICP-ACC
— Административный директор PMI Moscow, Russia chapter, 2020;
— Эксперт 2MNG.PRO;
— Приглашенный преподаватель ВШЭ;
— Старший преподаватель МАДИ.

Telegram: @vezzird

Подпишитесь на @pmclub, чтобы не пропустить новые статьи