Путь аналитика от получения пожеланий бизнеса до подготовки ТЗ для разработчиков: на примере реального кейса

[oldzas]

Между бизнесом и разработкой - работа с требованиями (и их формализация) - у вас ее нет. Максимально сырая постановка.

[BA_TW]

Это не было задачей данной статьи. Я хотела показать, с чем, с кем и на каких этапах приходится работать системному аналитику, что он получает на вход и что выдает на выходе. Детальная проработка требований - это тема отдельной статьи.

[Kanamaha]

В этой статье на реальном кейсе я хочу рассмотреть весь путь превращения требований от бизнес-заказчика в техническое задание для разработчиков

Таки заявлена цель статьи в первом же предложении. Однако дальше идет перечисление гипотез маркетинга и сразу:

Собственно говоря, на основе этих пунктов любой начинающий аналитик без труда напишет юзер-стори.

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

[BA_TW]

Да, отчасти Вы правы. Мы слепо доверились маркетингу. :-)
Но у нас ситуация, когда у пользователя богатый положительный опыт конкретно в нашем магазине, поэтом мы можем смело доверять анализу его активности и советовать именно то, что выдаст мат модель.

[BosonBeard]

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

[BA_TW]

Спасибо. :-)

[Tat_Ksard]

Скажите, а зачем вам три разных эндпойнта, если контракт запроса-ответа один и тот же?

• Если в магазине появится новый раздел - придется делать новую "ручку"

• Если потребуется изменить контракт (добавить вывод картинки, например) - придется дорабатывать все три "ручки"

А если передать кодовое название раздела в параметрах запроса - и у вас будет универсальный масштабируемый инструмент

[BA_TW]

Спасибо за комментарий! В итоге так и сделала. :-) Выложила статью еще до того, как до конца продумала и проработала ТЗ. В итоге после дополнительных размышлений сделала да, один endpoint. Но статью решила не исправлять.

[ViseMoD]

Отличный подход, продолжайте в том же духе!

[Katerina_yrs]

Интересно. А менеджер проекта тут участвовал или его роль отчасти выполнил аналитик?

[BA_TW]

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