이미 기획과 디자인이 다 나오고나서 개발자에게 공유하자니 공격과 방어 같은 모습이 나오고, 정작 기획에 참여시키면 아무 얘기가 없고.. 많은 회사에서 일상 같은 모습이겠지만.. 걱정하실만한 상황이네요. 제가 일하는 방식을 예로 들어 볼게요. 저는 DB를 설계하고 백엔드가 필요로하는 sql을 작성하는 일을 합니다. 첫 기획 리뷰할 때부터 프로젝트에 참여하고, 발견한 논리적 모순과 대안을 피드백하죠. (미팅 전에 기획서를 검토하고 피드백 드릴 내용의 대부분은 미리 작성해 둡니다) 큰 문제가 발견된게 아니면 왠만한 수정 사항은 미팅 자리에서 어떻게 수정할지 결정을 마무리하고 회의록에 기록합니다. 기획서가 수정되고 디자인이 진행되는 동안, 저는 회의록의 결정 사항대로 DB를 설계하고 DB 입출력에 필요한 인터페이스를 만들죠. 백엔드는 연동해야하는 다른 개발 요소나 프론트엔드와의 인터페이스를 설계합니다. 대충 DB와 백엔드 개발이 끝날 즈음 다지인도 끝나고, 프론트엔드가 마무리 짓습니다. 중요한 건 설계부터 프론트엔드 개발의 모든 단계에서 기획과 디자인 수정이 요청될 수 있습니다. 미처 발견하지 못한 모순점이나 좋지 못할 것 같은 사용자 경험이 눈에 띄었을 때죠. 이상한 것 같은데 그대로 만드는 것은 위험하거든요. 스타트업은 관성으로 움직이면 안된다고 생각합니다. 이렇게 움직이려면 앞서 작업을 끝낸 사람들에게 버퍼가 필요합니다. 뒷 작업을 하는 사람의 요청에 빠르게 응답할 수 있을 정도의 버퍼.. 프론트엔드가 API를 수정해 달라거나 디자인을 수정해 달라거나.. 심지어 기획 상의 일부 규칙을 수정하자는 요청 같은 것들이죠. 정말 빠르게 응답할 수 있어야 프로젝트가 빠르게 끝납니다. 결국 필요한 1단계는 개발자가 더 일찍 참여해서 "함께" 만드는 것이겠네요. 다만 개발자가 이런 방식에 익숙하지 않거나.. 애초에 반대할 가능성도 있으니 섬세한 접근이 필요할 겁니다. 문제가 잘 해결되었으면 합니다.

다음 내용이 궁금하다면?

지금 간편 가입하고 다음 내용을 확인해 보세요!

또는

이미 회원이신가요?

2022년 12월 29일 오전 12:32

 • 

조회 267

댓글 0