Как провести Discovery на новом проекте: конкретные шаги и примеры

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

Сказать, что украинские IT-компании рутинно проводят полноценные Discovery на новых проектах — преувеличить, если не соврать. Наш рынок завоевывает все больше доверия у иностранных заказчиков. Если ваша компания хочет и может взять фазу Discovery на себя, это преимущество выделит вас среди конкурентов.

Жизненный путь проекта начинается с фазы Discovery и переходит в фазу Delivery.

В рамках Discovery мы:

• исследуем предметную область;
• исследуем бизнес-процессы заказчика;
• узнаем ожидания заказчика от нового продукта;
• выявляем узкие места;
• формулируем решения его проблем на высоком уровне;
• расставляем приоритеты и формируем backlog;
• составляем roadmap проекта.

Есть первоначальные условия, которые позволят провести Discovery:

• доверие заказчика;
• его желание идти вам навстречу ради хорошего результата;
• относительная свобода сроков.

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

Нет единой схемы, как провести дискавери, но есть эффективные сценарии. Например, Double Diamond дизайн-процесс:

О том, как можно применить его на практике и пойдет речь.

Что произошло в реальности?

Наш партнер — компания Х, где многие процессы все еще не автоматизированы и выполняются вручную. И да, в ее распоряжении уже существуют несколько систем, которые позволяли компании Х делать свою работу:

• Frontstage: общедоступный сайт для внешних пользователей.
• Backstage: тяжеловесное desktop-приложение + система хранения и обработки документов сотрудниками компании Х. На backstage действует множество ролей, его задача — обработать заявки пользователей, пришедших с frontstage... или как-то еще (интрига).

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

Наша команда: два дизайнера и бизнес-аналитик. Позже к нам присоединились архитекторы и инженеры по качеству.

Шаг 1. Discovery Initiation

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

Это самый легкий этап, но лучше им не пренебрегать.

Выгоды для команды:

• Вместо надвигающейся горы задач команда получает примерный план, что делать и чего не делать.
• С другой стороны, план дисциплинирует и задает планку качества: «Мы сделаем это и это, сделаем так и так. Мы будем ориентироваться на артефакты до самого релиза проекта».

Выгоды для отношений с заказчиком:

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

Что произошло в реальности?

Решили делать короткие спринты по 4-5 дней с ежедневными статус-митингами. Что касается инструментов:

• задачи хранили в Trello;
• пользовались interview cards;
• записывали интервью и сессии обучения дефолтным для мака QuickTime Player;
• для диаграмм и ментальных карт подошло бесплатное Гугл-приложение draw.io;
• прототипы — в Sketch (планировали еще Axure и inVision).

Шаг 2. Изучаем материалы удаленно

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

После этого ваши первые помощники — служба поддержки пользователей сайта. Эти люди сходу назовут вам основные проблемы пользователей: новых и опытных.

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

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

Выгоды для команды:

• Первые впечатления и незамыленный глаз выявят то, что позднее может потеряться.
• Команда может составить первое впечатление о продукте в роли пользователей. Такие вот неофициальные юзер-тесты. Пока команда не вовлеклась в разработку, такие тесты можно считать объективными.

Выгоды для отношений с заказчиком:

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

Что произошло в реальности?

Frontstage

Поддержка сайта предоставила .csv файл с ~13 000 обращений за последние 3 года. Первая пара тысяч записей показала: типичных проблем — не больше пяти. Например, кроме банального восстановления пароля, в случае коллективной заявки пользователи не могли добавить своих коллег. Эта функциональность на сайте есть, но, очевидно, разобраться с ней нелегко.

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

Backstage

Новичку нужно в среднем 6 месяцев (!), чтобы разобраться с backstage-системой. Клиент предоставил нам их стандартное обучающее видео. Роликов было немного, и учитывая общий срок адаптации, погоды они не делают.

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

Шаг 3. Проведение удаленных интервью

Понимающий клиент с удовольствием предложит вам список кандидатур для интервью. Если нет, попросите его сами.

Даже самое отдаленное представление о функциях перечисленных людей позволит составить «interview cards». Это общие вопросы об их работе, которые так или иначе придется задать. Всегда оставляйте место на карточке для уточнений или информации, которую нельзя было предусмотреть.

Выгоды для команды:

• Удаленные интервью не требуют такой тщательной организации, как личные.
• Это прекрасный формат, когда у вас лишь поверхностные знания о бизнесе вашего клиента.

Выгоды для отношений с заказчиком:

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

Что произошло в реальности?

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

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

• с директорами по развитию, которые рассказали, что делает организация, откуда приходят потоки заявок и что их ожидает на backstage;
• с архитектором существующей backstage-системы, которая писала и кастомизировала ее в течение последних 15 лет;
• с членами разных backstage-команд, подробно описавших цикл, который проходит типичная заявка;
• со службой поддержки.

На этом этапе было решено разделить наше исследование на два этапа: сначала Discovery frontstage-сайта, а затем — backstage-системы.

Шаг 4. Результаты и артефакты discovery frontstage

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

Допустим, вы провели интервью и начали ориентироваться в сфере бизнеса заказчика. Как структурировать полученную информацию?

