Дайджест №99

Сегодня в выпуске:

• Отчет с Analyst Day 9. vol.2
• I'm a YouTuber
• Гонка героев. Анонс
• #КнижнаяПолка

Авторы: Меньшиков Алексей, Лалов Антон, Кривоногов Сергей

Как и обещали, продолжаем рассказ о докладах и мастер-классах на Analyst Day 9.

Карта эмпатии

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

Одним из самых практически полезных мастер-классов провел Дмитрий Безуглый (как оказалось знаменитый человек в столичной аналитической тусовке и у него еще на подходе книга о том, как грамотно подготовить постановку на разработку ПО) на тему «Как понять интересы пользователей?». На мастер-классе поднимался вопрос практики формирования карты эмпатии.

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

Составление карты эмпатии будет полезно командам, работающим на розничного клиента, т.к. описание клиента «Дела» детально проработано в брэнд-буке, а вот про розничного клиента мы знаем куда меньше, и такой инструмент, возможно, позволит нам узнать его чуточку ближе. Построение карты эмпатии занимает около 60 минут, что прекрасно вписывается в стандартные рамки мозгового штурма.

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

После того, как мы определились с Персонажем, нужно определить цель – что мы хотим, чтобы он сделал. Например, мы хотим, чтобы он оформил кредит.

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

·        Что в этот конкретный момент клиент видит?

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

·        Что он говорит? Или что он отвечает на поставленные вопросы?

·        Что он в этот момент делает? Вышел с рабочего места в надежде перекусить в тишине или едет в маршрутке домой после рабочего дня?

·        Что он слышит в этот момент? От сотрудника, с которым он взаимодействует вживую или через чат, а может, он читает отзывы в stor’e или на banki.ru, или коллега, уже имевший опыт взаимодействия, поделился впечатлениями.

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

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

Кроме того, карта эмпатии позволит всем членам команды иметь единое понимание кто наш клиент, его возможности, боли и потребности.

P.S.: Интересный пример оформления карты эмпатии :)

Аналитик в продуктовой разработке

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

Основные моменты доклада:

Три этапа цифровой эволюции.

1.      Автоматизация рабочих мест (поставщик понятия не имеет, как и для чего будет использован инструмент).

2.      Комплексная система (сложная цепочка взаимодействия между бизнесом и ИТ; часто ни те, ни другие не имеют полного представления о том, как это работает).

3.      Цифра (цифровая команда (Digital Team), обладающая знаниями и компетенциями для создания и развития цифрового актива).

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

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

Модели разработки.

1.      Традиционная модель:

Бизнес выдает «хотелку» -> Бизнес аналитик -> Системный аналитик -> Разработка -> Тестирование -> Релиз.

Используется Инкрементальный (инженерный) подход:

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

Итог: TimeToMarket (T2M) равен минимум 6-ти месяцам. На самом деле – в разы дольше.

2.      Гибкий процесс разработки

Используется Итерационный подход:

·        Построение простой версии, ее проверка, затем переход к построению качества продукта.

·        Переход от расплывчатой идеи до реализации, корре��тируя решение по мере продвижения.

·        Иди по чуть-чуть – не ошибешься. Даже если понимаешь, что текущего драфта достаточно, значит, его достаточно.

Зафиксировали Время и Ресурсы, а также определили направление движения. Не путать «направление» с «результатом». Данный принцип называется «Time Boxing» - Фиксация времени.

Наглядная иллюстрация отличия двух подходов:

Есть минус – неопределенный T2M. Классический пример – Кёльнский собор. T2M = 632 года. Концепция менялась практически каждый год жизни проекта. Тем не менее, в итоге получился шедевр.

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

В итоге кроме этой цифровой команды больше нет никого, кто знает, как нужно развивать продукт. Команда обладает всем необходимым и достаточным для этого. Если команда не добывает знания в процессе работы над проектом, значит, что-то идет не так. Такой Agile называется «Чип и Дейл: слабоумие и отвага». Такие команды быстро умирают.

Бизнес и системный аналитик

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

Системный аналитик отличается от бизнес аналитика только точкой приложения своей деятельности:

·        Для системного аналитика система – это ПО. Это complicated системы – много сложных и повторяющихся деталей, но меньше неопределенности.

·        Для бизнес аналитика система – это организация. Несколько больше неопределенности.

Методы с точки зрения познания у них одни и те же. И компетенции должны быть очень похожи.

Все данные, собранные аналитиком, должны быть свежими. Каждый релиз команды, как и релиз ее конкурентов, меняет среду и приводит к устареванию требований. Из этого также следует мнение, что практически нет смысла анализировать «возрастные» данные. Что нам скажут данные о том, что предпочитали клиенты 10 лет назад? Совершенно ничего. Даже данные о том, что предпочитают клиенты сейчас, могут нам подсказать, что мы можем сделать прямо здесь и сейчас. Но ничего не скажут о будущем. Ведь уже сегодня кто-то делает что-то, что сделает любые линейные прогнозы на текущих данных не валидными.

И напоследок один из вопросов с доклада:

- Как вы планируете загрузку аналитика? User Story может оказаться больше, чем предполагалось изначально.

- Аналитик – свободный творец. Но должен все успеть…

Для всех желающих программа конференции доступна по ссылке:

https://analystdays.ru/ru/program/62120

По каждому докладу доступны материалы:

·        Оригинал презентации на языке докладчика

·        Видео на языке докладчика

·        Видео с синхронным переводом

P.S.: Никогда, слышите, НИКОГДА не выбрасывайте чеки от командировочных расходов!

Подписывайтесь, ставьте лайки...

А вы знали, что у СКБ ЛАБ есть канал на YouTube? А он есть!

Сюда мы неспешно выливаем видео, которые снимали в ЛАБе или для ЛАБа!

Так что, добро пожаловать, как говорится:

https://www.youtube.com/channel/UCsJSks7XCjd9oEN8wD8LZig/featured?view_as=subscriber

И по классике жанра - подписывайтесь, ставьте лайки и нажимайте на колокольчик, чтобы не пропустить наши свежие видео! :)

Гонка героев 2019

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

Записываться тут: https://docs.google.com/spreadsheets/d/1R3cqqyfvNxAugfw46-KhfSXBwZDPUbGuMJfrUDAktkg/edit?usp=sharing

Это мы как бы предупреждаем...:)

Больше чатов богу чатов

В Слаке Витя Репников создал очень полезный чатик #Книжная_Полка!

Там можно будет посмотреть какие книги из нашей библиотеки где искать в бумажном и электронном виде!

Подписываемся:)