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

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

Слава был обычным линейным менеджером, зато в известной немецкой компании, которая плавно так росла по 10% в год аж с 1945-го года. Получал оклад, ежемесячную премию и иногда летал в отпуск. Даже корпоративную машину имел.

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

С работы, естественно, всем пришлось уволиться. Задача оказалась уж очень серьёзной : нужно и интерфейс программы создать, и работу с сервером настроить, и с магазинами договориться . Первый месяц думали над названием компании, регистрировали юр. лицо, доли в будущем много ярдном бизнесе делили, разрабатывали логотипы, фирменный стиль, визитки. Работы было много. Дальше нужно было придумать очень красивый, сочный интерфейс. Так под смузи, латтешечки и прочее прошел еще месяц.

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

Продукт с горем пополам, но создали.
Создали — но он почему-то не продается.
Наверное потому, что за это время мяундекс и гоголь свои продукты на рынок выкатили, раз эдак в 10 лучше и удобнее.

Ребята быстро разбежались, Слава с Витей остались одни и с нулем в кармане. Что же делать? Начали думать, как бы найти инвестора под этот проект, чтобы деньги на поиски и развитие получить.

Долго везде стучались и искали, но вдруг нашли одного начинающего ангела… бизнес-ангела, Максима. Поверил он в ребят и денег даже готов был выделить, только при одном условии: если обучатся они технологиям заморским.

Нашли ребята платформу, где классные специалисты обучают продвинутым технологиям инновационным. Оказалось, мир меняется так стремительно, что не только продукты быстро устаревают, но и профессии исчезают. А на их смену приходят совершенно новые. Максим указ им дал: «Ребята, помните, ценность профессионала будет определяться лишь навыками, которыми он владеет».

Слава и Витя взялись за ум, откопали курс по гибкой разработке. «Идеально» — подумали парни. Как раз быстро научимся управлять проектами и внедрять гибкие методологии на практике.

Так Слава и Витя узнали, что разочарование от незавершенных проектов не ново для этого мира.

Еще в 2001 году в штатах собрались 17 профессионалов своего дела на горнолыжном курорте. Поесть, попить, отдохнуть и обсудить насущные проблемы постоянных факапов проектов. В итоге выработали они правила создания продуктов, которые будут востребованы теми, для кого их создают. Именно там и был опубликован «Манифест о гибкой разработке Agile» или «Манифест Agile».

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

Славе и Вите тема гибкого управления проектами показалась интересной. Зашибись же, когда за тебя уже всё придумали, тебе только внедрять осталось. Только, само собой, это надо осваивать на практике.

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

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

Слава и Витя сформировали видение проекта и пошли с бизнес-ангелом Максимом общаться.

• Итак, ребята, как в итоге называется ваш продукт, который вы производите?
• Мы назвали наш сервис — «Всё уже дома»

• Для кого вы его делаете?
• Наша аудитория мужчины и женщины 22-34 лет, кто живет отдельно и хочет просто и выгодно пополнять холодильник продуктами и получать мелкие расходники в свой дом.

• Когда хотите закончить продукт?
• В течение месяца выпустим первую версию.

• Что делает ваш продукт?
• Наше приложение сравнивает цены во всех магазинах вокруг вашего дома и находит самое оптимальное по ценам и доставке.

• Чего он не делает?
• Мы не продаём сами продукты.

• Какую выгоду получает ваш бизнес от этого продукта?
• Мы зарабатываем от партнерских программ с местными магазинами и от спецразмещения.

• Какую выгоду получает пользователь?
• Пользователю не надо ходить по магазинам, сравнивать цены и вообще что-либо делать. Быстро, простое и наиболее выгодное решение.

Максим внимательно выслушал и сказал: «Хорошо, но помните, что самый главный показатель вашего проекта — удалось ли воплотить концепт в реальность».

Слава с Витей воодушевились, вроде усвоили они знания. Видение проекта есть, теперь нужно понять, как и кто его будет выполнять.

В первую очередь нужно было назначить владельца продукта (Product Owner). Человека, который будет жить этим продуктом, а во время реализации отстаивать интересы бизнеса и конечного пользователя. Таким лидером и визионером стал Слава.

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

Вместо технического задания команда начала разрабатывать журнал требований продукта или бэклог (Product Backlog). Это список идей, ориентированных на конечного пользователя. Более того, эти идеи должны быть понятно каждому.

