소프트웨어 개발 회사에서 기획, PM업무는 무엇일까?

SW 회사의 기획에 대한 정의는 사업(Biz) 파트나 도메인에 따라 정의 및 업무가 다르다고 생각한다.
사업 기획, 제품 기획, 서비스 기획, 상품 기획 등 다양한 부문(어두 또는 단어)에 기획이라는 단어를 붙인다.

요즘 화두는 기획 업무의 경계가 모호해지며 PM(Product Manager)으로 지칭하고 역할의 더 좁히고 전문화하고 있다. 그래서 전통적으로 기획자들이 해오던 다양한 업무들이 개발 조직의 다양한 구성원들에게 분배되고 있다. 

기획자도 개발을 알아야 한다. 기획자의 개발 용어 알아가기

 

개발 파트에서 기획이란?

필자가 말하고자 하는 부분은 소프트웨어를 개발하는 파트의 구성원으로서의 기획 업무를 정의한다.

모든 학문에는 공학(工學, Engineering)이 있듯이 소프트웨어 개발에는 소프트웨어 공학이 존재한다.
따라서 소프트웨어 공학에서 필요로하는 기획 업무가 개발 파트에서 기획에 대한 정의가 된다.

소프트웨어 개발을 위해 사전에 사업 기획서가 만들어지고 사업 진행이 결정되면 개발해야 할 대략적인 모습이 보이기 시작한다.
아래 개발 프로세스 바탕으로 주요 업무에 대해 다루어 본다.
(프로젝트 셋업은 TPM, Technical Project Manager 의 주 업무로 다루지 않음)

[알쓸신잡] PM? No! TPM의 직무 알아보기.

주요 업무를 언급할 뿐, 상세 업무는 연결된 다른 글에서 확인할 수 있다.

 

---

1. 요구사항 분석 및 정의 업무

그러면 구체적으로 무엇을 개발해야하는지를 정의하는 것이 기획의 첫 업무이다.
요구사항 분석은 사업 기획서를 바탕으로 제안자가 원하는 내용과 시장의 상황을 반영하여 이 프로그램을 이용하는 고객의 니즈를 파악하는 업무이다. 

요구공학에 의하면 5개의 프로세스로 업무가 진행된다.

Feasibility Study (타당성 조사)
- 사업 기획서를 바탕으로 타당성이 검토되었기 때문에 이 부분은 사업(비즈니스) 파트 담당자가 이미 완료했을 것이다.
- 회사 규모가 작을수록 이 업무도 SW 기획자에게 할당될 확률이 높다.

Requirement Elicitation and Analysis (요구사항 도출 및 분석)
- 제안자가 요청한 기능과 시장 상황을 분석하여 실제 원하는 항목을 도출하는 형태로 시나리오 형태로 분석하는 것을 추천한다.

Software Requirement Specification (요구사항 정의)
- 작성된 시나리오에서 기능과 비기능 항목을 구분하여 하나의 문장으로 작성을 한다.
- 애자일에서 말하는 에픽이나 스토리 단위의 항목이다. 

Software Requirement Validation (요구사항 검증)
- 요구사항이 작성되면 요구사항에 대한 검증이 이루어진다.
- 과연 고객이 원하는 것이 맞는가? 개발이 가능한가? 검증할 수 있는가? 등...
- 여러 파트의 관점에서 확인하고 피드백을 반영하여 요구사항을 좀 더 구체적으로 정제할 수 있다.

Software Requirement Management (요구사항 관리)
- 요구사항은 언제든지 변경이 될 수 있기때문에 변경 이력을 관리하도록 권장하고 있다.
- 변경된 항목에 대하여 반드시 이유와 어떻게 변경되었는지 확인이 가능하도록 작성해야 된다.
- 간단한 작업으로 보일지라도 불필요한 리소스가 많이 들어가기 때문에 툴을 이용하여 관리하면 좋다.
- 필자는 테스트링크나 레드마인으로 관리하고 있다. (X-ray, Testrail 도 Jira 와 연결하여 사용하면 좋다)

 

> 참고 내용

유저스토리 작성하기, Given When Then

누구나 따라하기 쉬운 요구사항 작성 Tip, 템플릿

PON (Problem/Opportunity, Needs) - 제품 관리자

소프트웨어 요구 공학, Requirement Engineering

 

---

 

2. 구조 설계 업무 (Information Architecture)

요구사항을 정의하여 무엇을 개발할지가 명확해지면 개발을 할 수있는 작업지시서가 필요하게 된다.
작업지시서는 개발 팀원이 일정안에 개발할 수 있는 상세 기획을 정의한 문서가 된다.
디자이너가 디자인 업무를 진행할 수 있는 화면설계서와 개발자가 기능 개발을 할 수 있는 기능명세서가 작업지시서에 포함된다.

