태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

프로젝트 관리 (4)


중소규모의 솔루션을 공급하는 IT 업체의 엔지니어들은 하루에도 두 개 이상의 프로젝트를 지원해야 하는 경우가 많다. 일 년 내내 그렇게 프로젝트를 지원하다 보면 프로젝트별로 작성된 산출물에 대한 관리가 무척 어렵다. 개인적으로는 노트북이나 외장하드에 고객사나 프로젝트 별로 폴더를 만들어 저장해 두는 경우가 대부분이다. 그리고 혼자 사용한다면 폴더에 의한 관리만 잘해도 크게 문제가 되지 않는다.


하지만 문제는 산출물의 공유에서 발생한다. 


산출물이나 기술자료의 공유를 위해 FTP서버나 게시판을 이용하는 경우가 많은데 이 또한 고객사나 프로젝트 혹은 문서내의 목차 등에 의한 검색에 한계를 갖는 경우가 대부분이다. 그래서 기술 지원 업무 관리 시스템을 재구축 하면서 그누보드5를 이용해 문서 관리를 위한 기능을 만들어 보기로 했다.


아래 화면이 그누보드의 스킨을 조금 수정하고 그누보드에서 지원하는 확장필드를 이용해 만든 문서 저장 게시판이다.


그누보드5의 리스트 스킨 수정



맨 위의 문서 종류는 그누보드에서 지원하는 식별자다. 아래 게시판의 글 목록에서 "제목" 대신 확장필드에 지정한 "고객사"와 "프로젝트"를 보여주도록 했다. 


그리고 아래의 검색창에도 "고객사명"과 "프로젝트명"을 이용해 검색할 수 있도록 했다. 그누보드에서 검색창에 확장필드의 값을 지정할 경우 자동으로 확장필드에서 검색하도록 편리하게 만들어져 있었다.


그누보드5 글쓰기 스킨에 확장 필드 값 입력하기

글쓰기 스킨에서 확장필드의 값을 입력하는 입력상자를 만들고 기술지원 관리시스템에서 등록한 프로젝트를 선택하여 입력할 수 있도록 그누보드5의 write.skin.php를 수정하였다.

아래 화면처럼 "찾기"버튼을 클릭하면 고객사/프로젝트 (단위업무) 선택 창이 뜨고 특정 단위업무(프로젝트)를 선택하면 입력이 된다.


아래 화면은 프로젝트가 선택되어진 화면이다.



등록된 산출물...


아키텍쳐 설계서가 등록되었고 "제목" 부분에 "고객사"와 "프로젝트명"이 표시되는 것을 볼 수 있다. 고객사와 프로젝트 명으로도 검색이 가능하다. 그누보드5에서 지원하는 구분자와 함께 사용하면 특정 프로젝트의 특정 산출물을 검색할 수 있겠다.



등록된 산출물 게시글의 내용을 보는 화면에도 고객사와 프로젝트명, 그리고 문서 종류를 함께 표시하도록 하였다.




산출물 관리에서 이렇게 도구를 만들어 제공하는 것 보다 더욱 중요한 것은 이 도구를 얼마나 효율적으로 사용하느냐다. 


문서의 작성자, 작성일, 버전은 물론...

문서를 등록할 때 등록자가 문서 내용의 목차,문서의 주요 내용 등을 함께 기재하여 검색의 효율을 높일 수 있도록 하는 것이 더욱 중요하다. 아무리 좋은 도구를 제공해도 사용자들이 등록된 문서를 제대로 검색해 볼 수 없다면 그 활용도는 매우 떨어질 수 밖에 없다.


다음에는...


위키를 이용한 문서 관리를 한번 연구해볼 필요가 있겠다. 위키에서도 수십..수백개의 고객사와 프로젝트 같은 키에 의한 문서 식별이 가능할까 모르겠다.


<추가 2015.03.18>

실제로 사용해 볼 수 있는 환경을 공개합니다. 언제까지 공개될지는 알 수 없지만 사용해보시고 좋은 의견(?) 주시면 감사하겠습니다


