company_banner

Эволюция обзора спринта в Agile-команде

    Привет! Меня зовут Анатолий Савченко, я разработчик и по совместительству скрам-мастер в команде сервиса «Автотека». Как вы уже догадались, мы работаем по Cкраму. Каждые две недели мы проводим обзор спринта — встречу, на которой команда и заинтересованные стороны обсуждают, что было сделано. На основе этой информации команда может сделать выводы о том, в правильном ли направлении движется разработка, какие доработки ещё необходимы и т.д. Недавно мы получили ценный новый опыт проведения этой важной встречи. О нём я и хочу вам рассказать.



    Инструменты получения обратной связи


    Конечно, обзор спринта — это не единственный канал обратной связи: у нас есть UX-лаборатория, мы обрабатываем отзывы в сторах мобильных приложений, обращения в поддержку, отзывы на всевозможных интернет-ресурсах, проводим опросы пользователей на сайте и прочее.
    Это — то, что касается частных пользователей.


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


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


    Обзор спринта — как было раньше


    Наши встречи в целом проходили на хорошем уровне: мы получали оперативные и качественные комментарии от наших стейкхолдеров (то есть внутренних заказчиков — менеджеров) и других коллег из Авито. Создавалась довольно камерная обстановка, но в какой-то момент нам стало не хватать полноты обратной связи. Нам захотелось что-то поменять. И наш agile-тренер Левон Гончаров из AgileVerse навел нас на идею позвать внешних пользователей — наших бизнес-партнеров — прямо на встречу.


    image


    Левон Гончаров, co-founder AgileVerse: «С ребятами я познакомился, когда они решили улучшить свои процессы. Они понимали, что что-то идёт не так, и искали ответ. Во время диагностики каждый член команды так или иначе говорил о необходимости понимать “как живёт пользователь”. На кого-то это влияло с точки зрения мотивации, кому-то необходимо было понять, как развивать проект архитектурно. Это, в принципе, довольно частая проблема скрам-команд — превращение обзора спринта в встречу, где рассказывают то, что было сделано и мыслят не как создатели, а как исполнители. Чтобы этого не допускать, нужно задуматься вот о чем.

    №1 Когда вы разрабатываете продукт, вы больше думаете о фичах или о проблемах пользователя?
    №2 Вы знаете, как живёт ваш пользователь и для чего он должен использовать ваш продукт?
    №3 Достаточно ли часто вы общаетесь с теми, кто пользуется вашим продуктом?
    Я посоветовал команде обсудить эти вопросы и изменить формат обзора спринта.

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


    Подготовка


    Для начала мы с Левоном собрали с коллег ожидания от новой встречи, после чего спланировали повестку и подготовили все необходимые материалы.
    Могу сказать, что про одну только подготовку можно было бы написать целый пост. Она позволила создать нам целостную картину встречи и абсолютно всё учесть (конечно, мы учли не всё, потому что это невозможно, но мы учли и это).


    Сначала мы расписали на флипчарте цель и образ результата. Прописали по пунктам общий план встречи. Детализировали наполнение каждого этапа.
    Прописали тайминги всех этапов (и несколько раз переписали их). Определили для каждого этапа необходимые материалы и записали, что нужно не забыть взять на встречу.


    Вкратце у нас получилось вот что.


    Цель


    1. Проговорить фокус команды на квартал
    2. Понять, насколько обновленный личный кабинет пользователя (ЛКП) удовлетворяет потребностям
    3. Показать тизеры и сформулировать план на 1-2 спринта

    План


    1. Открытие (5 минут)
      a. Agenda
      b. Рассказываем, как давать фидбек
      c. Знакомство с командой
    2. Общая часть (15 минут)
      a. Что сделали?
      b. Планы на будущее (фокусируемся на квартал)
      c. Q&A
    3. Demo (15 минут)
      a. Обсуждаем
      b. Тизеры
    4. Диалог по ЛКП (10 минут)
      a. Что обнаружили? (что так, что не так)
      b. Когда доработаем (примерный спринт)
      c. Что заменить? (говорим про жизнь пользователя)
    5. Сбор фидбека на формат ревью (5 минут)

    Образ результата


    1. Фидбек по квартальным планам
    2. Список доработок по ЛКП
    3. Обсудить самые сильные боли пользователя, записать остальные
    4. Обсудить общее понимание тизеров, планы на 1-2 спринта
    5. Фидбек на формат ревью от участников

    image


    Левон Гончаров, co-founder AgileVerse: «Когда мы заполняем примерную повестку встречи, выписываем всё, что может произойти на ней и какими способами мы можем этим управлять. Мы предположили, что пользователи начнут говорить об совершенно общих болях и мы внесли это в дизайн обзора спринта. Но в процессе подготовки стало ясно, что места на это не хватит. Так что мы получили полезную информацию перед встречей, что общие темы мы затрагивать не сможем».


    Как всё прошло



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



    Ну, получилось чуть больше, чем два члена команды у каждого гостя


    Обсуждение получилось насыщенным, и мы даже продлили показ продукта по времени. В результате не только получили массу полезных комментариев, но и узнали о том, как построена работа нашего партнёра изнутри. Это поможет нам в планировании дальнейшей работы над продуктом.



    Так выглядела первая версия продукта


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



    Версия продукта после правок


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


    Мы как команда получили очень ценный опыт. Вот что говорят мои коллеги.


    image


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

    image


    Мансур Ахмади, QA Автотеки: «В голове инженера образ конечного пользователя и его UX зачастую расходится с реальной картиной мира, что в свою очередь может привести к не самым подходящим решениям. На прошедшей встрече это было достаточно наглядно, когда наш гость обозначил свое видение продукта. То видение, которое доставило бы ему больше счастья. То видение, на которое нам стоит ориентироваться. На мой взгляд, именно такие встречи помогают быстрее к нему прийти».

    image


    Андрей Тумкин, product owner Автотеки: «Первое, что может прийти на ум, перед тем как позвать реальных пользователей на демо — зачем? Мы же на ранних этапах выявили их боли, а после релиза соберём обратную связь и внесём правки. Но не всё так просто.
    Во-первых, вы будете терять время и деньги, вместо того, чтобы сразу решить проблемы пользователей. Во-вторых, даже проведенный до разработки CusDev не сможет выявить всех проблем, которые вскроются в реальном продукте. В-третьих, никакой другой процесс не даст такой вовлеченности команды в продукт».


    Заключение


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

    • +13
    • 5,1k
    • 9
    Авито
    163,38
    У нас живут ваши объявления
    Поделиться публикацией

    Похожие публикации

    Комментарии 9

      0
      Толя, отличная статья! Спасибо большое!

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

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

      Спасибо!
        0
        Костя, здравствуй!
        Так как это была наша первая ласточка, мы позвали двух наших партнеров, из них явился только один=) Таких партнёров у нас в принципе небольшое количество, в отличие от простых частников, пользующихся основным продуктом.
        Это был представитель крупного автодилера, поэтому было очевидно, что некоторые его пожелания релевантны только для больших масштабов(например, просьба предоставить более сложную иерархию сотрудников с правами доступа). Однако, в нашем случае нам было важно понять, понимает ли вообще пользователь, как пользоваться представленной функциональностью. Оказалось, что не особо.

        Если ты имеешь ввиду трудности непосредственно на самой встрече, то, пожалуй, разве что растянулась сессия демо продукта. Как мы и предполагали, дошедшему до нас пользователю захотелось сразу излить душу и многое нам рассказать. Так что на это нужно сразу закладываться.
          0
          Спасибо большое за развернутый ответ!
          Продолжайте делиться опытом — это очень интересно.
          0
          Умные люди говорят, что хотя теоретически вам нужны большие выборки и все такое, на практике после 5 пользователя порядка 90% болей пользователя будет повторяться и эффективнее три раза выпустить доработанный продукт и потестить суммарно на 15 пользователях, чем ждать светлого будущего с полномасштабным исследованием.
          0
          И наш agile-тренер Левон Гончаров из AgileVerse навел нас на идею позвать внешних пользователей — наших бизнес-партнеров — прямо на встречу.

          Я правильно понимаю что "обзор спринта" это Sprint Review и у вас на нём обычно не присутствует никто из внешних пользователей/заказчиков/клиентов? То есть даже Stakeholder'ы обычно не присутвуют?


          Или "внешние пользователи" это просто обычные сотрудники вашего заказчика?


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

          Мы такое обычно делаем после отдельных "командных" Review и каждая команда демонстрирует какие-то свои вещи, а "гости" просто ходят и смотрят где им интереснее что посмотреть. И как я понял это не особо то и ново и называется "Scrum/Review bazar".

            0
            Я правильно понимаю что "обзор спринта" это Sprint Review и у вас на нём обычно не присутствует никто из внешних пользователей/заказчиков/клиентов? То есть даже Stakeholder'ы обычно не присутвуют?

            Да, это Спринт ревью. Stakeholder'ы(то есть заказчики — наши менеджеры, биз дев) присутствуют, а внешние пользователи, клиенты — нет.


            Мы такое обычно делаем после отдельных "командных" Review и каждая команда демонстрирует какие-то свои вещи, а "гости" просто ходят и смотрят где им интереснее что посмотреть.

            Что вы имеете ввиду под "командными" ревью? И что за "гости"? Это сотрудники компании или приглашенные извне пользователи продукта?


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

              0
              Что вы имеете ввиду под "командными" ревью?

              У нас у каждой команды свой Sprint Review, на котором присутствует только Stakeholder того продукта над которым работала команда. Ну и его сопровождающие, если он например решил кого-то с собой привезти.


              И что за "гости"? Это сотрудники компании или приглашенные извне пользователи продукта?

              Это все подряд. То есть могут и разработчики/PO/тестеры приходить смотреть что и как делается в других командах. И просто люди из нашей фирмы, например из саппорта. И Stakeholder'ы других продуктов и их сопровождающие.

            0
            Старая-престарая книжка «Веб-Дизайн: книга Стива Круга, или „не заставляйте меня думать!“ наверное могла бы очень помочь тем, кому статья кажется интересной.
            Там в конце про пользовательское тестирование.
              0
              В PMBook это одна из областей знаний со сводом лучших практик «Управление заинтересованными сторонами». И нет большой разницы Agile или Waterfall. Кроме того, что в Agile эти ошибки менее фатальны.

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

              Самое читаемое