Книга: Пользовательские истории. Искусство гибкой разработки ПО
Назад: Суть исследований не в создании программных продуктов
Дальше: Действия, обсуждения и артефакты в исследовании
Четыре необходимых шага исследования
Если у меня есть большая идея или даже не очень большая, но требующая некоторой доработки, я последовательно провожу определенные обсуждения. От большой идеи мы переходим к деталям, которые нужны, чтобы лучше понять, достойно ли это решение реализации.
1. Сформулируйте идею с точки зрения бизнеса.
2. Постарайтесь понять, каким образом вы можете помочь заказчикам и пользователям.
3. Сформируйте видение вашего решения.
4. Минимизируйте его, а также составьте план, как выявить и затем создать минимально жизнеспособное решение.
1. Сформулируйте идею
Если вы и в самом деле используете бэклог возможностей и проводите настоящие обсуждения возможностей, чтобы принять решение о начале исследований, то вы на правильном пути. Используйте дискуссии для обкатки идеи, чтобы запустить направленное исследование. Привлекайте людей, с которыми будете вместе работать, чтобы они лучше поняли эту возможность.
Применяйте формирующие дискуссии, чтобы очертить границы намеченной работы. Если вы хорошо понимаете, зачем и для кого что-то делаете, то вам и вашей команде легче будет прекратить обсуждать решения, которые никак не повлияют на рассматриваемую проблему и никак не помогут выбранным пользователям.
2. Поймите заказчиков и пользователей
Применяйте обсуждения заказчиков и пользователей, чтобы лучше понять людей, для которых предназначены ваши продукт или функциональности, а также пользу, которую вы собираетесь им принести. Привлекайте к дискуссии тех, кто хорошо понимает проблемы пользователей, а также всех, кому нужно их понять.
Рисуйте эскизы упрощенных персонажей
Мне нравится быстро набрасывать эскизы упрощенных персонажей вместе с небольшой исследовательской командой, чтобы выработать одинаковое понимание пользователей. Персонаж – это пример целевых пользователей, в описании которого использованы факты, а порой и предположения о ваших пользователях. Создание персонажей помогает нам взглянуть на программный продукт глазами пользователей, поэтому создание персонажей – очень полезная техника.
Я создал этот простой персонаж вместе с группой из Mano a Mano, некоммерческой организации, которая помогает жителям Боливии всем, чем может: от постройки дорог до обеспечения образования и здравоохранения. Наша дискуссия в тот день касалась скромных благотворителей, вносящих небольшие пожертвования через Интернет, – пусть у них нет больших денег, но они могут внести свою скромную лепту, если уверены, что она пойдет на доброе дело. Мы ожидали, что люди наподобие Чака могут найти информацию о Mano a Mano в Интернете или наткнуться на упоминание о ней в Facebook или Twitter.
Мы создали этот персонаж все вместе на большом листе бумаги. Это было веселое занятие с участием многих людей, каждый из которых вносил свой вклад, называя известные ему факты. И времени оно заняло немного.
Если вы опытный дизайнер UX, которому прежде приходилось создавать персонажей, то, наверное, уже закипели от возмущения. Я поясню для остальных: обычно хорошие персонажи создаются по результатам тщательного сбора и анализа данных, полученных путем научного исследования. Специалисту UX члены команды, наперебой выкрикивающие характеристики пользователя и пишущие их на доске, кажутся совершенно нелепыми. В этом нет ничего научного. Поэтому и в самом деле не стоит орать что попало – просто обсудите то, что вы знаете и сами наблюдали. Изложите истории. Вовлекайте в дискуссию людей, которые непосредственно взаимодействовали с пользователями. Если вы проделали большие исследования, захватите их результаты на обсуждение. Отметьте детали, наиболее важные с точки зрения возможности, которую вы обсуждаете, и занесите их в карточку персонажа. Отфильтруйте все лишнее. Когда закончите, честно обсудите, какая часть сделанного основана на догадках и предположениях.
«У нас уже есть персонажи. Вон там, на стене, висят красиво оформленные документы». Сколько раз я слышал эти слова! Но будьте честны сами с собой: большинство из вас этого не читали, правда ведь? А половина тех, кто прочитал, сделали это просто ради смеха. Может быть, я циник, но я наблюдал такую картину множество раз.
Создавайте персонажей вместе, как команда. Сделайте это, чтобы у всей команды было общее мнение по поводу людей, которые будут использовать ваш продукт. Сделайте это, чтобы учесть самые релевантные аспекты персонажа.
Создавайте упрощенных персонажей вместе, чтобы выработать одинаковое понимание и сопереживание внутри команды.
Я создаю упрощенных персонажей для каждого типа пользователя, который может использовать обсуждаемую нами функциональность. Если времени мало, то просто перечисляю разные типы или роли пользователей, применяющих продукт, и кратко упоминаю некоторые относящиеся к ним детали. Помните Гэри из главы 1? Одна из групп карточек рядом с ним была именно такой – с названием пользователей и парой предложений о каждом из них.
Создавайте профили организаций, или «оргсонажи»
Если вы работаете над продуктом, который могут купить организации, скажем над программой для бухгалтерского учета, выделите время, чтобы перечислить разные типы организаций и записать несколько деталей о каждой из них. Это ваши заказчики – люди с деньгами, которые собираются извлечь какую-то пользу из вашего продукта. Информацию о типе организации с несколькими дополнительными деталями принято называть профилем организации. Моя подруга Лейн Хелли первой подала мне идею создавать примерные профили организаций аналогично тому, как делаются персонажи. В шутку она называет эти профили оргсонажами.
Составьте карту работы пользователя на сегодняшний день
Вы можете продвинуться на один шаг дальше и составить карту работы ваших пользователей сегодня, еще до реализации продукта. Если вы сделали упражнение из главы 5, то легко построите такую карту аналогично той, где отображается ваше утро. Создание карты, где представлены существующие способы решения проблем пользователей, поможет вашей исследовательской команде по-настоящему разобраться в проблеме, которую они решают.
На этих фотографиях Дункан Браун из Caplin Group показывает то, что у них называется описательной картой маршрута. Видна «теперешняя» часть модели «до и после», с которой я начал эту книгу. На ней никак не отражается наше великолепное решение, а изображено лишь то, каким образом люди достигают своих целей сейчас – неудобства, неудачи и т. п.
Основная часть карты содержит факты, наблюдения, моменты раздражения и удовольствия. Составляя карту того, что вы понимаете сейчас, вы непременно найдете горячие точки – области процесса, где сосредоточено много проблем. Возможно, вы также найдете моменты удачи, когда, выполнив последовательность из нескольких шагов, пользователь доволен результатом, который принесли его усилия. Вы можете создать великолепный продукт, минимизируя неприятные вещи и увеличивая приятные. Используйте карту как трамплин для решений путем мозгового штурма или для того, чтобы убедиться, что уже намеченное решение поможет справиться с реальными проблемами.
3. Визуализируйте свое решение
К настоящему моменту вы должны были ясно сформулировать, почему что-то создаете, с точки зрения бизнеса; вы исследовали пользователей и заказчиков, так что знаете, как у них обстоят дела сейчас. Настало время вообразить будущее – сформировать видение своего решения, а также взаимодействия с ним заказчиков и пользователей.
Составьте карту решения
Вот где карты историй проявят себя – по крайней мере, я так думаю. Я использую карты историй, чтобы четко представить себе жизнь пользователей после того, как им будет предъявлено мое решение. И Гэри, и команда Globo.com из первых двух глав строили именно такие карты. И как мы говорили во вступительных главах, шаги, которые делают люди в вашей истории, формируют последовательное повествование слева направо. Эти шаги называются пользовательскими задачами и представляют собой короткие глагольные фразы, которые, если читать их слева направо, образуют историю. Более точно сформулированные задачи и различные детали перечислены вертикально под каждым шагом. Если история длинная, выделите группы действий и постройте трехуровневую карту.
Слова и картинки
Случалось ли вам, описав программисту идею продукта, с приятным удивлением слышать в ответ: «О, это просто. На разработку не потребуется много времени»? Правда, позднее, когда вы приступали к разработке, оказывалось, что программист понял вас неправильно и думает о чем-то значительно более простом, чем представлялось вам. Например, вы говорили о сайте, с помощью которого можно продавать вашу продукцию в Интернете. Вы воображали что-то вроде Amazon Marketplace или eBay, а программист подумал о чем-то наподобие Craigslist, поэтому и дал такую оптимистичную оценку. В общем, за последние десять лет я твердо усвоил, что одних слов недостаточно.
Визуализируйте пользовательский интерфейс, чтобы выработалось одинаковое понимание вашего решения.
Если в вашей команде есть дизайнеры пользовательского взаимодействия, настало время им нарисовать эскизы. Наброски отдельных экранов можно помещать прямо наверху карты в порядке их появления. В конце концов у вас получится что-то вроде раскадровки.
Полная визуализация взаимодействия
Джош Сайден (иллюстрации Демиана Репуччи)В один прекрасный день мне позвонил Роберт, менеджер по дизайну, недавно получивший работу в большом, хорошо финансируемом образовательном стартапе. Компания недавно начала крупный проект и активно набирала людей, которые должны были в сжатые сроки разработать обширную систему. Одна проблема: никто не знал, как подступиться к дизайну такого огромного и сложного проекта. Не могу ли я помочь?Придя в офис через несколько дней, я встретился с Робертом. Он, одновременно гордый и предельно замотанный, все мне показал. Компания наняла большую консалтинговую фирму для помощи в разработке требований к проекту, и фирма проделала впечатляющий объем работы. Все стены в просторном офисе-лофте были завешаны листами тонкой коричневой бумаги, а каждый лист, в свою очередь, покрыт карточками и стикерами. Это были требования в форме пользовательских историй. Тысячи историй. Пока Роберт вел меня вдоль стены с историями, я обратил внимание на то, что истории были организованы согласно функциональным модулям: стена текстового редактора, стена английского языка. Но мне не удавалось представить себе работу системы целиком.Роберт работал над созданием команды дизайна, а также пытался разделить задачу на составные части. Обсудив возможные потребности его команды, мы пришли к выводу, что можно использовать карту историй, с помощью которой будет удобно организовать тысячи пользовательских историй так, чтобы команды дизайна и разработки пользовались ею совместно.Случилось так, что через несколько недель я присутствовал на семинаре, который проводила команда художников-раскадровщиков. Целью семинара было обучение заказчиков формулировать видение их бизнес-идей. Эти художники сидели рядом с заказчиками и, быстро работая, рисовали по их описанию истории и набрасывали идеи в виде раскадровок – мини-комиксов, которые ясно и четко излагали каждую историю. Мне тут же захотелось скомбинировать этот подход с составлением карт историй, поэтому я пригласил присоединиться ко мне художника Демиана Репуччи, чья работа впечатлила меня наиболее сильно.Через пару недель Демиан и я встретились с Робертом и его командой, а также менеджерами продуктов из разных частей системы. Мы сфокусировались на высокоуровневых процессах – основных вариантах действий пользователя в системе. В течение встречи Демиан рисовал в блокноте, а я выкладывал на стенах конференц-зала пользовательские варианты с помощью карточек и стикеров. После окончания встречи Демиан должен был вернуться к себе в студию, чтобы проиллюстрировать ключевые моменты, а я использовал Omnigraffle, чтобы выполнить окончательные версии карт историй, черновики которых мы набросали на встрече.
Мы с Робертом решили: самое лучшее, что мы можем сделать для команды, – это организованная структура, поэтому выпустили серию постеров, которые можно было напечатать на листах 11×17 дюймов и повесить на стены, что сформировало бы каркас карты историй. После этого команды могли бы пользоваться ими независимо друг от друга, чтобы реорганизовать свои истории. В результате из вида, организованного по модулям, который никак не помогал итеративной разработке, мы получили вид, основанный на логике пользования, который легко было трансформировать в несколько многомодульных релизов.
Один из способов визуализации пользовательского взаимодействия, вовлекающий в работу всю команду, – подход проектной студии. Проектная студия – это быстрый и простой способ, позволяющий организовать сотрудничество большой группы людей для работы над осознанным формированием идеи, или, проще говоря, выдвижения большого количества всевозможных идей. Вы быстро поймете, что самые лучшие идеи не может выдвинуть какой-то отдельный человек – лучшие идеи возникают из комбинации предложений нескольких авторов во время обсуждения. Проектная студия (и осознанное выдвижение идей) – противоположность общепринятому подходу, когда кто-то приносит идею, на первый взгляд кажущуюся подходящей, и все обсуждают ее. Впервые услышав о методе проектной студии от его авторов Джеффа Уайта и Джима Унгера, я удивился, почему раньше не пользовался таким прекрасным подходом. С тех пор я много раз запускал сессию проектной студии с участием команд разработки, ключевых партнеров и даже пользователей или заказчиков.
Какой бы подход вы ни использовали, комбинируйте идеи, совершенствуйте их и приходите к единому пониманию программного продукта, который хотите создать.
Может случиться, что в попытке визуализировать свое решение вы обнаружите, что некоторые моменты не были внесены вами в карту. Придется что-то добавлять, менять или переставлять карточки, чтобы отразить на карте вашу новую идею. Не волнуйтесь, на самом деле это положительный момент.
Рецепт проектной студии
Проектная студия – эффективный и быстрый способ работы в группе для генерации идей. Этой техникой можно пользоваться по-разному, вот мой простой рецепт.1. Пригласите группу людей, чьи мнение и идеи вам близки, а одобрение и понимание нужны для создания продукта. Оптимальный размер группы – от восьми до двенадцати человек.2. Опишите задачу, которую решаете. Рассмотрите уже проделанную работу, чтобы выявить возможности. Просмотрите еще раз персонажей и карты, отражающие то, как пользователи решают проблемы сейчас. Если вы уже начали составлять какие-то карты для решений, просмотрите и их, но будьте осторожны, не говорите слишком много, иначе все неизбежно будут отталкиваться от ваших мыслей и вы не услышите самые лучшие идеи других людей.3. Можно продемонстрировать примеры для вдохновения. Посмотрите вместе и обсудите удачные похожие продукты. Рассмотрите также продукты, не совсем схожие с вашим, но воплощающие удачные идеи, которые могут натолкнуть на хорошую мысль.4. Рисуют все! Раздайте всем бумагу, ручки, карандаши, при желании – какие-то шаблоны экранов и установите таймер. В моей практике встречались отрезки времени как 5, так и 60 минут. Лучше всего, по-моему, примерно 15 минут.5. Делитесь идеями, если действуете в маленьких группах. Этот прием работает в группах до четырех человек, поэтому, если всего вас, например, 12, разбейтесь на три меньшие группы. Поделитесь друг с другом своими идеями и дайте им оценку. Следите, чтобы оценки высказывались с точки зрения эффективности решения изначальной проблемы, а не просто из-за того что нравится или не нравится. Следите, чтобы каждый развивал не только свои, но и чужие идеи. Продолжайте личную работу в маленьких группах в течение фиксированного времени, скажем 30 минут.6. Попросите каждую группу объединить свои лучшие идеи в одно решение и проиллюстрировать его эскизами. Это самая сложная часть. На нее стоит отвести 15–30 минут.7. Попросите каждую группу представить свои лучшие идеи, сведенные воедино, всей группе. Обсудите их.8. Поблагодарите всех и объедините все идеи и наброски. Вы, UX-специалист и исследовательская команда должны рассмотреть и задействовать их, чтобы создать финальные, наилучшие эскизы UI. Помните выражение моей подруги Лизы Райшелт: «Дизайн через сотрудничество – не то, что дизайн в комиссии»? У вас будет много отличных, но не согласующихся друг с другом идей, и кому-то придется принять нелегкое решение.
Убедитесь в законченности
Что мы умеем делать хорошо, так это додумывать детали. Например, если мы видим два кадра какого-нибудь комикса, то легко догадаемся, что произошло между ними. Этот прием широко используется в комиксах, романах и кинофильмах. Но, раздумывая о том, что делает программный продукт, мы часто склонны воображать себе интересные функциональности, пренебрегая тем необходимым, что их связывает. Продолжая аналогию с фильмом, можно представить, что на экране сменяли бы друг друга погони на автомобилях и перестрелки, но ни слова не было бы сказано о том, почему все это происходит и какая история их связывает.
Изложение во всех подробностях пользовательских историй с помощью карты поможет вам проговорить все критически важные детали, которые их связывают. В большинстве случаев люди понимают, что крутая функциональность, которую они рассматривают, потребует изменения некоторых пользовательских настроек в самом начале истории, а также отчетов и уведомлений в конце. Могут быть затронуты не только функциональности, но и люди. Например, администраторы должны обработать новые настройки безопасности для системы, а менеджеры – контролировать, как функциональность используется в их командах.
Проверьте технические особенности
Возвращаясь к аналогии с киносъемками: если вы собираетесь продолжать работу над своим фильмом, стоит подумать о выборе места съемок, спецэффектах и других деталях. В какой-то момент вам придется с головой погрузиться в сценарий и продумать все технические детали создания фильма.
Карта историй вашего программного обеспечения очень полезна в дискуссиях того же типа, что вы проводили бы, будь вы режиссером кинофильма. Обсудите карту своих решений с инженерами и архитекторами, прежде чем двигаться дальше. Видение картины в целом поможет им заранее предусмотреть большинство технических ограничений, которые могли бы затруднить реализацию по-настоящему удачных решений. Вас могут заранее предупредить о том, что хоть ваше решение и выглядит прекрасно, но реализовать его при заданном бюджете времени и имеющейся архитектуре не представляется возможным. Они могут также предложить альтернативные пути выполнения задач, которые обеспечат вашим пользователям те же возможности взаимодействия, но будут более экономичны с точки зрения реализации.
Эти инженеры большой страховой компании потратили много времени на обсуждение находящейся на стене карты. По ходу обсуждения они обнаружили в огромной карте своего продукта небольшую нестыковку: придется изменить обработчик бизнес-правил их продукта. Возможность увидеть картину в целом помогла им визуализировать свою работу несмотря на сложность продукта. Обладая этим знанием, ребята смогут обсудить, что им необходимо запланировать на самых ранних этапах и как минимизировать риски.
Поиграйте в «Что, если»
Вы представляете свое решение с точки зрения пользователя, и у вас есть видение пользовательского взаимодействия. Выделите некоторое время для обсуждения того, что происходит внутри интерфейса. Обсудите строгие бизнес-правила, сложную валидацию данных, а также разные серверные сервисы и системы, с которыми придется взаимодействовать. Добавляйте на карту истории, обозначающие эти части, или делайте пометки в уже имеющихся историях.
Это хороший момент, чтобы рассмотреть то, что вами уже сделано, с большим количеством других людей. Расскажите им обо всем, к чему удалось прийти вам и вашей группе. Обещаю: у вас будет большая группа людей, наперебой задающих вопросы, начинающиеся с «А что, если…». Я обожаю таких людей (только не в тот момент, когда они стоят прямо передо мной). И я благодарен им за то, что они помогают мне задуматься о множестве проблем, прежде чем я натолкнусь на них сам позднее, когда полученный урок обойдется гораздо дороже.
Аналогия с киностудией, как мне кажется, отлично работает. Если бы я собирался снимать кино, мне нужны были бы сценарий и раскадровка – эскизы ключевых сцен, которые помогли бы мне лучше представить будущий фильм. Если бы я собирался вложить деньги в съемку фильма, то хотел бы увидеть как минимум две эти вещи, чтобы иметь представление о картинке, сложившейся в головах сценаристов и режиссеров. Если бы в тот момент задумка мне понравилась, я продолжил бы исследования, чтобы узнать, сколько денег потребуется на съемку фильма и насколько реально воплотить в жизнь эти замыслы.
Я думаю, в кино эти эскизы используются для того, чтобы более тщательно обдумать будущий фильм. Как инвестор я хотел бы, чтобы можно было заранее подсчитать, сколько площадок и павильонов нужно для съемки и как они должны выглядеть. Необходимо также знать, какие потребуются декорации, реквизит и спецэффекты. Словом, мне нужны были бы сценарий, раскадровка и множество других деталей, на которых базируются построение плана и оценка затрат. Имея эти данные, можно запланировать бюджет и временной график съемок фильма.
Вот какие сведения вы должны получить, прежде чем приступите к реализации своего решения.
Идеи, примеры и маршруты
Дэвид Хассман, DevJamМногие люди излишне усложняют процесс исследования, а он может быть очень простым и при этом вполне эффективным. Оставьте в стороне воображаемую жесткость требований и выделите время на исследование идей с помощью примеров и маршрутов пользователей, как говорится в приведенном далее руководстве.
Следуйте простому плану.1. Предложите идею для исследования.2. Выберите людей, которым, по вашему мнению, будет выгодна реализация этой идеи.3. Сделайте подборку примеров того, как эти люди используют данную идею.4. С помощью этих примеров составьте карту и маршруты, которые, по вашему мнению, понадобятся.Помните, что, как автор, вы несете ответственность за создание адекватного пользовательского взаимодействия, а не просто новых функциональностей.Идеи не обязаны быть гениальными. Да, вы хотите создать великолепный продукт, но зачастую самые блестящие идеи не срабатывают как надо, в то время как полезность других, не вызывающих такого восхищения поначалу, раскрывается, когда их рассматривают в контексте применения для выполнения определенной задачи.Выбор «пассажиров» не отбор космонавтов. Не стоит чересчур усложнять отбор целевой аудитории. Если вы не уверены, с чего начать, просто составьте список пользователей, которым, по вашим предположениям, будут полезны ваши идеи. Дополните их образы, чтобы они долго оставались живыми и реальными в сознании членов команды разработки. Поработав с ними некоторое время, выберите какой-то конкретный тип пользователя и не слишком волнуйтесь о правильности решения. Будьте готовы извлекать уроки из исследований и не беспокойтесь о том, верен ваш выбор или нет, – скорее всего, нет.Составьте обширный перечень примеров. Именно здесь многие люди теряют контроль над собой и лезут в дебри. Начните с самого простого, очевидного примера, чем конкретней он будет, тем лучше. Затем переходите к примерам посложнее и не бойтесь поднимать планку высоко. Создавая набор ограничений, вы не даете никаких гарантий. Но чем сложнее пример, тем конкретнее он должен быть. Если вы не уверены в необходимом уровне конкретики, трансформируйте рабочий пример в тест – это на шаг приблизит вас к автоматизированной валидации.Добавьте еще несколько примеров среднего уровня сложности, а затем начните работу с простыми примерами. Расскажите историю «пассажира», используя самый простой пример в своем руководстве. Поделитесь ею с кем-нибудь и попросите этого человека помочь вам обработать остальные истории в маршруте. С чего начинают ваши пользователи? Какова их мотивация? Что конкретно они проделывают? Чем заканчивается история? Используйте разные примеры для обработки разных маршрутов ваших «пассажиров».Выберите маршруты, которые помогут вам в исследовании. Еще одна сложность, которая вас ждет, – выбор стартовой точки. Пройдитесь по карте, выбирая маршруты, которые, как вы думаете, помогут вам узнать больше о пользователях и их нуждах. Как и прежде, беспокойство о правильности выбора может быть оправданным. Но лучший способ проверить это, как и лучшая инвестиция в исследование, – просто выбрать несколько маршрутов, создать их, а затем лично или средствами аналитики в реальном времени посмотреть, как люди их используют.Остерегайтесь ложных представлений о продукте. Разница между тем, что, как вы думаете, нужно пользователям, и тем, что им нужно на самом деле, вызвана вашими ложными представлениями о продукте. Реализуя изложенный здесь процесс, вы можете быстрее провести исследования прямо в контексте, создавая и проверяя один маршрут за раз.
Праздновать победу рано
На этом этапе процесса исследования вы уже должны были начать описывать части своего решения в виде отдельных историй. Каждый фрагмент является частью большой возможности. Если мы с вами хоть немного похожи, вам будет удобно организовать все эти части с помощью карты историй. Если вы умнее меня, может быть, изобрели лучший способ и, если это так, уже погружены в работу. Если же вы не склонны к порядку, у вас получится просто большая куча историй. Или, еще хуже, кто-то может написать длиннющий документ с требованиями, который немедленно запутает все, чего вам удалось достичь. Пожалуйста, не допустите этого.
Но с чем бы вы ни подошли к этому рубежу, именно сейчас вы, как и многие другие, испытываете искушение отпраздновать «окончание работы над требованиями». Не поддавайтесь ему. Перед вами последний и самый важный этап работы.
4. Минимизируйте объем работы и составьте план
У вас есть представление решения в словах и картинках, и сейчас ваша команда вполне может гордиться собой. Но самые большие проблемы с исследованиями возникают, когда вся команда работает сообща, чтобы разработать блестящее решение с множеством разных фишек и примочек, которые мы все так любим.
Я знаю, вы думаете: «А что тут страшного-то?»
Как правило, проблема заключается в том, что мы хотим сделать довольными всех и каждого и в то же время упускаем из виду четкие и конкретные ожидаемые результаты. В итоге полученное решение оказывается куда более громоздким, чем должно было быть.
Помните: наша цель в том, чтобы сделать объем работы, необходимый для реализации, как можно меньшим, а пользу, которую мы получаем (результаты и долгосрочные эффекты), – как можно большей. Ваша возможность разбита на множество маленьких индивидуальных историй. Вряд ли вы собираетесь реализовать их все до одного, ведь в таком случае о минимизации объема работы и речи не идет.
Если вы не отбросили больше историй, чем оставили для реализации, то, скорее всего, исследовательская работа проделана неверно.
Ресурсов всегда будет не хватать
Я очень сожалею, но это все еще так. Если вы имеете какой-то опыт в разработке программного обеспечения, то, скорее всего, и без меня это знаете. Я много лет – почти десять – пробовал притворяться, что это неправда, но в конце концов пришлось взглянуть фактам в лицо. Вам тоже придется с этим смириться. Но не волнуйтесь: есть способы выделить какую-то часть, которую реально построить при имеющихся у вас временных и человеческих ресурсах.
В главе 3 вы прочитали о том, как в Globo.com использовали карты, чтобы уложиться в жесткие временные рамки. Компания сконцентрировалась на дедлайне, чтобы выделить достаточный для успеха объем работы. Затем бэклог был разбит на части: все, что не было необходимо для достижения нужного результата, отбросили. Таким образом появилось предположительное минимально жизнеспособное решение. И это не была грубая, слабо очерченная версия большой идеи – это было в самом деле блестящее решение, точно нацеленное на достижение необходимого результата к выборам в Бразилии. Ребята из Globo.com были уверены, что эта работа принесет пользу их бизнесу, рекламодателям, телевизионным компаниям и клиентам. Они подумали обо всех своих пользователях и были уверены, что делают для них что-то нужное. А разделив карту на части, они сформулировали решение, которое можно было реализовать силами своих команд за имеющееся время. Сочетание ценности, полезности и реалистичности для конкретных пользователей, заказчиков и задач и является жизнеспособным решением.
Жизнеспособность означает успех решения для конкретной бизнес-стратегии, конкретных пользователей и заказчиков.
Мы можем сразу же применить этот подход не только к первому, но и ко второму и к третьему релизам, чтобы обеспечить и их жизнеспособность. Но мы знаем: как только первый релиз выйдет в свет, мир изменится (и это хорошо). Это автоматически означает, что нам нужно будет пересмотреть свои будущие релизы с точки зрения новых условий, которые мы создали.
Секрет расстановки приоритетов
Подойдите поближе, я хочу поведать вам один секрет.
Он известен немногим – во всяком случае, люди ведут себя так, словно ничего о нем не знают. Впрочем, быть может, они прикидываются тупицами с каким-то умыслом?..
Если вы какое-то время вращаетесь в мире разработки Agile, то наверняка много раз слышали выражение «расставить приоритеты историй по ценности для бизнеса». Само по себе это утверждение верно, но, видя слова «ценность для бизнеса», хотелось бы понимать, что конкретно под ними подразумевается. Вы и ваша команда должны определить, что в данном случае будет ценным для бизнеса.
Давайте снова вернемся к MadMimi. Гэри нужно было придумать продукт, который быстро завоевал бы определенный рынок, прежде чем закончатся деньги. Жизнеспособность, с точки зрения Гэри, означала, что у него были бы клиенты, полюбившие продукт и готовые за него платить. Затем он начал бы увеличивать аудиторию продукта и, как следствие, свою прибыль.
Данная бизнес-цель в сочетании с финансовыми ограничениями заставила Гэри сконцентрироваться на конкретных пользователях и их задачах, которых он решил поддерживать. Гэри не оставлял надежду создать «маркетинговый интерфейс музыкальной индустрии», давший Mimi название, но для начала решил сфокусироваться на задачах менеджера, рекламирующего свою музыкальную группу с помощью прямой электронной рассылки фанатам. Как только Гэри принял это решение, конкретные функциональности, над которыми следовало работать, стали яснее ясного.
Если вы сейчас читали внимательно, то, конечно, уже поняли, в чем секрет расстановки приоритетов.
Конкретные результаты, необходимые бизнесу, устанавливают фокус на конкретных пользователях, их целях, а также действиях, которые они проделывают в нашем продукте. Фокус же на действиях, в свою очередь, привлекает наше внимание к каким-то конкретным функциям и инструментам, которые нужны пользователям для достижения своих целей.
Работая над MadMimi, Гэри принял взвешенное решение сконцентрироваться на достижении целей менеджеров, рекламирующих свои ансамбли. Это и была конкретная ценность, которую он поставил своей основной целью. Он не использовал абстрактное понятие «ценность для бизнеса», а совершенно конкретно определил то, что будет иметь ценность для него.
Ошибка большинства людей в том, что они пытаются сперва расставить приоритеты функциональностей.
Начните с расстановки приоритетов бизнес-целей, заказчиков и пользователей, а также их задач и лишь потом расставляйте приоритеты функциональностей.
В следующий раз, услышав, как кто-то интересуется, у какой функциональности самый высокий приоритет, без обсуждения бизнес-целей, целевых пользователей и ценности для них, сочтите это хорошей возможностью начать задавать вопросы. Постарайтесь не быть слишком высокомерным: все-таки не все знают этот секрет.
Назад: Суть исследований не в создании программных продуктов
Дальше: Действия, обсуждения и артефакты в исследовании
