비동기 우선 플레이북 본문

book

비동기 우선 플레이북

halatha 2024. 6. 16. 20:14

  • ★★★★☆ June 13, 2024 → June 15, 2024 https://www.thoughtworks.com/insights/books/async-first-playbook
  • Playbook: 스포츠 팀(특히 미식축구팀)이 평소 훈련하고 경기에서 펼치는 플레이들을 모은 ‘작전집’. 소프트웨어 개발팀들도 스포츠의 비유를 채용해서, 자신들이 주로 실행하는 어느 정도 정형화된 활동, 관행(practice)을 ‘플레이’라고 부르곤 한다.
  • p6
    • 비동기 협업은 사람들이 꼭 필요할 때만 만나고, 생산적인 대화를 나누고, 실질적인 업무를 수행할 시간을 사람들에게 부여할 것을 약속한다
    • 동료들이 “나는 재택근무가 좋아요”라고 말한다면, 이는 단지 일하는 장소에 대한 것뿐만이 아니라 일하는 시간에 대한 것이기도 함을 유념하자. 이것이 바로 평범한 곳에 숨어있는 비밀
  • 동기성 스펙트럼
    • 위키와 지식베이스 - 협업 문서 - 이메일 - 녹화된 동영상 - 채팅 - 화상회의/대면 회의
    • ← 단기적으로는 힘들지만 장기적으로는 이점이 있다
    • 단기적으로는 쉽지만, 장기적인 이점은 별로 없다 →
    • https://pragprog.com/titles/jsrw/effective-remote-work/
  • p35
    • 팟캐스트를 10배속으로 들으면 1배속보다 훨씬 효율적이지만, 정보를 10배속으로 소화할 수 없다면 실질적인 효과는 없는 셈. 동기적 의견 교환이 유익할 것은 분명하지만, 일반적으로는 먼저 비동기적 의견 교환을 진행한 후에 진행하는 것이 가장 좋다.
    • 글쓰기가 어렵다는 데에는 나도 동의하지만, 말하기가 더 쉬운 것도 아니라는 점에 주의
  • p42
    • 오픈소스 프로젝트들은 40년 동안 화상통화나 대면 회의 없이 유지… 가능한 이유는 오픈소스 개발자들이 프로세스를 예외적이라고 할 만큼 잘 따르기 때문… 대부분의 회사가 말소리가 들릴 정도로 가까운 거리에서도 이 정도로 효과적인 협업을 해내지 못한다
    • 글쓰기는 비동기 우선을 위한 근본적인 관행
  • p53
    • 작업현황판은 팀이 진행중인 모든 업무를 파악하는 데 사용할 ‘진실 공급원(source of truth)’, 즉 신뢰할 수 있는 정보의 출처가 되어야 한다
    • 이메일과 인스턴트 메시징은… 2차 도구
  • IM의 ‘인스턴튼’ 특성, 즉 즉시성을 다스리는 데 익숙해지도록 돕다 보면, 일인당 업무 중단 횟수가 점점 줄어들 것
  • p115 아이젠하워 행렬
    • 긴급함과 동시에 중요한 사안… 전체 작업 중 극히 일부
    • 기한이 명확하며, 기한을 지키지 않으면 심각한 후과(consequence)가 따른다.
    • 여러분 또는 여러분의 팀만 해결할 수 있다.
  • 견고한(solid) 프로세스가 잦은 회의를 없애는 데 도움… 실행 수준에서 자율성을 촉진… 엄격한 규일이 필요
  • p138
    • 회고를 회의가 아니라 하나의 프로세스로 생각해야… 이러한 사고방식은 회고뿐만 아니라 모든 의사소통으로 확장
    • 의사소통은 이벤트가 아니라 프로세스
    • https://www.funretrospectives.com/
  • 사용자 스토리를 잘 작성하면 착수 회의를 열 필요가 없어진다… 회의의 필요성을 줄이려면, 개발자에게 필요한 모든 세부사항을 스토리에 포함해야 한다.
  • p150
    • 협업의 저주(collaboration curse)
    • 우리는 이미 (비교적 자유롭게) 원격근무를 병행하고 있고 이걸 되돌리고 싶은 사람은 (저 포함) 아무도 없을 것. 그러기 위해서는 우리의 (주로 미팅으로 구성하는) 프로세스가 효과적이고 효율적으로 진행되는 걸 드러내야 함
  • 맥락을 존중하지 않는 기법은 그 어떤 것이든 피해야 한다.
  • pp170~171
    • 팀이 크고 결정 사항이 많을수록 그 모든 것을 머리에 담거나 대화 속에서 추적하기가 어려워진다. 따라서 분산 팀은 모든 비즈니스 의사결정을 비즈니스 의사결정 기록(BDR, business decision records)의 형식으로 문서화하는 것을 규율로 삼아야 한다
    • adr의 business version
    • 아키텍처가 시간에 따라 변할 것이며, 언젠가는 아키텍처가 왜 그런 식으로 만들어져 있는지 조사할 필요가 있을 수도 있음을 뜻한다… 아키텍처 의사결정 기록(ADR, architectural decision records)이 도움이 된다.
    • 문서화하기에 너무 작은 의사 결정은 없다
  • pp180~181
    • 간결하고 명확하게 작성
    • 원하는 것은 신중한 피드백
    • 속도가 곧 생산성은 아니다
      • 속도 ≠ 생산성
    • 기능 분해 문서(feature breakdown document)
  • p183
    • 설계서가 짧다는 것은 그만큼 설계 문제가 작아졌다는 신호… 모든 팀이 추구해야 할 미덕… 문제가 클수록 해법이 복잡… 시간이 길어진다.
    • 효과적인 설계서는 상세해야
    • 확인 필요: git PR에 issue number 들어갔는가?
  • p198
  • pp204~205
    • 애초에 원격 근무에 깊은 편견을 가진 현업 전문가들을 설득하기는 어려우므로, 그 부분은 넘어가기로 하자
    • ‘걸어 다니며 경청하면서 관리하기(MBWAL, manage by walking around and listening)’가 리더십의 ‘참된 방법(the way)’이라고 배운 사람들이 많다. 그런 관리 방법을 비동기적으로 할 수는 없는 일
  • pp219~220
    • 피드백은 적시에, 원자적인 방식으로 공유하는 것이 최선
  • pp226~227
    • 비동기 업무 방식의 초점은 제작자를 위한 최적화
    • 리더들은 제작자들로 팀을 채우기 전에 관리 계층부터 생각할 때가 많다
    • 비동기 우선 조직은 “동기적 조직에 비해 관리 계층이 50% 작다”
    • 변화가 직선으로 진행되는 경우는 드물다
  • 변화 과정 모형(Process of Change Model)
  • p236
    • HP가 아는 것을 HP가 알고 있었다면 생산성이 세 배는 높아졌을 것
    • 암묵적인 지식 혹은 ‘암묵지(tacit knowledge)’를 양성하고 관리하려면 어떻게 해야 할까?
  • 관리자는 입력보다는 출력에 초점을 두어야 하며,… 직급에 따른 권위를 버려야 한다… 효과적인 방법 하나는 프로세스와 문서화를 명확히 하는 것… 질문에 답할 때 같은 설명을 반복하는 대신 적절한 자료로의 링크를 제시할 수 있어야… 관리자가 팀원의 업무상 문제점을 대놓고 지적할 수 있으려면 팀원을 개인적으로 챙기고 업무를 파악해야 한다. 관리자가 적응하지 못하면 비동기 우선으로의 전환이 유지되지 않는다.
  • 의식적 능력학습단계 모형(Conscious Competence Learning Stages Model)
  • p277
공유하기 링크
'book' Related Articles more
Comments