Дальше команда составила список необходимого для реализации сервиса. Для этого нужно было представить себя пользователем приложения:

Так, вначале я бы хотел быстро и просто найти те продукты, которые дома использую. Затем быстро выбрать самый лучший вариант и заказать в этом магазине. И если мне все понравилось — рассказать об этом друзьям.

Поиск продуктов —> Анализ разных вариантов / магазинов —> Заказ в понравившемся магазине —> Поделиться в соцсетях

Так команда определила базовую функциональность приложения. Дальше размышляли над тем, какой функционал добавить для каждого шага.

Например, первый шаг, Поиск продуктов. Как можно максимально упростить поиск продуктовой корзины:

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

• фотографировать продукты из холодильника прямо в приложение;
• фотографировать чек со списком продуктов;
• поиск по названию / бренду;
• поиск по артикулу.

И так по каждому шагу.

Витя посмотрел на этот список характеристик:
— Слав, ты же помнишь, как в курсе было сказано?
Нам важно найти баланс: если в продукте будет очень много функционала, мы очень много времени потратим на его разработку. А если продукт будет слишком мал — то наши пользователи его не поймут. Мы должны найти баланс.

— Да-да, полностью согласен с тобой. Тянуть с выпуском продукта точно не хочу. Как раз Слава недавно смотрел Гая Кавасаки, он на выступлении сказал: «Если вам не стыдно за свой первый продукт, то вы выпустили его слишком поздно».
Поэтому я расставил приоритеты в характеристике: что является лишь приятным дополнением — убрал в самый самый низ, а наиболее важное — наверх.

Так ребята выбрали достаточный минимум, чтобы показать продукт конечному пользователю. Это называется — минимально жизнеспособный продукт (minimum viable product, MVP).

После того, как Слава с командой определили, что будет в начальном продукте, остальные характеристики разбили на части. Их они уже будут реализовывать после выпуска первой рабочей версии.

— Вить, смотри, мы на данном этапе сформировали лишь видение MVP, но самого продукта-то у нас еще нет. Во время разработки нам всё-таки лучше понимать характеристики будущего продукта, чтобы лучше детали прорабатывать.
— Слав, нужно написать пользовательские истории. Это короткое описание использования характеристик продукта с точки зрения конечного пользователя.

Это можно делать простым способом в 4 этапа.
Давай придумаем название истории, по которой легко её будет найти.
Ок, пусть название первой истории будет: «Устал покупать продукты в магазине».

• Кто будет пользоваться продуктом?
• Ну, например, Мужчина лет 30.
• Что именно мне нужно?
• Хочу пополнять продукты в холодильнике.
• Зачем пользователю наш продукт?
• Не хочу тратить время на поход в магазин, при этом хочу выбирать наиболее выгодные предложения.

— Вить, мы описали видение MVP и пользовательские истории. Но ты понимаешь, что этого недостаточно. Давай сразу определим, что первая версия нашего продукта готова?
— Да-да, по Agile, мы с командой выписали односложные оценки, которые всем понятны:

• В сервисе я должен найти те продукты, которые мне нужны.
• Я должен знать о их наличии или о дате их прихода.
• Нужный товар легко добавляется в корзину.
• Мне очевидна дата и способ доставки.

Ну и так далее.

— Супер. Вить, сколько времени вам нужно на создание приложения?
— Я вот как раз думал, как лучше посчитать. Я вижу два варианта:
каждому этапу присвоить размер, как у одежды: S, M, L, XL и примерно заложить на них время;
или сгруппировать по объему задач и пронумеровать. Затем можем выполнить самую маленькую часть и понять сколько это занимает времени. После этого можно предположить, сколько времени занимают остальные задачи.

Огонь, мне нравится второй вариант: выполним самую простую задачу за пару дней и рассчитаем.

Так ребята поняли, что до выпуска MVP им нужно еще 2 недели.

Всё, Слава с командой готовы. Они сформировали конкретное и рациональное видение и ценность своего продукта как для бизнеса, так и для пользователя, который будет его использовать. Чтобы лучше понимать последнего, создали журнал требований продукта, где написали достаточно количество пользовательских историй, которые понятны всем. Всё-таки определились с MVP и выработали критерии принятия их продукта.

Продукт по методологии Agile создан. Как думаете, ребят ждёт успех?