** 호스팅이 만료되어 폐쇄합니다. (2016/01/05) **



  • 2016.01.05 00:18

    비밀댓글입니다

    • taeho Tae-Ho 2016.01.05 09:45 신고

      안녕하세요. 뭐 검토하고 자시고할게 있나요? 저도 오픈소스가져다 고쳐서 쓰고 있는데..당연히 도움드려야죠..
      그런데 저도 전문개발자도 아니고 수정한지 1년이 다돼가는지라 기억을 더듬어 찾아야 하네요. ^^ 어떤 식으로 도움을 드려야할지 모르겠습니다. 블로그의 메일주소로 메일주시면 답신드리겠습니다.

  • 2016.01.05 22:25

    비밀댓글입니다


전에 기술지원조직의 업무관리에 필요한 간단한 프로젝트 및 일정관리 시스템 개발에 대한 포스트를 기록한 적이 있다. 그리고 시간은 흐르고 흘러 6년이 되어 간다. 지금도 그 시스템은 우리 부서 30여명의 엔지니어들이 잘 사용하고 있다. 비록 많은 버그와 부족한 점이 있지만 기본적인 프로젝트관리와 일정(캘린더)이 확실하게 연결되어 있어 기본기능만큼은 충실하기 때문이다. 그리고 영업부서로부터 엄청나게 밀려오는 신규사업과 유지보수사업 그리고 영업지원에 대한 요구로 인해 사용하지 않고는 못배길 만큼 엔지니어들이 관리해야 하는 프로젝트와 기술지원 일정이 넘쳐나기 때문이기도 하다.

* IT 솔루션 기업의 핵심 부서

내가 지금 근무하는 기업은 IT솔루션, 그중에서도 SW 개발 기업이다. 그리고 SW 중에서도 시스템SW이자 보안SW다. 그리고 SI 사업으로 고객의 요구에 맞춰 그때 그때 수정하여 제공하는 SW가 아닌 패키지 SW다. 즉 한번 만들어서 지속적으로 판매/설치/컨설팅/유지보수가 반복되는 상용SW다. 그리고 계속적인 버전 업그레이드와 재설치, 보안정책 수립에 대한 기술지원과 컨설팅이 이루어진다.

이러한 솔루션 기업(하드웨어도 포함)은 기업내의 여러 조직 중 세개의 조직이 핵심조직이다. 바로 영업-개발-기술지원/컨설팅 부서다.

영업조직은 IT솔루션 기업에서 가장 중요한 조직이다. 제품이 아무리 뛰어나도 영업력 부재라면 그 기업은 십중팔구 사라진다. 존재의 여부마저도 아무도 모르게 망해 없어지는 경우가 허다하다. 반면 제품의 수준은 형편없어도 오랜시간 생명을 유지하며 자신의 존재를 뽐내는 참 대단한 기업도 다수 존재하는데 이런 기업들은 확실한 인맥을 가진 영업맨이 한두명은 있게 마련이다. 제품의 기술력이 우수하고 시장에서 인정받아 수요가 꾸준한 제품이라면 직접영업보다는 간접영업을 하는 것이 보다 효율적이다. 이런 경우에는 직접영업조직과 인바운드영업을 담당하는 조직을 별도로 가져가는 것이 효과적이다. 그리고 매출규모가 더 커진다면 마케팅부서를 별도로 두거나 영업조직의 하위에 두는 것도 효과적일 수 있다.

개발조직은 SW개발자 집단이다. 제품의 품질을 좌우하는 무척 중요한 조직이다. 어느정도 영업이 이루어져 제품의 판매가 이루어지기 시작하면 개발조직과 영업조직간의 여러가지 갈등이 발생하기 시작하는데 이 싸움이 어떻게 진행되느냐에 따라 기업이 흥하느냐 망하느냐가 결정되기도 한다. 어느정도의 균형은 이루어야 하겠지만 일반적으로 개발조직의 제품개발 방향은 영업조직과 기술지원/컨설팅 조직의 요구에 맞추어가는 것이 바람직하다. 고객과의 접점에서 고객의 요구사항을 직접적으로 전달받는 즉, 시장의 요구사항을 피부로 체험하는 조직의 요구에 제품 개발 방향을 맞추지 않고 나름 개발자들의 "환상"에 방향을 맞춘다면 제품은 시장에서 점점 외면받게 되며 결국 도태될 가능성이 매우 높아진다.

