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

기획하는데 개발을 왜 알아야 하죠??
Product Manager 는 제품만 잘 알면 문제없던데요??
Product Owner 는 방향만 잘 잡으면 잘 되던데요??

 

라고 생각하는 사람이 아직도 있는지 모르겠지만, 혹시 모르는 마음에 개발을 모르는 기획자라도 알아두면 좋은 지식에 대해 다루어 본다.

개발은 SW가 만들어지는 모든 과정을 통칭하는 용어로,

기획자는 개발을 알아야 한다.
단, 코딩을 알 필요는 없다.

 

이런 것들이 기획자가 범하는 가장 많은 오류이다.

이런 것들 => 용어의 잘 못된 이해

 

 

 

 

 

 

1. 개발 (Software Development)

 

SW개발 회사에서 개발은 하나의 SW 제품이 나오기까지의 시작과 운영까지의 모든 단계를 일컫는다.
즉, 요구사항 > 설계 > 구현 > 검증 > 운영 의 모든 프로세스를 포함하고 있다.

그럼 기획자는 각 단계별 어떤 업무를 수행하는지 확인하고 왜 개발을 알아야 하는가를 이해하면 된다.

첫 번째로 기획자는 요구사항 항목에서 요구사항 수집(도출)/분석/정의/관리(검증) 업무를 수행하는 요구사항 개발 행위를 진행한다.

두 번째로 요구사항 정의서를 기반으로 화면설계서 및 기능명세서를 작성한다.
이것은 기획자가 하는 설계 작업이다.
이 설계를 기반으로 개발 담당자들이 시스템 설계 및 구조설계를 진행하게 된다.
기획자와 개발자의 설계 행위를 합쳐 SW 설계 단계가 마무리되고 구현 단계로 넘어간다.

세 번째로 구현 단계는 코드 작성(코드베이스)이 메인 업무가 되지만, 일부 누락된 항목이나 잘못 설계된 부분으로 인해 기획자와 개발자의 의사소통이 지속적으로 이루어지게 된다.
일정에 영향을 주는 항목들은 매니저와 협의하여 범위 수정이 원활하게 이루어질 수 있도록 서포트해야 한다.

네 번째로 검증 단계에서 기획자는 개발된 산출물이 자신의 의도를 만족하는지 검토하고 피드백하는 행위를 한다.
보통 기획 검수나 개발자 테스트 단계에서 기획자가 수행하는 업무이다.
기획자의 검수가 완료되면 실제로 테스트 및 품질에 대한 검증이 진행된다. 
이때는 예상치 못한 예외 케이스와 같은 항목에 대해 기획자가 정의해주거나 의사 결정을 내리는 행위를 한다.

다섯 번째로 운영 단계에서는 업무가 운영 기획 담당자에게 이관될 수 있다. 
기획자는 GA나 유사한 데이터 분석 툴을 통해 사용자 패턴이나 유입/사용량, VOC 등 데이터를 확인하고 제품의 문제점 해결을 위한 고민 및 새로운 백로그를 만드는 행위들을 진행한다.

 

5단계의 프로세스가 일반적으로 말하는 SW의 개발이며 기획자는 모든 단계에 걸쳐 업무를 수행하고 있다. 따라서 기획자는 개발을 알 필요가, 아니 반드시 알아야 하며 좀 더 구체적으로 본인이 속한 조직의 개발 프로세스를 이해하고 본인의 담당 업무를 이해하고 수행해야 된다는 것이다.

 

기획자도 알기 쉽게 설명된 간행물을 소개한다.
애자일 초심자를 위한 '애자일 SW개발 101'

 

애자일_SW개발_101_v1_0.pdf

8.59MB

 

 

 

2. QA 와 QC, 그리고 테스팅

 

SW 개발 구성원 중에서 품질 담당자 이외에 개념 이해를 잘 못하는 사람이 꽤 많은 부분이다.
보통 QA, QC 구분 없이 테스팅이라 부르면서 개발팀이 만든 SW산출물의 오류를 찾는 행위 또는 그냥 테스터로 오해한다.

아래는 QA 와 QC 를 구분하기 위해 작성된 내용이다.
볼드체만은 반드시 기억하면 좋을 것 같다.

 