1. Определите стейхолдеров продукта.
2. Выделите главные проблемы пользователей (pain points). Может быть полезно их классифицировать по происхождению.
3. Назначьте приоритет каждой проблеме.
4. Вспомним схему Double Diamond. Каждая проблема является запросом на улучшение (opportunity). Если начать вопрос с «How might we..?», то укажем и на проблему, и откроем возможность пофантазировать над ее решением. Например, «How might we help clients get real time feedback from the system?». Записываете их.
5. Проводите сессию мозгового штурма по списку «How might we...» вопросов. На этом этапе подключаем архитекторов и сочувствующих (QA/QC).
6. Создаете lo-fi прототипы, если это нужно.
7. Создаете Product Vision или Service Blueprint (или что вашей душе угодно), что позволит подробно и полно описать, как работает нынешний продукт и как будет работать будущий.
8. Составляем roadmap.

Выгоды для команды:

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

Выгоды для отношений с заказчиком:

• Споры о приоритетности задач будут решены уже на этом этапе.
• Заказчик обретает первое видение будущего продукта, когда еще не написана ни одна строчка кода и не нарисована ни одна страница.

Что произошло в реальности?

Стейкхолдерами стали: все виды внешних юзеров — индивидуальные и организации; все backstage-команды, напрямую соприкасающиеся с внешними юзерами в ходе своей работы.

Почти все обнаруженные проблемы относились к:

• процессам (например, многие организации, обращающиеся в Х с заявками, требуют особого, нестандартного подхода; служба поддержки разрывается между разными инструментами, внедренными в течение многих лет; сложно быстро обнаружить срочную заявку);
• удобству интерфейса;
• коммуникации;
• техническим ограничениям системы;
• человеческому фактору (раскрывается #интрига: юзеры пользуются не только сайтом, но еще и присылают свои заявки с вложениями просто по email или даже по наземной почте. Сколько усилий требует обработка таких заявок для компании Х?).

Мы внесли все проблемы в Decision Matrix. Она строится на двух осях: Urgent — Not Urgent и Important — Not Important. Само собой, критическое значение имеет квадрант Urgent — Important.

Как мы описали инсайты с помощью вопроса «How might we...»: «Как помочь клиентам присылать заявки только через сайт?», «Как помочь клиентам настроить совместную работу над заявкой?» и так далее.

При мозговом штурме вы атакуете заданные вопросы, ищете варианты ответов на них. Мы объединили мозговой штурм с построением ментальных карт. Вы здесь ничего не разберете, но цель картинки не в этом.

С этим мы прибыли в офис заказчика за подтверждением того, что Discovery идет в правильном направлении. На этом мы приостанавливаем его. Теперь пора взяться за backstage и создать артефакты, которые соединят обе системы.

Шаг 5. Проведение интервью на выезде

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

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

Можете вновь воспользоваться interview cards, делайте записи, получите разрешение делать аудио- и видеозапись, если такая возможность в компании предусмотрена (часто — запрещена).

Выгоды для команды:

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

Выгоды для отношений с заказчиком:

• Вы увидите сами: многие действия сотрудников клиентов монотонны или повторяются. Пользователи оценят, если и вы это заметите.
• Если вы бережно отнесётесь к тому, чем компания заказчика пользуется сейчас, это тоже будет в вашу пользу: многие с опаской относятся к радикальным решениям. Даже если вы можете аргументировать решение начать все с нуля и построить нечто совершенно новое, помните: ваша аудитория занимается своей работой не первый год, она может сомневаться, что вы изучили все подводные камни их деятельности. Это особенно важно, если текущий продукт разрабатывали штатные сотрудники компании. Покажите уважение к их продукту. В конце концов, то, что вы сделаете в результате, может так и остаться невостребованным, а имеющиеся инструменты как-то да справляются. Вы это знаете — и они это знают.

Что произошло в реальности?

Настало время нам перенестись в офис компании Х.

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

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

Шаг 6. Результаты и артефакты дискавери backstage

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

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

Стейкхолдеры: все виды внешних юзеров — индивидуальных и организаций; все backstage-команды.

Мы пошли по проторенному пути и разделили обнаруженные проблемы по происхождению. В этот раз не сводили проблемы в Decision Matrix. Все они все равно попали бы в квадрант Urgent — Important.

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

Сессия мозгового штурма + ментальные карты с участием архитекторов и тестировщиков.

В это время стало ясно, что цель — объединить frontstage и backstage в одну платформу с одной точкой входа. Ментальные карты показывали, что сделать хочется много (очень много). Решили пойти по пути создания Minimum Viable Product и последующего его расширения.

Общий backlog для наглядности разбили на задачи, глобальные для платформы и специфичные для frontstage и backstage. Так в MVP попали почти все задачи для frontstage и половина глобальных.

Составили диаграмму Гантта для первых месяцев фазы Delivery. Она и стала основной roadmap’а проекта.

Вывод

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

А с точки зрения дизайна, проведение фазы Discovery — подтверждение, что основная работа дизайнера над проектом происходит еще до прототипа или первой нарисованной формы.