기획서 완성도에 따른 개발환경

무언가를 개발하기 위해 구두로 일 할 수는 없다. 개발이 완료된 다음에 쌍방간에 서로 떠넘길 수 있는 요지가 생기거나, 개발 중간중간 어떻게 해야할지 몰라 막히기 때문이다.

내부 기획서부터 외부기획서 소기업부터 대기업에서 나오는 모든 기획서를 보았지만 역시 대기업에서 받았던 기획서을 토대로 개발할 경우에는 기획서를 정독하게 되며, 따로 기획자에게 물어볼 필요성을 못느끼게 한다. 기획서를 받는 순간 서류의 두께가 말해주고 있음은 물론이고, 나눠진 분류나 스토리 보드만 보고도 대충의 흐름이 파악된다.

반면 부족한 기획서는 화면만 달랑 넣어놓고 버튼 기능설명만 해 놓거나, 전체적인 구조를 알 수 없게 해놓는다. 이 화면에서 저 화면을 어떻게 가는지 중첩이 되는지 예외상황이 발생하면 어떻게 처리해야 하는지등 보고 있으면 한숨이 절로 나올지경이다.

퀄리티 높게 기획서를 쓰려면 정말 많은 시간 투자를 해야만 한다. 개발자에게 기획서 쓰라고 해도 혀를 내두른다. 그만큼 기획서는 작업의 시작 단계이자 마무리까지 어떻게 진행될지 한눈에 알게 해준다. 개발보다 어쩌면 더 많은 노력이 들어갈 때도 있다.

좋은 기획서는 많이 읽어 종이가 너덜너덜해지고, 반대인 경우에는 너덜해지는건 기본이고 몸이 바쁘다. 만들면서 기획하고 회의하고 수정하고 짜증내다 결국 해탈한다. 기획서 대신 디자인 시안을 보고 개발하는편이 나을 때도있다.

기획서에 꼭 넣어주었으면 하는 내용을 개발자 입장에서 정리하면 다음과 같다.

1. 전체 흐름을 볼 수 있는 스토리보드 또는 워크 플로우. 화면이 어디서 어디로 가는지 파악되면 초기 구조를 잡을 때 용의하다.

2. 화면에서 쓰일 입력 폼이나 형태. 특정 값을 입력하거나 선택할 때 자체 UI로 처리할 것인지 커스텀 할 것인지 아이폰, 안드로이드 각각 OS특성에 맞게 적어주면 더 좋다.

3. 예외가 발생할 수 있는 상황에서 대처방법. 아이템 갯수 제한을 두거나 특정 아이템만 선택되어야 한다면 토스트로 알려줄 것인지. 자체 팝업을 쓸것인지. 하단에 설명글이 나온다는지 발생할 수 있는 상황에 따라 어떻게 동작해야 하는지 설명하고 스토리보드까지 넣어준다면 훨씬 파악하는데 용의하다.

4. 오탈자 검사. 개발자가 한번 더 검사하기는 하지만 바쁘다 보면 신경쓰지 못하고 써진 문구 그대로 사용할 때가 있다. 꼭 설명글이나 UI등의 문구는 다시 한번 확인해 달라. 팝업 설명글도 마찬가지이다.

이정도만 지켜줘도 기획서가 알차지 않을까 싶다. 화면이 하나임에도 기획서 한장이 나올지 5장이 나올지는 스킬여하에 따라 다를것이다.