기술지원/컨설팅조직은 우리나라에서는 그 중요성을 제대로 인정받지 못하는 조직이다. 우리나라의 IT솔루션 기업에서 기술지원을 담당하는 엔지니어들은 대부분 일정기간이 지나면 영업조직으로 옮기거나 조금 규모가 있는 SI기업으로 이직하는 경우가 많다. 그만큼 IT솔루션 기업에서 엔지니어를 우대해주지는 않는다. 때문에 훌륭한 솔루션을 개발하고 팔아 놓고도 제대로 기술지원을 하지 않아 나쁜 평가를 받게 되고 결국엔 그저그런 솔루션으로 시장에서 근근히 살아남아 겨우 명맥만 유지하는 경우가 너무도 많다. 그 이유가 바로 "엔지니어의 기술 수준이 형편없이 낮고 경험이 부족"하기 때문인데 기술자를 천대시하는 역사적 전통(?)이 현시대를 살아가는 사람들에게 영향을 주기 때문인 것으로 보인다.

나머지 조직은 영업-개발-기술지원 부서를 서포트(Support)해주는 역할을 수행해야 한다. 이 대목에서 많은 다른 조직의 직원들이 기분나빠할 수도 있다. 하지만 그럴 필요는 없다. 기업내에서 불필요한 조직(?)은 없다. 다만 이 세개의 조직은 기업의 근본적 가치인 "돈"을 버는데 필요한 업무를 수행한다는 의미에서 핵심부서라는 이야기이기 때문이다. 군대로 치자면 "전투병과" 라는 이야기다.

프로젝트관리


* 영업-개발-기술지원/컨설팅 부문을 아우르는 프로젝트 관리 방향 (CMMI)

보통 PMS(프로젝트관리시스템)를 개발할 때 보통은 사업수행의 관점에서만 생각하는 경우가 많다. 프로젝트를 수주한 이후 프로젝트가 시작되는 시점부터의 업무만을 프로젝트관리시스템의 관리 대상으로 보는 것이다. 하지만 프로젝트는 영업조직에서 고객사의 사업 준비를 포착하는 단계에서부터 이미 시작된다고 봐야한다. 그렇지 않고 사업을 수주한 시점을 프로젝트의 시작으로 보게되면 영업단계에서 소요되는 시간과 인건비를 고정비로 보게 되고 사업 수주를 위해 지출한 상당한 비용의 접대비와 인건비가 원가에 제대로 반영되지 않아 사업의 수익성이 왜곡되는 결과를 초래하게 된다.

또한 비록 패키지성 솔루션을 만드는 개발조직이라 할 지라도 특정 사업의 필요에 의해 특정 기능이나 모듈을 개발하는데 투자하는 인건비는 제품의 개발원가가 아닌 사업수행의 원가에 포함시켜야 하는데 영업단계의 비용과 마찬가지로 자칫 개발부서의 인건비를 고정비로 보게되면 프로젝트의 수익성이 왜곡되어 적자성 사업이 흑자 사업으로 둔갑하는 결과를 초래하게 된다. 

기술지원/컨설팅 조직 또한 마찬가지다. 한명의 엔지니어나 컨설턴트가 동시에 한개의 사업만을 수행한다면 인건비 산정과 프로젝트에 원가 반영이 쉽겠지만 한명의 엔지니어가 두개 이상의 사업을 수행하게 되면 어느 사업에 얼마만큼의 인건비가 소요되었는지를 제대로 반영하기는 사실상 어렵다. 

