Ложь железного треугольника
18 Авг 2020
Перевод оригинальной статьи
Привет, дорогие друзья!
Многие из вас слышали о таком термине, как Проектный Треугольник, описывающий баланс между содержанием, стоимостью, временем и качеством проекта. Но почему же он называется треугольником, если ограничения четыре? Сопоставим ли он со Scrum’ом? Читайте об этом в данной статье!
До моей карьеры в agile у меня часто бывал такой случай, когда проект был определен, спланирован, заложен в бюджет, объявлен, продан и расписан по времени — и затем почти сразу сходил с плана. Запоздалое уточнение или внезапное новое требование к планированию может мгновенно превратить лучшие планы менеджера проекта в бессмыслицу.
Даже если этого не произойдет, естественный ход развития проекта приведет к возникновению сложностей, которые невозможно было предвидеть при первичном планировании. Никакие благие намерения или интенсивная работа нам не могли помочь — все всегда заканчивалось тем, что мы должны объяснить клиенту, почему он не получит то, за что заплатил по графику, который мы обещали. Беседа выходит всегда веселой.
Оглядываясь назад на мою карьеру с использованием водопадной методологии управления проектами, я вспоминаю, что подобные проблемы происходили гораздо чаще, чем сейчас. Я могу вспомнить только два или три проекта, которые действительно шли в соответствии с планом, который мы заложили на первой же встрече с заказчиком. И все же мы продолжали работать по старинке снова и снова! Что может быть безумнее?
Так что можете себе представить мою радость, когда меня познакомили с Железным треугольником.
Также известный как проектный треугольник или тройственная ограниченность, Железный Треугольник — Это попытка простым способом передать взаимосвязь аспектов, влияющих на реализацию проекта.
Три стороны треугольника: содержание (scope), бюджет (budget) и время (time).
Исходя из принципа треугольника, все три аспекта соединены между собой в трех углах. Можно изменить любую из сторон, но, по крайней мере, одна из оставшихся двух тоже должна измениться, если вы собираетесь сохранить треугольник.
Как говорится: ”Если сломать треугольник, качество просочится наружу”. (Об этом позже.)
Ценность этой диаграммы заключается в том, что она легко передает идею о том, что, если вы увеличиваете содержание, вам нужно либо добавить бюджет (обычно с точки зрения количества членов команды), либо время. Если вы уменьшаете бюджет без изменения времени, вам нужно будет уменьшить содержание. И так далее.
Это довольно изящное выражение взаимосвязи некоторых факторов реализации проекта. И позвольте мне сказать вам, что иллюстрация этого треугольника на доске для заказчика, который запросил новую функцию, которую он только что придумал, обеспечило одни из самых тяжелых, но удовлетворительных моментов в моей карьере.
Это очень мощный инструмент для менеджеров водопадных проектов, чтобы исключить вмешательство заказчиков в проект. Мы называем это ”защитой содержания», но на самом деле речь идет о том, чтобы ценить подписанный лист бумаги, а не работать в коллаборации с реальными людьми.
То, что я никогда не понимал, пока не начал работать по-новому, — это то, что на самом деле есть четвертая сторона Железного треугольника.
Вот что делает все это ложью. Кто-то когда-нибудь слышал о четырехгранном треугольнике?
Подумайте вот о чем: сколько из нас, работающих над проектами по водопадной модели, застряли с неизменными требованиями, невозможными сроками и негибкими бюджетами одновременно? Когда все это просто не может работать, что вы делаете? Как вы это делаете?
Ответ для меня и многих других, кого я знаю, заключается в том, что вы отказываетесь от качества. Конечно, вы можете и не называть это так. Вы «сокращаете время тестирования» (то есть экономите на Quality Assurance — обеспечении качества). Вы “понижаете серьезность» стольких дефектов, сколько можете (т. е. игнорируете их), и все. Вы также можете сжать свой план развертывания, сократив время на обучение или найдя пользователей быстрее, что является компромиссом качества реализации.
Классический Железный Треугольник говорит, что качество страдает, если любая из трех сторон перемещается независимо от других, но я лично могу поручиться, что плохое качество также является результатом отказа подвинуть любую из трех сторон перед лицом неизбежных изменений проекта.
Качество не «утечет», если вы сломаете треугольник. Качество — это невидимая «четвертая сторона» треугольника, которая часто незаметно «меняется» в попытке удовлетворить остальные три ограничения.
И, конечно же, низкое качество грозит серьезными затратами на техническое обслуживание, снижает удовлетворенность пользователей и, конечно же, ценность, поставляемую клиенту. И, само собой, поскольку стандарты качества падают, а технический долг увеличивается, сроки поставки растягиваются, а затраты растут.
К счастью, Scrum спасает нас от всего этого. Мы можем потихоньку забывать о Железном Треугольнике!
В Scrum качество фиксируется. Это задано в определении «сделано» — вот и все.
В Scrum бюджет фиксирован. Scrum-команда стабильна и кросс-функциональна, содержит все наборы навыков, необходимые для доведения работы до конца.
Время в Scrum не фиксировано. Время до релиза — это неизвестное, небольшое число коротких спринтов фиксированной длины. Мы не притворяемся, что можем видеть будущее вплоть до даты развертывания; мы знаем эмпирически, что не можем.
Теперь можно поспорить, что Scrum все-таки фиксирован по времени. В конце концов, мы знаем, как долго длится каждый спринт, и мы знаем, что каждый спринт будет производить потенциальный прирост готовности продукта. Это правда! Но ключевое слово — ”потенциально». Только потому, что каждое приращение может быть развернуто, не означает, что они все будут развернуты. Количество спринтов, которые отделяют нас от релиза, заранее неизвестно и зависит от множества факторов, некоторые из которых не находятся под контролем команды. Мы делаем эту неопределенность планирования приемлемой для клиента, заставляя каждое приращение доставлять им ценность, даже если эта ценность не полностью наглядна пользователям.
Но самое главное, что не фиксируется в Scrum, — это содержание. Оно может меняться изо дня в день, прямо во время спринта, по мере изменения потребностей бизнеса и рыночных условий. Содержание очень легко изменяется, поскольку мы узнаем больше в процессе разработки или когда мы проверяем продукт с заинтересованными сторонами и клиентом. В Scrum мы не претендуем на то, что можем видеть будущее, даже в конце конкретного спринта! Принятие этой гибкости делает нас лучше в процессе разработки, и, конечно, оставляет нас с лучшим продуктом в конце концов.
Принципиально важно, что если ты хочешь быть гибким, то концепция “как долго это еще будет продолжаться?” должна быть выброшена из твоего мышления. “Как долго” задает непостижимый вопрос о времени. И что вообще означает «законченный», если вы не наткнулись на какие-то идеи на рынке по пути? (Но обратите внимание, насколько нерационально наше мышление при водопаде, что мы думаем, что это единственный самый важный вопрос, который нужно задать? Насколько наш подход основан на предположениях, мифологии, подчинении авторитету и полном отрицании того, что говорит нам наш послужной список?)
Попробуйте представить себе, что «закончено» — это не главное и никогда им не было. Вместо того, чтобы ползти до какой-то постоянно отдаляющейся финишной черты, выпустите что-то незаконченное и крошечное! Посмотрим, что получится! Просто попробуйте с этого момента спланировать небольшой релиз!
Вскоре у вас появится ощущение того, как небольшие версии вашего продукта находятся в тренде, что позволит вам планировать, основываясь на фактическом знании чего-то, а не работать с благими, но обреченными на провал намерениями. И вы обнаружите, что защита, которую призван обеспечить Железный Треугольник, больше не нужна.
Если вы хотите стать Agile, то вы можете зарегистрироваться на наш открытый тренинг Agile Certified Professional в онлайн или очном формате.
Подписывайтесь на наши соцсети, чтобы не пропускать новые статьи:
- Telegram-канал «Проектные сервисы и Product Lab»
- Telegram-канал Андрея Бадина «Управляй иначе»
- YouTube
- VK