[멘토링] FE/BE 협업에서 재작업을 줄이는 커뮤니케이션 방법 및 습관 (답변희망멘토 : jayden.bin) #211
-
🙋질문자판교 3기 / 5팀(개발자지만 독서는 하고싶지?) - green.yoo(유지연)/풀스택 🙋답변 희망 멘토jayden.bin(김한빈)/@konempty 궁금한 내용백엔드 개발자 입장에서 “협업이 편하고 신뢰가 가는 프론트엔드 개발자”는 어떤 특징이 있는지 궁금합니다. 질문 내용 정리
시도한 방식문서와 실제 응답이 다르면, 바로 수정을 요청하기 전에 제가 놓친 전제들(권한/환경/파라미터)이 없는지 먼저 점검합니다. 이제 어떻게 하려고 하는지?멘토님 피드백을 바탕으로 이번 팀 프로젝트에서 이슈 공유 템플릿(재현 절차/요청·응답/환경/로그/스크린샷 등)을 정리하고, 반복되는 충돌 포인트는 협업 체크리스트/팀 룰로 만들어 재작업을 줄이는 방향으로 적용해 볼 예정입니다. 추가 참고자료 (선택사항)#Frontend #Backend #TeamProject |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
@jiyeonyooo 일단 저는 몇가지 떠오르는게 있네요
마지막으로 드리고 싶은 이야기는 아마 버그가 아닌걸 BE개발자 한테 버그라고 리포팅 하는게 있을것 같아 껄끄러워서 일것 같은데 |
Beta Was this translation helpful? Give feedback.
@jiyeonyooo
안녕하세요 그린~!
요건 어느정도의 대부분의 사람들이 선호하는 특성이 있겠지만 제 취향이 많이 들어나는 답변이 될것 같네요 ㅋㅋㅋ
일단 저는 몇가지 떠오르는게 있네요
그냥 무조건 안된다고 하지 않고 절충안을 찾으려고 노력하는 사람
가끔 FE에선 어려운 기능이니까 BE가 무조건 맞춰달라고 하는 개발자가 있구요. 그 반대도 있어요
그런데 다행히 저는 좋은 FE분들과 같이 일하고 있는데 FE에서 하기 힘든 기능이라고 하더라도
첫마디로 "구현이 어렵다" 라는 말보다 "BE가 ~~만큼만 더 해주시면 나머지 부족한 부분은 FE에서 할수있다"
라는 식으로 구체적인 제안과 절충안을 제시해주시는 분이 결과가 같을때에도 긍정적으로 다가와서 좋았어요.
물론 진짜 불가능한 경우도 있고 그건 어쩔수 없죠 ㅎㅎ
FE에서 기술 로드맵을 역으로 제시해주는 사람
보통 많은 개발에선 BE개발자가 개발 속도나 기능 구현 순서를 제어하는 경우가 많아요
그런데 반대로 FE에 개발자가"A, B, C 기능이 있을때 C, A, B 순서대로 개발해주시는게 편하다/좋다"
라고 역으로 제안 해주면 물론, BE개발자 입장에선 오히려 불편한 순서가 될순 있지만 그 이후 논의를 해보면서
최적해를 찾아갈수 있는 물꼬를 트는것 같아서 좋았어요
BE 버그 발견시 자세하게 리포트 해주는 사람
요건 약간 케바케이긴 한데 BE에서 명확하게 버그가 발생했을때 바…