만약 프로젝트의 시작을 영업 초기단계로 설정하고 제품의 신규기능 및 수정될 기능에 대한 개발 과정을 프로젝트의 업무단위로 보며 개발자와 엔지니어/컨설턴트의 개발일정, 지원일정을 프로젝트의 수행과정으로 본다면 영업-개발-기술지원/컨설팅의 단계로 이어지는 하나의 프로젝트가 완성되며 제대로된 투입인력 산정(M/M)과 소요비용의 산출이 가능해진다.

또한 프로젝트별 인력투입현황과 현재 조직의 업무 포화도, 직원 개인간 업무 수행 시간의 비교와 업무 유형별 투입시간의 파악이 가능해지기 때문에 인력 부족 여부는 물론 앞으로의 인력 채용 계획을 수립하는데도 무척 효과적일 수 있다.

이렇게  IT분야의 개발단계를 명시하고 업무 프로세스의 관리 능력을 평가하는 평가모델이 바로 CMMI 다. 사실 서양 아이들(?)이 잘하는 것이 다양한 경험을 바탕으로 각 분야의 지식을 종합/정리하고 새로운 이름을 붙이는 짓(?)이다. ISO 모델이 그렇고 BS7799 등이 그렇다. 대부분 이미 수행하고 있는 세부 단계들을 하나로 엮어 체계화한 것이 이런 표준 모델이다.

정작 새로운 이름으로 표준을 정립한 서양 아이들은 조용한데 이러한 모델들이 우리나라에 도입될 때 마치 전혀 새로운 것인양 호들갑을 떨며 대단한 새로운 개념인것처럼 그리고 그것을 자신이 먼저 알고있다는 근자감에 사로잡혀 잘난체하는 일부 사람들을 보면 씁쓸할 따름이다.

연관포스트 : 프로젝트 및 일정관리 시스템 리뉴얼




개발 배경

10여년전 PDA를 처음 접했을 때 내 손안의 새로운 세상을 만난 느낌이었다. 손바닥 만한 디지털기기에서 일정관리, 주소록, 메모, 텍스트북 기능을 모두 사용할 수 있다는 것은 정말 획기적인 일이었다. 그리고 10여년이 지난 지금 손바닥 만한 모바일기기에는 위에 언급한 기능에 동영상, 음악은 기본이고 내비게이션, 뱅킹, TV, 라디오, 웹브라우저, 메신저 등 커다란 데스크톱컴퓨터나 노트북에서만 가능했던 일들이 가능해졌다. 대단한 발전이 아닐 수 없다.

하지만 기능의 품질면에서, 특히 일정관리와 같은 기능은 체계적인 관리가 이루어질 수 없다는 문제는 10년전이나 지금이나 내 마음을 충족시키지 못하고 있다. 다이어리의 황제격인 프랭클린 다이어리가지는 아니더라도 일정 혹은 작업, 메모에 제대로된 카테고리의 구축과 검색기능의 부재는 모바일 기기에서의 일정관리를 사용하기 어렵게 만드는 요소 중 하나다. 더군다나 모바일기기에서 입력한 일정을 PC에서는 관리할 수 없다는 것도 PDA의 일정관리 기능을 제대로 활용하지 못하게하는 이유중의 하나였다.

그러던 중 회사에서 업무적으로 사용하기 위해 만들었던 기술지원 및 프로젝트 일정관리 시스템을 만들었던 아이디어를 기반으로 개인 일정관리 시스템을 만들어보자고 마음먹었고 볼품없지만 일단(?) 사용할 수 있는 최소한의 기능을 완성했다. 



특징

- PC에서도 사용가능한 웹 기반
- 테마 및 테마내의 프로젝트 기반의 일정/작업/메모관리
- 모바일디바이스가 아닌 서버에 일정데이터 저장
- 주간캘린더 및 아젠다 뷰 제공
- 일정 검색기능 (제목 및 내용)
- 통계기능 (프로젝트 별 수행 시간 통계)
- 이미지를 사용하지 않아 빠른 브라우징 속도
- 전혀 예쁘지 않은 디자인, 미적감각 전혀 고려하지 않음.
   오로지 적은 트래픽용량과 속도만 고려하여 코딩함(완전 텍스트, 이미지 전혀 없음) 


