문서 개발 프로세스

조앤 해코스(JoAnn Hackos)는 “문서화 프로젝트 관리 (Managing Your Documentation Projects)”에서 문서 개발 프로세스를 다섯 단계로 나눈다.

1. 정보 계획 (information planning): 문서 기획에 필요한 정보를 수집하고, 문서 얼개를 대략적으로 계획한다. (10%)
2. 내용 상세화 (content specification): 보다 상세한 정보를 수집하고, 세부 단위까지 문서 구성과 내용을 계획한다. (20%)
3. 실행 (implementation): 짜여진 계획에 따라 내용을 작성하고, 삽화를 그리고, 문서를 조판한다. (50%)
4. 발행 (production): 필요하다면 번역하고, 인쇄나 배포가 가능한 형태로 문서를 마무리한다. (19%)
5. 평가 (evaluation): 계획대로 프로젝트가 진행되었는지 평가한다. (1%)

둘째 단계가 주목할 만한다.  이 단계가 의미하는 바는

• 무엇을 화제(topic)로 삼을 것이며,
• 그에 대해 무슨 정보를 제공할 것이며,
• 그것이 어떤 더 큰 주제 아래 올 것인지

이 단계에서 모두 결정되어야 한다는 것이다. 세째 단계가 가장 많은 시간을 차지하지만 실행 단계에서 고민할 것들은 그다지 많지 않다. 만들어져야 할 내용들이 이미 모두 결정되어 있기 때문에 이 단계에서 고민해야 할 것들은 그 내용들을 어떻게 표현하느냐이다. 무슨 용어를 사용할지, 어떻게 판면을 디자인할지, 어떤 문체를 사용할지 (IBM 스타일을 따를지 아니면 마이크로소프트 스타일을 따를지) 이 단계에서 결정해야 한다.

이 프로세스는 이상적으로 보인다. 이 프로세스를 잘 따른다면 실패 없이 좋은 문서를 갖게 될 것이다. 이와 같은 프로세스를 흔히 폭포 (waterfall) 개발 모델이라고 한다. 그런데 이 프로세스가 과연 실행 가능한가?

폭포 개발 모델의 특징을 두 가지로 요약할 수 있다.

• 앞 단계가 완료되지 않으면 다음 단계로 진행할 수 없다.
• 각 단계에서 해야 할들이 정의되어 있으며, 그 일들도 순차적으로 진행된다.

이와 같은 프로세스로 진행하려면 기획이 완벽하게 이루어져야 한다. 의사 결정을 요구하는 모든 문제가 미리 예측되어야 하며, 그 각각에 대해 이해당사자들의 다수가 동의하는 답이 주어져야 한다. 이와 같은 프로세스로 문서를 개발하는 것은 많은 경우에 불가능에 가깝다.

소프트웨어 개발에서 최근에 많이 선호되고 사용되는 방법이 애자일 (agile) 개발 모델이다. 이 방법론은 업무 영역을 여러 개의 짧은 단계로 나누고 각 단계의 계획, 수행, 평가를 자주 되풀이하며 각 업무를 점진적으로 그러나 동시에 진행시킨다.

이 방법론은 무계획적으로 보이지만 실제로는 폭포 모델보다 더 짧은 기간에 더 좋은 결과를 낳는다. 그 이유는 기획 단계에서 모든 문제를 예측하고 각 문제에서 가장 좋은 결론을 얻기 위해 필요한 모든 정보를 수집하는 것이 사실상 불가능하기 때문이다. 어떤 경우에 이 두 방법론 가운데 어느 하나가 다른 것보다  우위를 차지할 수 있는지 논하는 것은 그다지 현명하지 않다. 대개 프로젝트에서는 애자일 개발 모델을, 프로세스에서는 폭포 모델을 쓴다고 보는 것이 타당하다.

많은 사람들이 프로젝트와 프로세스를 구분하지 못한다. 프로젝트는 프로세스에 의해 수행되지 않는다. 그렇게 하는 것이 가능하다면 그것은 프로젝트가 아니다.

