бэклог задач что это
Что такое бэклог продукта: основы
Узнайте, как создать и вести бэклог продукта
Бэклог продукта — это один из инструментов agile-разработки, который представляет собой перечень требований к продукту и задач, расставленных по приоритету.
Содержание
Как вести бэклог продукта
За составление бэклога продукта отвечает product owner (владелец продукта). В его формировании может также принимать участие scrum-мастер и другие напрямую заинтересованные лица, например, вовлеченные стейкхолдеры. Список задач составляют на основании дорожной карты и требований к продукту. Product owner регулярно пересматривает и обновляет бэклог если это необходимо, чтобы команда разработчиков на его основании могла выполнять свою работу и продвигаться к поставленной цели.
Согласно методологии скрам требования из бэклога продукта служат основой для проработки задач в спринтах, которые представляют собой временные интервалы для выполнения работ. Перед каждым этапом разработки команда проводит встречу со scrum-мастером, чтобы обсудить план работ и сформировать бэклог спринта.
Для того, чтобы процесс был максимально прозрачным для всех участников команды, используют виртуальные или физические доски. Посмотрите пример ниже. По вертикали расположен бэклог и основные этапы разработки. Цифрами отображены задачи, требующие решения. Чтобы изменить статус какой-либо из них, необходимый стикер перемещают из одного столбца в другой. Количество этапов (вертикальных столбцов) зависит от продукта, над которым работает команда и специфики ее работы.
Похожие доски используют и в методологии канбан. Однако, в этом подходе работу над продуктом не разбивают на спринты, а создают только один бэклог. В scrum процесс разработки продукта делят на этапы, поэтому возникает путаница между такими понятиями как «бэклог продукта» и «бэклог спринта». В следующем разделе вы ознакомитесь с отличиями этих двух инструментов.
Чем бэклог продукта отличается от бэклога спринта
Главное отличие заключается в том, что бэклог продукта представляет собой полный перечень требований и задач для разработки того самого продукта. Это основа, которая ведет к достижению главной поставленной цели.
Бэклог спринта помогает визуализировать процесс работы на пути к достижению краткосрочных целей. Он представляет собой список задач, которые необходимо выполнить на конкретном этапе разработки, чтобы реализовать один из элементов продукта. Созданием бэклога спринта руководит скрам-команда, а не владелец продукта. Участники формируют перечень задач в начале каждого этапа работы.
В следующем разделе вы узнаете, что собой представляет бэклог продукта и как его создать.
Как создать бэклог продукта
Бэклог требует регулярного обновления, поскольку в процессе работы могут появиться новые конкуренты, измениться требования на рынке, цены и прочие факторы, влияющие на функционал создаваемого продукта. Для разработки бэклога продукта используют product roadmap, user stories и customer journey map. Давайте подробнее разберем, для чего необходим каждый из этих инструментов.
Следуйте пошаговому плану ниже, чтобы разработать бэклог продукта при помощи этих трех инструментов.
На скриншоте ниже вы видите, как может выглядеть бэклог продукта. В таблице указана приоритетность задач и их описание, объем и сложность работ по каждой из них в цифровом эквиваленте — story points.
Для постановки задач в своем бэклоге используйте методику SMART. Обязательно пропишите подробно элементы, которые необходимы для работы во время ближайших одного или двух спринтов. Задачи для последующих этапов скорее всего необходимо будет корректировать на основании полученных результатов и обратной связи. Главное, тщательно собирайте и анализируйте всю информацию, чтобы регулярно обновлять и актуализировать свой бэклог продукта.
Команды, работающие над развитием различных продуктов, имеют одну общую цель: обеспечить максимальную скорость изменения своего продукта для реализации возникающих потребностей пользователей / заказчиков.
Вопрос: В каких условиях команда может достигнуть требуемых показателей?
Ответ: При одновременном достижении двух условий:
Для того, чтобы подсчитать всех дьяволов, кучно роящихся в деталях, предлагаю более пристально взглянуть на то, как формируется этот «вход».
Что слева?
Для иллюстрации воспользуемся классификацией компании Atlassian:
Если вы взглянете на эту иерархию, то увидите, что в ней смешиваются объекты двух назначений:
Эпики находятся в этой пирамиде между инициативами и историями в первую очередь для того, чтобы более наглядным образом проиллюстрировать и объяснить покрытие общей формулировки инициативы очень частными определениями историй. Эпики никогда для являются объектами обработки для команды, они просто очень велики для этого, не имеют строгого самостоятельного DoD, не являющегося компиляцией дочерних требований.
Темы можно смело считать статичными аналитическими управленческими группировками.
Где здесь Бэклог?
Из чего состоит бэклог команды? Из каких объектов он состоит? Какая работа предшествует его пополнению?
Беклог команды состоит из понятных команде конечных элементов, обрабатываемых командой за один или несколько (не более чем некоторое N) условных «тактов».
Такими объектами в иерархии Atlassian являются истории и подзадачи. Все ли с этом хорошо и понятно? Нет.
Истории изначально сформулированы так, чтобы обеспечивать сохранение/подтверждение некоторой ценности на нижнем уровне инкремента.
Задачи — не имеют такого свойства. Откуда же они появляются?
Реальные приложения устроены так, что отдельные пользовательские истории могут выливаться в чрезвычайные объемы работ. Из недавнего: «Кредитный менеджер должен иметь возможность выдать коммерческой компании кредит государственной поддержки бизнеса во исполнения ПП РФ №. от вчерашнего числа», волосы причастных по сей день шевелятся.
Это вынуждает команду дробить истории в бэклоге на задачи, каждая из которых не имеет самостоятельной ценности.
Более того, иногда даже корректно сформулированная история не имеет настоящей ценности, пока не будут разработаны другие истории в рамках эпика. Условно, пока эпик (реализуемая в нем фича) не достиг состояния MVP, готовности к реальному использованию, составляющие его истории не ценны.
Итак, бэклог команды состоит из набора взаимосвязанных историй и задач, которые по отдельности могут не иметь доказанной/воспринимаемой ценности. Тем не менее — именно с этим команда может работать быстро.
Команда тратит регулярные усилия на анализ бэклога для поддержания его актуальности (верификацию остаточной ценности историй и задач).
Как пополняется бэклог?
Владелец продукта отвечает за развитие продукта, а значит и пополнение бэклога. Как это происходит?
В какой-то момент у владельца продукта возникает Идея, эта идея могла быть обретена разными способами:
Идея должна быть осмыслена, измерена и классифицирована так, чтобы владелец продукта вместе с командой понимал, является эта Идея новой инициативой, отдельным эпиком, или ее будет достаточно формулировать ее в виде истории. Нужно ли инициировать принятие отдельных инвестиционных решений.
Заказчиков и, тем более, пользователей много, и каждый их них дышит противоречивыми идеями, наискорейшую реализацию которых они непременно видят в продукте. Формируется поток.
Владелец продукта формирует поток обработки Идей (воронку), конечным результатом которого является:
Если ценность Идеи подтверждена, то истории из ее декомпозиции включаются в бэклог команды. Для идеи проходит точка принятия решения. Заказчик (если он явно присутствует) начинает ждать ее реализации (акцент к конечной ценности отдельных историй: заказчик, по умолчанию, ждет не реализации отдельных историй, сформулированных командой, а его Идеи целиком).
Команда может сама инициировать добавление новых историй в бэклог, если первичное покрытие эпика историями было не полным и что-то важное для совокупной ценности эпика (ценность которого больше, чем ценность всех входящих в него историй) было упущено.
Вопросы на которые потребуется ответить команде при организации этой работы:
Управление проектами что это? Пошаговое руководство!
Управление проектами что это? Пошаговое руководство! Бэклог продукта. Цель проекта. Руководитель проекта. Проектная группа. Бэклог спринта.
Здравствуйте, уважаемые коллеги, руководители среднего и высшего звена, а также Project-менеджеры!
Сегодня расскажу, как профессионально управлять проектами в организации! Тем более, что сам являюсь действующим практиком! В настоящее время я управляю крупным бизнесом, группой компаний с различными направлениями: оптовые продажи, розничные продажи, транспортная логистика, управление недвижимостью, брокерские таможенные услуги.
Итак, все по порядку! Что необходимо делать в project management!
1. Управление проектами. Подготовьте бэклог продукта (product backlog).
Бэклог продукта (product backlog) включает в себя все пожелания, требования внутреннего или внешнего заказчика (product owner), или менеджера продукта (product manager). Product owner может быть в лице высшего руководства компании, где Вы работаете или быть сторонним заказчиком.
Примерами product backlog в моем случае являются:
Можно перечислять и дальше проекты под моим управлением, но будем экономить время!
Итак, что включают в себя требования product owner?
Язык требований product owner включает в себя, как технические параметры, так и общие, широко распространённые и понятные большинству лексические формы.
И структура, и функции, и содержание с формой product backlog состоят из «кирпичиков», отдельных элементов бэклога, которые называются пользовательские истории (user stories). Каждая user stories имеет вес, уровень приоритета, что предполагает разные временные, энергетические, финансовые затраты. Это позволяет проектной команде более гибко распределять свое рабочее время, в зависимости от значимости user stories.
2. Управление проектами. Поставьте цель проекта (project target).
При этом цель должна соответствовать следующим критериям:
Без экологической проверки поставленной цели критериям возрастает риск «прийти туда, не зная куда, получить то, не зная что».
Обычно цель проекта определяется в процессе генерирования идей на основании бэклога продукта уже проектной группой (project team), в составе которой должны быть product owner, product manager.
Цель проекта без бэклога продукта не может быть качественно сформулирована. Однако, наличие бэклога продукта еще не гарантирует генерирование качественной цели проекта (project target), необходимо будет отсечь все лишнее и оставить наиболее важное. Об этом легко говорить, но на деле непросто сделать.
Потому что заказчик (product owner) весьма часто хочет «и на елку залезть, и дрова получить, и в смоле не испачкаться, и об иголки не уколоться».
ПОСМОТРИТЕ ВИДЕО “Переговоры. Как преодолеть возражения?!”
Идеальный бэклог продукта
И снова здравствуйте. Перевод данной статьи был подготовлен в преддверии старта курса «Agile Project Manager в IT».
Здоровый бэклог продукта является необходимым условием для успешной Scrum-команды. Вместо того, чтобы сосредотачиваться только на доработке пользовательских историй для предстоящего спринта, предусмотрительные Scrum-команды инвестируют в доработку бэклога продукта, чтобы повысить прозрачность, сосредоточиться на своем видении и сохранить согласованность действий. Прозрачность – это гораздо больше, чем просто предоставление информации, заинтересованная сторона должна иметь возможность получить искомую информацию в течение нескольких секунд.
Взгляните на бэклог продукта, который представлен ниже, чтобы понять, что я подразумеваю под идеальным бэклогом. Этот бэклог четко отражает работу предстоящего спринта, долгосрочную дорожную карту, ключевые контрольные даты и формулирует видение будущего – и все на одной странице! Взгляд на такой бэклог позволяет всем заинтересованным сторонам, клиентам, членам команды и руководителям быстро сформировать понимание о состоянии продукта. Самые последние ретроспективные действия находятся сверху. Все пользовательские истории подвергаются оценке. Вне зависимости от типа аудитории, каждый ее член получит необходимую информацию меньше, чем за 30 секунд.
Где умирают пользовательские истории
Сталкивались ли вы когда-нибудь с бэклогом продукта, когда пользовательские истории следующего спринта четко определены, но за под ними куча неприоритезированного мусора? Я называю это бэклогом-кладбищем. Со временем это кладбище растет. Пользовательских историй слишком много, чтобы следить за ними постоянно, поэтому оценки устаревают. Такой бэклог больше не помещается на один экран, и люди больше не возвращаются к нему, даже Product Owner. Это кладбище порождает нездоровое поведение внутри Scrum-команды. В поведении это проявляется по-разному: у команды возникает противоречивое представление о том, что они делают и зачем они это делают, а Product Owner тратит свое время на создание версии бэклога продукта в Power Point, чтобы донести до команды его текущий статус. В свою очередь стейкхолдеры создают и поддерживают свою собственную версию бэклога для дорожной карты продукта, и каждая команда говорит на своем языке, а конфликт возникает в тот момент, когда появляется понимание, что интерпретация бэклога продукта у этих команд разная. Этот антипаттерн, укрепившийся в отношениях между бизнесом и Scrum-командами, проявляется, когда бэклог превращается в заброшенное пространство небольших пользовательских историй, над которыми уже никто не будет работать и ценность которых ставится под сомнение.
Как воскресить бэклог продукта, чтобы он стал идеальным?
Итак, каким образом команда может получить из бэклога-кладбища идеальный бэклог продукта?
На что больше похож ваш бэклог: на идеал или на кладбище? Как бэклог продукта влияет на поведение команды и результаты? И что вы можете с этим сделать?
А если вы хотите разобраться в том, чем отличаются Project и Product, выяснить, как между ними распределяются обязанности и определить разницу в софт скиллах для этих ролей, записывайтесь на бесплатный урок по курсу.
Discovery бэклог: как не упустить важное
Всем привет! Меня зовут Юля, я отвечаю за развитие продукта Social Trading в Exness. Немного обо мне. Работаю в продуктовой разработке восемь лет в роли продакта. Начинала заниматься этим, когда эта роль в российских компаниях так даже и не называлась. Сейчас мы вместе с командой делаем продукт, который позволяет трейдерам с небольшим опытом инвестировать на финансовом рынке. Если кратко, суть в том, что эти трейдеры копируют понравившиеся стратегии более опытных трейдеров.
Давайте на примере нашего сервиса поговорим о том, откуда брать идеи для бэклога и как сделать его полезным и удобным инструментом для работы.
Итак, какая важная часть работы продакта? Конечно, ведение продуктового discovery бэклога. В discovery бэклог мы фиксируем и систематизируем все идеи и гипотезы по достижению продуктовых целей. Этот же бэклог есть источник для формирования delivery бэклога, то есть списка идей, которые мы передаем в разработку. Если задача delivery бэклога — сформулировать то, что несет максимальную ценность в данный момент, то задача discovery бэклога — фиксировать все, что может быть полезно сейчас или в будущем.
Тема поиска идей для продуктовой разработки крайне актуальна. Мы часто обсуждаем ее с продактами, которые работают в других компаниях. Создается впечатление, что источники идей сильно зависят от культуры компании, устоявшихся процессов или личных предпочтений продактов. По факту чаще используют ограниченное число источников, а другие просто не задействованы. Бывает, продукт пилится просто в соответствии с утвержденной стратегией, и то, как воспринимают его клиенты, с какими проблемами сталкиваются каждый день — никого не беспокоит. Или наоборот, продакты закапываются в цифры, днями и ночами подкручивают воронку и улучшают опыт клиентов, не внося по факту никаких значимых изменений в продукте и не запуская чего-то, что может дать реальный прорыв или конкурентное преимущество в будущем.
Также часто сталкиваюсь с тем, что продакты воспринимают определенные источники идей не как источники идей, а как раздражители и барьеры развития продукта. Особенно это касается сотрудничества с другими подразделениями компании: «Вот, пришли сейлзы, опять чего-то хотят, диктуют, что нам делать. Что они вообще понимают, я продакт, я вижу цифры, я знаю свой продукт лучше всех».
Но задача discovery бэклога — фиксировать все проблемы, идеи, гипотезы. И если используется только часть источников, то бэклог получается однобокий, а вслед за ним таким станет и продукт.
Теперь расскажу, какие источники используем мы. Итак, поехали.
Первый пункт плана — послушать клиента
Пожалуй, самый очевидный источник, но это не уменьшает его ценность.
Клиенты непрерывно делятся фидбеком: оставляют отзывы в сторах, комментарии в соцсетях и на форумах, пишут сообщения в службу поддержки. Может, проще оставить их без внимания, это ведь работа саппорта разбираться с обращениями клиентов? Или все-таки лучше «выжать» максимум из ситуации и взглянуть на это как на массовый, бесплатный канал получения идей в режиме 24х7? В Exness мы постоянно читаем, что пишут клиенты в сторах и в письмах в службу поддержки (стоим в копии переписки), имеем чат с саппортом и сразу фиксируем все идеи.
На а как получить фидбек клиентов по конкретному вопросу? Здесь помогут исследования — лично, по телефону или online; глубинное интервью, опрос, UX-тестирование. Все зависит от задачи и наличия времени. Исследование можно легко провести самому online: множество сервисов вам в помощь или же попросить саппорт, продажи. Последние с радостью примут предложение, ведь какой sales откажется от позитивного повода для контакта с клиентом?
Также у нас на постоянной основе запущено исследование NPS в приложении с полем для фидбека в свободной форме. Его обычно заполняют подробно те, кто ставит низкую оценку. Мы это понимаем, но в любом случае собираем там много полезной информации не только о том, чего именно хотят пользователи (многое из этого уже есть в бэклоге), но и о том, какому числу пользователей это актуально. Все это помогает при определении приоритетов.
Так, одним из самых популярных пожеланий инвесторов было добавление Stop Loss и Take Profit (автоматическое закрытие инвестиции при достижении определенной суммы). Мы запустили эту фичу в августе. Посмотрим, как отразится это на общем уровне NPS, и какое пожелание будет в топе в сентябре.
Там же запускаем быстрые опросы — инвестиционный профиль, предпочтения по рынкам и так далее.
Что еще? Ежемесячно проводим глубинные интервью с разными сегментами клиентов: пользователями, которые ушли в отток, самыми высокодоходными клиентами, инвесторами, которые являются одновременно и трейдерами, пользователями, которые перешли на шаг платежа, но не сделали его и так далее.
Интервью проводим по фреймворку Job to be done, он позволяет получить максимум инсайтов юзера. Каждый раз узнаем массу нового, так как продукт развивается, а клиенты все разные, и они также развиваются вместе с нами.
Яркий пример. Узнали, что многие новые пользователи делают депозит и сразу вывод для того, чтобы протестировать, как вывод работает. И если работает хорошо, они доверяют брокеру, принимают решение о сотрудничестве. У нас вывод делается полностью автоматически, средства поступают быстро (время зависит только от правил пополнения выбранного клиентом платежного средства), клиенты это видят, ценят и начинают с нами работать.
Данные не умеют говорить, но задают вопросы
У продуктов обычно существуют целевые метрики, по которым измеряется его успех. Если метрик нет, то лучше сделать так, чтобы они появились. Метрики и цели по ним часто являются результатом каскадирования метрик компании, измерителями достижения цели продукта (например, в виде OKR, Objectives and Key Results) или же синтезом этих двух вещей. Например, число активных пользователей, время, проводимое в приложении одним пользователем за период, доход на одного пользователя, NPS.
Так или иначе, есть метрики, есть целевые значения, которые мы хотим достичь к определенному времени, есть их фактическое состояние на сегодня. И для того, чтобы из состояния «факт» перейти в состояние «план», в продукте нужно что-то менять.
Чтобы понять, что менять, каждая метрика обычно раскладывается на метрики нижнего уровня (конверсия в регистрацию/ покупку/ оплату, повторные визиты, средний чек, отток), ведется трекинг каждой такой метрики, определяется то, какую из них нужно и можно улучшить, и формируются гипотезы по тому, какие фичи нужно сделать, чтобы этого достичь.
Сами по себе данные, конечно, не умеют говорить и никаких идей принести не могут. Они скорее поднимают вопросы, чем дают ответы. Но чем больше мы смотрим на цифры под разными углами, чем больше вопросов себе задаем, тем больше гипотез у нас появляется. Особенно если совместить этот пункт с другими.
Покажу на примере. Наша цель — в 5 раз увеличить число активных пользователей (активный пользователь имеет открытую инвестицию на 7 день после регистрации и позднее). Мы смотрим на конверсию скачивания в первую инвестицию, сравниваем с аналогичным показателем в другом продукте Exness (мобильное приложение для самостоятельного трейдинга). Видим, что там конверсия в полтора раза выше, хотя по идее наш продукт более простой и направленный на массового потребителя. Начинаем смотреть глубже: для разных стран, разных типов трафика — разница почти везде есть, особенно большая для рекламного трафика. Берем самую популярную страну и рекламный трафик, строим воронку по каждому шагу и видим, что самое большое отличие на шаге пополнения баланса. Встречаемся с коллегами, просим поделиться секретом успеха, и все оказывается просто. Все мы изначально внедрили стандартный процесс: клиент кликает в «Сделать депозит», заполняет анкету о себе, прикрепляет документы, потом выбирает платежное средство. Коллеги сделали A/B тест, где просто поменяли местами эти шаги и сначала дали выбрать платежное средство. Пользователь на первом шаге видит, что есть удобный для него способ пополнения (клиентам это очень важно, так как в разных странах распространены совершенно разные способы). И дальше он уже готов потратить время на заполнение анкетных данных. А/В тест показал свой эффект, коллеги раскатали на всех. Уже через неделю мы запустили аналогичный тест у себя, который также показал статистически значимый прирост в конверсии.
Конкуренты формируют ожидания, или куда движется рынок
Если ваши клиенты уже пользовались продуктами конкурентов, то у них уже есть ожидания на основании этого опыта. Если у конкурентов есть фичи, которые клиенты считают ценными, их отсутствие в вашем продукте вызовет разочарование, клиенты не начнут или перестанут пользоваться продуктом. Речь не идет о слепом копировании того, что есть у других (не все имеющееся там несет ценность для клиентов). Важно понимать «стандарт качества» рынка и соответствовать ему. Он постоянно меняется, поэтому рука должна быть на пульсе.
Пока мы смотрим на воронки, конверсии, отзывы клиентов, мы очень погружаемся в детали и можем пропустить глобальный тренд. Чтение исследований и обзоров рынка позволяет ненадолго вытащить голову из песка и взглянуть на происходящее немного со стороны. А также добавить в бэклог что-то, что уже происходит, но не лежит на поверхности.
А что в это время делают ведущие digital-сервисы?
Ведущие локальные и мировые digital-сервисы также формируют привычный клиентам опыт и ожидания, даже если работают на другом рынке. Если клиент смог оплатить в Интернет-магазине одежды покупку через Apple Pay, он захочет оплатить также и бронирование отеля. Ну и не зря эти ведущие сервисы — ведущие. У них можно черпать идеи по стандартным юзер-сценариям, таким как регистрация, онбординг, каталоги товаров/ услуг, платежные сервисы и так далее.
О чем могут рассказать коллеги
Коллеги также пользуются или могут пользоваться продуктом. Да, их вижен несколько искажен, а методички по маркетингу говорят никогда не тестить продукт на коллегах, но они также сталкиваются, как и клиенты, с проблемами в использовании, у них также есть ожидания от продукта. Это быстрый и доступный источник информации и идей.
В прошлом месяце мы вместе с коллегами, отвечающими за тренинги и качество, провели конкурс среди сотрудников. Сотрудники компании приняли участие в нем в качестве провайдеров торговых стратегий (130 человек выступили в этой роли) и в качестве инвесторов (250 человек выступили в этой роли). В течение двух недель одни трейдили, другие инвестировали в них. Сейчас мы подводим итоги, выявляем победителей и параллельно собираем фидбек. Мы получили десятки развернутых, подробных комментариев, и часть из них уже вошла в план четвертого квартала, часть будет сделана позднее.
Стратегия компании
У компании есть стратегия, она обычно формулируется как минимум на год и описывает то, где компания хочет оказаться к этому сроку. Это может быть выход на новые рынки, запуск новых направлений бизнеса, выход на новую клиентскую аудиторию и так далее. Продукт является частью бизнеса компании, а значит, должен поддерживать реализацию этой стратегии. Поэтому все, что нужно сделать в продукте для реализации стратегии — тоже часть бэклога. Помимо общей стратегии, в компании могут возникать отдельные стратегические инициативы. Это нечто менее глобальное и более краткосрочное, но также нуждается в поддержке продуктом.
А что за продукт мы вообще строим
Мы тратим много времени на цифры, клиентов и конкурентов. Конечно, идеи, которые мы там находим, ценные и важные, но их нужно было реализовать вчера. И если мы хотим быть не «как на рынке», а отличаться чем-то, нести уникальную ценность, если хотим вырасти в разы, то должны сделать что-то, чего еще никто не сделал, чего не просят клиенты, так как даже не догадываются, что так бывает. Описание этого содержит целевой вижен продукта. Каждый день появляются задачи по удержанию проваливающихся метрик, решению багов, доработок по пожеланиям клиентов, но вижен — это путеводная звезда, по направлению к которой нужно упорно идти.
Сотрудничество внутри компании
Продукт чаще всего не существует отдельно и сам по себе. Есть другие подразделения в компании, которые оказывают влияние на продукт и/ или зависят от него: поддержка, маркетинг, продажи, антифрод, финансы. У этих подразделений есть свои цели и свои проекты, для реализации которых нужны доработки в продукте. Часто вижу, что такие задачи воспринимаются продакт менеджерами негативно: «Вот снова пришли со своими идеями/ запросами». Да, это они авторы этих идей, но это не значит, что эти идеи бесполезные. Они могут принести в результате больше пользы продукту, чем ваши самые классные (потому что ваши) идеи.
В других подразделениях люди также изучают рынок, клиентов, конкурентов, но часто под несколько иным углом зрения, поэтому общение с ними, как с экспертами в их области, может дать очень много полезных знаний, идей и обогатить бэклог.
Продуктовой команде тоже есть, что добавить
Команда чаще всего источник идей по техническим улучшениям, и о том, что они важны, думаю, говорить не нужно. Но помимо этого у команды могут быть и продуктовые идеи, поэтому важно привлекать их к процессу генерации идей и бережно относиться к их фидбеку.
Подытожим
Вот такие источники мы используем в работе для ведения Discovery бэклога. Discovery бэклог — это место, где нет плохих или хороших идей, нет ваших идей и идей чужих. Задача продакта быть радаром, который собирает идеи на всех уровнях (клиенты, компания, рынок). Пусть в бэклоге будет все, что имеет отношение к целям продукта. И если бэклог правильно структурирован, все задачи, проблемы, гипотезы четко описаны и систематизированы, то при формировании бэклога разработки, ничего не будет упущено, а шанс того, что в разработку попадет то, что несет наибольшую ценность — выше.
Ну и небольшие заметки по тому, как фиксировать идеи наилучшим образом:
Сегодня я остановилась на источниках вдохновения, но понятно, что не менее интересна и тема приоритизации идей в бэклоге. Как решить, что реализовывать через год, а что включить в ближайший спринт? Ответ на этот вопрос очень сильно зависит от стадии жизненного цикла продукта, разрыва между план-фактом метрик, целей, которые стоят перед продуктом, ситуации на рынке, совершенства технической составляющей и многих других факторов.
Если эта тема вам интересна, откликается, то об этом можно будет поговорить в отдельной статье. Желаю всем найти свои источники и сделать продуктовую разработку максимально эффективной!