Сейчас речь пойдёт о книге Роба Коула “Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban”. Эта книга не просто объясняет, что такое гибкое управление проектами, но и даёт ответы на вопросы, актуальные для любого руководителя проектов:
- Нужно ли это вашему проекту?
- Будет ли от этого выгода?
- Какие навыки необходимы сегодня для успеха?
Это книга о том, как не следует запускать предприятие и как гибкое управление может стать вашим мощным инструментом в достижении целей.
Моё краткое содержание, этой книги призвано дать вам представление о ключевых идеях и концепциях, которые делают “Блистательный Agile” необходимым чтением для тех, кто хочет идти в ногу со временем и использовать современные подходы в управлении проектами.
Слава был обычным руководителем, в известной немецкой компании, которая плавно так росла по 10% в год с 1945 года. Получал оклад, ежемесячную премию и иногда летал в отпуск. Даже корпоративную машину имел.
Но всегда хотелось чего-то большего. И как-то задумали они с другом Витей приложение сделать, с помощью которого можно продукты из магазина домой заказывать. Нашли еще единомышленников. Вскладчину собрали под миллион рублей (спасибо семье, друзьям и дуракам), арендовали коворкинг в самом технологичном технопарке Санкт-Петербурга и начали создавать великолепный продукт.
С работы, естественно, всем пришлось уволиться. Задача оказалась уж очень серьезной: нужно и интерфейс программы создать, и работу с сервером настроить, и с магазинами договориться . Первый месяц думали над названием компании, регистрировали юридическое лицо, доли в будущем много миллионном бизнесе делили, разрабатывали логотипы, фирменный стиль, визитки. Работы было много. Дальше нужно было придумать очень красивый, сочный интерфейс. Так под смузи, латтешечки и прочее прошел еще месяц.
После начали делать программную часть и разбираться, какой лучше сервер использовать. Оказалось, что дизайн нужно переделывать. Вдруг кто-то вспомнил, что неплохо было бы с магазинами пообщаться. Пошли крутые условия выторговывать. В процессе еще раз 5 раз переделали дизайн и изменили программную часть. В итоге пролетел год, деньги почти закончились.
- Продукт с горем пополам, но создали.
- Создали — но он почему-то не продается.
- Наверное потому, что за это время Яндекс и Google свои продукты на рынок выкатили, раз эдак в 10 лучше и удобнее.
Ребята быстро разбежались, Слава с Витей остались одни и с нулем в кармане. Что же делать? Начали думать, как бы найти инвестора под этот проект, чтобы деньги на поиски и развитие получить.
Долго везде стучались и искали, но вдруг нашли одного начинающего ангела… бизнес-ангела, Максима. Поверил он в ребят и денег даже готов был выделить, только при одном условии: если обучатся они технологиям заморским.
Нашли ребята платформу, где классные специалисты обучают продвинутым технологиям инновационным. Оказалось, мир меняется так стремительно, что не только продукты быстро устаревают, но и профессии исчезают. А на их смену приходят совершенно новые. Максим указ им дал: «Ребята, помните, ценность профессионала будет определяться лишь навыками, которыми он владеет».
Слава и Витя взялись за ум, откопали курс по гибкой разработке. «Идеально» — подумали парни. Как раз быстро научимся управлять проектами и внедрять гибкие методологии на практике.
Так Слава и Витя узнали, что разочарование от незавершенных проектов не ново для этого мира.
Еще в 2001 году в штатах собрались 17 профессионалов своего дела на горнолыжном курорте. Поесть, попить, отдохнуть и обсудить насущные проблемы постоянных факапов проектов. В итоге выработали они правила создания продуктов, которые будут востребованы теми, для кого их создают. Именно там и был опубликован «Манифест о гибкой разработке Agile» или «Манифест Agile».
Пришли они там к выводам, что всё-таки важнее люди и взаимодействие между ними, чем инструменты и процессы. Важнее взаимодействие с клиентом, чем согласование условий договора. Важнее быть готовым к изменениям, чем следовать первоначальному плану. И всегда важнее работающий продукт, чем исчерпывающая документация на него.
Славе и Вите тема гибкого управления проектами показалась интересной. Зашибись же, когда за тебя уже всё придумали, тебе только внедрять осталось. Только, само собой, это надо осваивать на практике.
Из философии Agile ребята поняли, что продукт нужно выпускать как можно раньше, чтобы проверить основные идеи задумки. А конечный продукт уже создавать посредством частых и постоянных улучшений.
Так они начали с базовых требований, сократили начальные затраты, а после выпуска ранней версии продукта уже предполагали прибыль. При этом у них оставалась возможность полностью изменить направление в разработке продукта.
Слава и Витя выработали концепцию проекта и пошли обсуждать её с бизнес-ангелом Максимом.
—Так, ребята, как в итоге называется ваш продукт, который вы создаёте?
—Мы назвали наш сервис — «Всё уже дома»
—Для кого вы его разрабатываете?
—Наша целевая аудитория – мужчины и женщины в возрасте 22–34 года, проживающие отдельно и желающие просто и экономно пополнять свои запасы продуктов и получать мелкие товары в свой дом.
—Когда планируете завершить продукт?
—В течение месяца выпустим первую версию.
—Что осуществляет ваш продукт?
—Наше приложение сопоставляет цены во всех магазинах поблизости от вашего дома и находит наиболее оптимальные варианты по цене и условиям доставки.
—Чего он не делает?
—Мы не осуществляем продажу самих товаров.
—Какую выгоду получает ваш бизнес от этого продукта?
—Мы получаем доход от партнерских программ с местными магазинами и от специального размещения рекламы.
—Какую выгоду получает пользователь?
—Пользователю не нужно ходить по магазинам, сравнивать цены и вообще что-либо делать. Быстрое, простое и наиболее выгодное решение.
Максим внимательно выслушал и сказал: «Хорошо, но помните, что самый главный показатель вашего проекта — удалось ли воплотить концепцию в реальность».
Слава с Витей воодушевились, кажется они усвоили знания. Видение проекта есть, теперь нужно проанализировать, как и кем его будет реализовывать.
В первую очередь необходимо было определить владельца продукта (Product Owner). Человек, который будет жить этим продуктом и во время реализации отстаивать интересы бизнеса и конечного пользователя. Таким лидером и визионером стал Слава.
Витя вступил в Agile-команду. Это уже совокупность разнообразных специалистов, которая будет воплощать видение в жизнь. Они не боятся изменений и проявляют инициативу. К команде присоединились еще несколько опытных знакомых из разных областей.
Вместо технического задания команда начала разрабатывать журнал требований продукта или бэклог (Product Backlog). Это список идей, ориентированных на конечного пользователя. Более того, эти идеи должны быть понятны каждому.
Далее команда составила список необходимого для реализации сервиса. Для этого необходимо было представить себя пользователем приложения:
Так, в начале я хотел бы быстро найти те продукты, которые дома использую. Затем оперативно выбрать оптимальный вариант и заказать в этом магазине. И если мне все понравилось — поделиться этим с друзьями.
Поиск продуктов —> Анализ разных вариантов / магазинов —> Заказ в понравившемся магазине —> Поделиться в соцсетях
Так команда определила базовый функционал приложения. Далее обсуждали, какой функционал добавить для каждого шага.
Например, первый этап, Поиск продуктов. Как можно максимально упростить поиск наименований продуктов:
Я бы хотел открыть холодильник, сделать снимок на телефон продуктов, а приложение распознало бы их и добавило в корзину в приложении. Может быть, мне бы даже подошел ручной поиск по бренду, названию или артикулу продукта.
- снимать фотографии продуктов из холодильника прямо в приложение;
- фотографировать чек со списком продуктов;
- поиск по наименованию / бренду;
- поиск по артикулу.
И так по каждому этапу.
Витя взглянул на этот список характеристик:
— Слав, ты же помнишь, как на курсе было сказано? Нам важно найти баланс: если в продукте будет очень много функционала, мы потратим очень много времени на его разработку. А если продукт будет слишком маленький — то наши пользователи его не поймут. Мы должны найти равновесие.
— Да-да, полностью согласен с тобой. Тянуть с выпуском продукта точно не хочу. Как раз Слава недавно смотрел Гая Кавасаки, он на выступлении сказал: «Если вам не стыдно за свой первый продукт, то вы выпустили его слишком поздно».
Поэтому я расставил приоритеты в характеристике: что является лишь приятным дополнением — убрал в самый низ, а наиболее важное — наверх.
Так ребята выбрали достаточный минимум, чтобы показать продукт конечному пользователю. Это называется — минимально жизнеспособный продукт (MVP).
После того, как Слава с командой определили, что будет в начальном продукте, остальные характеристики разбили на части. Их они уже будут реализовывать после выпуска первой рабочей версии.
— Вить, смотри, мы на данном этапе сформировали лишь видение MVP, но самого продукта-то у нас еще нет. Во время разработки нам всё-таки лучше понимать характеристики будущего продукта, чтобы лучше детали прорабатывать.
— Слав, нужно написать пользовательские истории. Это краткое описание использования характеристик продукта с точки зрения конечного пользователя.
Это можно делать простым способом в 4 этапа.
Давай придумаем название истории, по которой легко её будет найти.
Ок, пусть название первой истории будет: «Устал закупаться в магазине».
—Кто будет пользоваться продуктом?
—Ну, например, Мужчина лет 30.
—Что именно мне нужно?
—Хочу пополнять продукцию в холодильнике.
—Зачем пользователю наш продукт?
—Не хочу тратить время на поход в магазин, при этом хочу выбирать наиболее выгодные предложения.
— Вить, мы описали видение MVP и пользовательские истории. Но ты понимаешь, что этого недостаточно. Давай сразу определим, что первая версия нашего продукта готова?
— Да-да, по Agile, мы с командой выписали односложные оценки, которые всем понятны:
—В сервисе я должен найти те продукты, которые мне нужны.
—Я должен знать о их наличии или о дате их поступления.
—Необходимый товар легко добавляется в корзину.
—Мне ясна дата и способ доставки.
Ну и так далее.
— Супер. Вить, сколько времени вам нужно на создание приложения?
— Я вот как раз думал, как лучше посчитать. Я вижу два варианта:
каждому этапу присвоить размер, как у одежды: S, M, L, XL и примерно заложить на них время;
или сгруппировать по объему задач и пронумеровать. Затем можем выполнить самую маленькую часть и понять сколько это занимает времени. После этого можно предположить, сколько времени занимают остальные задачи.
Огонь, мне нравится второй вариант: выполним самую простую задачу за пару дней и рассчитаем.
Так ребята поняли, что до выпуска MVP им нужно еще 2 недели.
Всё, Слава с командой готовы. Они сформировали конкретное и рациональное видение и ценность своего продукта как для бизнеса, так и для пользователя, который будет его использовать. Чтобы лучше понимать последнего, создали журнал требований продукта, где написали достаточно количество пользовательских историй, которые понятны всем. Всё-таки определились с MVP и выработали критерии принятия их продукта.
Продукт по методологии Agile создан. Как думаете, ребят ждёт успех?