Как Spotify создает продукты — пример ряда успешных массовых продуктов, созданных при участии нашего коллеги Хенрика Книберга по схожему процессу.
О Product Discovery Team узнала от Джефа Паттона, Каган тоже об этом говорит, уж не знаю кто из них первый начал :) Статистики у меня нет, поскольку не ею я руководствуюсь, при выборе инструментов, которые мне кажутся полезными.
Руководствуюсь тем, что: 1) пробую и наблюдаю разницу, 2) интересуюсь опытом применения у своих западных коллег, поскольку его «там» сильно больше
Думаю, вы говорите конкретно о скрам? На мелких проектах лучше работает канбан (чуть выше об этом писала). Визуализация потока работ, фокус на ценности работы, уход от детальной заготовленной наперед спецификации — будут оправданы.
Я ждала конкретного примера, спасибо. В описанном вами случае прироста производительности не будет.
В таком проекте, я бы порекомендовала использовать Kanban, как средство визуализации потока работ. Смотрела бы какая фаза является узким местом, и как можно увеличить ее пропускную способность. Для совмещения скрам и канбан в процессе можно проводить сессии регулярного планирования, скажем раз в неделю или в две. C такой же частотой — демонстрацию (формальную приемку работ) и ретроспективу (обсуждение и адаптация процесса).
При этом демонстрации могут быть не синхронизированы с деплойментом на продакшен. Если вы можете работать в режиме непрерывной поставки, то ваша демо может быть уже на рабочем продукте. Для чего в таком случае нужна демонстрация? Что бы получить понимание того, насколько доволен заказчик (Владелец Продукта), как меняется продуктивность команды (для этого можно использовать артефакт BurnUp Chart и метрику Velocity), сколько ресурсов отнимает саппорт (если он есть). Такая формальная оценка прироста продукта может быть полезной для оценки процесса и его обсуждению на ретроспективе. Оценивать ли работу и работать ли формальными итерациями — сугубо контекстуальный вопрос.
В команде из двух человек нет потребности в формальном скрам-мастере, но стоит обучить обоих участников, что бы их понимание гибкой разработки было общим. В такой команде нет необходимости в выделенных 15-минутках, но стоит обратить внимание на распределение задач командой и сделать процесс планирования и принятия ответственности максимально общим — тогда им будет о чем говорить по мере необходимости.
Отмечу, что такая команда является крайне слабой системой просто в силу своей конструкции. Я часто вижу две крайности в командах из двух человек: либо они так «дружат», что у формируется слабое разнообразие мнений, групповое мышление (как негативный паттерн) и склонность избегать конфликтов, даже если партнер не прав, или откровенно лажает в работе. Либо наоборот — неприятие партнера мешает воспринимать его здравые мысли, личный конфликт сводит на нет любой процесс. В такой системе нужен еще хотя бы один — балансирующий элемент. Кто-то, кто может ее уравновесить в случае перекосов в одну или другую сторону.
Чуть выше ссылка на MVP / MDP / VCP. Для публичных релизов MVP, как правило, не достаточно. Но для тестирования в закрытой бете — вполне. Вот еще одна интересная статья о том, как Spotify — один из наиболее успешных европейских стартапов, создает свои продукты. Процесс описан довольно подробно, включая решение о выходе на рынок.
Для того, что бы итеративно-инкрементально наращивать функциональность уже работающего продукта, необходим процесс разработки, в котором вносить изменения быстро и дешево. Над этой темой поработаю в следующей статье.
Ни одного. Я зарабатываю на жизнь другой деятельностью, а именно — обучением. Последнее время фокусируюсь не только на процессе разработки продукта но и на процессе проработки идеи. Учусь практикам у западных мастеров (Хассман, Паттон) и нахожу способы отработать их, что бы понять пользу и уметь модифицировать. Для этого участвую в стартап-конкурсах, работаю с друзьями над их продуктами и с партнером над собственным. Этот продукт нишевой, он в находится в фазе, в которой уже экономит деньги нашей компании и проходит проверку внешними пользователями и клиентами. Работаем над тем, что бы сделать его открытым и коммерческим.
В своей основной команде, работая над не-технологическими продуктами (программы обучения, конференции) мы используем такие инструменты как Видение, Персоны, Истории (даже для того, что бы «прогнать» воркфлоу участника мероприятия), иногда прорабатываем новые направления деятельности при помощи BMC. У меня есть iPad приложение, которое я использую скорее как инструмент размышления, чем как способ создания бизнес-плана. Поскольку речь идет о нашей собственной компании, многие решения мы обсуждаем и принимаем с партнером на кухне офиса, или на даче — процесс не очень формален.
Смысл слова «анархия» очень хорошо понимается на индийских дорогах в перенаселенных штатах. При практически полном отстутствии формальных знаков и правил, самом плотном трафике, который я видела где-либо — практически нет ДТП. В тех нескольких, которые мне доводилось видеть — были вовлечены западные люди.
Границы применимости может подсказать только здравый смысл, внутри определенного контекста. Например, если вы делаете сайты на вордпрессе по готовым шаблонам — не вижу смысла. В создании игр — вижу)
Для небольших веб- и мобильных проектов прохождение этих шагов может занять до недели. Этот ролик про то, как Nordstrom Innovation Lab создает небольшой рабочий прототип за неделю, включая тестирование на «живых» пользователях (к слову, разрабатывая продукт у них же на глазах).
На стартап-конкурсах у нас похожий, но сильно «обезжиренный» процесс занимал пару часов. На обучающих воркшопах с командами мы доходили до фазы планирования первой итерации за один день. Разумеется, набор практик зависит от контекста, идеи, рынка и даже технологий. Мы стараемся следовать Закону Чувака (Девида Хассмана):
Value = Why / How
Ценность практики равна отношению Пользы (Почему используем?) к Сложности (Как выполнять?)
Например, если ваши пользователи сидят в соседнем отделе, вы видите их каждый день и знаете их лучше семейного психолога, возможно ваш воркшоп по Персонам будет значительно короче, или он не нужен совсем. Хотя я даже в этом случае постаралась бы извлечь пользу из этой практики.
Затягивать не стоит, но небольшая подготовка поможет сэкономить время в дальнейшем.
SRichard, статья написана человеком, которого уже лет пять как для этого не нанимают. Последние полгода нанимали для того, что бы помочь командам, разрабатывающим свои продукты, получить более ясный, предсказуемый, итеративный процесс разработки.
Насчет объема первой поставки — эта статья описывает разницу в MVP (Minimum Viable Product) vs. MDP (Minimum Delightful Product) vs. VCP (Very Crappy Product), в импонирующем мне стиле.
На «кухонном жаргоне» мы с Максом так называем небольшие полнофункциональные команды, которые вместе могут — «взять банк», или создать продукт, обладая всеми необходимыми для достижения цели навыками и знаниями. Чуть больше о формировании такой команды я писала здесь.
От профанов с библией ни одна методология не спасает. К слову говоря, библия PMBook значительно толще 10-ти правил скрам.
Здесь собраны не правила методологии, а элементы рабочего контекста, способа внедрения, неверной трактовки ролей и практик, которые мешают эффективной работе по agile/scrum. Приведу такой пример:
Если при внедрении компания отправляет на обучение менеджмент и тимлидов, то команды затем получают набор правил (как работать), без понимания принципов и ценностей (почему так), часто возникает естественное сопротивление, правила кажутся идиотскими, за процесс «отвечает» один человек. На самом деле процесс разработки — это сфера ответственности (и власти) команды. Но для его обсуждения и совершенствования важна теоритическая база и будет полезен опыт практической работы. Если попытаться внедрить скрам по частям, без общего понимания (например, дейли митинги без правильного планирования), то правила действительно могут стать идиотскими.
Поэтому, когда к нам обращаются по вопросу обучения, первый вопрос, который мы задаем — «вам шашечки или ехать?». Вам нужен сертификат, углубленное обучение скрам-мастеров, или вы начинаете процесс внедрения? В последнем случе предлагаем работу со всей командой.
Про жизнь я в курсе :) Честно говоря, работая в формате коучинга, я не всегда понимаю — какие именно действия привели к этому результату, но изменения в процессе, команде и ее продуктивности бывают разительны. Спасибо за ваш коментарий, я поняла какие вопросы задать в последних компаниях, с которыми работали в последнее время.
По последнему пункту «Введение Agile в крупных фирмах» — я видела разные ситуации. За некоторые я бы не взялась. Либо оттого, что они безнадежны без радикальных изменений и сильной поддержки ТОП-менеджмента, либо потому что эта работа уж очень не fun :)
В английском языке есть понятия efficiency и effectiveness, по-нашему это эффективность и продуктивность. Будет ли команда работать эффективнее — не возьмусь утверждать. Но вы с большей вероятностью построите качественный продукт, нравящийся пользователям и ценный для рынка — в случае, если ваша идея хороша и своевременна. Либо потратите меньше сил и денег на ее проверку.
Когда мы размышляем о процессе разработки, мы часто сфокусированы на эффективности, будто это производство созданного прототипа, вроде пошива сапогов. На самом деле же мы имеем дело с проектированием — креативным процессом, и хотим соединить создание правильных вещей («Doing right things») с созданием вещей правильно («Doing things right»). Гибкие подходы — для этого.
В таком случае это религия опыта. Пока не попробуешь — кажется что не сработает. Быстро попробуешь — тоже не сработает. Многие из пунктов появляются как раз в результате внедрения «на скорую руку». А без понимания что и зачем поменять, кропотливого оттачивания процесса тут не обойтись. На и да, евангилизм — это часть работы. Как в продуктах так и в процессах.
Например, в аутсорсинге проектов из США, иногда назначают скрам-мастера там, поближе к Владельцу Продукта, что бы удобно было через него отжимать команду. В результате вместо «дейли» получаем 40-минутные статус-отчеты по скайпу, и другие «но»
Согласна с мнением о руководителе. Не могу согласиться, что это «следствие самоорганизации». Мы это используем этот инструмент как «причину» самоорганизации — формат, в котором команда может поднять и обсудить социальные вопросы.
Я использую шкалы для командного воркшопа, в котором все участники ставят свои отметки. Для того, что бы не было заякоривания используются специальные карточки от 2 до 5, которые выбрасываются значением вниз, а затем вскрываются одновременно всеми членами команды. После этого каждый участник объясняет — почему он поставил именно эту отметку, какие мысли, поводы были у него в голове.
Объясняю значение шкал разумеется менее формальным языком и с примерами. Тут еще важно понимать — что такие воркшопы мы проводим с командами гибкой разработки (scrum, kanban). Поэтому команды обсуждают бодро. Даже если команде отдана «власть» самоорганизации — не всегда просто катализировать процесс ее принятия. Такой воркшоп дает идеи о новых договоренностях, командных «ритуалах», запросах руководству, заказчикам и т.п.
Ответственность относится к пункту про обвинителей и жалобщиков.
По сути — это способы ухода от ответственности, но они описаны чуть уже чем Кристофера Авери. Мне нравится использовать его модель. Если совсем коротко то: отказ, обвинение, оправдание, стыд, обязательство и, наконец, — ответственность.
Когда команды говорят об этом пункте, можно сделать «вбрасывание» его процесса принятия ответственности. Он хорошо описан в книге Teamwork is an individual skill.
Согласна. Можно придумать части процесса (встречи, артефакты), которые помогут поддерживать эти параметры.
Например, часто вижу, как недостаток видения и вовлеченности заказчика в процесс разработки охлаждает мотивацию в команде. И наоборот — чем более зажженно заказчик хочет свой продукт, говорит о нем, тем больше команда вовлекается в процесс и начинает генерировать идеи и решения.
Или, члены команды часто опаздывают на встречи потому, что «все так делают». В этом случае полезно сделать правила видимыми, даже формальными — пусть висит два-три пункта на стене и всем своим видом как бы намекает :)
Кстати, еще — довольно часто вижу, насколько культура троллинга бывает заразительной. Вот например, если в твиттер-ленте конференции первые посты негативные, то и дальше участники будут скорее склонны критиковать. Если одобрительные — то будет больше позитивных публикаций. Поэтому когда прихожу на мероприятие первым делом стараюсь увидеть что-то положительное и сообщить об этом «миру».
А вот в Европе и Штатах троллинг на мероприятиях — вообще редкость. Изредка вижу выражение альтернативной точки зрения, но вряд ли резкие. Вообще кросс-культурные коммуникации — это очень интересная тема.
О Product Discovery Team узнала от Джефа Паттона, Каган тоже об этом говорит, уж не знаю кто из них первый начал :) Статистики у меня нет, поскольку не ею я руководствуюсь, при выборе инструментов, которые мне кажутся полезными.
Руководствуюсь тем, что: 1) пробую и наблюдаю разницу, 2) интересуюсь опытом применения у своих западных коллег, поскольку его «там» сильно больше
В таком проекте, я бы порекомендовала использовать Kanban, как средство визуализации потока работ. Смотрела бы какая фаза является узким местом, и как можно увеличить ее пропускную способность. Для совмещения скрам и канбан в процессе можно проводить сессии регулярного планирования, скажем раз в неделю или в две. C такой же частотой — демонстрацию (формальную приемку работ) и ретроспективу (обсуждение и адаптация процесса).
При этом демонстрации могут быть не синхронизированы с деплойментом на продакшен. Если вы можете работать в режиме непрерывной поставки, то ваша демо может быть уже на рабочем продукте. Для чего в таком случае нужна демонстрация? Что бы получить понимание того, насколько доволен заказчик (Владелец Продукта), как меняется продуктивность команды (для этого можно использовать артефакт BurnUp Chart и метрику Velocity), сколько ресурсов отнимает саппорт (если он есть). Такая формальная оценка прироста продукта может быть полезной для оценки процесса и его обсуждению на ретроспективе. Оценивать ли работу и работать ли формальными итерациями — сугубо контекстуальный вопрос.
В команде из двух человек нет потребности в формальном скрам-мастере, но стоит обучить обоих участников, что бы их понимание гибкой разработки было общим. В такой команде нет необходимости в выделенных 15-минутках, но стоит обратить внимание на распределение задач командой и сделать процесс планирования и принятия ответственности максимально общим — тогда им будет о чем говорить по мере необходимости.
Отмечу, что такая команда является крайне слабой системой просто в силу своей конструкции. Я часто вижу две крайности в командах из двух человек: либо они так «дружат», что у формируется слабое разнообразие мнений, групповое мышление (как негативный паттерн) и склонность избегать конфликтов, даже если партнер не прав, или откровенно лажает в работе. Либо наоборот — неприятие партнера мешает воспринимать его здравые мысли, личный конфликт сводит на нет любой процесс. В такой системе нужен еще хотя бы один — балансирующий элемент. Кто-то, кто может ее уравновесить в случае перекосов в одну или другую сторону.
Для того, что бы итеративно-инкрементально наращивать функциональность уже работающего продукта, необходим процесс разработки, в котором вносить изменения быстро и дешево. Над этой темой поработаю в следующей статье.
В своей основной команде, работая над не-технологическими продуктами (программы обучения, конференции) мы используем такие инструменты как Видение, Персоны, Истории (даже для того, что бы «прогнать» воркфлоу участника мероприятия), иногда прорабатываем новые направления деятельности при помощи BMC. У меня есть iPad приложение, которое я использую скорее как инструмент размышления, чем как способ создания бизнес-плана. Поскольку речь идет о нашей собственной компании, многие решения мы обсуждаем и принимаем с партнером на кухне офиса, или на даче — процесс не очень формален.
Смысл слова «анархия» очень хорошо понимается на индийских дорогах в перенаселенных штатах. При практически полном отстутствии формальных знаков и правил, самом плотном трафике, который я видела где-либо — практически нет ДТП. В тех нескольких, которые мне доводилось видеть — были вовлечены западные люди.
Границы применимости может подсказать только здравый смысл, внутри определенного контекста. Например, если вы делаете сайты на вордпрессе по готовым шаблонам — не вижу смысла. В создании игр — вижу)
На стартап-конкурсах у нас похожий, но сильно «обезжиренный» процесс занимал пару часов. На обучающих воркшопах с командами мы доходили до фазы планирования первой итерации за один день. Разумеется, набор практик зависит от контекста, идеи, рынка и даже технологий. Мы стараемся следовать Закону Чувака (Девида Хассмана):
Value = Why / How
Ценность практики равна отношению Пользы (Почему используем?) к Сложности (Как выполнять?)
Например, если ваши пользователи сидят в соседнем отделе, вы видите их каждый день и знаете их лучше семейного психолога, возможно ваш воркшоп по Персонам будет значительно короче, или он не нужен совсем. Хотя я даже в этом случае постаралась бы извлечь пользу из этой практики.
Затягивать не стоит, но небольшая подготовка поможет сэкономить время в дальнейшем.
Насчет объема первой поставки — эта статья описывает разницу в MVP (Minimum Viable Product) vs. MDP (Minimum Delightful Product) vs. VCP (Very Crappy Product), в импонирующем мне стиле.
Здесь собраны не правила методологии, а элементы рабочего контекста, способа внедрения, неверной трактовки ролей и практик, которые мешают эффективной работе по agile/scrum. Приведу такой пример:
Если при внедрении компания отправляет на обучение менеджмент и тимлидов, то команды затем получают набор правил (как работать), без понимания принципов и ценностей (почему так), часто возникает естественное сопротивление, правила кажутся идиотскими, за процесс «отвечает» один человек. На самом деле процесс разработки — это сфера ответственности (и власти) команды. Но для его обсуждения и совершенствования важна теоритическая база и будет полезен опыт практической работы. Если попытаться внедрить скрам по частям, без общего понимания (например, дейли митинги без правильного планирования), то правила действительно могут стать идиотскими.
Поэтому, когда к нам обращаются по вопросу обучения, первый вопрос, который мы задаем — «вам шашечки или ехать?». Вам нужен сертификат, углубленное обучение скрам-мастеров, или вы начинаете процесс внедрения? В последнем случе предлагаем работу со всей командой.
Про жизнь я в курсе :) Честно говоря, работая в формате коучинга, я не всегда понимаю — какие именно действия привели к этому результату, но изменения в процессе, команде и ее продуктивности бывают разительны. Спасибо за ваш коментарий, я поняла какие вопросы задать в последних компаниях, с которыми работали в последнее время.
По последнему пункту «Введение Agile в крупных фирмах» — я видела разные ситуации. За некоторые я бы не взялась. Либо оттого, что они безнадежны без радикальных изменений и сильной поддержки ТОП-менеджмента, либо потому что эта работа уж очень не fun :)
Когда мы размышляем о процессе разработки, мы часто сфокусированы на эффективности, будто это производство созданного прототипа, вроде пошива сапогов. На самом деле же мы имеем дело с проектированием — креативным процессом, и хотим соединить создание правильных вещей («Doing right things») с созданием вещей правильно («Doing things right»). Гибкие подходы — для этого.
Я использую шкалы для командного воркшопа, в котором все участники ставят свои отметки. Для того, что бы не было заякоривания используются специальные карточки от 2 до 5, которые выбрасываются значением вниз, а затем вскрываются одновременно всеми членами команды. После этого каждый участник объясняет — почему он поставил именно эту отметку, какие мысли, поводы были у него в голове.
Объясняю значение шкал разумеется менее формальным языком и с примерами. Тут еще важно понимать — что такие воркшопы мы проводим с командами гибкой разработки (scrum, kanban). Поэтому команды обсуждают бодро. Даже если команде отдана «власть» самоорганизации — не всегда просто катализировать процесс ее принятия. Такой воркшоп дает идеи о новых договоренностях, командных «ритуалах», запросах руководству, заказчикам и т.п.
По сути — это способы ухода от ответственности, но они описаны чуть уже чем Кристофера Авери. Мне нравится использовать его модель. Если совсем коротко то: отказ, обвинение, оправдание, стыд, обязательство и, наконец, — ответственность.
Когда команды говорят об этом пункте, можно сделать «вбрасывание» его процесса принятия ответственности. Он хорошо описан в книге Teamwork is an individual skill.
Например, часто вижу, как недостаток видения и вовлеченности заказчика в процесс разработки охлаждает мотивацию в команде. И наоборот — чем более зажженно заказчик хочет свой продукт, говорит о нем, тем больше команда вовлекается в процесс и начинает генерировать идеи и решения.
Или, члены команды часто опаздывают на встречи потому, что «все так делают». В этом случае полезно сделать правила видимыми, даже формальными — пусть висит два-три пункта на стене и всем своим видом как бы намекает :)
Кстати, еще — довольно часто вижу, насколько культура троллинга бывает заразительной. Вот например, если в твиттер-ленте конференции первые посты негативные, то и дальше участники будут скорее склонны критиковать. Если одобрительные — то будет больше позитивных публикаций. Поэтому когда прихожу на мероприятие первым делом стараюсь увидеть что-то положительное и сообщить об этом «миру».
А вот в Европе и Штатах троллинг на мероприятиях — вообще редкость. Изредка вижу выражение альтернативной точки зрения, но вряд ли резкие. Вообще кросс-культурные коммуникации — это очень интересная тема.