스타트업 문화 질문) 기획 디자인 개발 프로세스

Question

안녕하세요 IT스타트업에서 일하는 문화/방식에 고민이 있어서 질문글 올립니다

먼저 저희 회사를 설명드리면 주니어가 많고 열린 사람들이 많은 에자일을 지향하는 화기애애한 작은 스타트업입니다.
저희 프로세스를 설명드리면
1. 해결해야하는 과제or프로젝트에 대해 기획자와 디자이너가 착수를 한다
2. 기획안과 디자인이 완료가 되면 개발자들을 모아서 전달 및 공유를 한다
3. 개발자 끼리 이야기해서 이 일을 받을 사람을 정한다음 개발을 시작한다
4. 무한반복

개발자분들은 si와 유사하게 하루종일 코딩만 하게되고 누적되니 의지와 동기부여 측면에서 좋지 않고 결정적으로 미팅할 때마다 공격자와 수비자가 나뉘는 험학한 분위기가 고도되고 있어서 다같이 문제의식을 합의하고 논의하는 중이고 목적조직을 목표로 여러 학습과 아티클을 보았지만 도무지 방법이 떠오르지 않습니다...

제가 생각한 문제는
A. 프로젝트 초기부터 참여할 개발자 리소스가 당장은 없다.
B. 프로젝트간의 텀이 생기는 상황에 대해 거부감이 큰 분위기

대게로 A 가 반복유지되는데요 개발직군분들의 프로젝트들이 여유가 생기려고 하면 위에 프로세스1. 의 속도를 엄청 올립니다 그럼 다시 버퍼가 없어지게 되고 무한루프네요...

모두가 감정적인 공감은 되었는데 이성적 해결책이 떠오르지 않습니다... 마땅히 물어볼 조언자분들이 주변에 안계셔서 간절함에 질문 글 올립니다

+) 개발자가 기획단부터 참여한 경험은 있었지만 허수아비가 되더라구요...

어디서부터 시작해야 목적조직의 스쿼드처럼 직군들이 함께 협업하는 문화로 바꿀 수 있을까요?

김도열 · Answer

이미 기획과 디자인이 다 나오고나서 개발자에게 공유하자니 공격과 방어 같은 모습이 나오고, 정작 기획에 참여시키면 아무 얘기가 없고..  많은 회사에서 일상 같은 모습이겠지만.. 걱정하실만한 상황이네요.

제가 일하는 방식을 예로 들어 볼게요.

저는 DB를 설계하고 백엔드가 필요로하는 sql을 작성하는 일을 합니다. 첫 기획 리뷰할 때부터 프로젝트에 참여하고, 발견한 논리적 모순과 대안을 피드백하죠. (미팅 전에 기획서를 검토하고 피드백 드릴 내용의 대부분은 미리 작성해 둡니다)

큰 문제가 발견된게 아니면 왠만한 수정 사항은 미팅 자리에서 어떻게 수정할지 결정을 마무리하고 회의록에 기록합니다. 기획서가 수정되고 디자인이 진행되는 동안, 저는 회의록의 결정 사항대로 DB를 설계하고 DB 입출력에 필요한 인터페이스를 만들죠. 백엔드는 연동해야하는 다른 개발 요소나 프론트엔드와의 인터페이스를 설계합니다.

대충 DB와 백엔드 개발이 끝날 즈음 다지인도 끝나고, 프론트엔드가 마무리 짓습니다.

중요한 건 설계부터 프론트엔드 개발의 모든 단계에서 기획과 디자인 수정이 요청될 수 있습니다. 미처 발견하지 못한 모순점이나 좋지 못할 것 같은 사용자 경험이 눈에 띄었을 때죠. 이상한 것 같은데 그대로 만드는 것은 위험하거든요. 스타트업은 관성으로 움직이면 안된다고 생각합니다.

이렇게 움직이려면 앞서 작업을 끝낸 사람들에게 버퍼가 필요합니다. 뒷 작업을 하는 사람의 요청에 빠르게 응답할 수 있을 정도의 버퍼.. 프론트엔드가 API를 수정해 달라거나 디자인을 수정해 달라거나.. 심지어 기획 상의 일부 규칙을 수정하자는 요청 같은 것들이죠. 정말 빠르게 응답할 수 있어야 프로젝트가 빠르게 끝납니다.

결국 필요한 1단계는 개발자가 더 일찍 참여해서 함께 만드는 것이겠네요. 다만 개발자가 이런 방식에 익숙하지 않거나.. 애초에 반대할 가능성도 있으니 섬세한 접근이 필요할 겁니다.

문제가 잘 해결되었으면 합니다.