Страница 3 из 4
Рис. 1.1. Треугольник управления проектами
Так как треугольник представляет собой жесткую структуру, невозможно изменить одну из сторон, не влияя на остальные. Если меняется любой из параметров – сроки, затраты или содержание, это обязательно повлечет за собой последствия для разработки проекта. Зачастую это происходит, когда необходимо добавить новые требования в задачу проекта – тогда резко замедляется скорость разработки или урезается бюджет. Само собой, иначе и быть не может! Уже много лет команды, работающие над проектами, пытаются сохранять эти три переменные в равновесии, но миссия явно невыполнима.
С самого начала работы над любым проектом заказчик пристально следит за тем, чтобы не было потрачено слишком много средств или времени. Руководители проекта, таким образом, находятся сразу под двойным прицелом. Стоит, наконец, выпустить окончательный продукт, фокус сразу смещается со «сколько» и «как долго» на «а достаточно ли это хорошо?». Конечно, если заказчик получил, что хотел, задержка с выпуском продукта и дополнительные затраты сразу забываются, но пробираться через эту полосу препятствий действительно тяжело.
В мире Agile все обстоит совершенно по-другому. С самого начала фокус направлен на создание качественного продукта. Agile отодвигает в сторону традиционное беспокойство о бюджете или сроках и сосредоточивается в первую очередь на том, что заказчик хочет или, что куда важнее, что ему действительно необходимо. Превращая простые идеи в сложные, но элегантные решения, можно перестать беспокоиться о достижении совершенства. Больше никаких дополнительных трат и никаких недовольных заказчиков.
Блистательная мысль
Заказчикам не нужно лучшее управление проектом, заказчику нужен лучший продукт. Все инструменты и техники направлены именно на это. Используйте любые техники для достижения лучшего результата, главное – не сосредоточивайтесь на самих техниках. Цель куда важнее, чем средства, которыми вы ее достигнете.
Заказчик должен быть доволен
Проекты не начинают с идеи перевыполнить содержание. Вызов стар как мир – сделать тот необходимый минимум, чтобы закончить работу, и не более того. Для разработки точного и скрупулезного содержания проекта вопрос «что именно вы хотите?» подходит как нельзя лучше, но в стремлении осветить все детали вы можете оказаться в ситуации, когда вы все равно спрашиваете у заказчика: «Что-нибудь еще?» Это напоминает ребенка в магазине игрушек, которому разрешили брать все, что захочется.
Но совсем плохи дела становятся тогда, когда заказчик мыслит в категориях «сейчас или никогда». Это приводит его к идее, что единственный способ получить несколько приятных и полезных колокольчиков и свистулек к продукту – потребовать их сразу и ни в коем случае не уступать. В итоге мы имеем множество несущественных требований вкупе с чрезмерно завышенным бюджетом и чересчур длинными сроками.
И наоборот, первый релиз проекта, созданного с помощью Agile, представляет собой костяк основной идеи, только основные и необходимые функции. При этом предполагается, что все остальные штрихи будут добавляться со временем и по порядку, чтобы на выходе получить полноценно функционирующий продукт.
С Agile вам не придется все спешно подготавливать к январской распродаже. Вместо этого мы начнем с прочного фундамента.
Нет, спасибо, без изменений
Прежде подразумевалось, что после того, как все точки над i расставлены и все утверждено, изменения не приветствуются – ну или, по крайней мере, тщательно контролируются. Многие популярные подходы к управлению проектами, такие как PRINCE2 (PRojects IN Controlled Environments – проекты в контролируемых средах), фокусируются в рамках четко определенных требований и строго регламентируют контроль изменений. Изменение не одобряется и считается плохой новостью для бизнеса.
Тем не менее попытки работать по этой схеме не всегда успешны, потому что желание что-то поменять наверняка будет возникать в любом проекте. Само собой, если изменений немного, традиционные структурированные методы управления тоже работают достаточно плодотворно, но и тогда не обходится без споров. К сожалению, в итоге всегда есть риск получить заказчика, не до конца довольного продуктом.
К тому же далеко не в каждом проекте процесс разработки представляет собой прямую от точки A до точки В, где все требования совершенно четкие, а любые вносимые изменения – не больше чем слабое отклонение от заданного курса. В большинстве случаев любая идея, как неоперившийся птенчик, нуждается в проверке в реальных ситуациях и наверняка будет требовать различных дополнительных надстроек. Иногда приходится менять курс или вообще возвращаться к началу разработки. Это естественный ход развития для бизнес-проектов, и попытки двигаться против течения здесь точно не приведут ни к чему хорошему.
Agile совсем другой. Agile приветствует изменения и даже вдохновляет на них. Тут любые перемены – не ваш враг, а неотъемлемая часть развития хорошей идеи. Проекты, выполненные с помощью гибких подходов, могут быть представлены на рынке в короткие сроки, а значит, на тестирование будет больше времени. Эволюция – это совершенно естественно, а изменения – не такая уж и проблема. Это именно то, чего хотят ваши заказчики, и ничего удивительного, что для них это как глоток свежего воздуха.
Начните с малого, недорогого и быстрого
Тезисы Agile-манифеста, принципы и прочие элементы гибкой философии звучат отлично, но как именно применять их на практике? Чем конкретно отличается Agile? Основное – это то, что с самого начала разработки продукта подход совершенно другой. Вместо того чтобы составить список требований и ограничивать внесение любых изменений, Agile начинает с определения необходимого минимума и работает уже с ним. Этот минимум так и называется – минимально жизнеспособный продукт (minimum viable product, MVP), или минимальный набор функциональности (minimum feature set, MFS).
На практике оба этих определения обозначают одно и то же. Минимально жизнеспособный продукт уже отвечает основным требованиям бизнес-проекта и может быть успешно продан. Такой подход уменьшает затраты и время, необходимые на разработку. Минимально жизнеспособный продукт также может стать основанием для более сложного и функционального бизнес-решения. Чем меньше – тем лучше.
Блистательный пример
К первому рабочему дню на новом месте после окончания школы, колледжа или университета, несомненно, нужно подготовиться заранее. Особенно если место работы – фирма со строгими правилами и дресс-кодом.
Если рассматривать подготовку как проект с традиционным методом подхода, получится список вещей, которые необходимо купить, и это явно обойдется недешево:
• 3 костюма (чтобы их можно было менять);
• 10 рубашек (чтобы не стирать их каждую неделю);
• 5 галстуков (на выбор);
• 2 пары обуви (одна черная, другая коричневая);
• 1 пальто (зима всего-то через полгода);
• 10 комплектов нижнего белья;
• автомобиль, чтобы добраться до станции в восьми километрах от дома;
• велосипед в случае, если автомобиль сломается (и, конечно же, дождевик к нему).
Приобретение всего этого займет несколько уик-эндов – покупка костюма быстрой не будет. Таким образом, понадобится три-четыре похода по магазинам; к тому же стоит выбирать вещи, которые можно будет вернуть. Бюджет можно заложить около десяти тысяч фунтов.