Tuesday, September 1, 2009

본부장의 고민과 RedMine

현재 근무하고 있는 곳에서 재미있는 시도를 하고 있습니다.

지금의 회사에서는 메일을 지금껏 일해본 여느 회사보다 더 많이 사용합니다.
거의 모든 작업의뢰는 메일을 사용하여 전달하는 것을 기본으로 하고, CC도 굉장히 많이 입력합니다.

메일로 보고되는 것은 구두로 보고되는 것과 동일시 하게 취급됩니다.
메일의 사용에 있어, 특별히 교육받은 것은 없습니다만, 상식으로 여겨지고 있다라고 생각되는 것들이 몇가지 있는데,
예를 들면, 팀 멤버가 발송하는 메일은 누구에게 발송하든 CC로 팀 매니저를 넣는 것을 원칙으로 하고 있는 것 같습니다.
팀 매니저도 또한 관련된 모든 팀원은 CC로 넣어서 발송합니다. 또 팀간의 조정이 필요한 경우에는 부서장을 CC로 입력합니다.
CC가 없는 메일은 매우 드믑니다. 예를 들면, 패스워드를 전달하는 메일정도일까.

작업의 전달은 구두 + 메일을 원칙으로 합니다. 대인 접촉을 어려워하는 일본인의 특성이 더해져 있달까(plus 엔지니어의 특성),
구두 전달은 생략될 수 있습니다.
만일 전달이 명확하지 않은 경우는 받은 쪽에서 미팅을 의뢰합니다. 이 의뢰도 역시 메일로 전달이 됩니다.

여기서, 본부장의 고민이 발생했나봅니다.
메일로 보고는 되고있고, 정기적으로 매니저들간의 회의를 통해 이를 파악하고 있기는 하지만,

어느 부서가 어느 부서에게 어떤 의뢰를 받아 어떤 작업을 하고 있고, 어떤 이슈가 얼마만큼 로드가 걸려있고, 그 각각의 진행은 어떻게 되어 가고 있는 지,
부서의 Resource를 어디에 어떻게 운영해야 적절한 판단이 되고, 어느 시기에 어떻게 Resource를 충당해야 할 지 파악하기 어려웠나봅니다.
어느 팀이 사람이 없다라고 호소를 해도, 매 분기별 평가를 통해 팀의 성과를 평가하는 자료로도, 메일과 미팅으로만은 부족하고, 뭔가 다른 툴이 필요하다고 느꼈던 것 같습니다.

그래서 최근, Redmine을 통한 전체의 Activity를 일람해 보고자 하는 시도가 이루어졌습니다.
각 팀별, 세부 부서별, 프로젝트별 티켓시스템이라던지는 존재했었습니다만, 부서 전체에 대한 시도는 아직 없었습니다.
원래 Redmine은 프로젝트 툴입니다. 엔지니어라면 Trac을 선호하는 사람도 있겠습니다만, Calender와 Gantt등을 지원하는 Redmine쪽이 관리자의 측면에 좀 더 매리트가 있다는데 동의합니다.
이 툴의 도입에서 빛나는 부분은 부서간의 Activity를 한 눈에 알 수 있다라는 것입니다.

설정은

메인 프로젝트로 시스템본부,
서브프로젝트로 각각의 부서와 팀을 넣습니다. 이 프로젝트들은 실제 프로젝트가 아니라 부서를 대표하고 이슈를 관리하는 것이니, 부서, 팀이 존재하는 한 종료되지 않는 프로젝트가 됩니다.

멤버로는 시스템본부의 멤버 전원, 사업부의 멤버 전원, 그리고 몇명의 재무부와 인사부의 인원이 멤버로 등록되어 있습니다.

이슈로는 내부적으로 발생하는 작업이 아닌 부서간의 의뢰의 내용을 적습니다.
Issue Tracking Item으로는 다음과 같은 내용이 있습니다.

상재 서버 상태 확인 의뢰:
상재 서버의 설정 변경 의뢰:
상재 서버의 어플리케이션 거동 확인 의뢰:
데이터 추출 의뢰:
멘테넌스 대응 의뢰:
사내 메일 로그 조사 의뢰:
사전 상담:
장해에 관련하는 조사 의뢰:
돌발적인 작업 의뢰:
청구 관련의 처리 의뢰:

각 팀원이 이 시스템의 사용에 익숙해지기까지는 조금 시간이 걸리겠지요.
그러나 어떤 부서가 어떤작업을 하고 있는 지 한눈에 알기 쉽다라는 느낌입니다.
회사의 시스템을 캡춰해 계재할 수 없는 것이 안타깝습니다.

RedMine을 사용한 프로젝트는 여러차례 경험해 보았습니다만, 이러한 사용방식은 처음이었고, 꽤 Smart하다고 생각합니다.
비슷한 고민을 하고 있다면, 한 번쯤 도입을 연구해 보는 것도 좋다라고 생각합니다.
어쩌면 이미 사용하고 있는 곳이 벌써 많은지도.

2 comments:

듬뿍 said...

비개발적인 측면에서 이렇게 사용해도 큰 무리가 없는지요?
그 사이에 예상되는 문제점들은 무엇이 있는지요? 매우 궁금합니다.

Unknown said...

듬뿍님
답변이 늦어 죄송합니다. 이 글을 보실지 어떨지..

> 비개발적인 측면에서 이렇게 사용해도 큰 무리가 없는지요?

전혀 없습니다.

> 그 사이에 예상되는 문제점들은 무엇이 있는지요?

가장 큰 문제점은 새 시스템에 대한 "저항" 입니다.
'도입후 오히려 복잡해졌다.'
'지금까지 그것 없이도 잘 해왔다'
라는 이야기가 있을 수 있습니다.

도입하려는 분의 확고한 의지와 집행할 수 있는 권위가 필요합니다.

저희같은 경우는 부서장(이사직)이 평가에 반영한다 라고 명시해 두었습니다.

평가는, 주로 이슈 발생후 완료까지의 통계적 수치를 사용합니다.