2013-03-28: Как появляется PBL - Jeff Patton на AgileDays
Вчера и сегодня был на тренинге Джефа Паттона. Он рассказывал о том, откуда и каким образом получается самый важный артефакт SCRUM - Product Backlog, который является источником для всего остального. В описаниях процесса SCRUM об этом говорят реально мало, хотя практики известны. Джеф представил цельную конструкцию подходов к формированию продукта и его релизов, с фокусами ответственности и особым упором ценность продукта и user experience.
Хотя практические занятия были ориентированны именно на создание нового продукта, процесс и практики могут использоваться и при развитии продукта. Они сработают не только в продуктовой, но и в заказной и inhouse разработке - это я уже утверждаю из своего опыта. А еще - ряд из них, такие как сегментация и персонификация пользователей - может быть использована и при проектировании процессов разработки в компании.
А еще тренинг включал в себя обучение эффективным формам коллективной работы - collaboration. И, как сказал Джеф, "Collaboration - это не разговоры и обсуждения. Это - совместная работа, и желательно - молча."
Так что, хотя называется тренинг "Создание продуктов, которые полюбят ваши клиенты: Сертифицированный курс Product Owner", реально это - авторский тренинг, прочитанный звездой, как и тренинг Книберга два года назад. И я хочу сказать организаторам конференции спасибо за такие тренинги.
А я дальше не поленюсь и кратко раскрою содержание тренинга. К сожалению, кусок второго дня я пропустил, так что есть лакуны. Да. часть про SCRUM как сбалансированный процесс и agile как систему ценностей я опущу, потому что полагаю ее знакомой. Она не заняла много времени, но задала контекст для дальнейшего.
Замечу также, что изложение шло не с начала процесса и до конца, а от простого - к сложному. А наиболее сложной является формирование механизмов концептуальной части продукта - и именно они были ближе к концу тренинга, хотя при конструировании находятся ближе к началу процесса.
Содержание
Ведение тренинга
Рассказывая о тренинге, хочу начать со способа его ведения. Она - понравилась. И сильно отличается от того, что я видел ранее. Собственно, это - один из факторов, отличающих профессионала, Книберг на тренинге замечательно работал с карточками.
Джеф одновременно с рассказам он пишет основные положения, рисует небольшие картинки. Все это происходит на столе, на который направлена web-камера. Иногда используется заготовка - предложение заранее написано на стикере, который приклеивается, но чаще это происходит в момент демонстрации, и тоже с использованием стикеров, которые меняют рисунок. А еще сами рисунки меняются. Например, нарисовав стандартный SCRUM-процесс, Джеф потом раскрывает часть формирования PBL на отдельном рисунке, после чего отрывает ранее нарисованную часть от схемы общего процесса, заменяя новой. И так же - с выпуском релиза. И этот интерактив очень сильно способствует усвоению. На фото смонтировано то. что получилось.
Участие в тренинге - сильно форматировано. В самом начале, показывая коллективную работу, Джеф попросил каждого участника сформировать ожидания от тренинга. И в форме вызовов, которые сейчас стоят перед ним и в форме изменений через три месяца. Затем - на каждом столе участники провели группировку подобного, озаглавили группу, проголосовали за важные. Потом - то, что набрало больше голосов каждый стол озвучил Джефу, а он - зафиксировал. Увы, это не превратилось в разбор кейсов (у Книберга - превратилось), но все равно, не прошло просто так. Во-первых, сформулировав и сфокусировавшись на своих целях, участник воспринимает материал именно под этим углом. Во-вторых, на второй день проблемы были вывешены на больших плакатах, а участникам - было предложено пометить свое отношения - возможно, некоторые из них знают решения. И далее можно было уже обменяться опытом и знаниями.
Надо отметить, что выделение проблем, как и многое другое в ходе тренинга, было проделано достаточно быстро и без лишних обсуждений, эффективно. Сначала проблемы формулировались на карточках, молча. Потом - кратко рассказывались каждым. Затем - группировка, опять молча - любой берет и перекладывает карточки к группе, если другой не согласен - перекладывает по-другому, и только если это первому кажется неверным - могут быть обсуждения. Это как раз то, что относится к обучению collaboration без излишних обсуждений. Фото справа - то, что осталось при объяснении этой техники в несколько приемов.
Было также несколько показано техник работы малыми группами с последующим представлением и передачей (share) результатов остальным: от пар к группам и от групп к большим группам. Не как отдельные обозначенные техники, а просто в практической работе, участники этому учились через применение. Это, конечно, отличается от специального обучения техникам, когда ты представляешь еще их уместность и границы эффективного применения, но все равно - крайне полезно. Дальше можно пробовать, когда они кажутся подходящими.
Как появляется Product Backlog
Как известно, одной из эффективных техник наполнения Product Backlog являются user story. Но детали эффективного применения этой техники - известны гораздо менее.
User Story содержит три компоненты:
- Who - кто действует
- What - что он делает
- Why - зачем он это делает, какой value он от этого получает.
Часть Why - ключевая, хотя на практике часто выдается формально.
В эффективном формировании user story участвует триада, и каждый из участников имеет свой круг ответственности.
- Product Owner. Он отвечает за business value истории
- Developer. Он отвечает за реализуемость истории, чтобы она была feasible.
- И специалист по User Experience. Он отвечает, что история будет usable для пользователей.
Эта триада образует Product Discovery Team, которая формирует продукт: planing, facilitating and carring out discovery in parallel with delivery.
А кто - пользователи
Для качественного историй необходимо представление о пользователях. Оно формируется через цикл research - segmentation - personalization. И дальше работа идет с персонами, которые олицетворены и характеризованы.
Важным этапом этого процесса является выделение некоторого набора дихотомий, которые характеризуют поведение персон относительно исследуемого продукта. Например, в примере с продуктом для поиска фильмов, это смотрит ли он дома или в кино, смотрит для себя или активно обсуждает с друзьями, один или с компанией и так далее. Приемом тут является выделение именно дихотомий со шкалой, на которой конкретный персонаж позиционирован, а далее каждый из них получает некоторый профиль.
Каждая история обычно ориентирована на определенное поведение персонажа. Поэтому, имея профили, мы можем понять, какими историями кто будет пользоваться. Story map.
Надо отметить, что аналогичные приемы очень полезны и в enterprise-разработке. Это только кажется, что там о пользователях есть хорошее представление, и можно легко написать истории об их действиях. Потому что существенная часть историй вырождается в конструкцию "ищет в списке нужные документы, и внимательно на них смотрит, иногда что-то делая с некоторыми", и вот какие - нужные - остается нераскрытым. А ведь они должны быстро и удобно их найти из тысяч документов. А должность формально может быть одна и та же "операционист".
Отмечу, что цикл research - segmentation - personalization стоит применять не только к пользователям вашего продукта, но и конструируя процессы разработки в вашей компании. Составьте портреты типичных разработчиков, дизайнеров или руководителей - скорее всего, получился более одного сегмента на каждую занимаемую должность, а ведь именно они - пользователи процесса.
Как формируем релизы
Понимание пользователей дает возможность оценить userstory с их точки зрения. А дальше - есть правило трех релизов:
- делаем счастливыми целевую группу пользователей
- делаем совсем счастливыми целевую группу пользователей, и расширяем круг пользователей
- собираем оставшихся пользователей
Соответственно, в первый релиз включаются именно те истории, которые делают целевую группу пользователей счастливыми. А остальные истории - только если функционирование продукта без них невозможно, например, авторизация.
И это обеспечивает цельность релиза. А приоритеты - становятся не важны, надо просто идти по сценарию сквозного использования, обеспечивая потенциально поставляемый продукт в конце итерации. Он потенциально поставляемый, но не нужный - потому что мир не изменит. Хотя замкнутый функционал - реализует, этот подход - сохраняется.
А ключевой вопрос для релизов - целевая группа пользователей. Ее надлежит выделить, на основании нашего исследования пользователей. Целевая группа - это те пользователи, которые наиболее полезны для старта нашего продукта и именно на них должен быть ориентирован первый релиз, при котором создается Minimum Viable Product. И тут мы вплотную подходим к вопросу как мы формируем продукт.
Как формируем продукт
Основой любого продукта является идея изменения мира. Именно так, наш бизнес - не производство software, а изменение мира с его помощью. Мы придумываем идею такого изменения - с помощью нашего софта. Софт - он дает возможность (opportunity) такого изменения.
И уже из этого возникает целевая группа пользователей - те, кого изменение сделает счастливым, и те, кто помогут нам расширить круг лиц, вовлеченных в изменение. Таким образом, планируя релизы - мы рисуем roadmap изменения мира. И именно под этим углом следует оценивать результат работы - что изменилось в мире, соответствует ли это нашим планам и предположениям. И корректировать их.
Если таким образом смотреть, то производство продукта имеет output - наш продукт, и outcome - самые изменения мира. Задача - максимальный outcome при минимальном output. Хотя у программистов часто ровно наоборот: разработки много, а результат их применения - совсем невелик.
User Experience
Если мы смотрим на продукт как средство изменения мира, то User Experience определяет - будет ли мир изменен. В этой части основой изложения было конструирование интерфейсов, но реально здесь играют функциональные возможности, которые дает продукт. И с этой точки зрения техники подходят и для enterprise-разработки.
Для проектирования этого - нужен design thinking process, это способ организации мышления.
Если говорить о проектировании интерфейса, то здесь три уровня.
- utility - interaction designer - делать что надо
- usability - делать удобно
- эстетика - выглядеть красиво
Практически же часто начинают с эстетики, хотя она - лишь окончательная отделка. А уж совсем задача - забыть об utility и в результате - удобно делать через красивые интерфейсы вовсе не то, что нужно пользователю.
А для представления - стоит рисовать скетчи...
И заключение
Как и во всяком процессе, он - циклический и требует оценки и улучшения. А оценку - надо давать на основе изменений мира, достигнутых или нет.
Frame Solution
- Emphasize Problem
- Research
- Empaty
- Story map
- Journey maps describe the world today
- Focus
- Idea
- sketch
- UI
- prototype & test
- build
А остальное - техники. Их много, они - важны. Особенно - визуализация и коммуникация, и их в тренинге было много. Но все же это - техники.
[ Хронологический вид ]Комментарии
Тренинг не записывали, но кусочки техники ведения видны на видео доклада на сайте конференции или на youtube на 11 минуте (и на других тоже), а в начале доклада видна камера, подключенная к компу. В презентации кусочки 9-12 слайды, 88-91 слайды и еще разбросано внутри
Войдите, чтобы комментировать.