Декомпозиция. Критерии приёмки.
Скажите честно, часто ли к вам «прилетают» задачи со словами: «Сделать продукт самым крутым», или «Интерфейс должен быть понятным», или «Всё должно работать быстро»?

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

Знакомо, не правда ли!

Из названия вы догадались, о чем пойдёт речь. Да-да, как раз о тех самых вопросах: «Что значит крутой?», «Понятный — это какой?», «Быстро — это быстрее 5 секунд?». Отвечая на данные вопросы, вы проясняете мысли заказчика, с одной стороны, а с другой облегчаете себе работу над задачей.

Как только вы вместе поймёте, что для заказчика:
🟢«Крутой продукт» — место в ТОП-5 конкретного отраслевого рейтинга.
🟢Понятный интерфейс — когда 99,9% пользователей проходят по клиентскому пути без обращения к справке.
🟢Быстро — пользователь не ждёт загрузки интерфейса больше 1 секунды.

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

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

Вы уже получили несколько готовых для реализации задач:
🟠функция обновления иконки и подсчёт товара в корзине;
🟠смена кнопки «Добавить в корзину» на «Удалить из корзины»;
🟠интеграция с базой склада для получения актуального количества товара.

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

А теперь пример на самостоятельную декомпозицию. Как потребитель я хочу быстро сделать заказ, чтобы что-нибудь поесть. Ваши уточняющие вопросы можете задавать в комментариях к посту. Я буду отвечать из роли заказчика, и вместе мы получим критерии приёмки и предварительную декомпозицию.

@agileincubator

Декомпозиция. Временные, затем сохраняемые данные.

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

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

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

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

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

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

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

Декомпозиция. Отложить обработку ошибок, логирование.

«Отложить нельзя логировать». Часто сложно сделать выбор, куда поставить запятую.

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

Алгоритм:
1️⃣Посмотрите на свою задачу.
2️⃣Выделите места, где может что-то пойти не так, обозначьте их.
3️⃣Попробуйте разделить крупную историю на задачи разработки функциональности и лишь сигнализации о возникновении исключений.
4️⃣Важен сам факт наличия ошибки. На первых порах можно в ручном режиме проходить пользовательский путь: находить ошибку и затем её исправлять.
5️⃣И уже когда вы исправили самые критические ошибки, а функциональность прижилась, можно приступать к логированию ошибок, сбором разных метрик и подсказок, чтобы эти самые ошибки отлавливать быстрее.

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

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

@agileincubator

📕 Декомпозиция. Фиктивные данные, затем динамические.

Одним из инструментов декомпозиции пользовательских историй, подходящих, к примеру, для продукта «Интернет магазина», является разбивка по вариантам представления итоговых данных.

Рассмотрим подробнее. Наш продукт — это интернет магазин с большим количеством товара. Нам нужно показать товар покупателю. Начнём декомпозицию. ❤️

«Как покупатель, я хочу выбрать нужный мне товар».

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

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

❤️Развитием может стать добавление фильтров. Уже более тонкая настройка отображаемого результата, вместе с сортировкой, которую мы сделали ранее.

❤️Таким образом, мы прошлись нашим методом по пользовательской истории и провели декомпозицию от фиктивных данных до динамично обновляемых.

Потренируемся❤️ «Я как потребитель, хочу искать блюда в меню, чтобы выбрать себе ужин». Попробуйте применить новый метод.

❓А с каким продуктом работаете вы? Подойдёт ли вам этот метод?

📖 Декомпозиция. Вручную, затем автоматически.

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

Так и получается: сначала мы придумываем процесс, решение или действие, доводим его до «совершенства» и только потом начинаем автоматизировать.

❤️А почему бы такой же метод не использовать при декомпозиции задач? Задача почти любого бизнеса в быстрой проверке гипотез. В поиске наилучшего и самого выгодного как для пользователя, так и для системы решения. И порой, автоматизация каких-либо действий или процессов может занимать значительный промежуток времени, за который потенциальная выгода может быть упущена.

❤️ Рассмотрим на примере. У нас есть магазин с услугой доставки. И наш менеджер по продажам хочет собирать отзывы клиентов после каждой завершённой сделки, чтобы улучшать наши продукты и услуги.

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

❤️Первым шагом сделаем для него форму отправки письма из завешенного заказа. В ней можно указать e-mail получателя и текст письма. А ответы он получит на свою рабочую почту. Таким образом, мы создаем ручной процесс запроса обратной связи.

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

Таким образом, можно и дальше автоматизировать процесс вплоть до подключения AI для анализа обратной связи.

❤️ Так получилась декомпозиция от ручного до автоматического процесса.

❓А вы в своем продукте занимаетесь автоматизацией процессов внутри продукта или для клиента?