품질 보증 (QA) : 제대로 만들고 있는가? (개발 단계에서 모든 프로세스를 검사) 
 => Verification

소프트웨어 품질 보증(QA라고도 함)은 결함을 방지하고 특정 응용 프로그램에 맞게 기술, 방법, 접근 방식 및 프로세스를 설계해야 하는 일련의 작업이다.

품질 보증은 소프트웨어 개발 프로세스 내에서 수행되는 행위이다. 
응용 프로그램 단위 개발은 개발 순서에 따라 품질 보증 사양에 따라 점검됩니다. 
품질 보증 테스트는 소프트웨어 개발에서 고품질 프로세스, 우수한 품질 관리 시스템 및 정기적인 적합성 감사에 중점을 두고 있기 때문에 고품질의 소프트웨어의 개발을 보장한다.

품질과 관련된 문제를 방지하기 위해 계획적이고 체계적인 활동과 문서를 포함하는 관리 도구이다.

품질 관리 (QC) 잘 만들고 있는가? (개발 산출물의 유효성을 검증) 
 => Validation

QC 라고도하는 품질 관리는 개발된 소프트웨어의 결함을 식별하여 소프트웨어의 품질을 보장하는 작업이다.
주요 목적은 소프트웨어를 릴리스하기 전에 모든 유형의 결함을 수정하는 것입니다.  
소프트웨어가 고객의 요구 사항과 높은 품질을 충족할 수 있도록 수정 도구를 통해 문제의 원인 (품질을 저하시키는 원인)을 제거함으로써 프로세스가 수행된다.
품질 관리의 책임은 검증 및 수정 도구로 소프트웨어의 결함을 테스트하는 테스트 팀으로 알려진 특정 팀의 책임입니다.

 

우리가 일반적으로 말하는 개발단계에서의 검증은 QC 행위를 말하여 테스팅(유효성 검증)이라고도 표현하고 있다.
QA 담당자를 테스터라 부르는 오류는 범하지 않도록 하자.

 

참고 : www.javatpoint.com/difference-between-quality-assurance-and-quality-control

 

 

3. 배포 단계에 대한 이해

 

개발 중인 SW 는 검증을 위해 또는 고객에게 전달하기 위해 배포(Release) 를 진행하게 된다.
배포는 한 번에 이루어지는 것이 아니라 단계별로 이루어진다.

필자 경험에서 일반적으로 Alpha, Beta, RC 버전이 있다.

 

알파(Alpha) 단계

• 내부 개발 검증 단계이다.
• 개발 버전의 배포이다.
• 통합 테스트가 완료되고 시스템 테스트, 인수 테스트를 수행할 때의 버전이다.
• 품질팀의 통제에 따라 배포가 이루어지고 조직 내부 품질 조직에 의해 검증이 이루어진다.
• 공인 서비스와 동일한 구조로 Alpha 서버를 구축하기도 한다.

 

베타(Beta) 단계

• 외부 검증 단계이다.
• 내부 품질팀의 PASS 를 받은 버전으로 기능의 결함이 없다고 판단되는 수준이다.
• 공개 테스트할 수 있는 버전이다. (Open/Close 구분할 수 있다.)
• 사용성 및 고객, 외부 환경에서의 동작 테스트 용도로 사용한다.
• 공인 서비스와 동일한 구조로 서버스를 갖추고 테스트해야 한다.
• 플랫폼 제조사(apple, google, MS 등)가 개발자나 신청자 대상으로 배포하는 단계이다.

 

RC (Release Candidate) 단계

• 고객에게 배포되는 출시 마지막 단계이다.
• 사전적 의미로 찾아보면 Microsoft 에서 출시 직전의 단계로 배포하는 버전이다.
• RC 버전이 출시되었다는 것은 해당 버전이 정식 출시로 배포될 가능성이 높다.
• 보통 SW 개발회사라면 Beta 오픈 후, 정식 배포하는 것이 일반적이다.

 

Nightly build

• 위키에서 소프트웨어를 검색하면 나오기 때문에 개념만 옮겨놓는다. (알 필요 없다.)
• 굳이 기획자나 매일 발생하는 소프트웨어에 대한 수정사항을 포함하고 있는 배포 버전이다. 

 

 

 

