Как в фильме Начало (Inсeption), реальность в продуктовой разработке имеет определенную вложенность слоев. В зависимости от того, какая роль вам выпала, ваше “начало” в проекте может произойти раньше или позже, но всегда приятнее быть в числе создателей новой реальности, не так ли?

Эта статья — вступительная часть к трилогии о том, что собой представляет в гибкой продуктовой разработке:

• Готовность Начать
• Готовность Завершить
• Готовность Выпустить

Первая часть будет посвящена процессу открытия продукта (Product Discovery), вторая — процессу разработки продукта (Agile Delivery), третья — формированию цикла этих двух процессов, с обратной связью от рынка (Business Development). Здесь же, в начале, я задам общие рамки ролей и процессов, в которые буду углубляться в следующих частях.

Пишу эту статью для нынешних или начинающих Владельцев Продуктов — «ловцов снов» и «продавцов воздуха». Людей, идеи которых способны изменить реальность, а могут сами оказаться иллюзией.

Термин «скрам-бат» (от «scrum, but..») впервые начал использовать Кен Шуэйбер что бы описать неверную трактовку или умышленную модификацию правил скрам, что бы уйти от болезненной правды о процессе, которую он помогает открыть.

Типичная формулировка скрам-бата выглядит так:
У нас скрам, но <Причина>, <ОбходнойПуть>

Где Причина — это описание дискомфорта, неприятного открытия с которым команда в силу тех, или иных причин не может справиться. А Обходной путь — это способ закрыть глаза на проблему, или устранить «симптомы», не разобравшись с причинами «организационного заболевания».

Типичные примеры скрам-батов, соответственно, выглядят так:

• У нас скрам, но мы не всегда успеваем закончить всю взятую работу, поэтому меняем длину итерации.
• У нас скрам, но все проблемы, которые мы могли устранить мы уже устранили, поэтому мы не проводим ретроспективы .

Мы стараемся термином «скрамбат» не злоупотреблять, поскольку некоторые типы отклонений свойственны началу внедрения аджайл и являются частью эволюции процесса. Например, если у вас скрам, но вы не делаете TDD, у вас нет парного программирования и слабо выраженное коллективное владение кодом — возможно, вы просто в начале пути. Причины могут быть разными — от неумения «продать» ценность инженерных практик менеджменту до неумения их «готовить». И то и другое можно научиться делать, но это занимает определенное время, верно?

Однако, каждый раз, когда я слышу «у нас скрам, но» в зрелых командах, я пытаюсь услышать нечто большее большее о причинах, которые такую модификацию обуславливают. И знаете, что? Веских причин на самом деле очень мало. Скорее, это непонимание ценностей гибкой разработки, недостаток смелости и силы что бы им следовать, которые вместе образуют процессное «скрамно».

Работая с командами, мы собрали список из 85 заблуждений и препятствий успешного внедрения гибкой разработки. Многие выходят за рамки правил карсасса скрам. В зависимости от контекста проекта, некоторые пункты могут иметь большее или меньшее влияние, и иметь оправдания обстоятельствами. Однако мы верим, что каждый элемент этого списка провоцирует искаженение ценностей и принципов Agile.

Недавно, на Скрам портале была опубликована статья Майка Кона об Общепринятых практиках в Скраме — практиках, которые довольно часто встречаются в Скрам-проектах, но не являются базовыми правилами Скрам.

Скрам поощряет подобные добавления и специально построен минималистично, дабы команды могли добавить то, что им по вкусу. Не стоит путать подобные улучшения процесса с печально известным Скрам-ном. В отличие от последнего, добавленные практики улучшают процесс, повышая эффективность выпуска продуктов и выравнивая поток работ.

Сегодня я хочу поделиться множеством таких практик, собранных вокруг работы с требованиями. За последние несколько лет перечисленные практики мне не раз довелось наблюдать за кулисами у успешных команд в роли agile-коуча и рассказывать о них на тренингах Certified ScrumMaster в роли скрам-тренера.

