프로젝트 메모가 여기저기 흩어지는 이유 (그리고 해결법)

모든 프로젝트는 같은 방식으로 시작합니다. 누군가 미팅 메모를 위해 Google Doc을 엽니다. 다른 사람은 Notion에 몇 가지 생각을 남깁니다. 세 번째는 Slack에 디자인 근거를 게시합니다. 그리고 또 다른 누군가는 그냥 데스크탑의 무작위 .txt 파일에 타이핑합니다. 2주 후를 빠르게 감아보세요. 아무도 아무것도 찾을 수 없습니다. 어떤 데이터베이스를 사용할지에 대한 결정? Slack 스레드에 묻혀있습니다. 경쟁사 가격에 대한 조사? "제목 없는 문서 (3)"이라는 제목의 Google Doc 어딘가에 있습니다. 그 기능을 삭제한 이유? 사라졌습니다. 아마도 누군가의 머릿속에 있는데 그도 기억하지 못합니다. 이것은 규율 문제가 아닙니다. 도구 문제입니다. 메모가 프로젝트와 다른 앱에 있을 때 연결이 끊긴 맥락이 됩니다. 지원해야 했던 작업에서 분리되어 의미를 잃습니다.

대부분의 사람들은 문서화가 공식적인 스펙이나 사용자 매뉴얼 작성을 의미한다고 생각합니다. 그것도 일부이지만 일상적으로 실제로 중요한 것은 훨씬 더 비공식적입니다. 결정 로그는 아마 가장 과소 평가된 프로젝트 문서 유형입니다. 왜 Vue 대신 React를 선택했는가? 좌석당이 아닌 정액 가격 모델을 택한 이유는? 팀이 출시 날짜를 연기하기로 결정한 이유는? 이 결정들은 그 순간에는 당연하게 느껴지지만 6개월 후에는 아무도 근거를 기억하지 못합니다. 그 맥락 없이 사람들은 같은 결정을 재토론하거나 이해하지 못하는 선택을 맹목적으로 수용합니다. 조사 메모도 중요한 것 중 하나입니다. 라이브러리를 평가하거나, 호스팅 제공자를 비교하거나, 경쟁사를 검토할 때 그 조사는 초기 결정 이상의 가치를 가집니다. 미팅 메모, 브레인스토밍 세션, 이해관계자 피드백, 버그 조사 메모, 온보딩 지시사항, 내부 프로세스. 이 모든 것이 프로젝트를 더 원활하게 만드는 문서입니다. 패턴은 명확합니다. 팀의 다른 누군가(또는 미래의 나)에게 유용할 정보는 적어두어야 합니다. 그리고 찾을 수 있어야 합니다.

프로젝트 문서화에 Notion, Google Docs, Apple Notes를 사용할 때의 근본적인 문제는 맥락 분리입니다. 메모는 한 도구에 있습니다. 태스크는 다른 것에 있습니다. 타임라인은 세 번째에 있습니다. 아무것도 연결되지 않습니다. 팀원이 "API 디자인을 왜 바꿨죠?"라고 물으면 API 작업을 추적하는 태스크에서 한 클릭으로 답을 찾을 수 있어야 합니다. 대신 다른 앱을 뒤지고, 반쯤 기억하는 키워드를 검색하고, 메모가 다른 사람의 개인 워크스페이스에 묻히지 않았기를 바라야 합니다. 접근 문제도 있습니다. Notion 워크스페이스, Google Drive 폴더, 공유 문서는 모두 다른 권한 모델을 가집니다. 새 팀원들은 기본적인 프로젝트 맥락을 찾기 전에 여섯 군데의 접근을 요청해야 합니다. 모든 것에 접근할 수 있을 때쯤에는 이미 한 주를 추측하며 보냈습니다. 그다음은 포기 곡선이 있습니다. 사람들은 열정적으로 새로운 메모 시스템을 시작합니다. 2주 후 습관이 사라집니다. 메모 업데이트가 멈춥니다. 프로젝트 아키텍처가 있는 문서는 아무도 유지 관리하지 않는 1주차의 화석이 됩니다. 이것은 별도의 앱에서 메모를 유지 관리하는 것이 추가 작업처럼 느껴지기 때문에 발생합니다. 이미 보고 있지 않은 곳에서 기억해야 하는 추가적인 것입니다.

