Country not specified
Unknown website Share

Apps4all

Страна: -
Город: -
Был онлайн: -
О себе:
 
08-07-2016, 10:59
Apps4all

Андраш Густи (Бегемот-Бегемот): «Юзерстори – это концептуально, просто и модно»

​Процесс разработки мобильного приложения состоит из нескольких последовательных этапов. Первоначальным и в итоге во многом определяющим конечный результат является написание User Story.

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

Андраш, добрый день. Для начала разговора расскажите, как вы попали в mobile?

Все началось в 2011 году, когда под брендом «Yord» мы начали разрабатывать свои приложения. Сделали несколько, успешно их запустили и наделали невероятное количество ошибок. Несмотря на то, что некоторые оказались довольно популярными, стоимость наших ошибок была настолько велика, что мы не смогли выйти в ощутимую прибыль. Однако, набитые шишки и в итоге успешные попытки от них избавиться, позволили нам консультировать других начинающих предпринимателей в мобильной сфере. Так в 2013 году стартовала наша клиентская разработка.

Сначала мы делали акцент на дизайне: программирование оставляли либо за клиентом, либо арендовали программистов у других компаний. Вскоре поняли, что настоящее качество можно обеспечить только с помощью своего штата разработчиков и тестировщиков. Так мы превратились в то, что мы есть сейчас: студия «Бегемот-Бегемот» по разработке мобильных приложений на заказ, с большим акцентом на дизайн, как архитектуру и глубокое погружение в бизнес-составляющую продукта.

Как «убиваются» проекты?

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

А расскажите подробнее о том, что такое юзерстори и что такое юзкейс?

Это два концептуально разных подхода к описанию взаимодействия пользователя с приложением. Юзкейсы – это фундаментально, тяжело и немодно. Юзерстори – это концептуально, просто и модно. Первые возникли давно, использовались при единственном ранее распостраненном способе разработки – водопадном: когда мы говорим, что через десять лет построим «Титаник» и упорно строим его, наперед четко прописывая, что именно мы будем делать, затем тратим еще двадцать лет и раз в десять больше бюджета, чем планировалось. Утрирую, но в общей сложности так и есть.

При таком подходе имеет место быть BigDesignUpfront, то есть дизайн всего-всего заранее. Поскольку разработка длится очень долго, можно 100500 раз забыть, что может/должен делать пользователь и как может/должна реагировать система. И описание мы строим соответствующим образом: пользователь сделал тык – система отреагировала так-то. Это очень механичное, скучное, техническое и громадное описание, которое, как любая всеобъемлющая инструкция, пытается предусмотреть все возможные ситуации, и при этом не является применимой к жизни. Юзкейсы – это талмуд, которым можно отлично прикрыть свою задницу и который никто не читает.

С юзкейсами, на этом, наверное все.

Юзерстори появилась во вселенских масштабах где-то в одно время с другими способами облегчить разработку продуктов: agile, то есть гибкая, итеративная разработка и mvp, то есть минимально жизнеспособный продукт, который предполагает наличие минимальной функциональности для достижения оптимального бизнес-результата. Характиристики этих процессов похожи: делаем мелкие, осмысленные шажочки, держа в голове картину того, куда мы хотим двигаться, но всегда предполагая, что в любой момент нам, возможно, придется развернуться в другую, или даже противоположную сторону. Предполагается, что продукт может и должен эволюционировать.

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

Так и появились юзерстори: человеческое описание взаимодействия пользователя с ситемой; лаконичное, простое, с пользователем в центре внимания. В отличии от юзкейсов, юзерстори отвечает на вопрос не «что пользователь может сделать», а «что пользователь хочет, и как мы можем помочь ему достичь своей цели». Фундаментальное отличие, на самом деле.

Пример юзерстори: «я, как водитель такси, хочу посмотреть заявки для того чтобы выбрать потенциального клиента».

Пример юзкейса: «пользователь нажимает на кнопку «список заявок», «система выдает список заявок».

Когда использовать одно, а когда – другое?

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

Как определить, почему нам нужны именно юзерстори?

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

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

558154f04db520.16445829.jpg

Как правильно составлять юзерстори? С чего лучше начинать при составлении?