Я ни в коем случае не претендую на полноту практик и буду рад услышать дополнения. Некоторые из перечисленных практик заслуживают отдельных статей — это work in progress.

Программа AgileBaseCamp: VALUE Driven Development практически готова! В ее фокус мы взяли сближение бизнеса и девелопмента через понимание ценности продукта, нужд пользователей и приоритетов разработки. Доклады и воркшопы раскроют такие вопросы:

Алексей Кривицкий: Почему проваливаются оценки и как побороть проблему сроков?

Артем Сердюк: Как использовать Impact Mapping для наведения ясности в требованиях и приоритетах?

Наталья Тренина: Как работать над видением продукта и вовлеченностью команды в его создание?

Максим Климишин: Как достигать состояния “done” и что для этого важно сделать на старте проекта?

Анализируя 2012 год (перед концом света, уа!) я понимаю, что шесть недель простоя, которые мне выпали в марте из-за травмы колена дали мне очень-очень много.

Во-первых, я отлично отдохнул.

Во-вторых, я смог наконец-то сделать то, что уже не мог сделать много лет. А именно найти время для низкоприоритетной и совсем некритичной задачи — выучить ruby on rails.

В-третьих, я не только освоил рельсы, но и написал сервис для SCRUMguides, которым мы пользуемся вот уже 9 месяцев. Почему-то, у нанятых нами профессиональных рубистов в 2010-2011 году это получилось намного хуже.

Может все дело в колене?

Около полугода назад мне в руки попала книга Чарли Пелерина How NASA builds teams. В книге описывались социальные проблемы крупных технологических проектов, которые стоили миллионов долларов космической промышленности США.

В книге Чарли я подчерпнула ряд идей об измерении социального контекста проекта. И провела некоторые наблюдения с командами гибкой разработки. Думаю, лучше всего систему NASA 4-D лучше применять для тематической командной ретроспективы.

Однако, независимо от используемого процесса и зрелости команды, описанные ниже 8-мь социальных параметров довольно интересно обсуждать. Разговор о них может дать ряд идей об усилении командного взаимодействия и социальных факторов успеха проекта.

По каждому из пунктов я описала базовое значение “максимума”. Читая описание социальных параметров, попробуйте задаться вопросом: “Насколько хорошо функционирует этот аспект социальной жизни нашей команды?”

Когда мы заказываем костюм в ателье или дизайн интерьера, нас не просят прийти с готовыми мерками, выбранным фасоном или цветом потолка. Профессиональные модельеры и дизайнеры задают вопросы и предлагают решения на основе наших целей.

Однако, от заказчиков программной разработки, мы часто ожидаем получить готовую спецификацию требований.

Чуть лучше дело обстоит в продуктовой разработке, особенно в стартапах, где генерация требований равномерно распределена по всему жизненному циклу работы над продуктом. Благодаря принципам Lean StartUp: построить -> измерить -> изучить, продуктовые команды работают более короткими циклами. На входе каждой итерации — новая порция требований для «эксперимента», в формулирование которых часто вовлечена вся команда.

В заказной разработке я наблюдаю 3 типа проблем, связанных с ожиданием готовых требований от клиента:

1. “Бизнес” не умеет формулировать хорошие требования, потому что не понимает процесса разработки и технологических возможностей. Спецификация содержит представление заказчика о решении проблемы, докопаться до сути которой по документу сложно.
   
   
2. “Бизнесу” не хватает времени на проработку требований. Часть вариантов использования системы, не продуманная заранее, вбрасывается в ходе разработки. Чем меньше практик, поддерживающих итеративный процесс (CI, автоматизированное тестирование, ограничение по количеству фич в работе), тем сложнее вносить изменения в требования.
   
   
3. “Бизнес” и “разработка” говорят на разных языках. Как следствие — ложное понимание требований, не проясненные предположения, вытекающие из них 'сюрпризы' в момент демонстрации. Несуществующую систему сложно описать на бумаге. Отсюда вытекают проблемы, которые можно обобщить словами заказчика: “Я не знаю точно чего хочу, но точно знаю чего не хочу”.

