Джефф Паттон рассказывает о роли Product Owner-а. Интервью.
| March 19, 2012 | Posted by admin under Методологии, Практики, Статьи |
Интервью с Джеффом Паттоном (Jeff Patton) провел Кевин Бреннан (Kevin Brennan) , 9 декабря 2011г
Записано на конференции Agile2011 .
http://www.infoq.com/interviews/jeff-patton-the-product-owners-world
Резюме
В этом интервью Джефф Паттон обсуждает роль Product Owner-а и указывает на то, что Agile никогда не был слишком сосредоточен на заказчике. Хотя Agile разработка выделяется своей “поставкой”, она все еще борется за “выявление” (т.е. определение того, что действительно нужно заказчику). Также обсуждаются методики, такие как Lean Startup и карты историй (story map), и важность определения бизнес ценности (business value) в контексте Agile.
Биография
Джефф Паттон занимается разработкой ПО на протяжении последних 12 лет, для самых разнообразных проектов. Джефф ориентируется на Agile подходы, с тех пор как начал работать в XP команде в 2000 году. В настоящее время он является независимым консультантом, обозревателем StickyMinds.com и IEEE Software. Он стал обладателем премии Гордона Паска за 2007год (Agile Alliance) за вклад в Agile разработку.
О конференции
Agile Alliance организовал серию конференций по Agile. Эти конференции собрали вместе ключевых людей мира Agile, чтобы обсудить методы и технологии,отношения и политики, исследования и опыт, а также менеджмент и разработку на основе Agile.
Привет, я Кевин Бреннан, редактор InfoQ. Я здесь сегодня вместе с Джеффом Паттоном, одним из старейших адептов Agile. Он интересуется темой product owner-ов, созданием историй и бизнес ценностьтю в контексте Agile. Привет, Джефф, спасибо, что пришел сегодня. Может ты расскажешь нам, над чем ты сейчас работаешь – то, что было бы интересно Agile сообществу?
Сейчас я размышляю над тем, что же именно означает Agile , или что он должен означать. Как я уже говорил тебе раньше, я проснулся сегодня утром, подошел к шкафу и, поскольку мы на конференции по Agile, я нашел свою старую футболку с надписью “XP Universe”, которая у меня появилась в июле 2001 года, на первой конференции по XP. Это было в июле, а в феврале был введен термин “Agile”. Прошло уже десять лет, и я много думаю о том, что же сейчас означает Agile и что Agile означал тогда. Я пришел из мира разработки коробочного софта, в котором успешная разработка означала, что созданный вами продукт стал успешным на рынке. Сейчас, десятью годами позже, я думаю, что для большого числа людей успешная разработка означает, что продукт разработан вовремя и в рамках бюджета. Для меня этого было недостаточно в девяностых, и мне понадобилось почти десять лет, чтобы понять, что успех продукта на рынке – это не то, о чем все думают. И сейчас, глядя на многих людей вовлеченных в Agile разработку, я ловлю себя на такой мысли: “Думаете ли вы об Agile разработке или о чем-то другом?”
В твоем tweeter-е я прочитал, что для тебя Lean Startup это то, как ты себе представлял Agile. Можешь нам немного рассказать, почему ты так думаешь, и что принесет с собой Lean Startup?
Lean Startup появился из книги по управлению продуктами (product management), в контексте стартапов, книга называлась “Четыре шага к Прозрению” (“Four Steps To Epiphany”). В этой книге много говорилось о цикле customer development-а. Идея заключается в том, что перед разработкой продукта, нам нужно создать рынок для этого продукта, или потребителей для продукта. И чтобы понять этих потребителей, необходимо действовать: у нас есть идеи, мы претворяем их в жизнь, строим что-то, не очень большое, изучаем результат и корректируем наши идеи. Цикл, который управляет Lean Startup-ом, основывается на потребителях и пользователях, он строится на обучении, на том, насколько быстро мы учимся. Поведение, которое вытекает из Lean Startup это… Я был на первой конференции по Lean Startup, где выступал Кент Бэк (Kent Beck). Кент изменил Agile manifesto и добавил дополнительные утверждения. На конференции по Lean Startup люди, не сконцентрированные на теме пользователя и пользовательского опыта, с гордостью говорили о том, со сколькими пользователями и заказчиками они пообщались за неделю, как часто они показывают ПО заказчикам и пользователям. Здесь на конференции по Agile, я с трудом мог убедить людей делать это.
Они счастливы показать демо всем заинтересованным лицам раз в пару недель, но очень мало людей с гордостью говорили о том, насколько ценны отзывы, которые они получили от заказчиков. Кажестся в твиттере я написал, что единственная вещь, которая мне не понравилась в Lean Startup, это название. Эта методика подходит не только для стартапов. Многие крупные компании, с которыми я долгое время работал, должны вести себя во многом как стартапы. Это не просто Lean, это разумный подход.
У тебя есть ощущение, что Agile теряет фокус на заказчика? И что на твой взгляд можно с этим сделать?
Честно говоря, я не думаю, что Agile когда-либо фокусировался на заказчика. Когда был впервые написан манифест, и мы начали работать с XP, слово заказчик часто использовалось, но обычно так называли человека, который находился по другую сторону от разработчика, что часто означало человека из бизнеса, бизнес аналитика и редко конечного пользователя. Я пришел из организации, которая строит ПО, используемое людьми за пределами нашего здания. Мы отлично знали, что существует разница между заказчиками и конечными пользователями: заказчики покупают, а пользователи используют. Мы строили ПО для людей с производства, мы знали, что покупатели – это не пользователи. Как сказал Lou Coleman, ” Я буду использовать слова “пользователи” и “те, кто выбирает” (users and choosers)”. Люди, которые выбирают ПО, не используют его ежедневно. Мир гораздо сложнее, чем мы думаем.
Старая концепция в XP,о том что есть заказчик, единственный заказчик и/или заказчик, говорящий в один голос , и новая концепция в Scrum , что есть один product owner… Ни одна из них не имеет реального отношения к тому, что продукт выходит на рынок и предстает перед публикой. Поэтому ответ на вопрос “Обеспокоен ли я тем, что Agile не фокусируется на заказчика” – я не уверен, что он когда-либо фокусировался на этом.
Тогда следующий вопрос, как сделать так, чтобы это все же началось?
Интервью превращается в интересное рассуждение. Я не уверен, что это нужно начинать. Я не уверен в том, нужно ли это. Если ты помнишь в 2000 году, когда я начал заниматься XP (я начал работать в компании, которая применяла XP) , я как бы влюбился в эти инженерные практики, но там не было таких типов практик, которые я использовал. Многие вещи, которые я делал в 2000, 2001 я считаю неправильными, и я прошу прощения у всех своих сотрудников, но у меня осталось ощущение, что что-то фундаментально нарушено в XP, оно не работало. Человека, который помогал мне с XP, звали Rob Me. Rob владеет компанией Pipital. Это крутая компания , которая делает отличные вещи, но Rob говорил в то время, что это не XP, с этими практиками там нечего делать. Agile разработка кажется мне очень сфокусированной на поставке. Есть четкое взаимодействие между людьми, которым нужно готовое ПО и людьми, которые его делают и фокусировка на том, чтобы это взаимодействие было эффективным, и разработка шла эффективно и инкрементально, так чтобы мы могли видеть это. Мы получили прозрачность. Agile разработка дает действительно хорошее поведение, но Agile разработка – это о быстрой эффективной поставке.
Agile разработка – это не о работе, которую мы делаем, чтобы выяснить, поставляем ли мы правильную вещь. Agile разработка обращена к человеку, который просит что-то, получает это и получает это достаточно часто, чтобы поразмышлять над этим, и сделать что-то, чтобы понять, правильная ли это вещь. Agile разработка не направлена на помощь этому человеку, не дает ему какую-то специальную тактику, чтобы определить, правильная ли это вещь. Я понятно объясняю?
Я думаю, да. Нужно ли меняться бизнесу, который использует Agile , чтобы получить все преимущества Agile ?
Да, им многое нужно менять. Есть старое соглашение, и ты услышишь много разговоров. Мы говорили о Lean Startup, ты вскоре услышишь это для Lean Startup. Старое соглашение заключается в следующем: владелец, основатель, заинтересованное лицо от бизнеса находит отличную идею, совместно с несколькими людьми разрабатывает эту идею в Agile контексте, чтобы построить баклог. Мы строим баклог и начинаем итеративно и инкрементально строить систему. Мы смотрим на эту систему изнутри. Кто-то в роли product owner-а, или заказчики, или стейкхолдеры смотрят на этот продукт, мы можем показывать или не показывать его людям, но в конце звенит звонок, это релиз, и это время, когда мы учимся. Очень часто то, что мы построили – хотя и соответствует тому, что мы хотели сделать – не является тем, что нам действительно нужно. И мы узнаем об этом слишком поздно. Для меня Agile разработка – это процесс получения знаний, а не процесс поставки. И я хочу использовать эти циклы для того, чтобы обучаться настолько быстро, насколько возможно. Ждать несколько месяцев цикла разработки, чтобы получить новые знания – это слишком долго.
Таким образом с точки зрения бизнеса, для реального использования Agile, организация должна начать по новому думать и планировать свои продукты. Им нужно планировать обучение, им нужно планировать действия в случае провала. Никто не хочет потерпеть неудачу, но необходимо осознанно представлять продукты людям, чтобы можно было получить новые знания о том, подходят ли эти продукты людям. Это понятно?
Это подводит нас к другому вопросу. Вы проводите много работы по теме “product owner”, работаете с product owner-ами, чтобы помочь им стать более эффективными. Какие методики, подходы могут использовать люди, чтобы делать то, о чем вы сейчас говорили, чтобы быть эффективными product owner-ами и чтобы быть реальными представителями реальных заказчиков, а не внутренними заказчиками?
Что интересно, я встречался с тобой несколько раз, мы говорили об этом, ты уже много времени погружен в тему Agile и мы сейчас на Agile конференции, и есть миллион техник в Agile сообществе, которые поддерживают поставку. Есть множество методик, которые поддерживают..комплиментарный термин для поставки, который я использую, – это выявление (discovery) – т.е. работа, которую мы делаем, чтобы понять, что же нам нужно поставить. Есть работы по выявлению и по поставке. Многие люди используют термин выявление. Разговаривая с моим другом Дэвидом Хуссманом (David Hussmann), мы решили, что эти термины хорошо дополняют друг друга. Product owner-ы учатся выявлять и получать знания о заказчике. Я не буду перечислять все методы, но фундаментальная вещь, которую должен знать product owner – это то, что он отвечает за последствия. Я уже говорил об этом, и полностью это звучит так: ” Результат (output) – это то, что мы построили, последствия (outcome) – это то, что происходит после этого”. Я говорю людям, ваша роль в IT – не строить ПО, ваша роль – менять мир.
Я делаю длинную паузу, потому что это звучит возвышенно. Но дело в том, что мы действительно строим ПО, чтобы что-то исправить, изменить мир к лучшему. Индикатором того, работает ли ваше ПО, является не то, что оно сдано вовремя и содержит все запрошенные заказчиком фичи, а то, что люди используют эти фичи и довольны результатом. За это отвечают product owner-ы. И я думаю, твой первоначальный вопрос: “Как product owner-у стать лучшим представителем заказчика?”. Есть много разных методик и тактик, и здесь можно применить Lean. Существует Lean концепция, которая говорит о присутствии и участии. Идея гемба – это иди и будь на месте производства.
Если вы product owner, вы представляете своих заказчиков, никто не строит ПО для “кого-то там”. Очень редко бывает так, что вы являетесь представителем только одного заказчика или одного конечного пользователя. Вам нужно прийти прийти к заказчикам, а не приводить их к себе. Идите туда, где они работают, на Гемба, и смотрите, что они делают. Я общался со знакомым по имени Дон, с которым мы работали много лет назад. Вместе мы изучили много методов работы product owner-а. Он стал product manager-ом в компании, и очень успешен. Я задал ему тот же вопрос: “В чем твой секрет? Какой совет ты дал бы product manager-у, чтобы он стал таким же успешным, как ты?” Он сказал “Иди на производство”. Вы не можете сымитировать соучастие, вы не можете собрать достаточно требований, вам нужно искренне проявить соучастие. Вам нужно действительно знать людей, с которыми вы работаете, видеть их и уметь смотреть на вещи с их точки зрения.
Одна из вещей, которые сделали вас известным, это карты историй. Я знаю, что это немного меняет направление нашего разговора, но все же делаю это. Как карты историй помогают product owner-у получить понимание или донести понимание до команды?
Я много работал с историями, я начинал с XP в 2000, и работал с историями тех дней, с user story и историями из Scrum. И хотя многие считают, что истории пришли из Scrum, на самом деле они из XP. Они используются уже давно. Это не единственный способ работы с требованиями, но идея действительно очень проста. Я собираюсь перейти к картам историй через минуту. Я отдаю должное Кенту Бэку (Kent Beck) в изобретении историй, но хочу сказать, что над этим работало много людей. Вот вопрос, от которого я уже устал: “Как я пишу хорошие истории?”. Дело не в том, чтобы писать хорошие истории, они потому и называются историями, что предполагают рассказ. Не важно, что вы пишете на карточке, важно то, что вы говорите об этом.
Сначала я пишу что-то, некоторый набор предложений. Мы может собрать набор карточек и сказать: “Важнее всего поговорить об этой карточке… теперь давайте поговорим.” Вы рассказываете мне историю о том, что вы хотите, мы приходим к некоторому общему пониманию, или к общей модели того, что нужно построить. Когда мы делаем это, у нас появляется набор записей о том, что нужно построить, у нас появляется общее представление о том, что нужно построить, и мы можем двигаться дальше. Не так важна записанная история, важно ее развитие, разговор и обсуждение. Поэтому, оригинальный смысл названия “история” – это “Я хочу услышать твою историю”. Ок, теперь мы переходим к разработке того, что задумали. Поэтому я говорю, что Agile разработка построена на отношениях между человеком, который хочет создать что-то и человеком, который делает это. Product owner должен понять, какая система нужна, но он не знает точно, что нужно строить. Это сложно, и никто не строит системы для себя.
Я бы сказал, что никто в роли Agile product owner-а не строит систему , единственным пользователем которой будет он сам. Product owner – это всегда представитель группы людей, и поэтому ему надо научиться понимать их. Карта истории – это простая концепция. Это карта, потому что у нее есть долгота и широта. Ось, которая идет слева направо – это большая история, поток, рабочий поток, это шаги, которые предпринимает человек, чтобы сделать что-то с помощью системы. Это опыт работы. Сверху вниз – это декомпозиция для построения системы. Когда я говорю с кем-то перед картой истории, я могу использовать термины производства и говорить о том, что делают люди в процессе работы, а потом я могу перейти к разговору о том, что нужно построить и в каком порядке. Т.е. слева направо идет описание с точки зрения пользователя, сверху вниз – шаги построения системы, в порядке приоритета.
После разговора с другом, который живет рядом со мной, Алистар Коберн придумал название карта истории (story map), это вещь, которой я давно уже занимаюсь, и это долгая история, как я к этому пришел. Я адаптировал материал, который изучил у Larry Constantine и Lucy Lockwood. Мне казалось, что я очень умнО разработал эту простую вариацию того, что они делали с анализом задач (task analysis) и моделированием задач (task modeling). У меня была эта простая квадратная форма и я чувствовал себя очень умным, пока не начал сталкиваться с другими людьми, не знакомыми со мной, которые пришли к той же самой форме и к той же структуре. Вот какое определение шаблона (pattern) я услышал у Линды Райзин (Linda Rising): если вы говорите людям о отличной идее и они отвечают “О, это прекрасная идея”, то это не шаблон, но если вам отвечают “Да, мы делаем тоже что-то подобное”, то это шаблон. И хотя этот удачный термин “карта истории” пришел со мной, этим занималось уже много людей, т.е . это действительно шаблон. Это простой шаблон, который помогает нам смотреть на продукт в целом, показывать, что мы узнали, что мы поняли о пользователях, и с тактической точки зрения, в плане последовательности разработки.
Мог бы ты рассказать о той ситуации, которая заставила тебя использовать истории и разработать шаблон?Может быть о конкретном проекте, где ты впервые это использовал? Что привело тебя к этому?
Странная вещь заключается в том, что я никогда не думал использовать user story в том виде, в каком они были. У меня не было никакой мотивации использовать их…. Вернемся немного назад. Чем я занимался в 90х… Я работал на компанию, которая сначала была меньше, а потом немного выросла, и компания была достаточно умной или наоборот, достаточно глупой, чтобы разрешать разработчикам общаться напрямую с заказчиками. Нашими заказчиками были крупные сетевые ритейлеры, т.е. они находились вне нашего здания. Когда я обсуждал какую-то фичу с кем-то из заказчиком, я имел в виду, что его компания большая, и мнения могут быть разными. Я также имел в виду, что фича используется и другими сетевыми ритейлерами, и я отвечаю за нее. Поэтому я никогда не принимал слова одного из моих заказчиков как требование. Я знал, что я ответственен, должен понимать моих заказчиков, и то, что им действительно нужно.
Когда я натолкнулся на идею user story , я стал рассматривать их как основу, фокус разговора, общую мантру и механизм, который приводит к разработке фичи. Мне это показалось отличной идеей. Мне нужно понимать заказчиков, и то, что они хотят. Я подумал о том, чтобы упорядочить эти user story в некоторой форме, что помогло бы мне объяснить, что происходит у заказчика. Я достаточно ленив для того. чтобы писать use case-ы и рисовать модели потоков, а также другие типы моделей, которые позволяют понять, что делают пользователи, показывать это другим людям и извлекать из этого user story. Я ленив и просто хочу построить модель из историй. И это всё. Я думаю, первый раз я использовал это, когда работал со start up-ом в Сан Франциско, где я изучал XP и влюбился в Agile и XP, а также действительно научился сбегать, потому что компания не сделала успешный продукт. Продукт не пошел на рынке, и не были сделаны многие вещи, которые я думаю, нужно было сделать.
Я вернулся к product manager-ству и управлению командами в организации, из которой ушел, и конечно я собирался использовать Agile , и в первом же проекте я начал строить карты историй. Это была очевидная вещь.
Итак, чтобы перейти к другой теме, которую мы обсуждали. Недавно ты был на десятилетии в Сноуберде (Snowbird) и там обсуждался вопрос про очевидные вопросы в Agile, на которые никто не обращает внимания (elephants in the room).
Ты читал что-нибудь об этом?
Да.Правда, я не знаю насчет нашей аудитории.
Мне повезло, что я живу в Солт Лейк, там где был подписан манифест. Так что я должен был быть на этом мероприятии, это было своего рода воссоединение после десяти лет. Там были те, кто подписывал манифест, и еще несколько властителей дум. На том собрании, где был подписан манифест, находилось семнадцать человек, а сейчас нас был тридцать с чем-то. Отчасти потому, что я там живу и никому не хотелось оставить меня без приглашения, я должен был там быть. Во вводной части Дэвид Андерс (David Anders) сказал о том, что есть много очевидных вопросов, на которые никто не обращает внимания, много вещей, о которых говорится, но никто не вникает в детали. В качестве примера он привел ценность для бизнеса (business value). Этот разговор прошел, но потом на большом перерыве вечером я сидел рядом с Дэвидом и сказал ему: “Дэвид, мне хотелось бы продолжить разговор про эти очевидные вопросы, давай начнем с ценности для бизнеса. Из этого возникло обсуждение, которое продолжалось несколько часов, и мы составили длинный список проблем.
Ценность для бизнеса – важная тема, мы возвращаемся к ней снова и снова. Ты спрашивал, чему я учу product owner-ов. Одна из вещей, которым я учу product owner-ов – вам не нужно говорить это (“ценность для бизнеса”). Вы можете говорить про ценность для бизнеса, но это ваша задача определить, что ценно и что нет. Нельзя сказать – ценность для бизнеса. Это расплывчато. Это неоднозначно. Вы должны быть способны объяснить людям, что ценно и что нет. Итак, давайте поговорим об очевидных проблемах. Ценность для бизнеса или то, что ценно – мы стремимся к позитивному результату, результату построения системы. Для нас важно не ПО, как таковое, а те преимущества, которые мы получаем после его установки. Я работаю с разными компаниями. В основном меня зовут продуктовые компании, которые используют Agile разработку и понимают, что Agile хорош с точки зрения поставки ПО, но есть пробел между всем тем, что нужно построить и тем, что происходит вне спринта – своего рода белое пятно.
Мы много говорим о том, что нужно ориентироваться на результат, и более зрелые компании понимают, что нет простой взаимосвязи между размером построенного ПО и размером полученной пользы. Результаты всегда ориентировочные. Я могу создать небольшое по размеру ПО – и получить большую пользу, я могу создать крупную систему – и получить небольшую пользу или не получить ее совсем или даже понести убытки. ПО дает ориентировочное представление о ценности. Каждая часть построенного нами ПО – это некоторая гипотеза о том, что мы можем поставить на рынок, что мы приносим в мир, чтобы сделать его лучше. Это и есть ценность. Иногда меня раздражает слишком упрощенное обсуждение ценности для бизнеса в Agile сообществе. Это идеи о том, что мы можем отметить ценность для бизнеса на карточке истории, приоритезировать на этой основе, о том, что мы знаем, какой она будет. Зрелые компании, с которыми я работаю, знают, что нет прямой взаимосвязи между размером поставляемого ПО и объемом полученной пользы. Я сталкивался с компаниями, которые были очень недовольны низкой продуктивностью, потому что они не видели большой пользы. Но на самом деле они делали так много, как только могли, и были даже более эффективными чем раньше, но то, что они создавали не приносило прибыль на рынке, поэтому они стали уделять большее внимание результатам.
Настоящая загадка в том, что нет линейной или простой взаимосвязи между тем, сколько мы построили, и сколько получили. Это действительно очень относительно. Мы приходим к тому, что мы всегда знали. Сложно построить систему, очень сложно добиться хорошего качества и супер сложно принимать решения о том, что мы должны построить.
