사이드 프로젝트로 레벨업 하기 - 6장
비사이드 참여기 6. 개발자와 협업
기획문서를 보며 개발자는 여러 질문을 한다. 이건 어떤 기능이에요? 여기서 이 버튼 누르면 어떻게 되나요? 이러이러한 상태일때 어떤 화면으로 보여져야 하나요? 서버 사정고려하면 기간 내에 힘들 것 같은데 다른 방법은 없을까요? blah blah... 개발자와 협업하며 몇 가지 느낀 점이 있다.
문서는 완벽할 수 없다. 고쳐도 여전히.
당연한 얘기지만 직군에 따라 기획서를 바라보고 느끼는 시선은 다르다. 사람마다도 다르다. 각자가 쓰는 근육이 다르기 때문에 자연스레 그에 초점이 맞춰진 상태로 문서를 이해하고 질의한다. 하루냥 팀 개발자분들은 꼼꼼한 성향을 지녔다. 꼼꼼한 개발자분들은 예외 케이스를 진심으로 대한다. 따라서 기획서 리뷰할 때 마다 프로세스에서 논리적으로 어색한 부분과 기획에서 놓친 예외 케이스를 중심으로 질문을 했다. 기획에서 아무리 케이스를 열거한다고 해도 서버 설계, 프론트 개발 역량이 없기 때문에 놓치는 게 발생한다. 하루냥 팀처럼 기획자가 놓치는 케이스를 개발에서 잡아주는 경우엔 그나마 수월하게 풀리지만 꼼꼼하지 않은 개발자와 꼼꼼하지 않은 기획자가 만난다면...... 왠만한 실무 짬밥이 없으면 많이 힘들어지기 마련이다.
사람은 처음부터 완벽할 수 없다. 기획서에 누락된 내용을 개발자가 짚어준다고 해서 끝일 리 없다. 개발자가 미처 보지 못하는 부분들이 있다. 가령 디자인 폰트가 어색하거나 컴포넌트가 전반적으로 웹접근성을 위배하는 경우는 디자이너가 훨씬 잘 발견한다. 이렇게 놓치는 부분을 최소화하기 위해 모든 직군이 모인 자리에서 기획서 리뷰를 해야 한다고 생각한다. 그래야 커뮤니케이션 비용을 조금이라도 아낄 수 있으니깐. 시간이 곧 돈이다.
그러나 아무리 문서를 보완해도 QA때 누락된 부분이 발견될 수 있다. 히스토리 관리 차원에서 나는 문서 개정이력 관리를 소홀히 하지 않았지만 많은 기획자분들이 이러한 히스토리 관리에 힘들어한다고 들었다. 어차피 문서는 아무리 열심히 작성해도 완벽하지 않기 때문에 프로젝트가 끝나기 전 까지 매 순간 최선을 다해야 하지 않을까..
끝없이 반복되는 기획서 관리. 마치 시시포스의 바위처럼 느껴지기도 했다.기획서를 모든 팀원이 같은 의미로 이해하도록 명확하고 객관적으로 작성해야 한다.
기획자나 PM은 팀이 나아갈 방향을 설정하고 이를 구성원에게 의미를 정확하게 전달해야 한다. 기획서가 누구나 같은 방향으로 이해되도록 명확하고 객관적으로 작성되지 않으면 기획 문서가 무한으로 수정되는 일이 일어날 수 있고, 각 팀원들이 같은 내용을 다르게 이해하므로 프로젝트 진행이 힘들어진다. 명확하게 문서를 작성하는 습관이 없었던 시절 요구사항 정의서나 스토리보드, 프로세스 같이 중요한 문서를 작성하면 무수한 수정 요청, 질의 폭탄이 날아들었다. 직군을 떠나서 독자마다 이해하는 내용이 달랐기 때문이다. 이 경험과 하루냥에서의 쌓은 역량을 양분 삼아 이후 기획서 작성 시 중학생도 의미를 파악하기 쉽도록 간결하고 절제해서 문서를 작성하려 노력한다. 특히나 개발자는 문서를 보고 개발 의도를 파해야 하는데 다음과 같은 표현이 이에 방해가 될 수 있다고 느꼈다.
미사여구
~등 처럼 확장적인 표현
간결하지 않고 길게 늘여쓴 문장
감정이 보이는 단어
좀처럼 보기 힘든 어려운 단어
핵심 내용이 잘 드러나지 않는 문장 구조
또한 "모든 개발자는 A에 대해 알고 있다" 라는 생각은 지양하며 기획서를 작성한다. 어쩌면 유혹처럼 느껴질 수 있지만 자신의 경험과 주관을 담는 실수를 하게 된다. 문서는 장황해지고 모든 개발자의 경험을 담지도 않을 뿐더러 몇몇 팀원이 나의 생각에 동화되어 대혼돈파티가 열릴 수 있기 때문에 오히려 프로젝트에 방해만 될 뿐이다.
직무마다 업무 우선순위를 바라보는 기준이 다르다.
개발자와 의견 충돌이 발생하는 가장 큰 이유 중 하나가 우선순위 설정이라고 생각한다. 직군마다 바라보는 관점이 다른데 일반적으로 기획자는 프로덕트의 논리적인 서사와 구조, 디자이너는 디자인 완성도와 사용성, 개발자는 기능, 코드 안정성, 서버, 구현 난이도를 중요시한다. 이처럼 한 배를 탄 팀원들의 생각이 다 다르다 보니 PM은 키를 잡고 결정을 해야 한다. 그러나 나의 개발 지식은 겨우 OOP나 동적 할당 정도만 아는 체 할 수 있을 정도여서 개발의 우선순위에 직접적으로 관여하기가 부담스러웠다. 여기서 업무 우선순위를 모두가 공감할 수 있도록 RICE 기법을 사용해서 설정했다.
우선순위는 R*I*C/E 수치로 결정한다.MoSCow라는 유명한 방법이 있지만 굳이 RICE 방법을 선택한 이유는 개발자의 의견을 담을 수 있어서다. Confidence와 Effort 값은 기획자와 디자이너도 응답할 수 있지만 직접적인 구현은 전적으로 개발자가 한다. 개발자만큼 개발 공수와 기능 개발 성공 여부를 정확히 아는 팀원은 없으니 RICE 기법을 채택했고 어떤 업무부터 할 지 우선순위를 정할 수 있었다. 이렇게 하면 PM이 놓치기 쉬운 개발 속도나 기존 레거시를 개발자가 고려하여 의견을 반영할 수 있으니 일석이조인 셈이다.
코딩 공부는 아니더라도 디지털 서비스가 어떻게 구동되는지 원리 정도는 공부하자 제발
프론트엔드, 백엔드에 대한 이해도가 없이 '언제까지 될 것 같아요?'라고만 한다면 개발자 입장에서 속이 터진다(저도 그랬던 것 같습니다 죄송합니다 개발자님들 ㅠㅠ). 개발중인 앱에 문제가 있으면 프론트에 말해야 할 지 서버에 말해야 할 지 판단을 못하면 무작정 물어보거나 개발 지식을 공부한 뒤 개발자에게 물어볼 수 있다. 그치만 그 과정에서 리소스 소모가 되기 마련이니 이러한 시간 비용을 줄이기 위해서라도 개발 관련 공부를 했어야 한다고 느꼈다.
무시당하지 않기 위해, 개발 관련 지식을 올리기 위해 주간 스크럼 때 개발 이슈가 나오면 '음~그렇군요~ ㅇㅋ 알겠습니다 다음으로 넘어가죠'라고 말하지 않고 '어떤 코드가 리팩토링이 필요해요?', '도커가 어떻게 설정되어 있다고요?', '현재 명언 추천 로직은 이런 문제가 발생할 수 있지 않을까요?' 와 같이 개발 관련 지식을 모르는 걸 부끄러워하지 말고 모든 것을 놓치지 말자는 마음가짐으로 질의했다. 우리 팀원 중 나 때문에 속이 터진 분도 계시겠지만 적어도 아는척 하며 방관하는 것 보다는 낫다고 생각하며 태도를 고수했다.
이러한 노력이 쌓인 결과 개발 프로세스에 대한 이해도가 높아졌다. 런칭 직전 서버에 문제가 발생한 적이 있는데 우리 팀의 서버에 어떤 문제가 있는지 서버 개발자님에게 계속 질의하며 상황을 완전히 이해했고 내가 이해한 내용을 바탕으로 개발자 친구에게 자문을 구해 솔루션을 우리 팀에 제안하기도 했다. 결론적으로 이슈는 해결되어 세상에 잘 나올 수 있었다 :)
적고 보니 개발 지식을 쌓기 위해선 실전으로 부딪혀 보는 게 빠른 방법 같다. 이래서 경력자를 선호하는건가