프로젝트에 참여할 때 알아야 할 것들
WBS, UML 이런건 배운 적 없는데..
개발자로 취업했으니 개발만 하면 될 줄 알았으나 더 큰 복병이 숨어있었다. 우리가 에둘러 말하는 '협업'과 '커뮤니케이션'이 항상 중요한 순간에 걸림돌이 되었다.
수많은 IT회사와 스타트업에서 말하는 '협업'이 대체 무엇이고, 왜 그렇게 중요하게 생각하는 걸까? 스타트업에서는 원활한 협업을 위해 'JIRA', '노션', 'slack' 이외에도 다양한 협업 툴을 사용한다. 손발이 맞아야 박수도 치는 것처럼 서비스를 성공적으로 개발하고 시장에 내놓기 위해서는 기획자, 디자이너, PM, 개발자의 손발이 맞아야 한다.
프론트엔드 개발자로서 어려운 점은 백엔드 개발자와 디자이너 그리고 기획자 사이에서 의견을 조율하는 것이었다. 나의 경험상 대표의 경우 요청한 기능이 다 들어갔는지, 디자이너의 경우 내가 만든 결과물대로 나왔는지, 백엔드 개발자의 경우 요청 처리 속도나 성능에 더 많은 초점을 두고 피드백을 주었다. 경험 상 업무에 있어서 가장 많이 부딪히는 사람은 기획자였다. 우리 회사의 경우 개발이 시작된 이후에도 기획서 및 디자인이 수도 없이 바뀌었고, 이미 개발 마무리 단계에 들어왔어도 기존 기능과 모순되는 신규 기능을 요청하기도 했다.
회사에서는 원활한 협업을 위해 개발에 착수하기 전 다양한 개발 문서를 만든다. 적어도 내가 다녔던 회사에서는 공통적으로 화면 설계서, 요구사항 정의서, WBS는 요청했었다. 각 문서에 대한 형태는 회사마다 다르고, 개개인마다 다르지만 작성하는 목적은 같다.
1. 화면 설계서 (기획자 - 디자이너, 기획자 - 개발자)
일반적으로 기획자가 PPT나 기타 도구를 활용해 전반적인 영역을 잡는다. 로고가 어디에 배치될 것인지, 콘텐츠가 어디에 있을지에 대한 것을 러프하게 표시하며 각 콘텐츠에 대한 설명을 화면 옆에 서술한다. 디자이너는 화면의 배치를 참고하여 디자인을 만들고, 개발자는 화면 설계서의 설명에 기반하여 코드를 작성한다. 따라서 화면 설계서가 자세하면 자세할수록 개발자와 기획자 사이에 불필요한 대화가 줄어든다. 이것까지 말해줘야 해? 하는 것까지 디스크립션에 넣어주어야 이상한 결과물이 나오지 않는다.
2. 요구사항 정의서 (기획자 - 개발자, 개발자 - 개발자)
서비스 개발에 필요한 기능들을 정리한 문서이다. 일반적으로 표 형태로 많이 작성하며, 이를 통해 어떤 기능을 개발해야 하고, 몇 개의 기능을 개발해야 하고, 우선순위가 무엇인지 파악할 수 있다. 내가 다녔던 회사는 기획팀(기획자)이 화면 설계서만 전달해주었고 요구사항 정의서는 개발자가 정리했다. (개발 외주를 주는 경우 클라이언트가 이를 작성하여 외주사에 넘겨주기도 한다.) 요구사항 정의서를 작성하면서 이 기능은 어떤 라이브러리를 쓰면 되겠다는 개괄적인 가닥이 잡히고, 개발자 간의 업무분담에도 도움이 된다.
3. WBS(업무 분류 체계) (개발자 - 개발자)
간단하게 말하면 일정표 같은 것이다. 어떤 기능을 개발할 것이고, 누가 담당할 것이고, 이 기능을 개발하는데 얼마의 시간이 걸리고, 이 프로젝트의 전반적인 일정을 미리 계획하는 문서이다. 칸반 보드나 엑셀 등 다양한 방법으로 시각화하여 만든다.
4. UML (개발자 - 개발자)
UML이란 프로그램의 구조를 시각적으로 표현하기 위해 만든 문서이다. 목적에 따라 다양한 작성 방법론이 존재하며 오로지 개발자 간의 소통을 원활하게 하기 위한 문서로 기호와 도식을 이용하여 표현한다. 항공 우주 엔지니어는 비행기 모형을 만들어 실제로 날 수 있을지 확인하고, 건축가는 빌딩의 모형을 만들어 확인하는 것처럼 프로그램 구조도 이렇게 하면 되겠다는 모형을 만드는 셈이다. 그러나 실물이 존재하는 모형과 달리 프로그램은 개발자의 주관이 포함되기도 하고 뚜렷한 기준점이 없다.
개발자가 개발만 잘하면 된다는 것은 나의 착각이었다. 오히려 개발을 시작하기 위해 준비해야할 문서나 개발을 진행함에 있어 의견을 조율하는데 더 많은 에너지와 시간이 필요하다. 그리고 이것을 어떻게 잘 핸들링할 수 있는지까지가 보이지않는 역량이자 주니어와 시니어의 구분점인 것 같다.