작업지시서는 3번 기능 정의 및 화면설계에서 다루게 되며
3번 항목을 만들기 위해서는 구조를 잡는 행위가 필요하다.

정보처리기사나 기능사를 공부한 기억이 있다면 I.A. 작성 하는것을 추천한다.
그렇지 않다면 간단한 사이트맵이나 메뉴트리 형태로 구조를 잡을 수 있다.

필자의 경험으로 1번과 2번은 따로 분리해서 작업하기란 쉽지 않다.
구조를 잡으면서 요구사항이 수정/정제되는 작업이 반복된다.

그 이유는 보통 요구사항을 비즈니스 관점에서 작성하여 초기 작성시에는 추상적이거나 범위를 크게 잡는 경우가 많기 때문이다.
IA를 작성하다보면 데이터의 흐름과 연결고리가 가시적으로 보이기 시작한다.
그럼 초기 작성한 상위 수준 요구사항에 대한 상세 요구사항을 정제하기 시작하고,
요구사항 정의서도 IA 문서와 함께 완성도가 높아진다.

---

1, 2번을 수행한 산출물로 우린 SRS 문서를 만들어 낸 것이다.
Software Requirements Specification

---

2.5. 기능 정의하기 

SRS 가 너무 무겁고 시간이 없을 경우 간단하게 대체한다.
보통 사이트맵이나 메뉴 구조를 기반으로 상세 기능을 정의하면 간단하면서도 보기 편한 기능 명세를 작성할 수 있다.

작성 시 3개 Depth 를 넘지 않도록 구조를 잡는 것이 좋다.

• 1 Depth : 상위 메뉴나 주요 데이터(엔티티) 단위로 작성한다.
• 2 Depth : 화면 단위로 작성을 한다.
• 3 Depth : 화면에서 구현되어야 할 기능을 작성한다.

후배들에게 기능 정의를 해 오라고하면 보통 사이트맵이나 메뉴트리를 작성해서 가져온다.

그러면 질문을 던진다.

"이게 기능인가요? 메뉴 이름인가요?"

그제서야 기획자는 메뉴 이름 옆에다가 기능에 대한 설명을 추가로 작성해서 가져온다.
기능 명세서는 요구사항 정의서에서 언급한 내용과 거의 유사하기 때문에 구분하여 작성하기는 애매하다.
그래서 빠르고 간단하게 작성하는 방법을 설명한다.

링크의 2.2 I.A 항목을 참고하면 된다.

요구 사항 작성이 어려울때 하나씩 파헤치기 (경험기반)

---

 

3. 비즈니스 플로우 작성 업무 (Flowchart)

비즈니스 플로우는 서비스 전체를 담으려고 노력하기보다는 유사한 범주를 묶어서 모듈화 하는것이 좋다. 
2.5단계에서 언급한 1 Depth 기준으로 범주를 나누는것도 좋다.

• 회원가입 / 탈퇴
• 로그인 / 개인화 영역
• 서비스 이용 1, 2, 3, 4, 5 

비즈니스 플로우는 화면설계서를 작성하는데 필요한 구조를 잡는 역할을 수행한다.
개발하고자 하는 내용의 인터페이스와 기능들이 누락없이 명시되어야 한다.

아래 비즈니스 플로우 작성은 아래 문서를 통해서 확인할 수 있다.

나만의 순서도 작성하기 (feat, 범례 & SW기획자)

 

---

4. 화면 설계 업무

비즈니스 플로우가 작성되었다면 그게 맞는 상세 화면 구성 및 기능을 설명해야 한다.
바로 작업 지시서가 되는 화면설계서를 만들어 내는 작업이다.

보통, 기획서라 하면 SW공학에서 말하는 화면설계서(UI설계서)를 말한다.

개념은 알고 있어야 다양한 분야의 사람들과의 의사소통에 도움이 될 것이다.
기획서의 뜻과 분류는 지식백과나 위키에서 다양한 분야의 입장에서 자세히 설명하고 있으니 한 번씩은 확인해보길 권한다.

혹여, 화면설계서를 스토리보드라고 말하는 회사가 있는데, 이는 국내에서만 통용되는 용어니 글로벌 진출을 위해서는 지양하기를 바란다.
해외에서 스토리보드란 보통 미디어분야에서 사용되며 장면 이미지로 스토리를 전달하는 문서를 말한다.

화면설계서는 3가지 항목이 자연스럽게 매치되도록 작성하는 게 좋다.
화면(Screen Wireframe)과 사용자 행위 또는 동작(Action), 동작에 따라 변화되는 화면이나 내용들(Feedback)이 포함되어야 한다.

