Беклог продукту є однією з важливих частин ланцюга розробки продукту. Пріоритетний список функцій продукту та виправлення помилок, який веде від бачення компанії та продукту до виконання. По суті, управління невиконаними продуктами покладається на менеджера продуктів, який має ключове зобов’язання створити, визначити пріоритети та підтримувати їх. Крім того, ваш приклад невиконаної роботи продукту має бути побудований на інструменті, який є дружнім до користувача, досить гнучким, щоб його можна було налаштувати та легко доступним, особливо в хмарі. Читайте далі, щоб дізнатися про різницю між резервом продукту та резервом спринту та його вдосконаленням.
огляд
Белог продукту — це контрольний список роботи, який використовується групами розробників програмного забезпечення, щоб поставити в чергу бажані функції, виправлення помилок та інші технічні завдання. Іншими словами, це список справ для розвитку компанії. Беклог продукту пов’язаний із дорожньою картою продукту компанії, яка допомагає розставляти пріоритети для елементів і завдань у верхній частині резерву продукту, щоб команда знала, що виконати в першу чергу. Крім того, це ефективний спосіб для команди повідомити, над чим вони працюють і планують працювати далі. Коротко, давайте детально розглянемо, як створити беклог продукту,
Кроки для створення Backlog продукту
Беклог продукту — це більше, ніж простий список справ, у якому ви розбиваєте складні завдання на серію кроків і доручаєте їх членам команди. Виконайте ці кроки, щоб створити ефективний резерв продукту,
#1. Додайте ідеї до свого резерву
Якщо клієнт звернеться до вас з ідеями щодо створення нового програмного рішення або вдосконалення існуючого, подумайте про те, щоб додати ці ідеї до свого резерву. Тому що додавання їх до вашого резерву може стимулювати важливі розмови та допомогти команді знайти рішення для виконання запиту клієнта. Отже, включення їх допоможе вам визначити, чи можливо оновлення відповідно до графіка та бюджету проекту. Ось ще потенційні джерела ідей для невиконаних завдань:
- Команда компанії із забезпечення якості (QA).
- Опитування клієнтів щодо характеристик продукту
- Відгуки про продукт або послугу
- Продажі та маркетингові пропозиції чи запити
#2. Створіть дорожню карту продукту
Дорожня карта продукту є основою для резерву продукту. Ваша команда повинна спочатку створити дорожню карту, яка потім слугуватиме планом дій щодо того, як ваш продукт буде змінюватися в міру розвитку. Дорожня карта — це бачення довгострокового розвитку продукту, але воно також може розвиватися.
#3. Елементи резервної версії продукту контрольного списку
Пам’ятаючи про дорожню карту вашого продукту, ваша команда може почати перераховувати невиконані продукти. Ці пункти повинні містити як високопріоритетні пункти, так і більш абстрактні ідеї. Під час цієї фази створення резерву продукту вам також потрібно буде спілкуватися із зацікавленими сторонами та вислуховувати їхні ідеї щодо вдосконалення продукту.
#4. Зосередьтеся на своєму відставанні
Після того, як ваша команда складе список усіх предметів, відсортуйте та визначте пріоритети для найважливіших завдань, пам’ятаючи про клієнта та враховуючи, які предмети є найбільш цінними для нього. Після повного розуміння запиту клієнта подумайте про класифікацію ідеї на окремі та дієві завдання, які команда розробників має виконати в порядку пріоритету, причому найбільш критичні завдання будуть у верхній частині невиконаних завдань, а найменш критичні – у нижній.
#5. Оновлюйте регулярно
Коли ваша команда працює над беклогом продукту, пам’ятайте, що це живий документ, де вам потрібно постійно додавати елементи до беклогу, вибирати та вдосконалювати їх під час роботи. Тому, коли команда виконує завдання, важливо оновлювати, щоб відобразити ці зміни.
Приклад Backlog продукту
Відставання продукту є найважливішим артефактом у будь-якій компанії, що розробляє продукт. Як нам структурувати цей критичний артефакт? Прикладом відставання продукту є список завдань, пов’язаних із розробкою продукту, який використовується командами продукту для планування, вибору та керування завданнями. Наприклад,
#1.Проект
- Сторінка входу для кінцевого дизайну клієнтів
- Сторінка реєстрації для тестування клієнтів
- Створення збірки квитка (включно з додаванням документів і скріншотів)
- Виправлення: автоматичне призначення заявок керівнику групи підтримки
#2. Рейтинги
- Як людині, яка успішно пройшла сертифікаційний курс (стаючи сертифікованим ScrumMaster або сертифікованим Scrum Product Owner), мені електронною поштою надіслано посилання на опитування про курс та інструктора, щоб я міг залишити відгук про курс.
- Як тренер, я хочу бути впевненим, що ніхто не може надсилати однакові відповіді кілька разів і спотворювати мої результати, тому мої оцінки точні.
- Мене, як тренера, сповіщають про результати опитувань щодо моїх занять, тому я можу їх прочитати. (Питання: після кожного опитування? Через певний проміжок часу? Чи отримує тренер електронний лист чи просто знає, що потрібно відвідати сайт?)#3.членство
- Як адміністратор сайту, я можу встановлювати річні внески для учасників, практикуючих спеціалістів і тренерів, щоб можна було встановлювати плату без залучення програміста.
- Оскільки членство (будь-якого типу) незабаром закінчиться, мені надіслано нагадування та посилання, щоб я міг поновити його.
- Як учасник із проблемами короткочасної пам’яті, я можу попросити систему надіслати мені новий пароль або нагадування про пароль електронною поштою, можливо, моє ім’я користувача (якщо ми не використовуємо для цього електронну пошту), тощо
#4. Вакансії
- Як адміністратор сайту, мені надсилають електронні листи щоразу, коли надсилається вакансія, щоб я був у курсі цього та міг вирішити, чи хочу я його опублікувати.
- Як учасник сайту, я можу підписатися на RSS-канал доступних вакансій, щоб я міг читати їх, не відвідуючи сайт.
- Як адміністратор сайту, я можу редагувати та видаляти оголошення, які потребують допомоги, щоб я міг виправляти невеликі проблеми або робити
#5. Завершення курсу
- Як учаснику, мені показують сторінку, на якій розповідається, як отримати свої PDU після завершення курсу, щоб отримати кредит, який мене міг зацікавити.
- Як учасник, я можу отримати сертифікат про закінчення курсу, щоб мати підтвердження того, що я закінчив курс.
- Як учасник я можу отримати бейдж, який засвідчує, що я закінчив курс, щоб я міг розмістити цей бейдж на своєму веб-сайті.
Маючи відповідний приклад невиконаної роботи з продуктом, можна зробити точні оцінки робочого навантаження та спрогнозувати, що буде виконано з невеликими відхиленнями.
Уточнення резерву продукту
Уточнення продукту Backlog — це акт додавання деталей, оцінок і замовлень до елементів у продукті Backlog. Крім того, це процес, у якому власник продукту та команда розробників співпрацюють, переглядають і переглядають деталі елементів, які збираються впровадити. По суті, уточнення резерву продукту є необхідним, оскільки це дозволяє команді ознайомитися з найпріоритетнішими елементами. Давайте подивимося, як ефективно працювати з уточненням резерву продукту,
Як ефективно запустити сеанс уточнення продукту
Ось кілька найкращих практик уточнення, які допоможуть зробити ваш сеанс уточнення відставання ефективнішим.
#1. Зробіть це глибоким
Добре керований беклог має бути DE'EP, що є абревіатурою належним чином деталізовані, оцінені, невідкладні та пріоритетні.
- Відповідна деталізація означає, що елементи з вищим пріоритетом повинні мати вищий рівень деталізації, ніж елементи з низьким пріоритетом.
- Приблизний означає, що ви повинні мати гарне уявлення про час і ресурси, необхідні для реалізації кожного елемента відставання.
- Надзвичайний означає, що відставання є живим документом, який слід регулярно оновлювати.
- Залишені елементи слід розташувати в порядку пріоритету.
#2. Пам’ятайте про клієнтів
Кожне рішення, прийняте під час наради з уточнення відставання, має ґрунтуватися на потребах клієнтів. Зрештою, якщо продукт не працює для ваших клієнтів, усе інше не має значення. Команда буде відкрито обговорювати історії користувачів, обмінюватися ідеями та нарешті досягти спільного розуміння. Крім того, рекомендується задокументувати свої обговорення та думки, щоб PO міг переглянути їх пізніше та скласти підсумок.
#3. Визначте залежності
Іноді певні елементи відставання не можна реалізувати, доки не буде розпочато або завершено інший елемент. Нездатність визначити ці залежності може призвести до затримки просування по лінії. Тому добре виявити ці залежності на ранній стадії та спланувати їх.
#4. Подальші дії після Зустрічі
Після завершення зустрічі зв’яжіться з усіма учасниками та поділіться з ними протоколом зустрічі. Це допомагає тримати всіх на одній сторінці та гарантує, що вони знають про наступні кроки. Крім того, якщо в деяких історіях користувачів бракує інформації, продовжуйте проводити додаткові дослідження та додавайте деталі до наступної зустрічі.
Керування невиконаними продуктами
Керування невиконаними продуктами — це коли власник продукту додає, коригує, покращує та розставляє пріоритети невиконаних елементів, щоб клієнти отримували лише найкращий і найцінніший продукт. Тому, по суті, це список пріоритетних завдань, які необхідно виконати. Якщо будь-яке завдання зі списку неправильне, то воно не вважається виконаним.
Таким чином, управління невиконаними продуктами служить чудовою відправною точкою для планування спринту та розвитку команди для визначення завдань, які потенційно можуть бути частиною спринту. Таким чином, щоб забезпечити точність і прозорість, резервні версії продукту повинні бути актуальними через уточнення резервів. Нижче наведено поради для команди з управління продуктами,
#1. Почніть зі стратегії продукту
Належне управління відставаннями починається з чітко написаної та сформульованої стратегії продукту. Перш ніж зануритися в керування невиконаними продуктами, переконайтеся, що ви визначили та підтвердили стратегію продукту. Щоб досягти свого бачення, ви повинні спочатку мати чітко визначену стратегію продукту.
#2. Правильно встановіть параметри Backlog
Важливим аспектом є визначення пріоритетності завдань у вашому резерві. У відповідності з ключовими показниками ефективності та баченням продукту пріоритетність ваших невиконаних завдань має бути чіткою та прозорою. Використовуйте системи визначення пріоритетів і процедури, щоб допомогти вам упорядковувати свої ідеї та легко планувати повторення. Відгуки користувачів можуть допомогти вам у цьому, розуміючи, які ініціативи найбільш важливі для ваших клієнтів.
#3. Співпрацювати
Дозвольте менеджерам із продуктів і команді розробників співпрацювати, щоб забезпечити належне керування невиконаними документами. Залучайте обидві команди до обговорень, пов’язаних із невиконаними документами, щоб краще виявити технічні ризики та залежності. Крім того, кожен член команди продукту матиме цінний зворотний зв’язок, тому використовуйте ці зустрічі, щоб обговорити, як розставити пріоритети для невиконаних завдань, щоб покращити розуміння та підтримку. Це призведе до чіткого розуміння командою того, що було пріоритетним і чому.
#4. Використовуйте слово «ні» дипломатично
Одна з проблем, з якою стикається менеджер із продуктів, полягає в тому, що він може відчувати тиск, щоб прийняти кожен запит від зацікавлених сторін і членів команди, але мета полягає в тому, щоб порадувати ваших клієнтів, а не виконати кожен запит або сказати «так» кожній ідеї. Підвищуйте результати та ефективність (не кажучи вже про прибутковість), частіше кажучи «ні». Важливо не стати внутрішнім блокувальником і бути відкритим для нових запитів, але сказати «ні» допоможе вам визначити пріоритети, не відволікаючись.
#5. Тримайте зацікавлених сторін в курсі
Поділіться прозорими оновленнями із зацікавленими сторонами, щоб повідомити поточний статус вашого відставання. Оновлення можуть приймати форму надання зацікавленим сторонам доступу до інформаційної панелі в реальному часі, що містить актуальне зображення вашого відставання.
Або це може бути звичайний електронний бюлетень для відповідних людей у компанії, що містить лише знімок інформаційної панелі. Підтримуйте прозорість із зацікавленими сторонами, коли справа стосується відставання продукту. Повідомте зацікавленим сторонам про поточний стан, отримуйте останні оновлення та надсилайте корисні відгуки.
Беклог спринту проти Беклогу продукту
Спринт-беклоги та продукт-беклоги дуже схожі за складовими. Але резерв спринту — це список завдань, які ваша команда планує завершити під час спринту проекту, який зазвичай витягується з резерву продукту під час сеансу планування спринту. Таким чином, чіткий відставання спринту запобігає розповзанню обсягу, чітко пояснюючи, що ваша команда буде робити, а що не робитиме під час кожного спринту. Тепер ми подивимося на різницю між резервом спринту та резервом продукту,
По-перше, беклог продукту містить повний список майбутніх елементів для життєвого циклу продукту, тоді як беклог спринту зосереджується на тому, що необхідно для досягнення окремих цілей спринту. Тому кожен елемент, який береться з резерву продукту для формування резерву спринту, має бути пов’язаний з успіхом цієї конкретної цілі спринту.
По-друге, відставання продукту відстежує, як працює команда продукту залежно від розміру вашої організації, у вас може бути один центральний відставання продукту або кілька для різних команд. Крім того, власник продукту періодично уточнює резервну версію продукту, щоб переконатися, що найважливіші ініціативи знаходяться у верхній частині, і кожна ініціатива має всю інформацію, необхідну для її виконання. Тоді як беклог спринту є підмножиною беклогу продукту та містить список завдань, які потрібно виконати в одному конкретному спринті.
Крім того, для підтримки прозорості всього процесу розробки продукту необхідним є і резервне виконання продукту, і резервне виконання спринту. Вони забезпечують чітке уявлення про поточний хід роботи та плани на майбутнє.
Що таке Backlog продукту в Scrum?
У найпростішому визначенні Scrum Product Backlog — це просто список усіх речей, які потрібно зробити в рамках проекту. Він замінює традиційні артефакти специфікації вимог. Ці елементи можуть мати технічний характер або бути орієнтованими на користувача, наприклад, у формі історій користувачів. Власник Scrum є власником продукту Scrum. Scrum Master, команда Scrum та інші зацікавлені сторони сприяють створенню широкого та повного списку справ. Застосовуючи Scrum, немає необхідності починати проект із тривалими попередніми зусиллями, щоб задокументувати всі вимоги.
Коротко
Беклог продукту – це впорядкований список завдань, функцій або елементів, які потрібно виконати як частину більшої дорожньої карти продукту. За допомогою наведених вище вказівок я вважаю, що тепер ви зможете створювати ефективне управління, ви можете призначати розробникам щоденні, щотижневі або щомісячні завдання, які націлені на ваші кінцеві цілі та допоможуть створити кращий продукт.
посилання
- Асана.
- Дійсно.
- .mountaingoatsoftware
- .airgram.
Статті по темі
- ЩО ТАКЕ SCRUM: визначення, принципи та мета
- ГНУЧКІ ІНСТРУМЕНТИ КЕРУВАННЯ ПРОЕКТАМИ: визначення, використання та список APM
- Інструменти управління проектами: 25+ найкращих інструментів і методів
- Робочий наряд: проста процедура/ кроки для створення робочого наказу
- ДОРОЖНЯ КАРТА ПРОДУКТУ: значення, приклад, як це створити, програмне забезпечення та стратегія
- ТРАНСФОРМАЦІЯ БІЗНЕСУ: визначення, процес, стратегії, агентства та модель