프로젝트	프로세스
해본 적 없는 일	되풀이하는 일
목적은 새로운 것의 창조	목적은 정립된 업무의 반복을 통한 가치 창출
목표와 계획이 책임자에 의해 변경	상당한 계획과 투자에 의해 변경
지도력이 매우 중요	지도력 불필요
프로젝트는 변화를 창조	프로세스는 변화에 저항

자동차 회사가 2인승 전기 자동차를 개발하기로 결정했을 때 전기 자동차를 만들어 본 적이 없다면 그 개발은 프로젝트이다. 프로젝트가 시작되면서 질문들이 넘쳐난다. 어느 정도의 성능을 확보해야 상품으로서 가치를 인정받을 수 있는지, 배터리에 대해 보장할 수 있는 품질 보증의 범위가 무엇인지, 별도의 장비 없이 가정에서 전기 자동차를 충전하는 것이 가능한지 등등 매우 많은 문제들이 의사 결정을 기다린다. 확정된 답들이 정책 또는 프로세스가 된다. 따라서 프로세스는 프로젝트의 부산물이다. 대표적인 것이 제조 프로세스이다. 제조 프로세스가 어떤 순서를 따라 어떤 방법으로 전기 자동차를 조립해야 하는지 정의한다.

개발 프로세스라는 것은 같은 범주의 제품을 개발하는 데에서만 유효하다. 원형 제품에서, 이 경우 2인승 전기 자동차에서, 부품이나 디자인 일부를 바꾸어 새로운 제품을 만드는 것은  설계 변경과  성능 검사의 반복만을 요구할 것이다. 이 과정에서 풀어야 할 숙제는 그다지 많지 않다. 그리고 파생 제품의 제조 프로세스는 원형 제품의 것과 크게 다르지 않을 것이다. 경주용 전기 자동차나 화물용 전기 자동차를 만들기로 했을 때, 2인승 전기 자동차의 개발 경험이 별로 도움이 되지 않는다면 그것은 다시 완전히 새로운 프로젝트이다.

문서를 개발하는 것도 이와 비슷하다. 스마트폰이 처음 개발될 때 매뉴얼 개발자들은 기존의 매뉴얼을 활용하려 했겠지만 오래지 않아 그것이 거의 도움이 되지 않는다는 것을 깨달았을 것이다. 그들은 용어, 표현, 구성, 문체, 삽화 등 거의 모든 점에서, 그 완전히 새로운 제품을 적절하게 설명할 새로운 방법들을 찾아내야 했다. 그 방법들이 적절하다면 (본질적인 변화라 할 수 없는) 새로이 추가된 스마트폰 기능들을 위해 다른 새로운 표현 방법을 모색할 필요가 없다. 새 기능은 추가해야 할 내용일 뿐이다.

문서화 프로젝트에서 애자일 개발 모델을 사용하는 것은 불가피하다. 문서화 프로젝트가 문서화 프로세스가 아님을 이해한다면 어떤 출판 도구가 유리한지 판단하기가 쉬워진다. 테크니컬 라이터가 인디자인으로 원고를 작성한다는 것은 어불성설이다. 그래서 테크니컬 라이터가 워드 프로세서를 이용하여 원고를 작성하고 그것을 인디자인 포맷으로 옮기는 방법이 흔히 사용된다. 하지만 이 비효율적인 방법은 시간을 낭비할 뿐만 아니라 내용의 질적 개선도 방해한다.  프로젝트가 완료된 이후에 그리고 파생 제품의 매뉴얼을 만드는 데에 문서화 프로세스가 제대로 기능할 수 있을 때 인디자인을 쓰는 것이 합리적이다. 만약 매뉴얼의 개정과 번역이 빈번하게 일어날 수밖에 없다면 인디자인을 보완하거나 대체할 수 있는 방법을 찾아야 할 것이다.

모든 문제를 도구로 풀려는 시도는 현명하지 않다. 불필요하거나 부적절한 내용을 제거하거나 간략하게 만듦으로써 필요 이상으로 빈번하게 문서를 개정하는 일을 피할 수 있다.