첫 페이지는 화면 구성에 대해 작성을 하고.

로그인 화면에 대한 구성 및 UI 요소 설명

두 번째 페이지부터는 화면에서 사용자가 할 수 있는 기능과 기능 동작에 따른 결과를 명시한다.
위의 두 번째 페이지 부터는 하나의 페이지에서 1개의 기능만 명세하고 코드를 부여하는 것을 권장한다.
가독성이 높아지고 기능 명세의 코드와 매치할 수 있으며 재 사용에도 용이해진다.

로그인 부분의 화면 설계서 - 화면과 기능을 구분하여 작성

1. 타이틀
2. 화면 구성 : Header
3. 화면 구성 : Footer
4. 화면 구성 : Contnet
5. 기능 설명 : 로그인 버튼 동작
6. 기능 설명 : 로그인에 대한 서버 오류

화면설계서 작성 관련된 Tip 은 앞으로도 계속 업데이트되니 해당 글을 참고하면 된다.

 

기획업무, 화면설계서 체크리스트 만들어 보기

기획 업무, 문서 작성 이렇게 해보자

UX 전략 수립, 기획 시스템(모듈화)

---

 

5. 커뮤니케이션

기획분야 면접을 보면 면접관과 면접자 모두 중요시 여기는 것이 바로 커뮤니케이션 능력이다.
커뮤니케이션은 방법과 도구가 다양하고 트렌드도 많이 탄다.

 

리뷰 진행.

기획자는 자신이 작성한 문서에 대해 리뷰를 해야 한다.
- 의사결정권자에게 의도와 방향을 설명하고 의사결정을 받아야 한다.
- 개발팀에게 상세한 내용과 흐름을 이해시키고 피드백을 수렴하여 보완할 수 있어야 한다.

문서는 리뷰 하루 전에 배포하여 리뷰어들이 확인할 수 있도록 시간을 제공해야 한다.
또한 문서의 목적과 주요 사항을 메모하여 문서와 함께 배포하는 습관이 필요하다.
왜냐면, 내가 겪은 99% 의 리뷰어는 문서에 대한 사전 리뷰를 하지 않았다. 

따라서 더 먹여줄 필요가 있었다. (떠 먹여줄 때까지 기다리는 수동적이며 무책임한 사람이 너무 많다.)

의사결정권자에게 리뷰는 3의 법칙을 생각해야 한다.
3가지 안을 제시하고, 3번째에 자신이 원하는 것을 리뷰한다.
1, 2번이 유사하거나 비슷한 컨셉과 방향으로 작성되어야 3번이 채택될 확률이 높다.

개발팀에게는 만들고자 하는 기능의 목적이 사전에 주입될 수 있도록 해야한다.
그리고 화면의 구성보다 사용자 액션과 그에 따른 피드백이 어떻게 나오는지를 설명한다.
(어차피 화면은 디자이너가 제공한 가이드대로 구성해서 시간을 소비할 필요가 없다.)

필자가 생각하는 이상적인 개발팀에 대한 리뷰는 
한 페이지에 대하여
  - 기획 : 달성하고자 하는 목적 또는 작성 의도를 설명.
  - 개발 : 사전 리뷰에서 잘못 이해한 부분, 체크사항 질의.

이상과 현실의 경계는 얼마나 주도적으로 가이드하고 훈련을 시키냐에 따라 달라질 것이다.

 

이슈 대응.

기획자는 자신이 기획한 내용에서 발생하는 이슈를 처리해야 한다.
- 개발 기간에 예기치 못한 예외 사항에 대한 정의.
- 시장 상황 변동에 따른 제품 변경의 필요.

보통 리스크는 프로젝트 매니저가 관리하지만
이슈가 되었을 경우에는 몇몇 상황에서는 기획자의 발 빠른 대응이 필요하다.

기획자는 코딩이 어떻게 되었는지 알 수가 없기 때문에 생각하지 못한 예외 케이스는 반드시 존재한다.
그리고 겸허히 받아들이고 빠르게 정의를 내려야 한다.

case 1. 화면설계서에 없는 예외 사항에 대한 처리
case 2. 플랫폼 버전에 따른 제약 사항의 발견
case 3. 사용자 환경에 따른 동작의 오류
case 4. 화면설계서와 다른 디자인 가이드
case 5. 개발이 불가하거나 일정 부족으로 기간내 불가피한 경우

 

아이데이션

기획자는 창의적인 업무를 요구받기도 한다.
나 혼자 잘난 사람은 여기 없기 때문에 창의적인 결과물을 만들기 위해 여럿이 머리를 맞댈 필요가 있다.
따라서 기획자는 미팅을 주도적으로 이끌어야할 책임이 부여된다.

