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

Зачастую эти роли могут помещаться в одного человека 🙂 В нашей команде итоговое решение принимает Product Owner на основе проделанной аналитиков работы.

Я бы предложила попробовать найти что-то общее. Для меня это всегда про наличие последовательности действий, про участников и их роли в бизнес-процессе, про ограничения и условия. То есть входя в новую сферу стоит сначала изучить терминологию, специфику отрасли и ее проблемы. Затем расписать действия, роли, ограничения, например, взяв за основу Customer Journey Map. То есть по сути, аналитик, расщепляет весь процесс или систему на составные части, а потом собираем в цельную картинку. И если мыслить именно процессом расщепления, то его можно применять в любой сфере 🙂

Конечно! Митап это возможность посмотреть на свои задачи и решения под другим углом, узнать с какими вызовами можно столкнуться при реализации различных продуктов

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

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