사용신청 및 로그인 방법

플랜365의 URL은 http://www.plan365.kr 입니다. PC의 웹브라우저나 아이폰, 안드로이드폰에서 브라우저를 이용해 접속하실 수 있습니다.

1. 회원가입

플랜365를 이용하기 위해서는 회원가입을 하고 관리자의 승인을 얻어야 합니다.

화면 중간의 가입하기를 클릭하여 회원가입을 할 수 있습니다.
(호스팅 서버의 트래픽 문제로 인해 일정 숫자까지만 회원가입을 받을 예정입니다.)

원래 혼자 사용하기 위해 만들었다가 다른 분들도 함께 사용하면 과연 몇분이나 사용하게 될지 궁금해서 오픈하게 되었습니다.














- 이메일 : 로그인 시 ID로 사용됩니다.
- 비밀번호 :
   a-z, A-Z, 0-9 사이의 문자만 사용가능합니다.
  
   (비밀번호는 잊으시면 안됩니다.
    암호화되어 저장되기 때문에 저도 확인이
    불가능합니다. -.- )

- 이름 : 이름을 넣으시면 됩니다.
            (가명도 무관합니다.)

- 전화번호 : 연락가능한 번호를 넣어주세요.
            (스팸은 보내지 않습니다.)

회원가입을 하고 나면 관리자(블로그주인)가 사용허가를 해드린 이후 로그인 가능합니다. 전화번호에 휴대폰 번호를 입력해주시면 가입 승인 문자를 보내드릴 지도 .... ^^











2. 로그인


옆과 같이 ID와 비밀번호를 입력하고 접속하여 사용하시면 됩니다.





















3. 로그인 후 초기화면


최초 마이홈 화면입니다.

오늘날짜를 보여주고

1. 어제끼지의 미완료 일정

2. 오늘의 일정

3. 내일부터 계획된 일정을 보여
    줍니다.

마이홈은 좌측 상단의 이름을 클릭하면 표시되는 화면설정에서 주간캘린더 형태로 변경할 수 있습니다.
















4. 테마와 프로젝트


플랜365는 테마와 프로젝트를 만들어야만 일정,작업,메모등을 입력할 수 있습니다.

테마는 왼쪽 화면처럼 "대주제"에 해당됩니다.
"테마추가" 버튼을 눌러 테마를 등록할 수 있습니다.

현재 "삭제"는 지원되지 않고 이름의 변경만 지원됩니다. 추후 필요시 추가할 예정입니다.























프로젝트 관리 화면입니다.

프로젝트는 테마의 하위에 위치하는 "소주제"에 해당됩니다.

"취미"가 하나일 수는 없겠죠? 독서, 사진, 운동 등등등~~ 취미에 해당되는 여러 활동을 프로젝트로 등록할 수 있습니다. 그리고 나중에 시간이 흘러 통계에서 내가 그 취미생활을 몇시간이나 했는지 확인하고 반성(?)할 수 있는 수치상의 데이터를 확인할 수 있습니다.

당연히... 검색도 가능하겠죠...

이 테마와 프로젝트를 얼마나 체계적으로 만드냐에 따라 플랜365의 활용도와 가치가 달라질 겁니다.

저도 고민중입니다. ^^









5. 일정,작업,메모 등록


마이홈에서 "추가"를 클릭하거나 주간뷰에서 "날짜"를 클릭하면 일정을 등록할 수 있습니다.

구분에는 테마와 프로젝트를 선택하면 됩니다.

상태는 "예정"과 "완료"가 있습니다.

제목과 내용을 입력하고 "저장하기" 버튼을 클릭하면 저장됩니다.

저장후에는 마이홈으로 자동으로 되돌아갑니다.
















6. 설정


"설정" 화면은 화면 좌측 상단의 이름을 클릭하면 보이게 됩니다.

