Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban (pdf+epub) Коул Роб

Введение

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

В начале XX века сеть ресторанов Дж. Лайонса и сеть розничной торговли Ф. Вулворта процветали и до пятидесятых годов были примером классического британского предпринимательства. Тем не менее обе эти марки неизвестны подрастающему поколению – теперь это просто приятные воспоминания о юности для их бабушек и дедушек: от подъема до спада менее чем за полвека. Эти компании не смогли приспособиться к меняющемуся миру и под конец сделались чем-то вроде динозавров в среде корпораций.

В XXI веке все складывается даже более серьезно. Компьютерная сфера бизнеса должна развиваться со скоростью света. Клиенты, пользователи и спрос на рынке могут измениться за несколько недель. Время – это все; больше не может быть и речи о плане развития на пять лет. «Время до рынка» – вот что важно; компании должны иметь возможность поменять направление разработки быстро, развивая идею от концепции до прибыльного проекта почти в одночасье, чтобы оставаться актуальными и платежеспособными.

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

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

У Tesco 40 тысяч наименований продукции. Они торгуют всем – от автомобильных страховок до картофельных чипсов, а еще закрывают филиалы, увольняют персонал и выписывают штрафы работникам гораздо чаще, чем раздают бонусы. Aldi, новая компания на рынке Великобритании, работает только с двумя тысячами наименований продукции, но Aldi нанимает новых сотрудников, открывает магазины и получает прибыль. Вопрос в том, слишком ли велика Tesco, чтобы успеть адаптироваться до того, как Aldi захватит рынок?

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

Тьма перед рассветом

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

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

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

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

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

Основы Agile

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

• взаимодействием людей друг с другом и творческими подходами к решению проблем;

• участием бизнес-представителей и заказчика во всем процессе работы над проектом, начиная от концепции и заканчивая получением прибыли;

• сокращением «времени до рынка» для получения или сохранения конкурентоспособности;

• ранним получением работающего продукта и, как следствие, быстрой обратной связью;

• поэтапным добавлением улучшений с целью сохранить актуальность продукта;

• атмосферой гибкости и способности к изменениям;

• возможностью вносить значительные изменения, чтобы «оставаться в игре»;

• требованиями заказчика и конечного пользователя как основой для принятия решений;

• выпуском продукта, который является самым главным!

Мерой интеллекта является способность меняться.

Альберт Эйнштейн

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

Важнейшей частью философии Agile является ранний и частый выпуск продукта; разработка окончательного продукта от основной идеи путем постоянного добавления улучшений. Первый выпуск продукта отвечает требованиям бережливого управления и экономически эффективен. Главные идеи проекта испытываются уже на ранней стадии, при этом всегда есть место для более тонкой настройки продукта или полного изменения направления разработки. Это позволяет компании:

• начинать с самых важных требований и не более того;

• урезать стартовый бюджет до минимума;

• предполагать прибыли;

• расширять возможности команды;

• быстро приступать к разработке;

• изменять направление разработки, как только возникнет такая необходимость.

Лакмусовая бумажка для Agile-проекта – удалось ли воплотить концепт в реальность.

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

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

Может возникнуть ощущение, что Agile-проекты выглядят как жизнь на Диком Западе – почти никакого управления, никакой документации, слабо разграниченные роли и обязанности. Но на самом деле все обстоит не так. Все организовано более легковесно, чтобы не перегружать рабочий процесс.

Блистательное определение

Есть тонкая грань между фреймворком и процессом. В данном контексте фреймворк – это серия гибких ориентиров, а процесс проекта – более жесткая и негибкая схема. Фреймворк позволяет, процесс – ограничивает.

Анализ по-другому

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

Механизм поставки – вторичный вопрос для Agile-проекта. Используемые инструменты и методы важны, однако методики очень гибкие и могут быть изменены в соответствии с проектом и организацией. Нет двух абсолютно одинаковых реализаций Agile, но они будут очень похожими. Нет никакой «полиции Agile», зато есть множество рекомендаций, и соблюдение сути подходов важнее, чем любые правила. В основной философии Agile упоминаются важные для соблюдения моменты, но сейчас их уже полагают менее критичными к исполнению, чем ранее.

Для любого, кто привык к кажущейся защите тяжелых процессов, связанных с обычными проектами, такой подход может оказаться непривычным. Но Agile-проекты саморегулируются куда более прозрачным и эффективным способом. Agile берет проект малого размера и быстро выпускает рабочий продукт, получая на него обратную связь. Заказчика и конечного пользователя рабочий продукт интересует куда больше, чем документация, потому что именно продукт они могут видеть и использовать. Идеальный сценарий – раннее обнаружение хорошего, плохого и ужасного: глюки в коде программы намного проще найти и исправить на ранних этапах разработки, чтобы впоследствии они не привели к катастрофе.

Agile-вариант позволяет меньше волноваться о соблюдении правильности процесса и сосредоточиться на конечном продукте.

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