기획자는 회의에 있어 모더레이터 또는 퍼실리테이터로 역할을 수행하면 좋다.
(중재자 또는 촉진자 역할을 하면 됨)

우리는 전문가가 아니기 때문에 요약해서 3가지 업무에 충실하면 좋다고 생각한다.

 

회의 소집 (도입)

회의 목적 달성에 적합한 리소스를 선정한다.
- 주제나 안건 선정하여 공유한다.
- 장소와 일정을 정하여 공유한다.
- 참석 멤버를 선정한다.

회의 진행 (워밍업 > 미팅 진행)

회의 목적 달성을 위해 중재자 역할을 한다. (경청!!)
- 내 의견 보다 참여자의 의견을 듣도록 한다.
- 누락되는 의견이 없도록 메모해야 한다. (역할 지정도 좋음)
- 동등하게 발언할 수 있도록 조정한다. (나도 포함)
- 주제에 벗어나지 않도록 가이드 한다.
- 주어진 시간을 인지하고 안건에 따라 배분할 수 있어야 한다.

회의 정리 (결과 정리 > 마무리)

회의는 목적을 가져야하며 종료시에 목적 달성 또는 다음 행동들이 정해져야 한다.
- 회의 종료 전 의견을 취합하여 정리하여 공유해야 한다.
- 정리된 내용에 이견이 있을 경우 보완하여 회의록을 작성한다.
- 목적이 달성되었다면 확정된 내용으로 다음 업무를 진행하도록 한다.
- 목적이 달성이 되지 않았다면 다음 회의를 위한 업무를 정의한다.
- 합의된 내용이 이루어질 수 있도록 Follow-up 해야 한다.

 

설득력 있게 말하기, 6하원칙과 Context 그리고 습관

의사소통, 말만 잘하면 된다?? 퍼실리테이션과 모더레이션

---

 

6. 기획 검수

내가 면접을 본 지원자들 대부분이 품질팀이 없는 환경에서 근무한 경험이 많았다.
그래서 이력서에 테스트 케이스 작성, 테스트 수행한 경력들이 포함되어 있었다.

실제 그들은 명세 기반의 테스트를 수행했지만 테스트 계획 수립 및 방법에 대해 전혀 알지 못했고
본인이 기획한 내용이 제대로 되었는가를 간단하게 보는 수준이었다.

바로 기획 검수를 진행했던것이다.

기획자가 자신이 기획한 내용의 산출물에 대하여 기획 검수를 하기 위해서는 나름의 기준을 명확히 수립해야 한다.
- 기획 검수 통과 기준 (성공, 실패, 보류)
- 기능 축소 및 일정 변경에 따른 사용자에게 미치는 영향도
- 기능 축소 및 일정 변경에 따른 기능간 상관 관계

이것은 품질팀에서 수행하는 QC(Validation)하고는 명확하게 다르다.

기획 검수는 테스트 개념으로 보면 인수 테스트에 가깝다.
=> 사용자 입장에서(기획 의도대로) 기능 올바르게 동작하는지 체크한다.

필자의 회사에서는 통합테스트(개발자 테스트)기간에 기획 검수를 병행한다.
따라서 아래와 같이 간단한 점검을 진행한다.

- 사전 점검 : 개발파트에 대한 QA(Verification) 진행
- 기능 점검 : 기획자가 기획한 기능이 동작하는 여부 확인

개발자 체크리스트, 통합 테스트 기간에 기획자에 의한 검수가 진행

위 표를 보면 Test Case 와 분명히 구분되는 것을 확인할 수 있다.

기획 검수나 디자인 검수가 이루어지지 않고 품질팀에 배포되어 검증을 진행하게 되면, 일부 기능의 오동작이나 의도하지 않은 동작으로 인해 테스트가 지연될 수 있다. 반드시 기능의 동작에 대한 기획 검수를 할 수 있는 환경을 제공하는 것과 기능 검수를 하겠다는 기획자의 의지가 중요하다.

=> 개발 프로세스 내 하나의 프로세스로 정립하는 것을 추천한다.
=> 테스트 관리 도구가 있다면 상위 요구사항과 연결하여 검수하는 것도 좋은 방법이 될 수 있다.

 

유의사항.

• SW 개발 주기에 기획 검수라는 단계는 없다.
• 기획 검수는 디자인 검수와 병행하여 진행 할 수 있다.
• tip! 개발 리뷰 시간을 활용하여 산출물에 대한 기획검수를 할 수 있다.
• tip! 개발팀 통합 테스트 주관하여 기획검수를 병행할 수 있다.

OPR(One Page Report), 보고서 작성 요령