서버, 네트워크장비, 보안솔루션과 같이 동시에 다수의 고객사와 프로젝트를 지원하는 기술지원조직의 경우 하나의 솔루션에서 발생하는 버그나 이슈라 하더라도 고객사 혹은 프로젝트를 구분하여 관리해야 할 필요가 있다.
더군다나 새로운 프로젝트를 여러개 수행하면서 이미 프로젝트가 종료되어 무상 혹은 유상 유지보수 시기에 접어든 수 많은 고객사에서 다발적으로 발생하는 버그, 신규기능 요구, 패치요구 등 이슈를 제품의 벤더 및 자체 개발팀과의 중간에서 관리하는 것은 경험이 많은 엔지니어에게도 매우 어려운 일이다.
따라서 제품과 고객사, 프로젝트 그리고 개발자와의 원활한 소통을 가능하게 해주는 이슈관리 기능은 기술지원업무관리 시스템에서 필수적인 요소다.
나 또한 기술지원 및 업무관리 시스템을 조금씩 조금씩 수정해나가면서 이슈관리 기능의 필요성을 느꼈고 가장 마지막 단계에서 추가한 기능이 바로 이슈관리 기능이다. 다만 아쉬운 것은 이 기능을 개발하면서 기술지원조직을 분할 해 프리세일즈 및 기획업무를 수행하는 팀을 맏게 되었고 내부 조직의 사정 상 더 이상 사후 기술지원조직의 업무에 관여하지 않게 되어 제대로 완성하지 못했다는 점이다.
더군다나 Atlassian의 JIRA와 같이 뛰어난 오픈소스에서 프로젝트 관리 및 이슈관리가 가능해졌으니…. 개발도 제대로 해보지 않은 필자가 혼자 뚝딱뚝딱 코딩한 이슈관리 기능은 장난감 수준으로 느껴진다. (OTL)
하지만…
내가 직접 만든 것이라는 것과.. 코딩을 해본다는데 의미를 둬도 충분하지 않을까 싶다. 리눅스 서버와 깃허브 연동 시험도 겸하고~~
이슈(ISSUE) 유형 관리
이슈를 등록하기 위해서는 등록하는 이슈가 어떤 이슈인지를 구분해야 한다. 이 이슈는 개발관련 이슈일 수도 있고 기술지원조직에서만 사용하는 이슈가 될 수도 있다.
다음과 같이 이슈를 등록해 목록으로 관리한다.
이슈의 유형은 다음과 같이 [이슈유형]과 [이슈에 대한 설명]으로 등록된다.
이슈의 유형이 등록되었으면 고객사에서 발생한 이슈를 등록할 수 있다.
이슈(ISSUE) 관리
이슈는 다음과 같이 등록할 수 있다.
이슈는 [고객사]/[프로젝트] 에 대해 등록하거나 [업무]/[단위업무] 혹은 솔루션 단위인 [제품]/[버전 혹은 개발프로젝트]에 대해 등록할 수있다.
이슈에 대한 처리 담당자는 직접 지정할 수도 있고 [미정] 상태로 등록하면 해당 이슈를 담당하게 될 팀장 혹은 부서장이 담당자를 지정할 수 있다.
이슈 유형의 경우 앞의 “이슈유형관리”에서 등록한 유형이 다음과 같이 표시된다.
진행상태는 최초 등록자가 등록하면 [검토중]으로 등록하는 것이 일반적이며 이슈를 처리하게될 담당자 혹은 팀장(부서장)이 검토 후 담당자를 지정하며 상태를 변경할 수 있다.
완료 요청일의 경우 기본적으로 처리 완료를 요청하는 일자인데… 검토 후 담당자 혹은 이슈의 처리를 담당하는 팀장(혹은 부서장)이 변경할 수 있다.
등록된 이슈는 다음과 같이 목록으로 보이게 된다.
해당 이슈를 클릭하면 등록된 이슈의 내용을 볼 수 있다.
그리고 이슈의 내용 하단엔 다음과 같이 해당 이슈에 대한 처리내역을 입력할 수 있는 창이 표시된다.
이 입력창에는 진행상황을 등록하거나 해당 이슈에 대해 누구나 도움이 될 만한 글을 입력할 수 있다. 만약 이슈의 처리가 완료되었다면 해당 이슈를 클로징할 수 있도록 “종료하기”를 클릭하고 “저장”하면 이슈는 클로징된다.
그리고 하단에는 이슈의 상태변경, 담당자 변경, 입력한 진행상황등이 표시되도록 “답변 및 처리 진행 상황”이 표시된다.
프로젝트 산출물 게시판
SI 사업만큼은 아니지만 솔루션을 판매하는 벤더나 기술지원업체도 꽤나 많은 산출물들이 생산된다. 제안서는 기본이고 아키텍처설계서, 설치계획서, 설치확인서, 제품 매뉴얼, 고객사나 프로젝트 환경에 맞춰 수정된 운영지침서, 보안정책서, 장애관련 보고서 등 많은 기술자료들이 생산된다.
이런 자료들은 모두 고객사 및 프로젝트 별로 구분되어 관리되어야 하며 필요시 빠르게 검색이 가능해야 한다. 그래서 그누보드의 게시판 스킨을 다음과 같이 수정하였다.
게시판의 게시물 목록화면이다.
그누보드는 여분필드를 지원한다. 이 여분필드를 이용해 게시물 등록화면에서 [고객사]/[프로젝트] 또는 [업무]/[단위업무]를 선택하여 여분필드에 저장하도록 하고 위 화면과 같이 게시판의 목록을 보여주는 스킨에서 여분필드를 글의 제목 앞에 보여주도록 수정했다.
당연히 검색 때도 검색조건에 여분필드에 입력된 정보를 이용해 검색이 가능하도록 했다. 즉 특정고객사 혹은 프로젝트의 이름으로 검색이 가능하다.
산출물 등록시에는 다음과 같이 [고객사]/[프로젝트] 혹은 [업무]/[단위업무]를 선택하여 여분필드에 저장하도록 수정했다.
등록된 산출물을 조회하면 아래 화면처럼 여분필드에 저장된 [고객사]/[프로젝트] 혹은 [업무]/[단위업무]를 박스에 보여주도록 스킨을 수정했다.
하단에는 등록된 산출물의 파일 목록이 보이고 다운로드 받을 수 있도록 했다.
마치며
아마도 더 이상 이 기술지원 업무관리 시스템을 사용할 일은 없을 듯 하다. 내가 어딘가 취업해 기술지원 조직을 담당하지 않는다면 말이다.
그리고 앞에서 언급했던 JIRA와 같은 더 좋은 오픈소스 솔루션이 나와있기 때문에 능력만 된다면 해당 오픈소스를 조직의 업무특성에 맞게 커스터마이징해 사용하는 것이 보다 효율적일 수 있다.
하지만 어떤 솔루션도 해당 조직에 최적화하여 사용하는 것은 쉽지 않다. 그리고 타인이 만들어 놓은 표준적인 형태의 솔루션을 임의로 수정하는 것 또한 꽤나 위험한 일이다. 개인적으로는 오히려 조직운영 형태를 솔루션에 최대한 맞출것을 권하고 싶기도 하다. 그만큼 솔루션을 임의로 뜯어 고치는 것이 향후 더 큰 어려움에 직면하는 원인이 될 수도 있기 때문이다.
각설하고…
박제를 마친다 !!!
#기술지원업무관리시스템 #프로젝트관리 #이슈관리 #프로젝트산출물관리자료실