В большом правительственном агентстве случался переполох каждый раз, когда наступало время годового аудита по PRINCE2. Проектный офис лихорадочно старался найти любой проект, соответствующий критериям PRINCE2; при обычных обстоятельствах этих проектов было не слишком много. Успешное прохождение такого аудита считалось нормальной заслугой, но проблема заключалась в том, что для «полиции проектных нравов» основным условием было максимально точное следование принципам PRINCE2.

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

Начало реализации проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лучшие результаты. Никто не любит терпеть неудачи – и, само собой, быть частью успешной команды уже замечательно. Привыкайте побеждать — успех порождает успех.

Блистательный эффект

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

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

Испытание для руководителя проекта

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

Конечно, многие руководители проекта легко справляются с переходом – в основном потому, что, по сути, они уже сторонники Agile. Идея того, что управленец должен сосредоточиться на том, чтобы команда показала себя с лучшей стороны, а не «выкрикивать приказы», далеко не нова. Очень многие руководители не считают себя лучше других и рассматривают свою роль скорее как вспомогательную и фасилитирующую; таким в команде будут только рады. Руководствуйтесь здравым смыслом — одной из основополагающих черт Agile.

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

Не переходите на Agile, если:

• Вы получаете удовольствие, говоря людям, что им нужно делать.

• Вы привыкли присваивать заслуги команды себе.

• Вы первым делом начинаете искать козла отпущения, если что-то идет не так.

• Коллеги, которые рады своей работе, вызывают у вас подозрение.

• Вы полагаете, что гибкость – для слабаков.

Не панацея

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

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

Блистательная мысль

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

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

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

• крайне сжатые сроки;

• высокая сложность;

• явная неопределенность;

• множество неизвестных;

• скорее уникальный, чем повторяющийся;

• новые запросы по новым функциям.

На макроуровне организации будет тяжело принять Agile; если негибкое мышление усугубляется еще и культурными особенностями – это может стать окончательным приговором. К счастью, такое случается довольно редко; на практике куда чаще руководителям не нравится то, что предлагают гибкие подходы. Не каждый посчитает их удобными; так что, если «Самый Главный Начальник» против, переход к Agile будет сопровождаться напряженной борьбой.

Классические примеры, где не подойдет Agile:

• Неподходящая организация: не ожидайте, что военно-морской флот перейдет на Agile.

• Неверный проект: строительство авианосца точно не подходит.

• Неправильный подбор работников: диктаторы и одиночки не смогут адаптироваться.

Завершающие слова

Сможете привести пример бизнеса, компании или услуги, которых больше не существует или не имеющих той доли рынка, которая была у них раньше? Недавний экономический спад дал нам много таких примеров: HMV, Blockbuster, Woolworths, Myspace, Nokia, Blackberry и прочие. Почему казавшийся непотопляемым бизнес внезапно теряет свои позиции? Что происходит с мировым брендом, если его продают по скидочной цене?

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

Agile помогает двигаться к цели быстро и с наименьшими затратами. Это не волшебная палочка, но если вы стоите на распутье, как Tesco, то вам пригодится любая помощь. В сути своей, гибкие подходы – это общий термин для набора инструментов и техник, которые позволяют вам добиться гибкости: способности реагировать на изменения и адаптироваться. Однако не забывайте, что, несмотря на все эти отличия, Agile не совершенен. Всегда будут ситуации, в которых что-то пойдет не так, как должно. Жизнь – это череда поражений и побед. Лучше выиграть войну, чем пытаться выиграть каждую битву.

Блистательный итог

• Изменения – часть жизни; не будьте динозавром.

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

• Нет такого средства, которое помогает от всего. Agile подходит не всем… и особенно не всем руководителям проектов.

• Гибкость – это способность реагировать на изменения и адаптироваться.

• Может, Agile и не нов, но он очень отличается!

Введение

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

Определение видения

Недальновидные люди обречены на гибель. Моисей сказал это четыре тысячи лет назад, но большинство руководителей проектов до сих пор не понимают, что он имел в виду. Если мы не знаем, куда идем, то мы вряд ли доберемся куда-либо – и это особенно верно, когда речь идет о проектах. Люди часто имеют различные представления о том, чего и как они хотят добиться, и в итоге получают различные результаты. Четкое определение видения необходимо для успешного проекта. К сожалению, большинство проектов дают определение видению с помощью расплывчатых заявлений миссии, которые при более пристальном рассмотрении нередко оказываются бессмысленными:

• Мы предлагаем исключительное качество.

• Интересы наших покупателей для нас на первом месте.

• Мы будем лучшими в нашей сфере, и нас все будут любить.

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

Удача – это пересечение пространства возможностей и готовности ими воспользоваться.

Дензел Вашингтон

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

В качестве примера использования видения давайте представим, что мы – компания, которая собирается продавать овощи в рестораны. Видение поможет нам понять, что конкретно это значит.

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

Видение объясняет, что именно мы собираемся сделать. Оно должно учитывать особенности целевой группы, платформы и продукта, как, впрочем, и сроки. Однако самое главное, чтобы видение могло объяснить значимость проекта для компании и потребителя.

Определение видения проекта

• Как называется проект или продукт, который вы производите?

• Для кого он предназначен?

