성공적인 개발에 필요한 3가지

1. 풍부한 커뮤니케이션
대화의 정확성은 말, 글, 이미지의 순서라고 생각한다.
반면, 내용의 유지성은 글, 이미지, 말의 순서라고 생각한다.
따라서 의사소통의 주된 방식은 말과 글이 되어야 한다.
말을 이용한 회의와 이를 글로 정리해서 보관하고 참고하는 형식으로 말이다.

근데 많은 경우, 스토리보드란 이름으로 이미지가 말과 글을 대신한다.
직관적이고, 풍부한 의미를 담을 수 있다는 이유로 이미지가 사용되지만, 이미지는 아는 만큼 이해되는 법이다.
기획자의 의도와 방식을 제대로 이해하지 못한 상태에선 이미지를 충분히 이해하기 어렵다.

따라서, 잦은(혹은 필요한) 회의를 통해 아이디어를 정리하면서, 서로 간의 지식과 주장, 스타일에 대한 이해를 쌓아야 한다.
이러한 준비 작업 없이 기획서를 받아든 디자이너, 개발자는 보이는 대로 개발하기에도 벅찬 상태가 된다.

2. 마감된 기획서
일정에는 분명 각 단계별로 마감 시간이 있는데, 많은 경우 기획에서 계속해 새로운 아이디어가 나온다.
문제는 이렇게 끈임없이 개선(?)된 기획서의 변경 사항이 디자이너와 개발자에게 여과없이 전달된다는 점이다.
쉽고 간단히 말해 프로젝트가 변경사항을 통제하는 것이 아니라, 변경사항이 프로젝트를 흔드는 상황이다.

기획상의 프로세스 오류로 개선이 필요한 경우도 있고, 더 좋은 아이디어의 적용을 위해 변경되는 경우도 있다.
하지만, 종합적인 프로젝트의 성공을 위해서는 변경 사항을 필수적으로 통제해야 한다.
프로그램 개발에 있어 지금 당장 꼭 필요한 기능과, 지금 당장 꼭 필요한 개선은 없다.
일정과, 구현가능한 기능은 한정되어 있다는 것을 받아 들이고, 이것들에 대한 끊임없는 관리가 필요하다.

개선되는 아이디어가 반영, 정리되는 기획서도 물론 관리가 필요하다.
날짜와 일련번호로 구성되는 코드를 갖고 관리하거나, 문서 이력표를 문서에 추가해 기획서의 이력을 관리한다.
그리고 변경된 부분은 기존의 것을 유지한 채 문서의 이력 내용과 함께 정리되야 한다.

3. 꼼꼼한 개발 설계
조직이 작을 수록, 각 파트별로 담담자 체계가 잡혀 있을 수록 개발 설계는 담당자(=개발자)에게 전가되곤 한다.
하지만. 큰 그림을 그리지 못하는 상황에서의 개발 설계는 반쪽짜리가 되기 쉽상이다.
네이밍 규칙 준수, 공통 프레임워크 사용, 기존 모듈과 함수 그리고 변수의 재사용 등이 미흡해지고,
전체 프로젝트 일정에 분명한 개발 설계 일정이 없이, 쉽게 편하게 개발 일정으로 흡수되어 종국에는 일정에 쫓기는 상황이 된다.

여러 방안에 대한 고민, 가장 적합한 방식에 대한 선택, 개선된 방식에 대한 노력이 없다.
결국 최대한 빠르고 간단하게 페이지들을 작성한다.
코딩에 들어가기에 앞서 고민하고, 선택하고, 분명히 할 시간과 노력이 필요하다.
코드를 복사하지 않게, 디버깅이 용이한 구조가 되게, 에러와 예외 처리에 주의해 개발 해야 한다.
그리고 개발이 이렇게 되도록 설계하는 개발 설계가 꼼꼼하게 진행되야 한다.

0.
위에서 말한 것들이 프로젝트를 성공시켜 준다고 생각하지 않는다.
오히려 이것들은 프로젝트가 생존할 수 있는 생존조건의 기본이다.
개발 프로세스의 기본이다.
이런 것들이 지켜지는 상황 하에서 하나된 팀웍으로 프로젝트를 성공시킬 수 있을 것이다.