개발자 관점에서의 제안서 (기술장표) 작성

SI 프로젝트를 하다보면 그 시작에는 제안서라는게 있습니다. 갑자기 하던일 멈추고 다 모이라고 해서 입찰일자랑 내용을 듣고 있으면 하늘이 노래집니다. 예전에 거쳐왔던 직장중에는 제안서를 월요일에 제출하다보니 그 당시에는 주말출근해서 한주의 시작인 월요일 아침해를 사무실에서 보는 경우도 허다했습니다. 그 이후 관리직도 하게 되면서 최대한 제안서는 주중에 마무리를 짓게끔 하고 개발쪽도 미리 준비한 기술장표로 재활용하도록 변경했습니다만 그래도 해당 제안마다 추가로 써야 할 항목들이 생길수 밖에 없습니다.

 

개발자의 첫 제안서 작성

과장, 차장급 개발자를 선정해서 제안서의 기술 장표를 쓰게 합니다. 기존부터 쓰던 친구가 있으면 도움을 받는데 그렇지 못할 경우 사무실에서 자기가 당첨될까봐 눈치를 보는 개발자들중에서 선정해서 써와보라고 하게 됩니다. 몇일을 낑낑거리다가 자기도 이해 못하는 장표를 만들어 옵니다. 설명해달라고 하면 구두로는 강사 수준으로 설명을 합니다. 그걸 듣고 방금 한 얘기를 장표로 정리해 오라고 하면 텍스트로 써서 붙이는 형태가 되구요. 그걸 제출하는 날까지 반복합니다. 쓰기 싫은걸 억지로 쓰게 하다보니 발생하는 부작용 입니다. 여러명이 협업을 해도 마찬가지 입니다. 서로 쓰기 싫은거 모르는건 다른 사람쪽으로 넘기지요. 어쩔수 없습니다.

 

기술장표를 개발계획서나 설계보고서 라고 생각하면?

관점을 바꿔보면 어떨까요? 보통 개발자들에게 어떤 기능에 대해 어떻게 만들지를 물어보면 대부분 방안이 있습니다. 그때 고려해야 할 사항, 전제 조건, 그걸 만들때 필요한것, 대략적인 소요 일정 등등. 기술장표란 그런 내용을 구구절절이 쓰는게 아닌 장표로 짧은 시간안에 고객에게 최대한 많은것을 전달하기 위한 용도의 문서를 만든다고 보시면 좋을듯 합니다. 이때 이러한 점을 고려하는게 좋습니다.

 

상대(고객)은 개발을 모르는 경우가 대부분 이다

개발자들의 특징이 약어 좋아하고 자기네 은어를 좋아 합니다. 그런데 고객사 담당자는 개발자가 아닌경우도 많고 지식 도메인이 틀린 경우가 많습니다. 그러다보니 장표가 개발자 중심의 약어, 은어로 작성될 경우 고객은 뭔 얘기인지 모르는 경우가 많습니다. 혹자는 뭔가 있어보인다고도 하는데 저는 기술장표를 보고 이해하거나 짐작이라도 할수 있게 작성은 해야 한다고 생각합니다. 그렇다고 구구절절 서술형으로 풀어쓰라는건 아닙니다. 약어가 있으면 뭐에 약어인지 또는 밑에 비고 같은 형태로 간단한 설명이 있는게 좋습니다. 그렇게 해놓고 발표시에 좀 더 풀어서 설명하면 됩니다. 

기술장표도 스토리가 있는게 좋다

보통 저는 이런형태로 진행합니다. 고객사에서 아예 목차를 잡아서 RFP가 나오는 경우도 있습니다만, 없다면 저는 전체 큰 그림을 머릿속에 넣게끔 하고 각 구성요소(FE, BE, Admin 또는 기능별로 사용자 관리 시스템, 예약 관리 시스템)에 관련된 세부 내용과 각 구성요소들이 어떤식으로 연계가 되는지 어떤 기능을 제공하는지 형태로 구성합니다. 이 부분은 각 개발사(조직)별로 차이가 있습니다만 짧은 시간내에 고객에게 많은양을 전달하기 위해서는 스토리가 있게 풀어나가는게 좋습니다. 

• 우리가 만들려는 전체 시스템의 모습은 이렇다
• 어떤 구성요소를 가지고 있으며
• 각 구성요소는 어떤 기반에서 동작하며
• 이런 기능을 제공한다
• 이 기능은 이런 기술을 써서 이렇게 개발할 것인데 이 기술을 쓰는 이유는 이렇다
• 복잡한 플로우는 이런식으로 연동할것이다
• 이 기능에서 이런 위험요소(주의사항)이 있지만 이렇게 하면 해소될것 같다
• 위의 것을 만들기 위해 일정계획은 이렇게 잡고 인력은 이렇게 투입될 것이다  

기술장표는 일관성이 있어야 한다

