패스트캠퍼스 PM강의 6주(5) case study - 외주과제

요구사항정의(내부)

요구사항 접수 ► 다양한 채널에서 정보찾기 (공식사이트, 솔루션 분석 비교, 현업인터뷰, 경쟁사 도입여부 체크, 파트너사 만나보기)
📌 대체로 현업은 구체적인 요구사항을 정리해놓지 않는다! 그래서 우리는 궁예가 되어야 한다 😁
►보고서 작성에 필요한 컨텐츠 백업하기 : 요구사항, 동업계현황, 솔루션소개, 도입비용 등 

 

보고 및 비용 품의

• 회사 내부에서 진행 의사결정을 받는 단계
• 회사마다 방법과 문화가 달라서 일반화하기 어렵지만 시도해본다면?
  • 보고서를 작성한다(보고서에 포함될 내용 예시; 배경 및 문제점 > 개선방안 > 예상 일정 및 비용)
    • 배경 및 문제점 : 미리 정해져 있다. 이걸 왜 제안하는지, 어떤 문제들이 있는지를 명확하게 제시
    • 개선 방안: 가장 어려운 부분, 지인/다양한 업체와의 미팅, 제안내용을 참고/ 문제를 어떻게 어느 수준으로 해결할지 제시
    • 예상 일정 및 비용: 돈 + 인하우스 구축 이라면 리소스 투입기간도 비용임. 개발팀이나 업체와 상의해서 합리적인 수준으로 지정해야 한다.
  • 실무자들과 검토하며 수정(직속 선배 및 팀장님, 개발부서, 요청부서 등)► 사공이 많으면 배가 산으로 간다! 꼭 필요한 부서와!
  • 필요한 경우, 팀장 이상 레벨에 보고하고 피드백 받는다.
  • 의사결정 프로세스를 진행한다.
• 프로덕트 커뮤니케이션의 중심은 기획서이다. 마찬가지로 회사 내 의사결정 커뮤니케이션의 중심은 보고서이다.
• 보고서는 내가 작성하고 수정하지만, 내것은 아니다! 같이 만들어가는 것, 수정을 기분나빠할 필요가 없다.

외주 용역 또는 솔루션 구매 발주

• 프로젝트 진행에 필요한 외부자원을 구매하는 단계
• GA도입 방식은 다양함. ►솔루션 비용과 용역비가 함께 투입
• 돈 쓰는 방법도 회사마다 다름. 구매/개발팀이 진행하기도 하고 직접 진행하기도함. 가장 보수적인 케이스는
  • 제안요청서(RFP, Request for proposal)작성
    • 회사마다 양식이 다르지만 보고서와 비슷. 요구사항이 무엇인지를 명시하여 도와주실 분을 찾는 문서
    • 제안서 접수, 경쟁PT, 발표 등 일정을 명시
  • 업체 제안서를 받고 검토
  • 경쟁PT를 보고 질의응답 ► 회사내부의 규정을 잘 보고 지켜야되는 단계! 주의하기!
  • 평가서 작성
  • 평가 결과에 따라 우선 협상 대상자를 정하고 세부 협의 진행

요구사항 상세정의(w. 외주사)

• RFP의 큰 요구사항들을 토대로 세부 요구사항을 정의하는 단계
• 협력사와 여러차례 미팅을 하며 구체화한다. 이 과정에서 협력사의 요청사항에 최대한 협조하고 일정을 준수
  • 현업부서와 함께 꼭 분석해야 하는 항목들 정하기
  • 개발 부서에서 어느 수준까지 어떤 일정으로 협조가 가능한지 확인
  • 전자상거래 이벤트, 클릭이벤트, 페이지명 정의 등
• 요구사항 정의서와 WBS가 산출물로 나온다.

 

구현

• 요즘 솔루션들은 SaaS 형태, 이전에는 프로젝트 인력이 상주했다.
• GA360파트너의 경우, 고객사 요구사항을 구체화하고 적절한 개발 가이드를 만들어 고객사에 제공
• 이후 개발은 고객사에서 진행하고 잘 구현되고 있는지 검증을 도와준다
• 사실 구현단계에서 기획자가 할 수 있는 것은 거의 없다. 지원 업무를 수행한다.
  • 정기 회의를 만들고 회의록을 작성
  • 개발 과정에서 발생하는 이슈를 함께 고민(스펙 변경, 스펙 아웃 등)
  • 스펙 변경, 누락 정도가 크다면 상위 직책자에게 보고하고 의사결정을 받기도한다
  • 오픈 이후 운영과 활용 계획이나 사용자 교육방안을 세울 수도 있다.
• QA 조직이나 담당자가 없는 경우, 기획자가 직접 테스트를 한다. 이 단계가 매우 중요하다!
  • 개발변경 지점은 당연하고 영향이 없을 것 같아도 서비스의 중요한 흐름은 모두 확인하는 것이 좋다.
    • 회원가입, 로그인, 전시, 검색, 상품, 주문, 취소환불 사이클
  • 배포 일정이 정해지면 고객 부서에 변경내용을 공지하고 필요한 경우 리뷰한다.

안정화 및 결과 보고

• 열심히 준비했지만 배포 이후에 어떤 이슈가 생길지 모른다. 최악의 경우는 롤백+오픈일정 연기이다.
  • 예민한 상태의 개발자들과 동고동락해야한다. 이때 태도가 동료간 신뢰, 유대감에 큰 영향을 끼친다.
  • 내가 컨트롤 할 수 없는 이슈라도 적극적으로 도울 방법을 고민한다.(외부에서 문제가 생겨서인지 나름대로 파악해서 돕기)
  • 장애가 터져서 상급자들이 안달해도 최대한 개발자들을 괴롭히지 말자. 열심히 대응하는중에 원인 알려달라고 짹짹거리면 더 늦어짐
• 안정화가 마무리되면 오픈 공지한다. 오픈 공지는 길지만 구조는 아래와 같이 간단하다. 필요한 경우 결과 보고서를 만들고 보고한다.
  • 배포일시, 배포내용, 작업자
• 서비스가 시작되면 마케팅팀 등 현업부서의 질문에 응대하거나 일정때문에 포기했던 개발 항목들을 추려서 AS를 요청하기도 한다.

[내일배움카드], [국비지원교육]을 활용한 교육일지입니다!

#패스트캠퍼스 #내일배움카드 #국비지원교육 #K디지털기초역량훈련