Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban

Время до рынка (time-to-market) имеет решающее значение, но сама разработка продукта занимает только часть времени от момента высказывания идеи до ее успешной реализации. Часто бывает, что само начало разработки сопряжено с определенными усилиями, и этот период простоя сам по себе проблема и является частью процесса под названием технико-экономическое обоснование (feasibility study).

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

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

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

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

Блистательный пример

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

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

Приветствуя перемены

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

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

Некоторые трактуют эту способность изменяться так, что Agile-проекты сталкиваются с тем, что изменения приходится вносить в последнюю минуту. Но, безусловно, такая проблема может случиться в любом проекте, даже в Agile-проекте, если гибкая методология в нем применена плохо. Но уже давно в бережливом управлении, Lean, принята концепция принятия решения точно в срок (just in time). Без сомнений, принятое решение будет лучше, если основано на фактах, а не на догадках, а чтобы уточнить детали, может понадобиться время. Agile приветствует решения, принятые поздно, но это должна быть такая задача, неразрешение которой вовремя может создать еще больше проблем. Более традиционные методы управления с этим не справляются.

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

Жизнь становится легче