지인이 근무중인 사무실에 놀라갔다가 이런 결재서류가 눈에 띄어서 감탄을 했었습니다.

"와아~ 이런걸 쓰다니!"

그 지인이 의아하게 되묻더군요.

"그럼 회사에서 이런거 안써요?"

"응... 나는 회사생활하면서 이런걸 써본적이 없는거 같은데?"

대답하고 생각해보니 2002년에 근무했던 첫 회사에서 한 번 본적이 있기는 했던 것 같았습니다.
그 이후로는 본적도 쓴적도 없었네요.

대기업 계열사에 다닐 때는 그룹웨어를 통해 전자 결재를 올리기도 했었는데, 대개의 IT 기업은 결재라는 단어를 거의 사용하지 않는 것 같기도 합니다.


그럼 IT 회사들은 어떻게 일을 하느냐.
업무 지원도구를 씁니다. 업무 전용 웹사이트에 로그인을 해서 사용하는 식이지요.

개발자들은 이런 도구를 사용한지 꽤 오래 되었습니다.
개발을 하다보면 버그가 끝도 없이 쏟아지기 때문이지요.

"서비스 오픈 준비중이라 바쁘겠네"
"그렇지 뭐"
"QA(품질관리)에서 리포팅한 디펙(결함)이 몇 개나 돼?"
"한 800개 되는데 많이 잡아서 지금은 한 300개 남았나? ㅎㅎ"

보통 이렇게 처리할 업무의 갯수가 너무 많기 때문에 각각의 문제들을 일일이 이메일로 주고 받는 것은 사실상 불가능하지요.
그래서 전용 업무도구를 사용해서 QA가 발견한 문제점들을 이슈로 등록해둡니다.
그러면 개발팀 관리자가 각 이슈를 적절한 담당자에게 할당하고, 할당받은 개발자는 해당 이슈를 해결하면 '처리완료'로 상태를 바꿔놓는 식이지요.

주로 버그를 처리하는데 쓰기 때문에 버그 트래커, 혹은 BTS(Bug Tracking System)와 같은 이름으로 부르기도 하고, 버그가 아닌 이슈를 다루기도 하기 때문에 이슈 트래커라고 부르기도 합니다.
많이 사용되는 이슈 트래커로는 Jira, Redmine, Trac, Mantis 같은 제품들이 있습니다.



요즘은 개발자가 아닌 직군에서도 이슈 트래커를 사용하여 업무를 진행하기도 하는데요.
실제로 제가 근무하고 있는 회사에서는 전 직원이 이슈 트래커로 업무를 합니다.

팀장이 팀원에게 일을 하나 시킨다고 하면, 이슈 트래커에서 이슈를 하나 생성해서 내용을 적고 해당 팀원에게 이슈를 할당하는거지요.
그러면 팀원은 해당 업무를 시작할 때 '시작'버튼을 누르고, 완료되면 '완료' 버튼을 누릅니다.
그러면 모든 직원의 업무 진행상황과 처리한 업무가 업무 도구상에 쭉 쌓이고 통계를 낼 수 있게 되지요.

아래는 제가 근무하고 있는 회사에서 사용하고 있는 Jira의 화면입니다.



저에게 할당된 업무와 처리한 업무를 그래프로 보여주고 있고, 제가 처리해야 할 업무들의 목록을 볼 수도 있지요.
이번 달에 처리한 업무들을 확인한다던지, 제가 시간이 남아서 다른 팀원을 도와주려면 그 팀원이 지금 처리해야 할 업무들의 목록을 열람 할 수도 있습니다.



일을 주고 받고 처리하는데 이슈트래커를 쓴다면, 문서를 작성 할 때는 주로 사내 위키를 사용합니다.
위키야 굳이 설명을 안해도 여러분들이 잘 아시는 도구죠.
여러명이서 공동 편집이 가능하고, 파일을 주고 받지 않아도 쉽게 열람이 가능하기 때문에 IT기업들이 위키로 문서를 관리하기 시작한지 꽤 된 것 같습니다.

회사의 규모가 크거나 보안을 챙기는 경우라면 위키의 섹션마다 열람/작성 권한을 설정해두거나 부서 전용 위키를 사용하기도 하는데요.
규모가 크지 않으면 전 직원들이 모든 문서들을 열람 할 수 있도록 열어놓는 경우가 많습니다.

아. 데이터를 수시로 업데이트 하거나, 계산을 해야하는 경우에는 구글 스프레드시트를 사용하여 작업하기도 합니다.
엑셀을 통해서 할 수 있는 업무들인데, 엑셀은 파일을 주고 받아야 하는 불편함이 있고 동시에 여러명이 공동 편집을 할 수 없기 때문에 구글 스프레드 시트를 사용하는 경우가 많지요.

회사의 규모가 크면 비슷한걸 직접 만들어서 쓰기도 하고 아니면 구글 독스나 스프레드시트 사용을 금지하고 다른 대체 도구를 사용할 것을 강요하는 경우도 있습니다.
대개의 경우 구글 SW 같은 편리함을 주지 못하기 때문에, 직원들은 구글 도구 사용을 막는 것에 대한 불만이 많은 편입니다.

회사에서 구글도구를 막는 명분은 대개 보안 때문이구요. 뭐 그렇습니다.