В первую очередь, стоит максимально честно определить понимание того, что, как и для кого должен делать продукт. Ниже опишу нашу практику, хотя можно придумать и свою.

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

  • Как определить смысл приложения одним предложением (до семи слов)?
  • Кто наш пользователь (именно один, конкретный, описанный)?
  • Какая у него формальная потребность (вселенское добро, которое мы транслируем наружу, например, общение или мир во всем мире)?
  • Какая у него базовая потребность (то есть, боль; обычно – это что-то не очень хорошее, например, вожделение, лень, тщеславие – как из Библии, в общем)?
  • Какие у нас три основные инструмента для удовлетворения этой потребности?
  • Какое у нас целевое действие пользователя, критично важное для него и критично важное для приложения?
  • Какой основной способ заработка для приложения?
  • Как выглядит взаимосвязь инструментов и целевого действия со способом заработка приложения?
  • Какая у пользователя причина, по которой он будет возвращаться в приложение регулярно?
  • Как должна эта причина отражаться в интерфейсе (на данном этапе – в виде концепции)?

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

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

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

5581540c75b1b7.98960180.jpg

Очень важно помнить про характеристики хорошей юзерстори. Их шесть, и называются они INVEST (по первым буквам слов из списка ниже). Каждое слово, стоящее за каждой буквой этой аббревиатуры, критически важно для составления эффективной юзерстори. Поэтому стоит их хорошо запомнить:

  • Independent: юзерстори должна быть законченной сама по себе и не быть связанной с другими.
  • Negotiable: мы должны осознавать, что, возможно, нам придется что-нибудь поменять в этой истрии, так как она по определению не может быть окончательной.
  • Valuable: каждая история должна рассказывать о какой-то понятной для пользователя ценности.
  • Estimable: мы должны быть в состоянии оценить трудозатраты, необходимые для реализации этой истории.
  • Small: времени на реализацию должно уходить немного (от четырех часов до четырех дней).
  • Testable: описание самой истории должно вмещать в себя формулировки, на основании которых в дальнейшем можно будет проверить (протестировать) верность их исполнения.

Такая система позволяет довольно быстро выпускать осмысленные вещи, сведя риски к минимуму. Ведь теперь мы действительно сконцентрировались на самом важном и есть гарантировано четкое понимание сути продукта и его потребителя.

Параллельно с юзерстори можно делать тесткейсы, описывать технические требования и способы проверки; с одной стороны, это хорошо, но на практике может увести в ненужную бюрократию. Базовая версия юзерстори должна быть лаконична и понятна всем. Поэтому, если есть возможность сделать проще, то лучше делать проще.

К каким источникам вы обращаетесь при составлении user story?

Здесь можно действовать по-разному. Если речь идет о мобильном приложении для существующего бизнеса или бизнеса, хорошо понимающего своего потенциального пользователя, то мы обращаемся к нему. Все-таки центр юзерстори – пользователь. Мы знаем, как среднестатистический мобильный пользователь себя ведет, понимаем его психологию, и на это уже накладываем данные от владельцев бизнеса.

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

Есть мнение, что методика user story подходит только для agile-команд, вы согласны с этим?

Юзерстори изначально вышли из agile-методики и легко накладываются на все их рабочие процессы. Но не вижу ничего плохого или сложного в том, чтобы использовать юзерстори при водопадной разработке. В некоторых случаяхэто даже добавит определенной легкости в такой сложной методологии.

558153fdd26019.61708505.jpg

Почему юзерстори важны для программистов?

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

Приведите примеры удачных и неудачных юзерстори.

Как вариант, можно привести выдуманные неудачные примеры юзерстори, на основе нашего приложения SmartReading:

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

Удачные примеры юзерстори для нашего приложения SmartReading:

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

Как видите, в последних трех вариантах все просто, лаконично и понятно.

У вас есть какой-то интересный лайфхак о том, как использовать юзерстори в ежедневной жизни?

Юзерстори помогает нам концентрироваться на самом важном и достигать того самого эффекта Паретто, когда 80% результата достигаются 20% усилий. Если практиковать такую разработку, то со временем вы начнете наблюдать, что даже не осознавая этого, используете такой подход во всем: от времеи, проведенного в торговом центре, до времени, проводимого за разбором почты. А все потому, что появляется прицел на результат, а не на процесс.

5581547a38fa90.95934344.png

Наш традиционный вопрос: какие приложения есть в вашем смартфоне?

В основном, это приложения для работы, которые есть у всех – Skype, GoogleDocs, продукты Яндекса, почта. Приложения, которыми особенно приятно пользоваться и которые не связаны с работой – это, например, GarageBand для записи и обработки музыки, или приложение Paper, для рисования и создания презентаций.

Андраш, спасибо большое за интервью, это было интересно и конструктивно! :)

 
user story
юзерстори
дизайн
приложения
пользователи
разработка
мобильные приложения
mobile
смартфон
0 0 0

Чтобы оставлять комментарии вам необходимо зарегистрироваться