글 쓰는 것을 시작할 시간.
(alexnixon.github.io)아마존은 사내 회의에서 파워포인트를 금지하고, 대신 회의 주체자들은 잘 정리된 여러 장의 설명을 작성한 후 이를 모든 회의 참가자들에게 배포하고. 모두 다 읽을 때까지 회의를 시작하지 않도록 하였습니다.
이 글은 여러 회의를 하는 방법들 중에 왜 글쓰기여야하고, 왜 파워포인트와 기술자들이 빙 둘러서 앉아 이야기 하는 방식이 왜 안 되는 지 설명합니다. 아래는 간단한 요약입니다.
파워 포인트는 해당 아이디어에 대한 꾸미기를 허용하고, 상대적으로 중요한 것들을 밋밋하게 하며. 아이디어의 연속성을 무시합니다.
기술자들이 피자를 중간에 놓고 이야기 하는 방식은 많은 지식을 얻는 데에는 유용하지만, 이야기는 중구난방으로 갑니다. 그래서 이 교착 상태를 깨기 위해서는 그 중 한 명이 비즈니스 요구에서 구현의 실용성까지, 포괄적이고 유동적이고 논리적인 방식으로 어떻게 해야하는 지에 대한 설명이 필요합니다.
그것을 다른 사람들에게 전해주기 위해서 작가는 해당 사항을 고려하여 적었을 것입니다.
- 서문
- 기술 변경 결정의 원인은? 왜 이게 가치있고, 어떤 이점이 있는가?
- 이 특정 기술을 왜 솔루션으로 조사했는가? 조사할 만한 다른 대안은?
- 해치워야 할 게 얼마나 많은가? 빌딩의 기초를 세워야 하는가, 자전거 정류소를 그려야 하는가? 만약 문제가 해결이 안 되면 변경은 쉬운가?
- 본문
- 제안된 기술에 꼭 지켜야 하는 내용이나 대원칙이 있는가? 그게 우리의 문제와 철학에 어떤 연관이 있는지?
- 우리가 이걸 굴린다면, 어디가 최종목표인가? 구현이 끝나면 세상은 어떻게 변하는가?
- 방해를 최소화하면서 현재 위치에서 목표 지점까지 어떻게 이동할 것인가? 전환 기간은 어느정도인가? 대락 얼마나 걸리는가?
- 기존의 사내 전문 지식이 있는가?
- 위험은? 이를 줄이기 위한 조치가 있는가? 미지의 미지수는?
- 이 솔루션은 대체 솔루션보다 어떤 면에서 유리한가?
- 대안이 이것보다 어떤 면에서 더 좋은가?
- 결문
- 근본적인 비지니스 요구와 권장 사항을 요약하고, 이게 왜 최선의 선택인지 설명.
TDD와 비슷하지만, TDD는 TDD를 위한 것으로 끝나는 데에 비하여 이런 설명문 쓰기는 재미있는 사이드 이펙트가 발생합니다. 저자의 마음 속에 남아 있는 생각입니다.
이 생각을 자연어로 번역한 후 다시 저자와 구두로 논의한다면, 아무런 문제가 없습니다. 그리고 글을 잘 작성하기 위해 이루어져야하는 여러 수준의 분석에서 문제를 고려한 후엔, 모든 관중의 수준에 맞게 설명을 조정할 수 있습니다.
마지막으로. 특수한 툴과 달리, 설명 ( 내러티브 ) 는 일반적입니다. 가장 좁은 기술적 문제부터 회사 전체의 사명과 목적에 관한 근본적 문제까지. 명확한 사고에 저항하는 문제는 없습니다.
요약 감사합니다!
저게 2004년 메일엔 4 페이지 였는데, 2017년 주주소식지에서는 6페이지 네러티브 라고 해서 음 10년의 세월이 2장을 늘렸나 라고 생각했던 적이..
(아마존 직원의 말로는 저 네러티브 메모가 정말로 더 쓰기 어렵다고 하더군요)
10년의 세월 동안 세상이 꽤 복잡해져서 (... ) 2장 정도면 적당할 듯 하네요 ㅋㅋ
저도 매일 정리용으로 글을 쓰고 있는데, 저만 보는 글임에도 생각을 정리하고 무엇보다 솔직해지는 게 ( 지금 뭐가 부족하고, 지금 뭘 해야했는데 못했고.. 어떤 대안이 있었는데 무시했고.. ) 정말 어렵더라고요.