개발자들이 여러명 들어갔을때 생기는 문제중에 제일 큰건 용어를 통일 시키지 못하는것과 복잡한 플로우에서 각 구성요소의 기능 역할이 통일되지 못하는 점입니다. 개발자 몇명에게 역할을 나눠주고 작성을 시켜 왔습니다. 장표를 취합하고 나서 보니 누구는 서버, 누구는 시스템, 누구는 admin, 누구는 관리자 사이트 등등 천차만별로 작성해 왔습니다. 이런 경우 장표 작성전에 우리가 본 프로젝트에서 만들려고 하는 시스템(플랫폼)의 대략적인 형상을 논의하고 용어를 통일해서 작성을 시작하는게 좋습니다. 시스템 개요 장표를 하나 만들고 그걸 먼저 공유해 놓고 작업을 시작하는 것도 좋은 방법입니다.

이와 유사한 사례가 더 있습니다. 복잡한 플로우에 대해 게이트웨이 서버와 admin site 가 연동하는 기능이 있었습니다. 각각 다른 개발자들이 작성해 왔는데 이를 취합해 보니 게이트웨이 장표에서는 admin site에서 app push를 보낸다고 되어 있고 admin site 장표에는 게이트웨이가 app push를 보낸다고 되어 있었습니다. 서로 기술장표 쓰기 귀찮으니 반대편 개발자에게 고치라고 하는 상황이였고 결국은 교통정리를 해서 정리를 하긴 했습니다만, 이게 장표로 그대로 제출되고 발표까지 한다면 고객사에서 비웃을 상황이였습니다. 이런 부분에 대해서는 기술장표 작성 리더가 있다면 각 구성요소의 R&R등은 미리 정하고 시작하는게 좋습니다. 아니면 작성중에 발생되면 바로 내부 공유를 통해서 정리하고 가는게 좋습니다. 그런 활동이 없다면 저 문제를 발견할때는 어느정도 진행된 시점이라서 수정하는데 여유가 없을수도 있습니다. 

아이콘, 템플릿, 화살표, 설명 문구 등도 처음에 템플릿을 하나 정해서 해당 내용을 기반으로 작성하는게 좋습니다. 제안 인력에 디자인/기획 담당이 있다면 ppt 마스터 템플릿을 작성할때 요청하시는게 좋습니다. 

화려한 색깔보다는 그 장표에서 강조하고 싶은 내용에만 포커스를 주자

개발자들이 작성이 귀찮다보니 S/W 아이콘이나 서비스 로고등을 잔뜩 배치하는 경우가 많습니다. 예를 들어 우리는 SNS 연동을 합니다. 라고 어필하려고 한쪽에 트위터, 페이스북, 인스타그램 아이콘들을 잔뜩 배치 하는것과 같습니다. 그런데 화려한 그림이 많을수록 장표 어디에 눈을 둘지 모르는 경우가 많게 됩니다. 여기서 어필하려는게 뭔지 시청자들에게 잘 전달되지도 않구요. 그래서 이 장표에서 강조해야 할 사항은 강렬하게 표시하고 나머지를 흐리게 한다던가 해당 내용이 가운데에 갈수 있게끔 작성하고 저런 아이콘들은 작게 표시하는게 좋습니다. 어차피 유명한 서비스들은 작게해도 설명글이 없어도 고객은 인지를 합니다. 마찬가지로 컬러를 많이 쓰거나 원색 컬러로 작성해도 마찬가지 입니다. 이런경우에도 컬러 테마를 지정해서 그 범위안에서만 쓰는게 좋습니다. 특히 대기업의 경우 고유 브랜드 컬러가 있기 때문에 이 컬러쪽으로 장표를 작성하는 경우가 많은데 이와 어울리는 컬러로 작성하는게 좋습니다. 그거 아니면 무채색에 어필하려는 요소만 붉은색, 파란색등으로 표시하는 것도 방법입니다. 어떤 컬러가 어울리느냐? 그건 디자인팀에 물어보시거나 아래와 같이 컬러 배합을 조합해주는 ㅁAdobe kuler 같은 사이트를 참조해 보시면 됩니다.  

발표 환경도 고려하자

좀 어이없는 상황입니다만, 한때 강조되는 데이터 흐름을 진하게 하고 그외의 기타 데이터 흐름을 회색 점선으로 표시해서 기술 장표를 작성했던 적이 있습니다. 그러다가 모 고객사에 프리젠테이션을 하러 갔었는데 그 회의실에 빔 프로젝트가 오래되어서 색이 선명하지 않았습니다. 그러다보니 회색 점선으로 표시한 부분이 전혀 보이질 않아서 이상한 그림이 되어 버렸습니다. 데이터 흐름 뿐만 아니라 해당 색깔로 작성한 텍스트 도형들이 다 안보여서 설명하는데 애를 먹었던 적이 있습니다. 해상도가 안좋은경우도 있습니다. 이와 같이 발표 환경이 열악한 경우도 있기 때문에 가급적 어느 정도 선명도는 유지할수 있게 작업하는게 좋습니다.  

 

결론

쓰기 싫지만 일단 주어진 일은 해야 하다보니 내 소통이나 문서작성 스킬 늘린다고 생각하고 써보시는걸 추천 드립니다. 많이 써보면 소요시간도 줄어드니 결국 내가 하려던 업무로 더 빨리 복귀할수 있지 않을까요. 개발자들은 머리속으로 구상은 잘 합니다. 그건 다들 잘해요. 그걸 문서로 표현할수 있다면 더 경쟁력 있는 개발자가 되지 않을까 생각합니다.