Библиотеки постоянно ищут инновационные способы улучшения своих услуг и удовлетворения меняющихся потребностей своих посетителей. Для достижения этой цели многие библиотеки обращаются к методологиям управления проектами по принципам Agile, чтобы направлять разработку системы. Одним из ключевых компонентов любого проекта по принципам Agile является хорошо управляемый продукт-бэклог, который служит приоритизированным списком функций и возможностей, которые библиотека намерена реализовать.
В этой статье будут рассмотрены наилучшие практики планирования продукт-бэклога, специфичные для библиотек, включая вовлечение заинтересованных сторон на всех этапах процесса, обеспечение прозрачности и видимости бэклога, а также регулярный обзор и корректировка приоритетов для обеспечения соответствия общей стратегии продукта и бизнес-целям библиотеки.
Следуя этим наилучшим практикам, ответственные за продукт могут разработать продукт-бэклог, который точно отражает потребности и ожидания персонала и посетителей, и в конечном итоге предоставить высококачественный продукт, соответствующий их потребностям.
Что такое продукт-бэклог?
Продукт-бэклог — это приоритизированный список функций, улучшений и ошибок, которые необходимо устранить в программном продукте. Это основной источник требований для команды разработки, и он используется для руководства процессом разработки.
Продукт-бэклог служит динамическим и постоянно развивающимся документом, который определяет работу, которую необходимо выполнить для выпуска программного продукта. Это важный инструмент для команд разработки по принципам Agile, поскольку он помогает обеспечить согласованность всех участников по целям и приоритетам проекта.
Продукт-бэклог обычно включает такие элементы, как новые функции, улучшения существующих функций, исправления ошибок, технический долг и другие задачи, необходимые для создания высококачественного продукта. Эти элементы обычно описываются в виде пользовательских историй, которые отражают потребности и требования конечных пользователей.
Кто отвечает за продукт-бэклог?
Важно уточнить, кто отвечает за управление продукт-бэклогом. В большинстве случаев ответственность за создание и поддержание продукт-бэклога лежит на ответственном за продукт. Однако команда разработки и другие заинтересованные стороны также могут вносить вклад в бэклог.
- Команда ответственный за продуктОбычно ответственный за продукт отвечает за создание, приоритезацию и поддержание продукт-бэклога. Однако это не означает, что ответственный за продукт работает в изоляции. На самом деле важно, чтобы ответственный за продукт сотрудничал с командой разработки, заинтересованными сторонами и другими членами организации, чтобы обеспечить соответствие продукт-бэклога общей стратегии продукта и бизнес-целям.
- Команда разработкиНапример, команда разработки может дать оценку технической реализуемости определенных функций или предложить альтернативные решения, которые помогут достичь тех же целей. Заинтересованные стороны, такие как клиенты или конечные пользователи, могут дать обратную связь по удобству использования или ценности определенных функций. Вовлекая различные точки зрения и знания, ответственный за продукт может обеспечить, что продукт-бэклог является всесторонним, хорошо обоснованным и соответствует потребностям организации.
Как создать продукт-бэклог?
Объясните шаги, необходимые для создания продукт-бэклога, включая сбор требований, приоритезацию функций и разбивку крупных функций на более мелкие пользовательские истории. Также важно обсудить, как обеспечить соответствие продукт-бэклога общей стратегии продукта и бизнес-целям.
Вот шаги, необходимые для создания продукт-бэклога:
- Сбор требований:Первый шаг при создании продукт-бэклога — это сбор требований от заинтересованных сторон, клиентов и других источников. Это включает понимание потребностей и целей продукта, а также любых ограничений или ограничений, которые могут повлиять на его разработку. Требования можно собирать с помощью различных методов, таких как интервью, опросы, фокус-группы или тестирование пользователей.
- Приоритизация функций:После сбора требований следующим шагом является приоритизация функций на основе их значимости для стратегии продукта и бизнес-целей. Ответственный за продукт должен тесно сотрудничать с заинтересованными сторонами, чтобы определить, какие функции критически важны для успеха продукта, а какие можно отложить или исключить. Для этого можно использовать различные методы приоритизации, такие как MoSCoW, Kano или приоритизация на основе возврата инвестиций.
- Разбивка крупных функций на мелкие пользовательские истории:После приоритезации функций ответственный за продукт должен разбить крупные функции на более мелкие, удобные для управления пользовательские истории. Пользовательские истории — это краткие, простые описания функции или функциональности, отражающие точку зрения пользователя. Разбивка функций на пользовательские истории помогает сделать их более осязаемыми и легкими для реализации, а также обеспечивает соответствие их потребностям конечных пользователей.
- Согласование продукт-бэклога с общей стратегией продукта и бизнес-целями:Важно обеспечить соответствие продукт-бэклога общей стратегии продукта и бизнес-целям. Ответственный за продукт должен регулярно проверять и обновлять продукт-бэклог, чтобы убедиться, что он остается актуальным и направлен на создание ценности для клиента. Ответственный за продукт также должен тесно сотрудничать с заинтересованными сторонами и командой разработки, чтобы обеспечить согласованность всех участников по стратегии продукта и чтобы продукт-бэклог способствовал достижению этой стратегии.
- Как поддерживать продукт-бэклог:Создание продукт-бэклога — это только начало. Важно регулярно проверять и обновлять бэклог, чтобы он оставался актуальным и соответствовал стратегии продукта. Обсудите стратегии управления сессиями по улучшению бэклога, обработки изменений приоритетов и решения проблемы технического долга.
- Наилучшие практики планирования продукт-бэклога: Завершите статью, резюмируя некоторые лучшие практики планирования продукта, например, вовлечение заинтересованных сторон в процесс, обеспечение видимости и прозрачности бэклога продукта, а также регулярный обзор и корректировка приоритетов.
Планирование бэклога продукта предоставит ценные инсайты и руководство для команд агил, стремящихся улучшить свой процесс разработки. Следуя этим шагам, владелец продукта сможет создать всесторонний и хорошо приоритизированный бэклог продукта, соответствующий общей видению продукта и бизнес-целям. Это поможет обеспечить, что команда разработки сосредоточена на предоставлении наиболее ценных функций и возможностей, а продукт соответствует потребностям и ожиданиям клиентов.
Пример — система библиотеки
Описание проблемы
Местная общественная библиотека сталкивается с несколькими проблемами при управлении своей коллекцией книг и других материалов. В настоящее время библиотека использует ручную систему для отслеживания своего инвентаря, что занимает много времени и подвержено ошибкам. Сотрудники библиотеки тратят значительное количество времени на ручной учет книг, а также нет возможности легко отслеживать, какие книги доступны или просрочены.
Кроме того, библиотека испытывает трудности с соответствием меняющимся потребностям и ожиданиям пользователей. Многие клиенты теперь ожидают возможности получать доступ к ресурсам библиотеки онлайн, а текущая система не поддерживает онлайн-бронирование, продление или другие функции, которые становятся все более важными для пользователей библиотеки.
1. Сбор требований
Для сбора требований к системе библиотеки команда разработки может начать с проведения интервью со сотрудниками библиотеки, включая библиотекарей, персонал кассы и сотрудников ИТ. Во время этих интервью команда может задавать вопросы о текущей системе, ее сильных и слабых сторонах, а также о проблемах, с которыми сталкиваются сотрудники в повседневной работе. Команда также может уточнить цели и задачи библиотеки, а также любые ограничения или препятствия, которые могут повлиять на разработку новой системы.
Команда также может провести опросы или фокус-группы с пользователями библиотеки, чтобы понять их потребности и ожидания. Опросы могут содержать вопросы о текущей системе, ее полезности и ограничениях, а также предпочтения пользователей в отношении новых функций и возможностей. Фокус-группы могут предоставить более глубокое понимание потребностей пользователей и их проблем, а также опыт использования системы библиотеки.
Наконец, команда может провести тестирование пользователей, чтобы получить представление о удобстве использования и функциональности текущей системы, а также выявить области для улучшения. Тестирование пользователей может включать наблюдение за пользователями при взаимодействии с системой, проведение опросов или интервью после тестирования, а также сбор обратной связи по конкретным функциям или возможностям.
Собрав требования с помощью этих различных методов, команда разработки может получить всестороннее понимание потребностей и целей системы библиотеки, а также потребностей и ожиданий ее пользователей. Эта информация может быть использована для создания бэклога продукта, который приоритизирует наиболее важные функции и возможности и соответствует общим целям и задачам библиотеки.
2. Приоритизация функций
На основе требований, собранных для системы библиотеки, команда разработки и владелец продукта могут начать приоритизацию функций, которые будут включены в бэклог продукта. Вот некоторые возможные функции и их приоритет:
- Автоматизированный учет приема и выдачи книг – Высокий приоритет. Эта функция может помочь оптимизировать работу библиотеки и снизить нагрузку на сотрудников библиотеки.
- Информация о доступности книг и других материалов в реальном времени – Высокий приоритет. Эта функция может улучшить пользовательский опыт, предоставляя точную и актуальную информацию о доступности материалов.
- Онлайн-бронирование, продление и резервирование – Высокий приоритет. Эта функция может обеспечить пользователям более удобный доступ к ресурсам библиотеки и снизить необходимость личных визитов в библиотеку.
- Интеграция с веб-сайтом и мобильным приложением библиотеки – Высокий приоритет. Эта функция может обеспечить бесшовный пользовательский опыт, позволяя пользователям получать доступ к ресурсам библиотеки с их предпочтительных устройств.
- Подробный отчет и аналитика – Средний приоритет. Эта функция может помочь сотрудникам библиотеки лучше управлять коллекцией и эффективнее распределять ресурсы.
- Настраиваемые профили пользователей – Низкий приоритет. Хотя эта функция может обеспечить более персонализированный пользовательский опыт, она может не быть критически важной для успеха продукта.
Приоритет этих функций может быть определен с помощью различных методов, таких как MoSCoW или Kano. Например, команда может использовать приоритизацию MoSCoW для классификации функций как «обязательные», «желательные», «возможные» или «не будут реализованы».
Альтернативно, команда может использовать приоритизацию Kano для классификации функций как «обязательные», «производительность», «привлекательные», «нейтральные» или «обратные». Владелец продукта может тесно сотрудничать со заинтересованными сторонами, чтобы определить наиболее подходящий метод приоритизации и обеспечить соответствие приоритизации общей видению продукта и бизнес-целям.
Резюмируйте свои выводы
Вот пример таблицы для представления приоритизированных функций для системы библиотеки:
| Функция | Приоритет |
|---|---|
| Автоматизированный прием и выдача книг | Высокий |
| Информация о наличии материалов в режиме реального времени | Высокий |
| Онлайн-бронирование, продление и резервирование | Высокий |
| Интеграция с веб-сайтом библиотеки и мобильным приложением | Высокий |
| Детализированный отчет и аналитика | Средний |
| Настраиваемые профили пользователей | Низкий |
Приоритизация и оценка усилий
В этой таблице функции перечислены в первом столбце, а их приоритет — во втором. Приоритет классифицируется как высокий, средний или низкий, в зависимости от его значения для общей концепции продукта и бизнес-целей. Таблица предоставляет четкий и краткий способ представления приоритетных функций для библиотечной системы, что облегчает понимание ключевых функций, которые необходимо включить в бэклог продукта, как заинтересованными сторонами, так и командой разработки.
вот пример таблицы для представления приоритетных функций для библиотечной системы с дополнительным столбцом для очков истории:
| Функция | Приоритет | Очки истории |
|---|---|---|
| Автоматизированный прием и выдача книг | Высокий | 3 |
| Информация о наличии материалов в режиме реального времени | Высокий | 5 |
| Онлайн-бронирование, продление и резервирование | Высокий | 8 |
| Интеграция с веб-сайтом библиотеки и мобильным приложением | Высокий | 13 |
| Детальная отчетность и аналитика | Средний | 5 |
| Настраиваемые профили пользователей | Низкий | 2 |
В этой таблице добавлен столбец «оценка по баллам истории», чтобы количественно оценить уровень усилий, необходимых для реализации каждого функционального требования. Оценка по баллам истории используется в гибкой разработке для оценки объема работы, необходимого для завершения пользовательской истории. Оценки по баллам истории основаны на таких факторах, как сложность, усилия и риск. В этом примере оценки по баллам истории основаны на опыте и знаниях команды по системе библиотеки.
Что такое оценка по баллам истории
Оценки по баллам истории могут использоваться для помощи команде разработки в планировании своей работы и определении того, сколько задач они могут выполнить в каждом спринте или итерации. Чем выше оценка по баллам истории, тем больше усилий и времени требуется для завершения соответствующей функции. Включив оценки по баллам истории в таблицу, заинтересованные стороны и команда разработки смогут лучше понять уровень усилий, необходимых для реализации каждой функции, и принять более обоснованные решения о приоритетах продукта.
3. Разбейте крупные функции на более мелкие пользовательские истории
На основе приоритизированных функций для системы библиотеки владелец продукта может разбить каждую функцию на более мелкие пользовательские истории. Вот некоторые возможные пользовательские истории для каждой функции:
- Автоматический прием и выдача книг:
- Я, сотрудник библиотеки, хочу иметь возможность сканировать штрих-код книги для ее приема или выдачи, чтобы экономить время и сократить количество ошибок.
- Я, пользователь библиотеки, хочу иметь возможность взять книгу с помощью терминала самообслуживания, чтобы экономить время и избежать очереди.
- Информация о наличии материалов в режиме реального времени:
- Я, пользователь библиотеки, хочу иметь возможность видеть наличие книги или другого материала в режиме реального времени, чтобы более эффективно планировать посещение библиотеки.
- Я, сотрудник библиотеки, хочу иметь возможность в реальном времени обновлять информацию о наличии книги или другого материала, чтобы пользователи имели точные сведения о ее наличии.
- Онлайн-бронирование, продление и резервирование:
- Я, пользователь библиотеки, хочу иметь возможность бронировать книгу онлайн, чтобы убедиться, что она будет доступна при моем посещении библиотеки.
- Я, пользователь библиотеки, хочу иметь возможность продлевать книгу онлайн, чтобы избежать пени за просрочку и продлить срок пользования книгой.
- Я, пользователь библиотеки, хочу иметь возможность забронировать книгу, которая в данный момент находится в наличии, чтобы быть уведомленным, когда она станет доступной.
- Интеграция с веб-сайтом библиотеки и мобильным приложением:
- Я, пользователь библиотеки, хочу иметь возможность получать доступ к информации о своем аккаунте (например, выданные предметы, даты возврата) на веб-сайте библиотеки или в мобильном приложении, чтобы легче управлять своим библиотечным аккаунтом.
- Я, пользователь библиотеки, хочу иметь возможность искать и бронировать книги с помощью веб-сайта библиотеки или мобильного приложения, чтобы делать это в удобной обстановке своего дома.
- Детальная отчетность и аналитика:
- Я, сотрудник библиотеки, хочу иметь возможность создавать отчеты о библиотечном фонде (например, самые популярные книги, предметы, выданные по отделам), чтобы принимать обоснованные решения о распределении ресурсов и управлении фондом.
- Настраиваемые профили пользователей:
- Я, пользователь библиотеки, хочу иметь возможность настраивать свой библиотечный аккаунт (например, предпочтительные способы уведомлений), чтобы получить более персонализированный опыт.
Разбивая функции на более мелкие пользовательские истории, владелец продукта может создать более подробный и выполнимый бэклог продукта, соответствующий потребностям и ожиданиям конечных пользователей. Пользовательские истории могут служить основой для задач разработки и помогут обеспечить, что команда разработки создает функции, отвечающие потребностям пользователей в конкретной и осязаемой форме.
Объедините результаты в таблицу
Вот пример таблицы, включающей приоритет и количество очков истории для пользовательских историй:
| Функция | Приоритет | Очки истории |
|---|---|---|
| Автоматическая регистрация книг — персонал | Высокий | 3 |
| Автоматическая регистрация книг — самоподача | Высокий | 5 |
| Информация о наличии материалов в реальном времени | Высокий | 8 |
| Онлайн-бронирование | Высокий | 8 |
| Онлайн продление | Высокий | 5 |
| Поставить резерв на выданную книгу | Высокий | 5 |
| Информация об учетной записи на веб-сайте/приложении библиотеки | Высокий | 5 |
| Поиск и бронирование книг на веб-сайте/приложении | Высокий | 8 |
| Отчеты о библиотечной коллекции | Средний | 13 |
| Настраиваемые профили пользователей | Низкий | 3 |
В этой таблице перечислены пользовательские сценарии, созданные для каждого функционального элемента, а также их приоритет и оценки по баллам пользовательских сценариев. Приоритеты функциональных элементов основаны на приоритизации, установленной владельцем продукта, а оценки по баллам пользовательских сценариев основаны на предполагаемом уровне усилий, необходимых для реализации каждого пользовательского сценария.
Команда разработки может использовать эту таблицу для планирования своей работы и определения того, сколько она сможет выполнить в каждом спринте или итерации. Чем выше оценка по баллам пользовательского сценария, тем больше усилий и времени требуется для завершения соответствующего пользовательского сценария. Эта таблица также может использоваться для отслеживания прогресса и обеспечения того, чтобы команда разработки последовательно продвигалась к завершению каждого пользовательского сценария и функционального элемента.
Как пересматривать оценки по баллам пользовательских сценариев: каковы критерии?
Оценки по баллам пользовательских сценариев для функциональных элементов могли измениться после процесса разбивки, поскольку пользовательские сценарии предоставляют более детальное и подробное представление о работе, необходимой для реализации каждого функционального элемента. Вот некоторые факторы, которые могли повлиять на изменение оценок по баллам пользовательских сценариев:
- Сложность:Пользовательские сценарии могли выявить дополнительные сложности, которые не были очевидны при первоначальной приоритизации функциональных элементов. Например, пользовательский сценарий для онлайн-бронирования мог выявить необходимость в системе уведомлений по электронной почте, которая изначально не учитывалась при приоритизации функциональных элементов. Эта дополнительная сложность могла увеличить оценку по баллам пользовательского сценария.
- Усилия:Пользовательские сценарии предоставляют более детальное представление об усилиях, необходимых для реализации каждого функционального элемента. Например, пользовательский сценарий для информации о доступности в реальном времени мог выявить необходимость в новой базе данных или API для отслеживания доступности материалов. Эти дополнительные усилия могли увеличить оценку по баллам пользовательского сценария.
- Риск:Пользовательские сценарии могли выявить дополнительные риски, которые изначально не были очевидны при приоритизации функциональных элементов. Например, пользовательский сценарий для автоматического оформления выдачи/возврата книг мог выявить необходимость в обширном тестировании, чтобы убедиться, что новая система не вводит ошибки или неточности. Этот дополнительный риск мог увеличить оценку по баллам пользовательского сценария.
Процесс разбивки предоставляет более детальное и тонкое представление о работе, необходимой для реализации каждого функционального элемента. Оценки по баллам пользовательских сценариев могут меняться по мере того, как команда разработки лучше понимает сложности, усилия и риски, связанные с каждым пользовательским сценарием. Постоянно уточняя оценки по баллам пользовательских сценариев на основе опыта и знаний команды разработки, владелец продукта может обеспечить, чтобы бэклог продукта точно отражал уровень усилий, необходимых для реализации желаемых функций и возможностей.
4. Согласуйте бэклог продукта с видением и целями
Чтобы согласовать бэклог продукта с общей концепцией продукта и бизнес-целями для библиотечной системы, владелец продукта может предпринять следующие шаги:
- Проверьте и обновите бэклог продукта:Владелец продукта должен регулярно проверять и обновлять бэклог продукта, чтобы убедиться, что он по-прежнему актуален и соответствует концепции продукта и бизнес-целям. Это включает в себя удаление пользовательских сценариев, которые больше не актуальны или не требуются, добавление новых пользовательских сценариев, поддерживающих концепцию продукта, и переприоритезацию бэклога по мере необходимости.
- Сосредоточьтесь на предоставлении ценности клиенту:Владелец продукта должен обеспечить, чтобы бэклог продукта был сосредоточен на предоставлении ценности клиенту. Это означает приоритизацию пользовательских сценариев, которые напрямую способствуют опыту и удовлетворенности клиента, и снижение приоритета или удаление пользовательских сценариев, которые не предоставляют значительной ценности.
- Работайте тесно со заинтересованными сторонами:Владелец продукта должен тесно сотрудничать со заинтересованными сторонами, включая персонал библиотеки и пользователей, чтобы убедиться, что бэклог продукта соответствует их потребностям и ожиданиям. Это включает в себя регулярное сбор обратной связи и включение ее в бэклог продукта.
- Сообщайте о концепции продукта:Владелец продукта должен информировать команду разработки и заинтересованные стороны о концепции продукта и бизнес-целях, чтобы обеспечить согласованность всех участников и понимание того, как их работа вносит вклад в достижение этой цели. Это включает в себя предоставление регулярных обновлений и отчетов о ходе работы, а также обеспечение того, чтобы все были осведомлены о любых изменениях или обновлениях в бэклоге продукта.
Принимая эти меры, владелец продукта может обеспечить, что бэклог продукта согласован с общей концепцией продукта и бизнес-целями, и что он ориентирован на предоставление ценности клиенту. Это помогает обеспечить, что команда разработки создает функции и возможности, отвечающие потребностям и ожиданиям персонала библиотеки и пользователей, и что продукт успешно достигает своей цели.
5. Как поддерживать бэклог продукта
Чтобы поддерживать бэклог продукта для библиотечной системы, ответственный за продукт может предпринять следующие шаги:
- Планировать регулярные сессии по улучшению бэклога:Ответственный за продукт должен планировать регулярные сессии по улучшению бэклога совместно с командой разработки для обзора и обновления бэклога продукта. Это включает приоритизацию пользовательских сценариев на основе их важности, разбиение крупных пользовательских сценариев на более мелкие и управляемые, а также удаление или снижение приоритета пользовательских сценариев, которые больше не требуются.
- Учитывать изменения приоритетов:Ответственный за продукт должен быть готов учитывать изменения приоритетов по мере их возникновения. Это включает открытость к обратной связи от заинтересованных сторон и соответственно корректировку бэклога продукта, а также возможность переприоритизации пользовательских сценариев на основе меняющихся бизнес-потребностей и целей.
- Учитывать технический долг:Технический долг — это накопление технических проблем, которые могут замедлить разработку и повлиять на качество продукта. Ответственный за продукт должен придавать приоритет решению технического долга в рамках процесса улучшения бэклога и тесно сотрудничать с командой разработки для выявления и решения технических проблем по мере их появления.
- Отслеживать прогресс и информировать о обновлениях:Ответственный за продукт должен отслеживать прогресс по бэклогу продукта и информировать заинтересованные стороны и команду разработки о обновлениях. Это включает предоставление регулярных отчетов о ходе работы, обновление бэклога по мере необходимости и обеспечение того, чтобы все были осведомлены о любых изменениях или обновлениях в продуктовой концепции или бизнес-целях.
Следуя этим стратегиям, ответственный за продукт может обеспечить, что бэклог продукта остается актуальным и соответствует продуктовой концепции и бизнес-целям. Регулярные сессии по улучшению бэклога помогают обеспечить правильную приоритизацию и управление бэклогом, а решение технического долга способствует высокому качеству продукта и его эффективной разработке. Отслеживание прогресса и информирование о обновлениях помогают обеспечить согласованность всех участников по продуктовой концепции и понимание того, как их работа вносит вклад в достижение целей.
6. Лучшие практики планирования бэклога продукта
Вот некоторые лучшие практики планирования бэклога продукта для библиотечной системы:
- Привлекать заинтересованные стороны к процессу:Важно привлекать заинтересованные стороны, включая персонал библиотеки и пользователей, к процессу планирования бэклога продукта. Это помогает обеспечить соответствие бэклога их потребностям и ожиданиям, а также успех продукта в достижении его целей.
- Сохранять бэклог видимым и прозрачным:Бэклог продукта должен быть видимым и прозрачным для всех заинтересованных сторон и команды разработки. Это помогает обеспечить согласованность всех участников по продуктовой концепции и то, что прогресс достигается в направлении достижения бизнес-целей.
- Приоритизировать на основе ценности:Приоритизировать пользовательские сценарии на основе их ценности для клиента и бизнеса. Это помогает обеспечить, что команда разработки создает функции и возможности, которые приносят наибольшую пользу персоналу библиотеки и пользователям.
- Регулярно пересматривать и корректировать приоритеты:Ответственный за продукт должен регулярно пересматривать и корректировать приоритеты бэклога на основе меняющихся бизнес-потребностей и целей. Это помогает обеспечить, что бэклог остается актуальным и соответствует продуктовой концепции.
- Разбивать крупные пользовательские сценарии на более мелкие:Разбиение крупных пользовательских сценариев на более мелкие и управляемые помогает сделать их более осязаемыми и легкими для реализации. Это помогает обеспечить, что команда разработки создает функции, которые на практике отвечают потребностям пользователей.
- Учитывать технический долг:Придавать приоритет решению технического долга в рамках процесса улучшения бэклога. Это помогает обеспечить высокое качество продукта и его эффективную разработку.
Следуя этим лучшим практикам, ответственный за продукт может обеспечить правильную приоритизацию и управление бэклогом продукта, а также то, что команда разработки создает функции и возможности, отвечающие потребностям и ожиданиям персонала библиотеки и пользователей.
Краткое содержание
Планирование бэклога продукта — это важный процесс для библиотек, чтобы приоритизироватьусилия по разработке продуктаи обеспечить, что продукты отвечают потребностям персонала и посетителей. В контексте разработки системы управления библиотекой планирование бэклога продукта включает привлечение заинтересованных сторон, поддержание прозрачности и видимости бэклога, а также регулярный пересмотр приоритетов для обеспечения соответствия общей концепции библиотеки и ее бизнес-целям.
В статье подчеркиваетсянаилучшие практики для планирования продукта и предоставляет пример разработки системы управления библиотекой. Следуя этим наилучшим практикам, библиотеки могут создать продукт, который точно отражает потребности и ожидания персонала и посетителей, что приведет к созданию высококачественных продуктов, отвечающих их потребностям.