Очевидно, что и формулирование проблем и поиск технических решений будет проходить легче и эффективнее, если обе стороны — бизнес и разработка, будут вовлечены в этот процесс.

Как же помочь клиенту, горящему идеей продукта — сформулировать ее ясно, на языке бизнеса и проблемы. Как избежать навязывания решений, излишней и преждевременной детализации требований? Как сократить время на понимание рынка, пользователей, ценности требований и критериев успешности их реализации?

Ниже — обзор продуктовых техник, которые могут в этом помочь.

Цель — это сильный внутренний мотиватор, согласно последним исследованиям в психологии, которые собрал и обобщил Ден Пинк. Работая с продуктовыми командами, я довольно часто сталкиваюсь с примерами, подтверждающими его доводы.

Отсутствие ясности на уровне видения продукта, четкого позиционирования на рынке, стратегии развития на 3-6 месяцев, давления срочности или ощущения конкурентной схватки — гасит скорость работы команды и личную вовлеченность ее участников.

Способность Владельца Продукта (роль Product Owner в терминологии SCRUM) воплощать видение продукта в своих словах и действиях, нельзя переоценить, когда мы говорим о командной разработке. Такая способность помогает команде работать сфокусированно (focus — одна из ценностей процесса SCRUM).

Фокус внимания меняет наше восприятие. Что бы лучше понять о чем это, попробуйте небольшой эксперимент. На протяжении дня держите в фокусе какую-то простую вещь, например, красный цвет. Обращайте внимание на все красное на улице и в офисе, думайте о красном в душе и лифте, найдите пару интересных фактов о самом цвете, или красных вещах. Уже к концу дня вы начнете воспринимать красный по-другому. Мужчины могут с удивлением обнаружить, что у красного есть оттенкиJ А на следующий день, вам могут приходить в голову “красные” мысли.

Похожий эффект работает с концентрацией на видении продукта. Представьте команде продукт — как проблему, загадку, задачу, интеллектуальный вызов, над которым вы работаете. И через время фокус на решении проблемы изменит восприятие действительности, команда начнет видеть нетривиальные решения и не очевидные возможности, которые раньше оставались незамеченными.

Ниже — 5 идей для Владельцев продукта о том, как усилить внутреннюю мотивацию и командную работу через видение.

Провела полдня на баскетбольной площадке. Хорошая разминка, и, как говорят американцы “thought-provoking”. Хочу поделиться некоторыми наблюдениями — общими, на мой взгляд, для командного спорта и командной разработки.

Наблюдение 1: СЛАБАЯ КОМАНДА

Формирование команды из незнакомых и малознакомых игроков на площадке происходит стремительно быстро. Разбились три-на-три, более-менее справедливо по росту, по уровню игры и поехали. Если уже через пару минут ты понимаешь, что оказался в слабой команде — сложно получить удовольствие от игры.

Забавный паттерн: думать “я — в слабой команде”, вместо “мы — слабая команда”. Причем, независимо от собственного уровня игры. Казалось бы, и то и другое — формулировка факта, но есть нюанс. Попробовала повторить про себя по несколько раз, понаблюдать ощущения:

За последние полгода мне удалось побывать на двух стартап-конкурсах — DOU Mixer и Garage48. В первом команда формировалась “на лету”, что внесло определенную избыточность и путаницу ролей. Поэтому, во втором мы решили участвовать укомплектованным еще до его начала составом.

Скажу сразу, работать с командами клиентов и собирать свою команду — не одно и тоже. Есть свои преимущества и недостатки, но так же, есть общие практики, которые будут полезны как аджайл-коучам, так и технологическим предпринимателям.

Хочу поделиться парой инструментов, которые помогут быстро понять кто есть кто в команде и сэкономить время некоторых командо-образующих процессов.