몇개의 옵션만 설명합니다.

- 홈스타일 : 아젠다뷰와 주간캘린더뷰를 전환합니다.

- 폰트 : 모바일기기의 브라우저에 따라 폰트크기가 달라지는 증상이 있는데 이때 적당한 크기의 폰드로 변경할 수 있게 해줍니다.


- 비밀번호 변경 : 비밀번호를 변경할 수 있습니다.




















몇분이나 사용하게 될까요????
너무 많은 분이 사용하시면 안될텐데....

김칫국 마시는 거겠죠????? ^^

버그가 있을 수 있습니다. 아니 있을겁니다. 번거로우시더라도 이메일 혹은 블로그 방명록에 오류사항을 남겨주시면 최대한 신속하게 수정하도록 하겠습니다.

^^






  • 홍9 2012.01.20 13:39

    해보고싶은데 아직 스맛폰이 아닌지라...ㅜ;;



포스트 내용이 훼손되어 새로 씁니다. 티스토리가 불안~불안~ ^^ (http://blogger.pe.kr/391)


나는 엔지니어다.

내가 하는 일을 뭐라고 불러야 할지 지금도 모르겠다. 혹자는 SE(시스템엔지니어)라고도 하고 혹자는 컨설턴트라고도 한다. 일이 일이니 만큼 여기저기 돌아다니면서 일을 하게 되고 이런 저런 다양한 업무가 실행중인 서버들을 만지게 된다. 운영체제도 다양하고 하드웨어도 다양하고 네트워크도 복잡한 곳이 많다. 내가 가본 기업이나 관공서만 해도 수백 곳이 되지 않을까 싶다.

 

그렇게 많은 곳을 다니며 이런 저런 프로젝트를 진행하면서 만난 사람들은 대부분 나와 같은 엔지니어들이다.(개발자를 볼일은 자주 있지 않다) 엔지니어들은 적어도 하루에 하나 이상의 프로젝트에 투입되어 일을 하게 된다. 1~2회의 방문으로 시작과 끝이 나는 곳이 있는가 하면 많게는 백 회 이상 즉 백일 이상 방문 혹은 상주하여 진행해야 종료되는 프로젝트도 있다.

개발자의 경우 WBS니 뭐니 하는 개발방법론에 의해 일정과 개발 과정이 관리되며 큰 SI업체든 작은 개발업체든 일단 프로젝트에 투입되면 비교적 일정과 업무 단계가 잘 관리되는 경우가 많다. 하지만 동시에 여러 프로젝트를 떠돌며(?) 지원업무를 수행하는 엔지니어의 경우 업무 수행 과정과 단위 업무 혹은 프로젝트의 관리가 제대로 이루어지는 것을 보지 못했다. 더군다나 엔지니어들이 속한 기업들은 대기업보다는 소규모의 중소기업이 많다. 그렇기 때문에 아무래도 중소기업이나 벤처기업의 경우 엔지니어와 엔지니어들이 수행하는 프로젝트에 대한 관리가 소홀한 경우가 많은 것이다.

 

하지만 시작과 끝이 명확하고 업무 단계도 투명한 개발프로젝트와 달리 특정 하드웨어 혹은 S/W 솔루션의 기술지원을 위해 프로젝트 투입되는 엔지니어는 프로젝트의 시작과 끝이 명확하지 않은 경우도 많고 프로젝트 특성에 따라 동일한 규모의 두 개의 프로젝트라 하더라도 투입 인력과 시간이 천차만별인 경우가 많다. 따라서 더욱 철저한 인력과 시간관리가 필요하다 할 수 있겠다.

 

솔루션의 가격은 정해져 있는 상태에서 과도한 엔지니어의 투입은 인건비의 증가로 이어지고 결국에는 수입을 초과하는 인건비의 투자로 인해 적자로 이어지지만 그에 대한 비용의 산출을 위해 기술지원에 대한 근거를 남기지 못하는 경우가 대부분이다. 게다가 SI업체와 함께 시작한 프로젝트가 종료되어 SI업체의 개발자들과 프로젝트 팀은 모두 철수하였는데도 솔루션 업체의 엔지니어는 지속적으로 투입되어 일을 마무리(?)하고 있는 경우고 허다하게 보아왔다.

 

하지만 어느 업체도 그에 대한 문제를 심각하게 인식하거나 왜 그러한 경우가 발생하였고 그런 경우 얼마나 많은 추가적인 비용이 투입되었는지를 산출하여 제품의 원가에 반영하는 경우를 보지 못했다.

 

나는 그냥 엔지니어다.

 

기술지원 업무를 수행하는 엔지니어의 업무를 관리할 방법론을 만들만한 지식은 없다. 하지만 궁하면 통한다고 했던가... 내 엔지니어 업무 수행 경험을 바탕으로 내가 몸담고 있는 회사에서 사용할 간단한 기술지원 업무 관리 시스템을 만들어 보았다. 아마도 대부분의 솔루션을 판매하고 기술지원을 하며 유지보수를 수행하는 엔지니어를 보유한 기업에서 사용할만한 시스템을 목표로 만들었다.

 

특별히 설계도 없었고 누구와 협의도 하지 않았다. 그냥 혼자 만들었다. 그만큼 단순하고 비 체계적일 수 있지만 단순한 만큼 쉽게 사용할 수 있다.

 

로그인


프로젝트가 팀장 혹은 담당영업에 의해 등록되면 엔지니어들이 프로젝트의 수행 혹은 기술지원을 위해 일정을 등록할 수 있다. 프로젝트가 등록되지 않으면 엔지니어는 외근 혹은 내부에서 프로젝트 수행에 대한 일정을 등록할 수 없다.

등록된 일정은 다음과 같이 달력화면에서 어떤 프로젝트에 누가 기술지원을 수행하고 있는지 한눈에 볼 수 있다.

 


주 단위, 엔지니어 개인, 팀 등의 구분에 의한 보기는 하지 않았다. 현재 엔지니어가 9 명인데 사용하는데 전혀 불편함이 없다.(물론 나만의 생각~~~ ㅋㅋ) 그래서 그런 기능은 넣지 않았다.

 

달력에 표시된 일정 중 하나에 마우스를 올리면 다음과 같이 내용이 상세하게 보이는 팝업창이 보인다. 궂이 일정을 클릭하여 수정모드로 들어가지 않아도 내용을 마우스의 움직임 만으로 볼 수 있도록 하였다.



이렇게 등록된 일정이 누적되면 특정 고객사 혹은 프로젝트에 지원된 내역을 조회할 수 있게 된다. 어느 프로젝트에 얼마만큼의 기술인력이 투입되었는지 통계가 가능하고 언제 처음으로 엔지니어가 투입되었고 언제 설치를 진행하였으며 언제 어떤 문제가 발생하여 장애지원을 했는지 등 다양한 검색을 할 수 있다.



기술지원현황조회



위의 화면은 모 대학에 대한 기술지원 이력을 조회한 화면이다.조건에 따라 장애지원,설치,엔지니어 등 다양한 조건을 이용해 기술지원이력을 조회할 수 있다.

 

하나의 프로젝트가 검수단계를 거쳐 완료되면 무상 유지보수 기간에 들어간다. 또한 무상 유지보수기간이 종료되면 유상 유지보수 계약을 유도하여 매월 일정액의 금액을 받고 정기점검과 이따금씩 교육 혹은 업그레이드를 실시해주게 된다.

 

그래서 유상 유지보수계약이 된 고객사 및 프로젝트를 별도로 관리할 수 있도록 다음과 같이 유상 유지보수 계약 고객사 및 프로젝트를 관리할 수 있도록 하였다.

물론 엔지니어가 일정을 등록할 때에는 프로젝트가 진행중인 일정인지 유상 유지보수 계약이 되어 있는 고객사에 대한 기술지원인지를 구분하여 일정을 등록할 수 있도록 하였다.