Program Manager라는 역할을 지금 다니는 회사에 면접을 보면서 처음 들어 보았다. 이 일 저 일을 많이 한다고 들었었다. 왠지 이름만 들어도봐도 살짝 설레었고 사람들 속에서 내 이름이 많이 불릴 것 같은 생각이 들어서 맘에 드는 역할이었다. 사람의 이름이 불린다는 것은 내가 속한 사회에서 역할을 가지고 있고, 나의 가치가 있는 것이기 때문이다.
사실 전 직장에서도 Product Management 담당 부서가 있었다. 하지만 나와는 연관이 없는 사람들인지라 만나본 적은 없다. 지금 생각해 보면 Product Management가 지금 내가 하고 있는 하지만, PM은 Post meridiem 늦게까지 일한다고 PM이라고 농담으로 한 번씩 하였던 기억이 살짝 난다.
지금 일하는 회사에서 PM은 개발이 시작되는 곳과 끝나는 곳에서 전체적으로 잘 구성될 수 있도록 하고, 사용자들이 쉽게 사용할 수 있도록 활동을 해야 한다. 전체적으로 잘 구성되도록 하기 위해서는 제품에 대한 인사이트가 필요하고, 사용자를 확보하기 위해서는 대화 능력과 설득 능력이 필요할텐데... 2달이나 지났지만, 아직 제대로 하고 있는 게 없다. 그래서 그런지 항상 "내가 잘 할 수 있을까?" 라는 고민에서 벗어날 수가 없다.
이제 본론으로 들어가서, 이번 주면 내가 관여한 CUBRID가 릴리스되어 시장으로 나간다. 내 맘으로는 준비했다는 표현을 쓰고 싶지만, 그러기엔 CUBRID 2008 R1.2에서 내가 한 역할이 너무나 미미하다.
릴리스에서 내 목표는? 스펙, 매뉴얼, 릴리스 노트 정리
그런데 결과는? 매뉴얼 정리
기능의 구현의 시작이라고 할 수 있는 스펙을 정리하기 위해 개발자들의 수많은 메일 쓰레드의 내용을 따라가기도 바빴다. 맘같아서는 스펙 정리가 아니고 스펙 정의를 하고 싶었는데, 코딩 컨벤션을 비롯해서 시스템의 컨벤션도 잘 모르니, 좌충우돌하면서 앞으로 전진할 수 밖에 없었다. 전진? 아니 버티기를 할 수 밖에 없었다. 스펙을 정의하기 위해서는 무조건 개발자에게 붙어서 기본안을 이해하고 그것을 바탕으로 정리를 해야 하는 것이라고 느끼는 선에서 스펙 업무를 마무리할 수 밖에 없었다.
릴리스가 되기 위해서는 이슈 트래커에서 내게 할당된 이슈를 해결해야 한다. 머리털 나고는 처음 사용해본 이슈 트래커는 적응하기가 쉽지 않았다. 이슈 트래커에는 매뉴얼의 수정 사항이 등록되어 있다. 이번 릴리스에 해당하는 수정 사항을 모두 반영해야 한다. 게다가 이슈 트래커의 관리 효율을 올리기 위해서 촘촘하게 만들어 둔 필드 값을 적절하게 수정하는 것 또한 조금은 부담이었다. 이슈 트래커를 한 번 수정할 때마다 일부 팀원들에게 메일로 계속 공지가 나가기 때문이다.
CUBRID의 매뉴얼 중 빠진 내용 추가하는 것과 수정할 사항들로 등록된 것들을 매뉴얼에 반영하고 확인하는 작업이 이번 릴리스에서 가장 기억에 남는다. 사실 소프트웨어를 사거나 설치할 때 문제가 발생하지 않으면 그 제품의 매뉴얼은 한 번도 펼쳐보지 않고, 책장 속으로 혹은 기억의 저 편으로 보내었다.소프트웨어 뿐만 아니라 세탁기, 냉장고, 전자레인지의 제품 설명서를 제대로 읽어보는 사람이 있을까?
매뉴얼 관련 일을 하면서 매뉴얼에 대한 나의 생각은 상당히 많이 바뀌었다. 매뉴얼은 제품과 함께 호흡하고 같이 업그레이드가 매 릴리스마다 되어야 한다는 사실이다. 소프트웨어의 기능 패치 혹은 새로운 기능은 곧 매뉴얼 수정을 의미하는 것이다. 매뉴얼은 제품의 현재 상황을 가장 잘 반영하고 잘 표현해야 한다. 제품의 공식 문서이기 때문에 광고 문구 같은 것은 쏘옥 빼고, 사실 (Fact) 만 반영하여초보자가 내용을 쉽게 파악할 수 있도록 써야 한다.
매뉴얼도 제품의 일부이므로 한 번 릴리스되어 나가면 그 내용을 다음 릴리스까지 수정하지 못한고, 사용자에게 제품에 대한 올바르지 않은 인식을 심어줄 수 있다는 부담감 때문에 스트레스도 적지 않았다. 내용의 정확성, 문장의 명확성 등을 신경을 쓰다가 보니까 (결과는 좋지 않더라도) 업무 진도가 맘같이 빠르게 진행될 수가 없었다. (사실 지금 이 글을 쓰면서도 약간은 스트레스를 받고 있다. 잘못된 문장이 한 번 릴리스되면 다시는 주워담을 수 없기 때문이다.)
릴리스 (로마자 발음 규칙에 따라 릴리스라고 표기함. 릴리즈라고 표기하는 사람도 많다.) 노트도 역시 제품의 공식 문서이지만, 내가 이 일을 하기 전까지는 릴리스 노트를 한 번 살펴본 일이 없다. 릴리스 노트는 문제가 발생하면 한 번 펼쳐볼까 말까한 문서였다. 어떤 기능이 추가/수정되었는지를 짧은 문장으로 정리해야 했다. 짧은 시간에 작성을 하고, 조금 더 시간이 지난 후 시간을 내서 다시 읽어 보니, 문장과 내용이 정말 엉망이었다. 지식의 문제인지 문장의 문제인지 사실 조금 헷갈린다. 아직은 둘 다의 문제라고 생각한다.
내가 작성하고 관리하는 것은 제품의 공식문서이면서 사용자들이 잘 찾아보지 않는다는 공통적인 속성이 있는 것 같다. 사람들이 스타워즈 개봉일을 기다리듯이, 내 릴리스 노트와 매뉴얼을 기다리도록 해충을 퇴치하는 C사의 웹마스터의 재치를 발휘할 수도 없다. (다행스럽게도 나에겐 그런 재치가 없다.)
아직까지는 릴리스 일자에 맞게 매뉴얼과 릴리스 노트를 준비하여 실수없이 패키지하는 것만해도 상당히 벅찬 것 같다. 프로세스가 손에 익지 않아서일까? 다음 릴리스에는 좀 더 실수없이, 그리고 촉박한 일정을 가지는 일 없이, 순리에 맞게 차근차근 진행되도록 노력해 봐야 겠다.