해결책은 간단합니다. 이미 작업이 이루어지는 곳에 메모를 두는 것입니다. IndieDevBoard에는 모든 프로젝트에 내장된 노트북 기능이 있습니다. 프로젝트를 열고 노트북을 클릭하고 작성을 시작합니다. 서식 있는 텍스트, 형식 지정, 필요한 모든 것. 핵심은 이 노트북들이 프로젝트 자체의 일부라는 것입니다. 칸반 보드, 타임라인, 마일스톤, 파일 옆에 나란히 있습니다. 같은 워크스페이스에 있기 때문에 메모를 태스크에 연결하는 것이 자연스럽습니다. 버그를 조사하고 있나요? 노트북에 발견한 것을 적고 태스크에 연결하세요. 미팅에서 디자인 결정을 내렸나요? 문서화하고 관련 마일스톤에 연결하세요. 이런 종류의 연결이 흩어진 메모를 실제 문서화로 바꿉니다. 접근에 대해 걱정할 필요도 없습니다. 누군가 프로젝트에 접근할 수 있으면 노트북에도 접근할 수 있습니다. 별도의 공유 설정 없습니다. "편집 권한을 줄 수 있어요?" 메시지 없습니다. 그냥 작동합니다.

대부분의 문서화 노력이 죽는 이유는 마찰입니다. 메모를 작성하는 것이 다른 앱을 열고, 올바른 폴더를 찾고, 새 문서를 만들고, 적절하게 형식을 지정하는 것을 의미한다면 대부분의 사람들이 건너뜁니다. 매번. 트릭은 이미 하고 있는 작업의 부작용으로 문서화를 만드는 것입니다. 스프린트 계획 세션을 마치면 방금 태스크를 만든 같은 도구에 메모를 작성하세요. 결정을 내리면 그것이 영향을 미치는 작업 바로 옆에 기록하세요. 무언가를 조사하면 팀이 실제로 볼 곳에 발견한 것을 남기세요. 메모를 비공식적으로 유지하는 것도 도움이 됩니다. 모든 것이 세련된 문서가 될 필요는 없습니다. 한 접근법을 다른 것보다 선택한 이유를 설명하는 빠른 단락은 아무도 쓰지 않는 완벽하게 형식화된 스펙보다 무한히 더 가치 있습니다. 문서화로 인정되는 것의 기준을 낮추면 실제로 문서화를 얻을 것입니다. 메모에 타임스탬프를 찍으세요. 명확하게 이름을 지으세요. 관련 태스크나 마일스톤에 연결하세요. 그것이 전체 시스템입니다. 각각 10초가 걸리는 세 가지 습관이 나중에 "잠깐, 왜 이걸 했지?" 대화의 몇 시간을 절약합니다.

좋은 문서화는 길지 않습니다. 찾을 수 있고, 최신 상태이며, 그것이 설명하는 작업과 연결되어 있습니다. 강력한 프로젝트 노트북에는 팀이 의미 있는 선택을 할 때마다 업데이트되는 결정 로그가 있을 수 있습니다. 각 항목은 몇 문장입니다. 무엇이 결정됐는지, 왜, 누가 관여했는지, 어떤 대안이 고려됐는지. 그것으로 충분합니다. 작성하는 데 2분 걸리고 3개월 후 누군가 "왜 Postgres를 사용하는 거죠?"라고 물을 때 한 시간짜리 미팅을 절약합니다. 또 다른 유용한 패턴은 각 주요 기능이나 워크스트림을 위한 실행 메모 페이지입니다. 누군가 문제를 조사하거나, 옵션을 평가하거나, 피드백을 받을 때마다 몇 줄을 추가합니다. 시간이 지남에 따라 기능이 어떻게 발전했는지의 전체 역사를 포착하는 살아있는 문서가 됩니다. 새 팀원들은 세 번의 온보딩 미팅을 잡지 않고도 읽어볼 수 있습니다. 핵심은 분량이 아닙니다. 연속성입니다. 한 달 동안 업데이트된 10개의 짧은 항목이 있는 노트북은 한 번 작성되고 다시는 건드리지 않은 20페이지 스펙보다 더 가치 있습니다.

모든 프로젝트는 지식을 생성합니다. 결정, 조사, 대화, 얻은 교훈들. 그 지식의 대부분은 잘못된 장소에 포착되거나 전혀 포착되지 않기 때문에 증발합니다. 복잡한 지식 관리 시스템이 필요하지 않습니다. 작업이 이루어지는 곳에 사는 노트북이 필요합니다. 팀 전체가 도구를 전환하거나 권한을 요청하지 않고 볼 수 있고, 검색하고, 업데이트할 수 있는 것. 프로젝트당 하나의 노트북으로 시작하세요. 중요한 것을 적어두세요. 그것이 관련된 작업에 연결하세요. 그것이 전체 시스템입니다. 생각보다 적은 노력이 들고, 누군가 질문을 하고 기억에서 다시 설명하는 대신 메모를 가리킬 수 있는 첫 번째 순간에 왜 더 일찍 시작하지 않았는지 궁금해할 것입니다.