4. 기능과 비기능 요구사항

 

기획자에게 요구사항을 작성하라고 하면 비즈니스 요구사항만 접근할 수 있다.
그리고 기능과 비기능의 구분을 모호하여 구분을 못한다.

ISO 25010 의 품질 특성과 부특성을 기반으로 기능과 비기능 요구사항을 작성할 수 있다.

 

출처 https://www.it-cisq.org/cisq-supplements-isoiec-25000-series-with-automated-quality-characteristic-measures/

 

SRS (Software Requirement Specification)를 작성한다면 위 언급한 품질 특성 기반으로 작성하면 좋다.
하지만 개발 지식이 없다면 품질 특성을 구분하여 요구사항 명세를 작성하기는 어려울 것이다.
쉽게 품질 특성에서 기능성을 제외한 나머지는 비 기능으로 인식하면 된다.
(보통 개발지식이 있는 선임자 또는 개발 리더, 아키텍트가 작성하는 게 맞다고 생각한다.)

말하고자 하는 것은 기능과 비기능이 무엇인가는 구분할 수 있으면 좋겠다는 것이다.
(SW품질 특성을 아는 것은 분명히 도움이 될 것이다.)

 

기능 요구사항은 SW가 동작하는 로직이나 기능들에 대해 정의하고
비 기능 요구사항은 SW의 품질을 향상시키는 내용이 포함된다. 

 

예로, 1 더하기 1 이 2가 되어야 하는 것은 기능이고 1 더하기 1 이 1초 안에 계산되어야 하는 것은 비 기능이 된다.
또한 사용자가 1 을 입력할 때 숫자가 아닌 문자를 입력하는 것을 막는 것도 비 기능에 포함된다.

그럼 위 예를 바탕으로 화면설계서를 작성할 때 제약사항이나 조건들을 추가하여 비 기능에 대한 내용을 언급할 수 있다.

 

기능

• 숫자 2개를 입력받아 연산을 할 수 있어야 한다.

 

비 기능 항목 (제약, 조건 들)

• 입력 필드에 숫자가 아닌 다른 문자의 입력을 막아야 한다. (또는 문제 제거)
• 입력을 완료하고 계산 버튼을 눌러야 계산을 진행한다. (또는 입력 시 자동 계산이 진행되어야 한다.)
• 숫자 입력은 키보드 및 가상 키패드를 통해서 입력할 수 있어야 한다.

머릿속에 염두하고 문서를 작성하면 좀 더 완성도 높은 문서를 작성할 수 있을 것이라 생각한다.

 

 

 

5. 스토리보드가 아닌 화면설계서

 

한국형 SW 기획자는 기획서 만드는 것을 스토리보드를 작성한다는 표현을 간혹 사용한다.

기획서는 상당히 포괄적인 의미로 직무나 도메인별로 다르게 통용되고 있다.
말 그대로 무엇인가를 진행하기 위해 만드는 문서이다. 

그럼 SW 개발 회사의 기획자가 만드는 문서는 무엇인가?
스토리보드는 잘못된 표현이지만 한국에서는 익숙하여 통용되기는 한다.
SW 개발을 위해 만들어지는 작업 지시서는 화면설계서라는 용어가 적합하다.
화면에 대한 정의와 화면에서 이루어지는 기능에 대한 정의가 된 문서가 바로 화면설계서(=Wireframe)이다.

디자이너는 기획자가 작성한 화면설계서 기반으로 UI 설계(or UX 설계) 및 비주얼 디자인을 진행하며,
개발자는 화면설계서에 정의된 기능을 구현하게 된다.

화면설계서 작성을 위한 체크리스트

 

 

SW 개발 프로젝트에 참여하여 협업을 하다 보면 사용하는 용어(단어)에 따라 각 파트 간 커뮤니케이션의 혼선을 발생시킬 수 있다.
프로젝트 또는 제품 도메인에 맞는 용어집을 만들고 서로 공유하여 잘못된 용어 또는 의미가 다른 용어가 사용되지 않도록 노력하자.

 

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

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

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

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