60 подписчиков
#разборвопроса
Если в компании разработчики самостоятельно сразу пишут методы API в коде, то с чего стоит мне начать как аналитику, чтобы качественно проектировать и разработчики приняли нововведения?
Частая ситуация, когда разрабы, как говорится «сами с усами»: все знают, все умеют, сами договорятся, сами разработают и вуаля.
В целом, такой подход имеет место быть, так как он достаточно быстрый и если вам нужна скорость, а компания маленькая, то весьма оправданный.
Однако, долго так работать я бы не стал, слишком много рисков:
✖️ Нет актуальной документации,
✖️ Отсутствует управление требованиями,
✖️ Увольнение разработчика или целиком команды и нет инфы вовсе.
И итог у этого всего один - дальше будет больно, долго и дорого!
Поэтому, если вас позвали в команду, где СА - это новый невиданный игрок, который еще и должен отобрать работу у светил разработки, то я бы не стал с ноги вламываться и менять процессы, а сделал следующее:
1️⃣ Разберись в текущем процессе, пойми как всё работает сейчас
✔️ Как разработчики пишут API? Есть ли устные договорённости, минимальная документация или они работают "по наитию"?
✔️ Какие проблемы возникают?
Чаще всего это:
- Несоответствие ожиданий фронтенда и бэкенда,
- Изменения на поздних этапах разработки,
- Неполная документация или её отсутствие,
- Где я, как аналитик, могу быть полезен? Например, в структурировании данных, учёте бизнес-логики или создании стандартов?
Когда процессы и правила игры в команде станут понятны, можно переходить к шагу 2.
2️⃣ Объясни, зачем это нужно
Разработчики привыкли к своему процессу, поэтому важно показать, что проектирование API:
✔️ Экономит время
В первую очередь время разработки, так как им не надо думать о бизнес-логике, ходить к бизнесам и с ними общаться. Они могут спокойно кодить и сосредоточиться на технологиях.
✔️ Упрощает взаимодействие
Фронтенд, бэкенд, QA и аналитики работают по одному контракту, что снижает недопонимания. При этом, разработчиков уже не будут дергать QA, если у них вдруг возникнут вопросы.
✔️ Снимает рутину
В документации уже есть структура, параметры и ответы — разработчикам не нужно об этом задумываться.
Дальше, когда всем станет понятно, а зачем вообще СА что-то отдавать, то уже можно закатывать рукава и переходить к шагу 3.
3️⃣ Внедри удобный процесс
Задача аналитика — не усложнить жизнь команды, а наоборот, упростить её.
Начинаем с малого:
✔️ Шаблон проектирования API
Создаем новые описания по единообразному шаблону. Например, как у меня на курсе и верифицируем его с командой, чтобы всем было понятно как с ним работать.
✔️ Обсуждение на грумминге
Включи обсуждение API в командные встречи:
- Какой функционал нужен?
- Какие параметры будут передаваться?
- Что API должно возвращать?
Но что делать, если команда упирается рогом и никакую не соглашается?
Тут только показывать делом и примером, что ты можешь и как можешь помочь, поэтому начни с одного примера.
Покажи команде, как проектирование упрощает их работу:
✔️ Выбери простую задачу,
✔️ Вместе с разработчиками опиши API,
✔️ Убедись, что документация понятна всем:
- фронтенду,
- бэкенду,
- QA,
- и бизнесу
✔️ После завершения работы покажи результаты:
- Меньше вопросов,
- Нет доработок в процессе.
Вуаля, они уже вдохновятся этим 🥂
А дальше, постепенно внедряй изменения, не пытайся сразу перестроить весь процесс, работай поэтапно
Надеюсь, мои советы помогут тем, кто столкнулся с несговорчивыми разработчиками и они помогут растопить лед в их сердцах и помочь команде достигать крутых результатов 😉
2 минуты
4 января 2025