다음은 Software Friction에 대한 반응 중 일부입니다.

비슷한 주제를 다룬 블로그

Laurie Tratt가 쓴 What Factors Explain the Nature of Software? 역시 마찰이라는 주제를 다룹니다.

이메일과 댓글

저는 미 해병대 보병 장교로, 저희는 마찰에 대해 자주 이야기합니다. 클라우제비츠를 읽고 계시다면 관심 있으실 만한 책으로 미 해병대 교리 간행물 1호(MCDP 1) Warfighting(하단에 PDF 링크)이 있습니다. 분량이 짧아 금방 읽을 수 있습니다.

저희가 마찰을 다루는 방식은 님께서 정리하신 내용과 대체로 비슷합니다. 인력에게 경력 초기부터 마찰에 대해 교육하는데, 이는 경험을 쌓아가며 마찰을 해결할 방법을 스스로 찾도록 준비시키는 데 도움이 됩니다.

제가 보기엔 언급되지 않았지만 소프트웨어 팀에도 아주 잘 맞을 것 같아 저희가 자주 쓰는 전술 중 하나는 “hot washes”입니다. 기본적으로 훈련이든 실전이든 작전 직후 핵심 인원 모두가 모여 무엇이 잘됐고 무엇이 잘못됐는지, 그리고 더 나은 성과를 위해 표준운영절차(Standard Operating Procedures)를 업데이트해야 할지 검토하는 방식입니다. 이를 정기적으로 실시하면 — 더 적절한 표현이 떠오르지 않네요 — 일종의 “자존심 상함(ego sting)”도 완화됩니다. 동료들 앞에서 공개적으로 자신의 실수를 지적받는 것은 힘든 일이지만, 다른 모든 일과 마찬가지로 반복하면 쉬워집니다. 정기적인 hot washes는 팀원 간의 공유된 이해를 쌓는 데도 도움이 되며, 이는 의사소통을 원활하게 하고 마찰을 줄여줍니다.

“hot washes”가 포스트모템과 어떻게 다른지 물었더니 다음과 같은 답이 돌아왔습니다.

제 생각에 가장 큰 차이점은 — 어쩌면 애자일 쪽에서는 흔한 일인데 제가 모르는 걸 수도 있지만 — 보통 “scribe”가 정해진 형식(주로 Topic-Discussion-Recommendation, 즉 주제-논의-권고)으로 요점을 기록하고, 이 기록을 후대를 위해 보관해 부대 차원이나 더 흔하게는 군 전체 차원의 라이브러리에 저장한다는 점입니다. 이를 통해 과거에 저지른 실수를 참조할 수 있고, 심지어 지금 마주하려는 문제와 유사한 문제를 수년 전 다른 부대가 겪으며 남긴 실수까지 참조할 수 있습니다. 미 해병대 교훈센터(Marine Corps Center for Lessons Learned)에서 군 차원의 라이브러리를 관리합니다.

대규모 소프트웨어 기업과 비교했을 때 저희에게 조금 더 특수한 과제 중 하나는 인력 교체율이 높다는 점이라고 생각합니다. 보통 2년 정도 지나면 부대원이 교체됩니다. 그래서 지식을 인력의 머릿속에만 지속적으로 유지하기는 어렵고, 효과를 보려면 반드시 기록으로 남겨야 합니다.