5장. 설명, 묘사, 논중, 서사로 개발 가이드 쓰기
01. 서비스 개념을 범주, 용도, 특징으로 설명하자
- 범주, 용도, 특징
개발자가 독자에게 서비스 개념을 설명할 때는 범주, 용도, 특징 순으로 쓰는 것이 좋다.
개발자만 아는 것부터 다짜고짜 들이대는 것이 아니라, 독자가 이미 아는 것을 먼저 가져다가 천천히 설명해 나가는 방법이다.
ex) AWS가 Amazon S3 를 설명하는 첫 문단
(범주) Amazon Simple Storage Service(Amazon S3)는 인터넷 스토리지 서비스입니다.
(용도) Amazon S3를 사용하면 인터넷을 통해 언제 어디서든 원하는 양의 데이터를 저장하고 검색할 수 있습니다.
(특징) AWS Management Console의 간단하고 직관적인 웹 인터페이스를 통해 이러한 작업을 수행할 수 있습니다.
- 범주를 정확하고 적절하게 선택하자
AWS는 Amazon S3의 범주를 독자에게 익숙한 인터넷 스토리지 서비스로 정의한다.
이 경우 독자는 머릿속에 든 인터넷 스토리지 서비스의 범주에 Amazon S3를 추가하기만 하면 된다.
개발자는 독자가 이미 가진 범주를 사용함으로써 서비스의 개념을 간단하고 정확히 설명할 수 있다.
범주는 서비스를 소개하거나 설명하는 첫 문장인 만큼 정확하고 적절하게 정해야 한다.
가장 좋은 방법은 여러 경쟁사가 사용하는 보편적인 서비스 범주를 따라 하는 것이다.
강력한 마케팅을 전개할 수 있다면 완전히 새로운 개념의 범주를 만들어서 사용할 수 있다.
범주는 서비스의 정체성을 나타낼 뿐만 아니라 검색어와도 연관이 있다.
많은 문서의 첫 문단, 첫 문장에 범주가 사용되는 이유가 여기에 있다.
- 용도를 범주의 핵심 기능으로 기술하자
용도는 독자가 이 서비스를 이용하는 이유다.
서비스의 핵심 기능을 쓰면 용도를 기술할 수 있다.
서비스의 핵심 기능은 서비스가 속한 범주의 핵심 기능과 같다.
Amazon S3가 속한 인터넷 스토리지 서비스 범주의 핵심 기능은 인터넷을 통해 언제 어디서든 원하는 양의 데이터를 저장하고 검색하는 것이다.
이처럼 범주의 핵심 기능을 용도로 설명함으로써 독자의 머릿속에 서비스의 정체성을 명확히 심을 수 있다.
- 특징을 장점과 강점에서 뽑아 쓰자
범주와 용도에는 보편적인 내용을 적는다. 하지만 특징은 차별화하는 내용을 적어야 한다.
개발자에게 차별화는 서비스의 장점과 강점이다.
장점은 자기 기준에서 잘하는 것이고, 강점은 경쟁 서비스와 비교해서 나은 것이다.
서비스 개념에서 특징을 쓸 때는 장점이자 강점인 것을 쓰는 것이 가장 좋다.
장점이자 강점인 것이 없다면 장점과 강점을 합쳐서 한 문장으로 쓰는 것도 좋은 방법이다.
ex)
[ 장점이자 강점인 것을 하나를 쓴 예 ] ABC 서비스는 최고의 안정성을 제공합니다.
[ 장점과 강점을 한 문장에 같이 쓴 예 ] ABC 서비스는 간단하고 직관적인 웹 인터페이스와 안정적인 서비스를 제공합니다.
02. 정확히 이해하도록 그림과 글로 묘사하자
- 글에 묘사를 더하면 이해가 빠르다.
묘사는 어떤 대상이나 사물, 현상을 언어로 서술하거나 그림을 그려서 표현 하는 것이다.
글 아래에 그림을 그려 넣으면 독자가 직접 그림을 그리지 않아도 되고 더 빨리 이해할 것이다.
- 글과 그림의 내용을 일치시키자.
글과 그림이 같이 있으면 글과 그림이 같은 용어를 사용하는지 꼭 확인해야 한다.
같은 것을 다르게 표현하는 순간 독자는 헷갈리기 시작하고 그 결과는 에러로 나타난다.
- 객관적 묘사와 주관석 묘사 둘 다 하자.
기획자가 '주관적 묘사'로 기획서를 작성했다.
-> 개발자는 '객관적 묘사'로 요구사항을 정리하고 질의서를 만든다.
-> 개발자는 질의서를 가지고 기획자와 여러 번 논의한 끝에 정확한 요구사항정의서를 만든다. (only 객관적 묘사)
-> 개발자는 요구사항 정의서를 가지고 개발을 끝낸 다음에는 간단한 사용 설명서를 만든다. (주관적으로 묘사)
이처럼 개발자가 주관적 묘사를 객관적 묘사로 바꾸고, 그것을 다시 주관적 묘사로 바꿀 수 있으면 일하기가 한결 편하다.
경험으로 볼 때 기획자나 디자이너는 주관적 묘사에 익숙하고 객관적 묘사에 서투르다.
개발자가 주관적/객관적 묘사 둘 다 잘하면 기획자나 디자이너와 협의할 때 주도권을 가질 수 있다.
개발자가 주도권을 가지면 비교적 개발이 쉬워지고 나중에 변경할 것도 줄어든다.
03. 논증으로 유용한 정보를 제공하자
- 의견을 쓰려면 근거를 대자
논증은 객관적이고 논리적인 방식으로 어떤 사실을 증명해서 상대를 설득하는 일이다.
개발자가 의견만 말하고 근거를 말하지 않으면 독자가 청개구리가 되어 직접 테스트해 볼 수밖에 없다.
- 거칠게도 공손하게도 쓰지말자
개발문서에서 공손한 표현은 좋지 않다. 공손하게 말하는 순간 독자가 오해할 소지가 있다.
-- ~ 해야 합니다만 반드시 해야 하는 것은 아닙니다.
-- ~ 하면 좋습니다. 다만 ~한 경우에는 안 해도 무방합니다.
이러한 표현은 다음과 같이 바꾸자
-- ~하십시오.
-- ~하지 마십시오.
세상에 어떤 일이든 100% 확신할 수는 없다. 하지만 개발문서는 독자에게 여지를 줘서는 안된다.
- 주장과 이유의 거리를 좁혀서 쓰자
주장을 했으면 이유를 바로 이어서 말해야 한다. 앞에서 이유를 말했다고 해서 지금 주장만 하고 이유를 말하지 않으면 안 된다.
특히 개발문서는 잡지와 같아서 처음부터 순서대로 읽지 않는다. 그때그때 필요한 부분만 찾아보기 때문에 주장을 말했으면 중복되더라도
이유를 함께 말하거나 이유를 찾을 수 있는 곳을 알려줘야 한다.
이유를 설명하려면 너무 길어져서 일일이 쓰기 어렵다면, 일단 짧게라도 설명하고 이유가 있는 곳을 알려주는 방법이 있다.
- 문제와 답의 거리를 좁혀서 쓰자
답을 먼저 알려주고 나머지는 간단히 정리하는 것이 좋다.
04. 서사를 활용해 목차를 만들기
- 개발과 서사
서사는 사실을 있는 그대로 순서대로 적는 것을 말한다.
개발에서도 서사를 많이 쓰는데, 어떤 일을 하라고 지시한다는 것이다.
- 독자의 수준 대신 기술의 범용성을 기준으로 쓰자
개발자는 독자가 누구고 어떤 실력을 가졌는지 모른다.
독자의 수준에 맞춰 쓰기가 매우 어렵다.
좋은 방법은 기술의 범용성을 기준으로 하는 것이다.
개발문서를 읽기 전에 기본적인 수준을 맞춰놓는 것이다.
'시작하기 전에'나 '개요' 항목에 최소 분량으로 기본적인 지식을 설명한다.
- 순서에서 단계를, 단계에서 목차를 만들자.
6장. 수주를 돕는 SI 제안서 쓰기
(으악...!)
01. 개발자가 알아야 할 제안서 작성 원칙
- 개발자와 제안PM의 차이
제안서에서 개발자는 주로 기술 부문을 쓴다.
-- 기술 부문의 전략은 한마디로 뭔가요?
-- 이번 제안에서 기술 쪽 핵심이 뭔가요?
-- 기술적인 면의 특징이나 장점을 한 장으로 정리해 주세요.
개발자가 제안서에서 쓰기 어려운 것은 이렇게 전략적 제안에 관한 것이다.
- 시스템 구성도의 본질은 그림이 아니다.
- 제안 요청서 분석
제안요청서를 제대로 분석하는 것은 곳곳에 있는 기술 부문을 어떻게 작성해야 하는지 힌트를 찾아내는 것이다.
개발자가 제안요청서에서 힌트를 잘 찾아내기만 하면 기술 부문을 더 전략적으로 쓸 수 있다.
- 논리적 완결성
항목을 논리적으로 완결하는 것이다.
어떤 항목이 다른 항목과 내용 면에서 연결되어 있어서 순서대로 읽지 않으면 이해할 수 없는 경우가 있기 때문이다.
02. 고객의 문제 인식과 제안사의 문제 해결 능력
- 문제 인식과 문제 해결 능력
고객이 문제를 얼마나 중대하게, 또는 사소하게 인식하는지에 따라 제안서의 내용이 완전히 달라진다.
제안사의 문제 해결 능력도 제안서에 영향을 끼친다.
-
고객의 문제 인식 중대함 & 제안사의 문제해결 능력 탁월함
-> 경쟁사와 비교하여 제안하라 -
고객의 문제 인식 중대함 & 제안사의 문제해결 능력 부족함
-> 일단 동감하고 다른 방안을 제시하라 -
고객의 문제인식 사소함 & 제안사의 문제해결 능력 탁월함
-> 고객이 문제를 중대하게 인식하게 만들어라 -
고객의 문제인식 사소함 & 제안사의 문제해결 능력 부족함
-> 경쟁사의 전략을 확인하여 대처하라
03. 고객의 요구사항은 변할 수밖에 없다.
- 개발은 고객 요구 실현
고객이 요구사항을 처음부터 명확히 하지 않고, 중간에 바꾸고, 막판에 추가하는 이유는 여러 가지가 있다.
그래서 그 이유를 잘 알고 대비해야 한다.
- 요구사항을 분석하지 말고 제시하라
고객은 자기가 원하는 제품이 정확히 뭔지 모른다.
생각난 대로 여기에 적었으니, 이 중에 무엇이 요구사항인지 알아서 판단하고 내게 정확한 요구사항을 제시해 주시오 라고 쓴 것이 제안요청서다.
따라서 개발자는 고객의 요구사항을 받아서 분석해서 개발하는 것이 아니라, 고객에게 요구사항을 제시해서 고객이 선택하게 만들어야 하고
그 선택에 따라 개발해야 한다.
(음.. 고객이 아닌 기획자에게 받는 요구사항은 개발자가 캐치하는 건 아니라고 생각이듬.)
- 변화하는 요구사항에 대비해라
시간이 지날수록 요구사항은 달라지기 마련이다.
그래서 기존 방식을 투 트랙으로 바꾸는 것이다.
첫 번째 트랙은 목표 시스템 전체에 대해 분석 - 설계 - 구현 - 테스트 - 검수 단계를 밟는 것이다.
두 번째 트랙은 기능별로 분석 - 설계 - 구현 - 테스트 - 검수 단계를 짧게 밟는 것이다.
즉, 개발하기 직전에 고객과 요구사항을 다시 한 번 구체적으로 점검하는 것이다.
04. 고객의 총 만족도를 높이자.
- 요구라고 다 같은 요구가 아니다
개발자의 자원을 고객의 총 만족도를 높이는 쪽으로 설계해야 한다는 뜻이다.
[카노 모델]
By MyName (Bernd in Japan) - 자작, 퍼블릭 도메인, https://commons.wikimedia.org/w/index.php?curid=2884961
