Роб Коул. Блискучий 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 створений. Як думаєте, хлопців чекає успіх?

Залишити коментар

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *