기획에 대한 단상 #1

결국 문제를 정의하는 것이 첫걸음이고, 문제를 정의하는 것은 질문이다.

• 인터뷰를 어떻게 수행할 것인가?
• 전형적인 기획 과정들이 갖는 의미는 무엇인가?
• 모든 분석 프로젝트의 요구사항은 질문으로 정의/기술 된다.
• 발표는 20분을 한다면 > 40장 (30초에 1장)

용어를 알고 있는 것은 생각의 크기를 다르게 한다.

• 5 Why 분석

• MECE 분류

• 스크럼
  • 제품 백로그
  • 스프린트 백로그
  • 번다운 차트
• 미션과 비젼의 차이
  • 미션 = 사명
  • 비젼 = Goal과 도달하기 위한 해결책, 구체적

• Amazon Working Backwards

• 사용자 여정 지도

• 어프로치 > 개발방법론 > 계획

• MSA (Micro Service Architecture)
• RPA (Robotic Process Automation)
• Soft Sensor
• Edge Computing
• Autonomic Computing

인터뷰를 수행하는 방법

조사는 최대한 빠르고 신속하게 메일을 보내고 기다리지 말고 센터로 방문하는 것이 좋다 전문가는 시간을 많이 내주지 않는다. 인터뷰에도 전략이 필요하다

개요나 소개는 짧게, 바로 핵심 질문을 한다 프로젝트의 위험 분석을 미리 해가서, 다른 위험이 있는지 묻는다

한 번의 인터뷰로 원하는 모든 것을 얻기 힘들다. 프로젝트 조력자와의 좋은 관계를 만들기 위한 첫 걸음으로 생각해도 좋다.

Amazon Working Backwards

한장짜리 광고를 만들어 보는 것이다. 이런 제품이 어때요?

어떤 문제에 대한 방법은 하나만 있지 않다.

트렌드인, 메인 방법이 있겠지만,

미션과 비젼의 의미

둘다 방향성을 잃지 말자는 의미에서 정하는 것 프로젝트를 연구하면서 바뀔 수 있다

스크럼

제품 백로그란, 사용자 관점에서의 요구사항 스프린트란, 개발적인 요구사항

전형적인 기획의 과정들이 갖는 각각의 의미란 무엇인가?

• 우리 프로덕트의 니즈를 증명한다.
  • 고객 가치 설계
    • Value Proposition Canvas와 같은 접근법
  • 인터뷰
• 그 니즈가 얼마나 중요한지
  • 시장의 규모
  • 논리를 증명할 방법에 대한 고민
    • 설문조사
    • 실험
• 프로덕트 백로그
  • 서비스 시나리오
    • 사용자 여정 지도

이러한 사용자 관점의 기획에서, 어떻게 수행할 지 생산자 관점에서의 기획으로 나아간다.

• Approach, 기술 전략
  • 이 프로덕트 백로드의 문제들을 어떻게 풀 수 있을까
    • 학습 데이터의 수집 방안과 같은
• 프로젝트 위험 관리
  • 학습 데이터를 수집하지 못한다면?
  • 학습 결과가 원하는 정확도 만큼 안나온다면?
  • 위험 관리의 과정
    1. 위험 식별 : 어떤 위험이 있는지 판단
    2. 위험 평가 : 위험이 발생되었을 때 어떤 손해가 있는지
       1. 위험 가치 = 위험 평가 * 위험 확률
    3. 위험 회피 : 위험 상황을 회피한다
    4. 위험 약화 : 위험 상황이 닥친다면 어떻게 하면 위험 평가를 낮출 수 있을까
    5. 위험 탈출 : 위험이 터졌을 때 빨리 탈출하는 것

방법론 vs 방법

방법론 = 4(절차 + 기법 + 도구 + 산출물/결과물) + 1(테일러링 가이드)

방법 = Tailor(방법론, 프로젝트의 특성)

방법 제시를 위해서, 우리 프로젝트의 특성(가능성 + 한계성) 정의가 필요하다.

개발 일정

프로젝트 수행 방법 + 시간 = 개발 일정

개발 일정, 요구사항분석 > 설계 > 구현 > 테스트 > 출시 ==> X

우리들의 방법이 아니다. 우리 프로젝트만의 용어가 나와야 한다. 요구사항분석 > 모범견 행동분석