https://alexnixon.github.io/2019/12/10/writing.html

https://news.hada.io/topic?id=2504 에서 알게 된 글. 아카이빙을 위해 요약 내용을 발췌했다.

파워 포인트는 해당 아이디어에 대한 꾸미기를 허용하고, 상대적으로 중요한 것들을 밋밋하게 하며. 아이디어의 연속성을 무시합니다.

기술자들이 피자를 중간에 놓고 이야기 하는 방식은 많은 지식을 얻는 데에는 유용하지만, 이야기는 중구난방으로 갑니다. 그래서 이 교착 상태를 깨기 위해서는 그 중 한 명이 비즈니스 요구에서 구현의 실용성까지, 포괄적이고 유동적이고 논리적인 방식으로 어떻게 해야하는 지에 대한 설명이 필요합니다.

그것을 다른 사람들에게 전해주기 위해서 작가는 해당 사항을 고려하여 적었을 것입니다.

• 서문
• 기술 변경 결정의 원인은? 왜 이게 가치있고, 어떤 이점이 있는가?
• 이 특정 기술을 왜 솔루션으로 조사했는가? 조사할 만한 다른 대안은?
• 해치워야 할 게 얼마나 많은가? 빌딩의 기초를 세워야 하는가, 자전거 정류소를 그려야 하는가? 만약 문제가 해결이 안 되면 변경은 쉬운가?
• 본문
• 제안된 기술에 꼭 치켜야 하는 내용이나 대원칙이 있는가? 그게 우리의 문제와 철학에 어떤 연관이 있는지?
• 우리가 이걸 굴린다면, 어디가 최종목표인가? 구현이 끝나면 세상은 어떻게 변하는가?
• 방해를 최소화하면서 현재 위치에서 목표 지점까지 어떻게 이동할 것인가? 전환 기간은 어느정도인가? 대락 얼마나 걸리는가?
• 기존의 사내 전문 지식이 있는가?
• 위험은? 이를 줄이기 위한 조치가 있는가? 미지의 미지수는?
• 이 솔루션은 대체 솔루션보다 어떤 면에서 유리한가?
• 대안이 이것보다 어떤 면에서 더 좋은가?
• 결문
• 근본적인 비지니스 요구와 권장 사항을 요약하고, 이게 왜 최선의 선택인지 설명.

TDD와 비슷하지만, TDD는 TDD를 위한 것으로 끝나는 데에 비하여 이런 설명문 쓰기는 재미있는 사이드 이펙트가 발생합니다. 저자의 마음 속에 남아 있는 생각입니다.

이 생각을 자연어로 번역한 후 다시 저자와 구두로 논의한다면, 아무런 문재가 없습니다. 그리고 글을 잘 작성하기 위해 이루어져야하는 여러 수준의 분석에서 문제를 고려한 후엔, 모든 관중의 수준에 맞게 설명을 조정할 수 있습니다.

마지막으로. 특수한 툴과 달리, 설명 ( 내러티브 ) 는 일반적입니다. 가장 좁은 기술적 문제부터 회사 전체의 사명과 목적에 관한 근본적 문제까지. 명확한 사고에 저항하는 문제는 없습니다.