Почему Agile иногда не работает
Пару лет назад я заходил к родственнику. Моему бедному кузену (а он генеральный директор страховой компании) продали «серебряную пулю Agile» — но она не сработала, и его это очень расстроило: «Чушь всё это! Мы начали делать всё совершенно иначе. Мы пригласили консультантов. Мы наняли специальных руководителей проектов. Не сработало! Ничего не изменилось. Никто ни за что не отвечает. Я слышу только оправдания»
Не помню, что я ответил тогда, но знаю, как ответил бы сегодня. Я бы набросал несколько рисунков, словом не упомянув Agile. Пришлось бы объяснить кузену несколько основных понятий…
1. КПД процесса
Во-первых, если посмотреть на срок разработки — время, прошедшее с момента появления идеи до момента, когда ее воплощение дойдет до клиентов, — можно заметить, что большую часть времени занимает «ожидание». 15-процентный КПД (время фактической работы / срок разработки) — это нормально. Звучит странно, да? Но давайте пристальнее взглянем на то, что находится вроде бы на виду: на собственно выполнение работы тратится малая часть времени. У лучших компаний этот показатель достигает 40%. В общем, чтобы ускорить разработку, нужно сократить время «ожидания».
2. Незапланированная работа и многозадачность
Обычное дело, когда 75% ресурсов уходят на незапланированную работу и переключение между задачами. Команда может даже не понимать, что все происходит именно так. Это в буквальном смысле «накладные расходы», которые часто даже не отслеживаются в системах учета задач. Скорее всего, команда на такое положение дел жалуется (поскольку это ужасно раздражает), но если на эти жалобы достаточно долго не обращать внимания, люди просто принимают мрачную действительность как данность.
А теперь давайте представим это как одну из «совмещенных услуг» в рамках компании: команда отвечает за решение проблем в уже работающем продукте (или развертывание новой инфраструктуры) — и при этом одновременно занята работой над «проектами». Внезапно у нас появляется узкое место.
Мораль. Учитывайте источники незапланированной работы и просчитывайте экономические последствия оказания «совмещенных услуг». Эти услуги имеют очевидный смысл, но часто они толкают на затратное предварительное планирование.
3. Маленький, средний и большой
Есть такой интересный прием: нарисуем на графике срок выполнения больших, средних и маленьких «рабочих элементов» проекта, а затем попытаемся подняться на уровень выше и сосредоточиться на том, что имеет фактическую ценность для клиента (а не на задачах). Мы заметим, что во многих организациях «объем» работы не определяет срок ее выполнения. Так происходит потому, что на срок выполнения задачи влияет множество других обстоятельств (зависимости, незапланированная работа, много незавершенной работы и т. д.).
4. Реализация коммерческой выгоды
Множество усилий тратится на снижение того, что я называю «риском поставки» — это когда вы делаете проекты на заказ, а клиент оплачивает работу по факту поставки готового продукта. В случае SaaS (ПО как услуга) нам платят не по факту сделанной работы — коммерческая выгода нарастает со временем. Я называю это «риском коммерческой выгоды» (риск того, что работа окажется коммерчески бесполезной).
Крупные организации часто внедряют методологию гибкой разработки, но не видят ожидаемого повышения коммерческой выгоды. Причина в том, что разработка, конечно, идет быстрее, но это не влияет на 1) принятие правильных решений по продуктам и 2) работу над реализацией того, что дает коммерческую выгоду. ВЕСЬ СМЫСЛ методики Agile — снижение риска. В терминах работы над проектом риск определяется выполнением работ по графику и обеспечением заданной функциональности. Тот же риск в терминах продукта выражается так: «Эта штука ни черта не работает!» Поэтому заказчику нельзя соглашаться на «принятие» некоторой функции, если коммерческой выгоды от нее нет.
Во многих компаниях используется модель, изображенная слева. В некоторых — модель справа. И когда в итоге работы получается нечто дурно пахнущее, они пытаются впихнуть в систему побольше работы, но от этого становится только хуже.