현직장에 저의 사이드 프로젝트를 판매 하였습니다.

저는 현재 직장생활을 하며 사이드 프로젝트로 새출발을 준비 하고 있습니다.

오늘 현 직장의 리드회의에서 제가 사이드 프로젝트로 해결하고자 한 문제와 정확하게 일치하는 이슈를
대표님이 언급하셨습니다.

회사 생활을 하면서 느낀 문제점들을 개선하고자 사이드프로젝트를 준비한 것이기 때문에,
저희 디테일이지와 현 직장에서의 문제 해결 방식이 당연히 일치 할 수 밖에 없었을 것이라 생각합니다.

마침 사이드 프로젝트로 준비된 MVP 수준으로 많은 문제들이 해결 가능 하였고,
현 직장에 저의 사이드 프로젝트를 세일즈 하게 되었습니다.

디테일이지 도입으로 개선 될 이슈들!

• Weekly 서비스 업데이트 일정에 영향 없이, 업데이트 기능 QA TEST 를 모두 실행 할 수 있다.

  • QA 를 하게 되면 오류 보수 하느라 업데이트 일정이 연기되는것이 가장 우려되는 부분이지만
    오류를 수정하지 않고 배포 하더라도, 오류를 미리 인지하고 배포하는 것은 큰 차이가 있다는 관점으로 접근.

  • 각 개발 담당자, 기획자가 진행하는 "기능 단위 테스트" 외에도
    고객과 접점이 있는 부서 담당자들이 "유저의 서비스 이용 동선(테스트 시나리오)" 기준의 테스트를 실행 가능.

• 고객과 접점이 있는 모든 직원이 QA TEST 참여를 통해 업데이트 기능을 익힐 수 있다.

  • 고객과 접점이 있는 직원이 서비스에 대한 이해가 떨어진다는 것은 있을 수 없는 일.

  • 모든 업데이트 사항을 QA TEST 참여를 통해 인식하고 이해하는데 큰 도움이 된다.

  • 기획, 디자인, 개발에 참여하지 않은 인원이 엑셀로 정리된 TC (테스트케이스) 만 보고 QA TEST는 어려우나
    디테일이지를 통해 테스트 해야 할 항목을 쉽게 인지하고 실행 할 수 있는점이 크게 개선됨.

  • 디테일이지를 통해 QA TEST 참여자 현황을 파악 할 수 있어,
    어떤 담당자가 업데이트 기능을 확인하지 못하고 있는지 관리가 가능해 진다.

• 전체적인 개발 일정이 안정화 된다

  • 오류를 인지 못한 상태에서 일정이 잡혀있을 경우,
    크리티컬한 오류 보수 작업으로 인해 기존 스프린트 개발 일정에 차질이 생기는 문제를 해결 할 수 있다.

  • 서비스 배포 전, QA TEST 를 통해 오류를 미리 인지하고 있을 경우
    다음 스프린트 개발 일정에 미리 발견한 오류 보수 작업을 고려하여 작업목표일 또는 스프린트 기간내 작업할 항목을 선택 할 수 있다.

이 회사에서 디테일이지 서비스의 유저 성공 사례까지 만들어 버려야 것습니다. ㅎㅎ