Как ты реагируешь на требования заказчика, которые противоречат лучшим практикам разработки мобильных приложений?

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

🟠 Он всё обосновал и вы согласны с решением;
🟠 Он согласен с твоими доводами и выбирает твоё решение;
🟠 Договориться не удалось, но ты понимаешь, что решение заказчика неоптимальное.

В случае третьего исхода, можно:

➡️ Провести дополнительную аналитику (анализ конкурентов, анализ метрик и т. д.);
➡️ Подсветить возможные риски при реализации его решения;
➡️ Подготовить возможные альтернативные решения, которые будут удовлетворять требования заказчика.

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

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

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

Основными из способов являются:

🟠 Анализ конкурентов (функциональности приложений, отзывы пользователей в сторах и т. д.);
🟠 Опросы и интервью с целевой аудиторией;
🟠 Имеющиеся артефакты заказчика.

Как решить конфликт между дизайнером и разработчиком при создании пользовательского интерфейса мобильного приложения (МП)?

Избежать конфликты невозможно, но возможно их грамотно разрешать. Главное, разобраться в аргументах всех сторон и принять взвешенное решение, основанное на фактах, таких как:

🟠 Аргументированные мнения сторон конфликта;
🟠 Существующие решения в МП (важно сохранять консистентность дизайна);
🟠 Возможные технические ограничения;
🟠 Требования бизнеса.

Этот список можно продолжать долго, но главное, что при разрешении конфликта необходимо аргументированно обосновать то решение, которое принимает аналитик.

Как двум подрядчикам сработаться и не сойти с ума

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

В новой статье на Хабр об этом подходе и рассказываем. Точку зрения команды бэкенда расскажет Наташа, системный аналитик компании Интаро, со стороны фронтенда — 🏄‍♂️ Лиза, Surf Analyst.

🟠 Читать статью

#surf_analyst #surf_habr

Вакансия: системный/бизнес-аналитик в Surf 🏄‍♂️

Набираем крутых ребят в отдел BA Surf! Ты будешь документировать требования к продукту, писать ТЗ для разработчиков и участвовать в создании больших и амбициозных проектов.

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

🟠 Мы подходим к реализации проектов как полноценных продуктов, так что точно будет интересно 😊

➡️ Знакомься с требованиями и присылай резюме по ссылке.

#surf_vacancy #surf_analyst

Что такое рефакторинг, и когда он нужен?

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

Разберёмся, что это за зверь и в каких случаях может понадобиться.

Рефакторинг бизнес-логики — это изменение внутренней логики или алгоритмов бизнес-процессов. В контексте разработки ПО — это валидация актуальности описанной логики и её соответствия ожиданиям пользователей.

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

Когда требуется рефакторинг?

➡️ Аналитик-эксперт. Аналитик, благодаря своему опыту, глубоко понимает бизнес-процессы, цели и задачи компании. Он способен обнаружить устаревшие или неэффективные элементы бизнес-логики, которые могут быть улучшены для оптимизации работы системы.

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

➡️ Изменение бизнес-правил. Это может включать изменение механики расчёта скидок или нормативной базы, которая влияет на бизнес-процессы, автоматизированные в продукте.

➡️ Изменение нефункциональных требований. Увеличение нагрузки из-за роста пользователей или необходимость локализации продукта.

➡️ Исправление багов. Аналитик должен помнить, что исправление багов — это не только тривиальные задачи. Они могут повлечь за собой рефакторинг бизнес-логики. И тут полезным инструментом станет трассировка требований. Она поможет отследить сохранение целостности, оценить влияние изменений на всю систему и выявить возможные риски.

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

#surf_analyst