• Когда он должен быть закончен?

• Что он делает?

• Чего он не делает?

• Какая выгода для вашего бизнеса от использования этого продукта?

• Какую выгоду получит клиент от использования этого продукта?

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

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

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

Руководствуясь идеей бизнес-ценности

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

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

Блистательное определение

Люди упоминают получение отдачи от проекта так часто, что это уже стало бессмысленным. Что значит эта «отдача»? Рассуждайте в понятиях выгоды. Какую выгоду проект принесет заказчику или бизнесу? Успешный проект выгоден для всех.

Agile не определяет четко, что такое бизнес-ценность или «красота в глазах зрителя». Гибкие подходы служат основой того, чтобы деньги, заработанные с определенным трудом, были инвестированы с пользой. Agile облегчает и обеспечивает принятие разумных решений, но ничего более. Можно привести лошадь на водопой, но нельзя заставить ее пить.

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

Кроме того, определив в точности, что необходимо, заказчик определяет это как необходимый минимум – и с этого начинает добавлять другие кирпичики. Первый выпуск продукта может не иметь всех «свистулек», но он должен быть работающим, реализовывать товар или услугу и быть выпущен как можно быстрее. Инвестируем в X, затем в Y – получаем последовательный выпуск продукта; это правило должно соблюдаться в течение всех этапов разработки и быть совершенно прозрачным.

Блистательная мысль

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

Формирование команды проекта

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

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

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

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

Создание журнала требований

Когда определены видение и то, какую выгоду проект должен приносить, следующий шаг для команды проекта – записать требования в возможных деталях. В центре каждого проекта – список требований, который в Agile называется журналом требований продукта, или бэклогом (Product Backlog). Он заменяет традиционное, подробное техническое задание и представляет собой список важных для бизнеса идей. Элементы журнала всегда ориентированы на конечного пользователя продукта, даже если речь идет о технической части проекта. Они должны быть понятны любому.

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

Как сделать так, чтобы с самого начала все пошло наперекосяк

• Заявлять, что Agile – универсальное средство, даже для не предназначенных для него областей.

• Говорить, что тут все очевидно и любой дурак сможет справиться, так что никакого обучения не нужно.

• Считать, что Agile непогрешим, а неудачи происходят из-за личных недостатков.

• Устанавливать нереалистичные цели и сроки, оправдывая это тем, что в дивном новом мире Agile все возможно.

Определите базовую функциональность

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

Создайте функциональные группы

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

Приоритетность характеристик

Опираясь на видение проекта и здравый смысл, определите приоритет каждого элемента в нисходящем порядке – от самого важной в каждом списке.

Определение первого выпуска

Как только вышесказанное будет сделано, обдумайте каждый важный шаг в движении к заказчику от первого дня до реализации и что является самой ценной частью идеи в рамках этих шагов. Такой выбор может быть сложным и в конце концов зависеть от мнения, но мнение заказчика – или того, кто представляет собой его бизнес, – имеет решающую роль. Конечный результат шагов – тот приемлемый минимум для заказчика, которого проект должен достичь в этом шаге. Это обычно называется минимально жизнеспособным продуктом (minimum viable product, MVP) или минимально жизнеспособным выпуском (minimum viable release, MVR).

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

Стоить помнить, что чем больше всего будет в минимально жизнеспособном продукте, тем больше времени потребуется для получения обратной связи, тогда как если продукт будет слишком мал, будет недостаточно информации для получения обратной связи. Вам придется найти баланс между прибылью и риском – никакого универсального правила тут нет. Постарайтесь найти точку, в которой вы получите полезные отзывы о чем-то, что поможет вам принимать обоснованные решения. Это будет полезно и для анализа рынка.

Также обращайте внимание на термины. Для кого-то слово «выпуск» будет означать доступный для использования продукт, для других – продукт, предназначенный для тестирования закрытой группой. Помните, что всегда существует возможность сначала представить продукт малой группе, а уже потом выпустить продукт соответствующим образом. Главное, не делайте допущений, что все понимают термины одинаково! Нет абсолютно правильных подходов – выберите тот, что лучше подходит вам.

Добавление характеристик

Как только определено, что будет в минимально жизнеспособном продукте (MVP) или минимально жизнеспособном выпуске (MVR), начинается настоящее веселье. Дополнительный функционал или новые характеристики продукта могут добавляться по частям или быть частью большого релиза. Это называется инкрементная поставка, и бизнесмены ее очень любят. Никаких больше долгих лет ожидания одного большого выпуска со всеми «свистульками». Выпуск продукта в Agile-разработке происходит быстро и часто. И, опять же, именно заказчик определяет, что и когда выпускать. Как минимум отдельный выпуск должен содержать одну характеристику, проверенную практикой.

Получение информации

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

Расскажи мне историю

Пользовательские истории (user story) – короткие простые описания характеристик продукта с точки зрения человека, который собирается его использовать. Обычно это пользователь или покупатель. Пользовательские истории обычно следуют простому формату.

Будучи <тип пользователя>, мне нужно <цель> по <причина>.

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

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

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