#разборвопроса

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

Однако, долго так работать я бы не стал, слишком много рисков:

✖ Нет актуальной документации,
✖ Отсутствует управление требованиями,
✖ Увольнение разработчика или целиком команды и нет инфы вовсе.

И итог у этого всего один - дальше будет больно, долго и дорого!

Поэтому, если вас позвали в команду, где СА - это новый невиданный игрок, который еще и должен отобрать работу у светил разработки, то я бы не стал с ноги вламываться и менять процессы, а сделал следующее:

1 Разберись в текущем процессе, пойми как всё работает сейчас

✔ Как разработчики пишут API? Есть ли устные договорённости, минимальная документация или они работают "по наитию"?

✔ Какие проблемы возникают?

Чаще всего это:
- Несоответствие ожиданий фронтенда и бэкенда,
- Изменения на поздних этапах разработки,
- Неполная документация или её отсутствие,
- Где я, как аналитик, могу быть полезен? Например, в структурировании данных, учёте бизнес-логики или создании стандартов?

Когда процессы и правила игры в команде станут понятны, можно переходить к шагу 2.

2 Объясни, зачем это нужно

Разработчики привыкли к своему процессу, поэтому важно показать, что проектирование API:

✔ Экономит время

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

✔ Упрощает взаимодействие

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

✔ Снимает рутину

В документации уже есть структура, параметры и ответы — разработчикам не нужно об этом задумываться.

Дальше, когда всем станет понятно, а зачем вообще СА что-то отдавать, то уже можно закатывать рукава и переходить к шагу 3.

3 Внедри удобный процесс

Задача аналитика — не усложнить жизнь команды, а наоборот, упростить её.

Начинаем с малого:

✔ Шаблон проектирования API

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

✔ Обсуждение на грумминге

Включи обсуждение API в командные встречи:

- Какой функционал нужен?
- Какие параметры будут передаваться?
- Что API должно возвращать?

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

Покажи команде, как проектирование упрощает их работу:

✔ Выбери простую задачу,
✔ Вместе с разработчиками опиши API,
✔ Убедись, что документация понятна всем:
- фронтенду,
- бэкенду,
- QA,
- и бизнесу
✔ После завершения работы покажи результаты:
- Меньше вопросов,
- Нет доработок в процессе.

Вуаля, они уже вдохновятся этим 🥂

А дальше, постепенно внедряй изменения, не пытайся сразу перестроить весь процесс, работай поэтапно

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