Forwork

경험을 Framework로 바꾸는 방법

개인 경험을 이름 붙이고 설명하고 반복하고 다른 사람이 적용할 수 있는 구조화된 방법으로 바꾸는 법.

01

경험은 원재료이지 아직 방법은 아니다

“나는 보통 이렇게 한다”는 유용하지만 다른 사람은 무엇이 본질이고 무엇이 맥락에만 맞는지 알기 어렵습니다.

Framework는 개인 경험에서 반복 가능한 pattern 을 추출하면서 시작합니다.

02

여러 상황에서 반복되는 것을 찾기

project, decision, problem solving을 돌아보세요. 무엇을 반복하는가? 무엇을 먼저 하는가? 결정 전에 무엇을 확인하는가?

충분히 반복돼야 우연이 아니라 framework가 됩니다.

03

principle과 맥락 detail 분리하기

성공은 industry, team, budget, tools에 좌우될 수 있습니다. 좋은 framework는 transferable logic 을 남깁니다.

“항상 10문항 survey”보다 “assumption을 고정하기 전에 evidence를 모은다”가 더 범용적입니다.

04

Framework: Pattern → Principle → Steps → Boundary → Name

Pattern 무엇이 반복되는가. Principle 왜 작동하는가. Steps 어떻게 따라 하는가. Boundary 언제 쓰지 말아야 하는가. Name 무엇이라 부를 것인가.

명확성과 유연성을 함께 가져야 합니다.

05

개인 습관에서 framework로

경험: “proposal을 쓸 때 먼저 상대가 어떤 decision을 해야 하는지 묻는다.”

Framework: Decision-First Proposal . decision, 필요한 belief, evidence를 정한 뒤 의사결정 logic에 맞춰 proposal을 구성합니다.

06

framework는 why를 설명해야 한다

checklist는 what을 알려줍니다. 좋은 framework는 왜 그 순서와 principle이 필요한지 도 설명합니다.

logic을 이해하면 상황에 맞게 조정할 수 있습니다.

07

이름은 framework를 오래 남게 한다

이름은 기억, 참조, 공유를 쉽게 만듭니다. 하지만 이름을 먼저 만들고 경험을 억지로 끼워 맞추면 안 됩니다.

Naming은 clarity의 마지막 단계입니다.

08

boundary가 신뢰도를 높인다

모든 상황에 맞는 framework는 없습니다. 언제 유용한지, 언제 약한지, 무엇을 조정해야 하는지 말하세요.

09

Forwork Tips에 적용하기

짧은 story에서 pattern을 뽑고 name, purpose, steps, boundary, example을 보여주세요. Project와 Profile에 연결할 수도 있습니다.

10

결론

Framework는 경험을 personal memory 에서 shared method 로 바꿉니다.

다른 사람이 설명, 적용, 검증, 개선할 수 있을 때 경험은 body of thinking이 됩니다.