4. 직무 전환

    팀의 이동 및 업무의 전환에 따른 기존 업무가 방해 된다면 이러한 것 자체를 하지 말라/자제하라는 내용이다.
    하지만, 다른 프로젝트의 일원으로써 작업할 수 있는 여건이 좀 더 개선이 된다면, 아예 하지말라보다는
    현실적인 접근해서는(현실적으로 여러 일을 해야만 하는경우가 많기에..) 개선의 여지가 있을 것 같다.
 
    즉, 어느 팀에 소속되어 있으며, 무슨 일을 하고 있으며, 그러한 일의 업무량이 얼마나 되는지 체크가 가능하다면 ...
    직무 전환에 따른 리스크를 좀 더 줄일 수 있을 것이다. (물론, 이렇게 안하는 것이 좋다고 이야기하지만... )

5. 대기
   
    결국 대기라는 상태인 것을 팀원들이 공유하고 있는 자체가 가장 중요할 것 같다.
    현실적으로 대기를 함에 있어서도 그것이 대기 상태인지 조차 인지 못하는 것이 가장 큰 문제라면 문제일 것이다.
   
    앞서 잠시 나왔던 내용이지만, 이러한 것을 통해 대기상태에 대한 관리가 가능해지며, 업무의 치우침 현상도 막을 수 있다.

6. 이동
   
    문서화되어 전달되고, 공유하는 것에 따른 시간적 낭비, 업무 조율을 위해 움직이는 실제 움직이는 시간들의 낭비를 지적하고 있다.
   
    이 문제는 Web2.0 시대의 산물중 하나인 챗팅기능을 통해 어느정도 해소 할 수 있다.
    실시간 업무 조율 자체를 채팅으로 진행할 수 있으며, 문서 역할을 하는 작업내역이나 소스내역서, 빌드내역서 등을 해당 채팅창에
    가볍게 드래그앤드랍 만 시켜도 링크가 될 수 있도록하면 놀라운 협업 가능 메커니즘이 탄생하게 된다.
    (링크 된 내용은 클릭하면 하면 해당 내역서를 바로 띄워준다.)

7. 결함
   
    긴말이 필요없는 내용인듯 싶다. 테스트와 통합, 릴리즈를 빠르고 효율적으로 할 수 있게 해주는 내용이다.
   
    빌드 관련 내역 중심으로만 설명했지만, "3.가외기능" 설명에 있는 모든 내용이 이러한 결함 관리의 중요 내용이다.

8. 관리활동
   
    프로젝트와 팀에서 일어나는 일들을 한눈에 볼 수 있는 환경을 얼마나 제공하는지가 중요한 요건이 될 것이다.
    즉, 투명성의 확보다. 이를 통해 팀원 모두가 일관된 팀 작업이 가능토록 해주는 원동력이 된다.
   

    팀 아티펙트라는 윈도우를 통해 팀에서 일어나는 모든 일들을 다양한 형태로 볼 수가 있다. (변경도 얼마든지 가능하다)
    또한 유사한 형태로 My Work 를 관리해주는 윈도우 또한 가지고 있어 나 자신의 관점에서도 관리가 가능하다.



       eclipse 개발환경 뿐만이 아닌, 웹 Ui형태로도 모든 작업이 가능하다. 더욱이 중요한 것은 DashBoard 기능을 통해
       프로젝트의 내역을 한눈에 볼 수가 있다. (보고자하는 내용을 자유롭게 변경하여 구성도 가능하다.)


   
    리포트(차트) 형태로 한눈에 알기 쉽게 현 상황을 모니터링 해준다. (이 역시도 변경이 가능하며 결과를 위한 쿼리 역시 쉽게
    생성 가능하다)



    좋은 프로젝트 결과에 있어서 가장 중요한 요소로 뽑히고 있는 Feed 도 한눈에 볼 수 있도록 제공 가능하다.

================================================( 끝 )==============================================