하기 내용은 "개발자의 글쓰기" 라는 책에 있는 내용이다. 흥미롭고 유익한 내용이다. 이는 매사에 사리분별을 명확하게 하고 의견을 정확하게 전달할 때 아주 중요한 내용이다.
묘사에는 주관적 묘사와 객관적 묘사가 있다.
예를 들어 길을 잃은 사람에게 길을 알려준다고 할 때 주관적 묘사와 객관적 묘사는 다음과 같이 차이가 난다.
- 주관적 묘사 : "저기 앞에 큰 사거리에서 오른쪽으로 돌아서 5분쯤 가면 기차역이 보여요"
- 객관적 묘사 : "두 번째 사거리에서 10시 방향으로 돌아서 300미터 가면 우측에 기차역이 있어요"
다음은 기획자의 주관적 묘사' 에 대한 예시 글 (기획자 욕하는 거 아님)
'안녕하세요. 기획팀입니다. 고객과 좀 더 소통하기 위해 홈페이지 라이브 채팅 기능을 추가하려고 합니다. 경쟁사 홈페이지의 해당 기능과 비슷하게 만들면 됩니다.(첨부 이미지 참고). 홈페이지 우측 하단에 위치하되 원래 텍스트를 가리지 않아야 합니다. 크기는 우리가 쓰는 메신저만하면 좋겠는데 필요시 크기 조절이 가능했으면 좋겠습니다. 그 외 특별한 요청은 없습니다. 다음 주까지 완료될까요? '
'푸하하하하.... 그냥 웃김' <- 책 내용 아님
개발자는 어이가 없지만 어쩔 수가 없다. 기획자에게 객관적 묘사를 기대할 수 없으므로 스스로 주관적 묘사를 객관적 묘사로 바꿔야 한다. 다음과 같이 객관적 묘사로 요구사항을 정리하고 질의서를 만들어야 한다.
[요구사항]
- 기존 홈페이지에 라이브 채팅 기능 추가
- 채팅창은 홈페이지 우측 하단에 위치
- 채팅창이 원래 텍스트를 가리지 않게 하기
- 메신저 크기지만 크기 조절 가능
- 다음 주까지 완료
[질의 내용]
- 라이브 채팅 기능 적용 대상이 웹만인가, 모바일도 포함하는가?
- 채팅창은 홈페이지 우측 하단에 고정인가, 스크롤과 연동해야 하는가?
- 채팅창이 원래 텍스트를 완벽히 가리지 말아야 하는가? 그렇다면 해당 페이 내에 영역을 미리 확보해야 하는가?
- 메신저 크기가 정확히 몇 픽셀이어야 하는가? 화면 비율에 따라 크기가 달라져야 하는가, 고정적이어야 하는가?
- 크기 조절은 일정 배율로 하는가, 마우스로 늘이는가?
- 크기 조절을 하다가 원래 텍스트를 가려도 되는가? 환계가 있어야 하는가?
- 동시 접속자를 몇 명까지로 해야 하는가? 사내에 응답자가 없으면 어떻게 하는가?
- 다음 주까지 완료라는 것이 개발 완료를 말하는 것인가, 테스트 완료를 말하는 것인가? 아니면 실제 적용 완료를 말하는 것인가?
'ㅋㅋㅋㅋ 어쩜 이리... 정확할까? 근데 사실 저것보다 몇 배는 더 많은 부분을 고려해야할 것 같은데 ... 질문이 별로 없군.' <- 책 내용 아님
저런 상황에서 요구사항 정의서를 작성하는데 주관적 묘사를 완전히 배제하고 오직 객관적 묘사만 포함해야 한다. 다음은 예시다.
요구명 : 채팅장 크기
요구ID : C001-1
요구내용: 채팅창 크기는 화면에 디스플레이된 페이지 크기에서 가로 20%, 세로 25%로 정한다. 채팅창의 최소 크기는 가로 150px, 세로 200px로 한다. 디스플레이된 페이지 크기가 가로765px 이하, 또는 세로 600px이하일 경우에는 채팅창을 가로 50px, 세로 50px의 아이콘 이미지로 자동으로 대체되게 한다. 아이콘 이미지를 클릭하면 새 창에서 채팅창을 단독으로 디스플레이 한다.
개발자가 요구사항 정의서를 가지고 개발을 끝낸 다음에는 간단한 사용 설명서를 만들어야 한다. 채팅창 우측 상단의 "?" 를 클릭하면 자주 하는 질문과 답을 보여준다고 하자. 이때 개발자는 채팅장 크기를 다음과 같이 주관적으로 묘사한다.
질문: 채팅창 크기는 자동으로 커졌다 작아졌다 하나요?
답변 : 네, 그렇습니다. 채팅창 크기는 홈페이지 화면 크기에 따라 가장 보기 편하게 바뀝니다. 화면이 너무 작으면 채팅창이 자동으로 아이콘으로 변합니다. 이때 아이콘을 클릭하면 새 창에서 보기 편한 크기로 채팅할 수 있습니다.
이 처럼 개발자가 주관적 묘사를 객관적 묘사로 바꾸고, 그것을 다시 주관적 묘사로 바꿀 수 있으면 일하기가 한결 편하다.
기획자나 디자이너는 주관적 묘사에 익숙하고 객관적 묘사에는 서투르다. 개발자가 주관적 묘사와 객관적 묘사 둘 다 잘하면 기획자나 디자이너와 협의할 때 주도권을 가질 수 있다. 개발자가 주도권을 가지면 비교적 개발이 쉬워지고 나중에 변경할 것도 줄어든다.
마찬가지 기획자나 디자이너도 똑 같다.
'사는 이야기 > 좋은 글' 카테고리의 다른 글
생각의 독립 (0) | 2020.07.22 |
---|---|
기술 블로그의 4종류, 저, 술, 편, 집 (0) | 2020.07.16 |
의사결정을 객관적으로 하는 방법 (0) | 2020.07.09 |
나에게 하는 말 (0) | 2020.01.13 |
세밑한파, 세초 (0) | 2019.12.30 |