[카이젠저니] 01장 ~ 06장

당신은 어떤 일을 하는 분입니까?

아무것도 대답할 수 없었다. 한마디의 말도 나오지 않았다. 그리고 이해할 수 있었다.

난, 아무것도 하고 있지 않았다.

 

제 01장 회사를 떠나기 전에 꼭 해야 할 일

• 외부로부터 지식을 얻을 때 꼭 기억해야 할 중요한 점이 있습니다.
  외부로부터 얻은 지식을 우리가 속한 현장이나 업무에 그대로 적용하려고 하면 대부분 잘되지 않습니다.
  우리가 처해있는 '상황'에 맞춰 적용하는 것이 매우 중요합니다.
  • 다른 사람들이 만들어 낸 프랙티스의 배경에 어떠한 상황 또는 제약이 있었는지 이해하고
    우리가 처한 상황이나 제약하에서 어떤 프랙티스*를 적용할지를 반드시 다시 판단해야 합니다.
• 화려하게 설명돼 있는 각종 용어에 마음을 빼앗기지 않도록 주의하십시오.

* 프랙티스 : 어떤 일을 함에 있어 습관적으로 실행하는 것

 

제 02장 나부터 시작하다

• '무엇이든 할 수 있을 것 같다.', '할 수 있는 일이 많은 것 같다.'는 말은 바꿔 표현하면 '아직 무엇을 할 수 있는지 모른다.'는 것과 같다.
• 프로젝트 팀은 시작과 함께 구성되고 종료와 함께 해산된다. 그렇기 때문에 발생했던 문제와 해결책이 조직적으로 축적되지 않는다. 늘 개인에게 의지할 뿐이다.
• 혼자 시도해 볼 만한 네 가지 습관 (-> 상태 시각화)
  
  • Task Management
    • 업무 배경이나 목적을 이해한 후 시작
    • 잘되지 않는 요소들을 빠르게 식별
    • 작은 크기의 독립 태스크로의 분할
      • 처음에는 화이트보드나 포스트잇 같은 아날로그 방식을 사용해보는 걸 권장
  • Task Board
    • 수립한 계획 내용을 시각화 
    • 변화를 매일매일 반영하는 것이 매우 중요
  • 아침 회의
    • 태스크 보드에 변화를 반영할 타이밍 (매일 정해진 시간과 장소에서 같은 리듬으로)
      • 계획과 어듯난 정도 식별 및 재계획
    • 어제 무엇을 했는가? 그럼 오늘은 무엇을 할 것인가? 오늘 계획에 어려운 점은?
  • 회고
    • 결과를 바탕으로 계획 수립 및 일과에 활용
    • 일하는 방법을 개선할 기회 -> 4개 방법 중 최우선

 

제 03장 혼자 시작하는 회고

• KPT (Keep, Problem, Try)
  • Keep : 유지할 것. 좋았던 것. 계속할지 여부는 별도 판단
  • Problem : 문제점. 애매했거나 마음에 걸렸던 점까지. 감정까지 반영해 가능한 구체적이게.
    • 다 클리어 하지 않아도 됨. 나중에 재선정되는 문제가 있으면 우선순위가 올라갈 것.
  • Try : 다음에 시도해 보고 싶은 것. 긴급도나 중요도에 따른 순번 정하기.
    • 시도 결과가 효과적이었으면(=problem에 좋은 변화가 있었으면) Keep으로 이동
• 회고 빈도 : 스스로 찾을 것. 스크럼에서는 1개월 이하로 권장.
  • 처음엔 1주일. 익숙해지면 2주일이 적당.
• 재회고 : KPT를 반복하면 문제의 '경향'이 보임
  • 근본 원인에 손을 대는 방법도 생각할 것
  • '더 열심히 한다', '더 주의한다' 등의 의미없는 회고는 지양

 

 

알고 있는 것을 부인하지 않으면 아무것도 변하지 않는다.

 

제04장 혼자 시작하는 태스크 가시화

• 만들어 낸 결과는 상대가 말하는 '하고 싶었던 것'과 어긋나기 일쑤다. 나는 '이렇게 하는 편이 좋아'라며 내 생각을 우선시 하는 경향이 있다. (고객 만족 하락...)
• 태스크 관리 시 고려 사항
  
  • 태스크의 양은 얼마나 되는가?
  • 각 태스크의 목표는 무엇인가?
  • 각 태스크의 목표를 달성하는데 있어 주의해야 할 점은 무엇인가?
  • 현재 상황은 어떠한가?
• 태스크란, 일의 최소 단위
  • 큰 태스크는 목적에 따라 분할 (for 분할 정복. Divide and Conquer)
    • 분할 후 어디까지 구현할지는 조율
    • 적절한 크기 여부는 필요한 시간 기준으로 판단 (최대 하루)
  • 태스크 기록시엔 명사+동사 형태로 써야 알아보기 쉽다.
    • ex) OOO 처리 대신 OOO 처리를 프로그래밍 한다
• 태스크 정보
  • 누가 의뢰한 것인가?
    • 의뢰측에서 무엇을 기대하고 있는지? 
      • 의뢰 당사자 뿐만 아니라 의뢰의 의뢰자도 고려해야함
      • 완료 기준을 명확하게 정해 업무를 주고받을 것 (using 칸반)
  • 다음에는 누구에게 전달하는가?
    • 어떤 상황에서 전달받길 원하는지?
  • 기한은 언제까지 인가? 작업 시간이 얼마나 소요되는가?
    • 착수하는 순서가 있어야 함
    • 순서가 결정되면 의뢰자/상사/동료가 알 수 있게 공유할 것 (using 칸반)
  • 어떤 상태가 되면 이 태스크가 완료되는가?
    • ex) 문서 작성 후 저장소에 커밋, 문서 작성해 의뢰자 리뷰 후 의견 대응 마무리 등

 

 

제 05장 내일을 내 편으로 만들다

• 아침 회의 3가지 점검 사항 
  • 어제 한 일
  • 오늘 할 일
  • 곤란한 일 (회고의 problem)
• 오늘과 내일을 구분하고 그 사이의 태스크를 조정
  • 오늘 해야할 게 정해지면 무엇을 미뤄도 좋을지도 판단 가능

 

제 06장 경계를 넘나들다

• 내가 하는 태스크가 누락되는 것과 마찬가지로 다른 사람에게 부탁한 태스크의 행방을 알 수 없게 되는 것이다.
  • 문제점 1) 내가 다른 사람에게 무엇을 의뢰했는지 잊어버리는 것
  • 문제점 2) 그 태스크가 언제 돌아올지 모른다는 것
• 태스크 보드 기본 
  • 대기 중 (TODO)
    • 일정 기간 수행 가능한 것만 넣어두고 나머진 Icebox 또는 Parking Lot으로 보내기
  • 진행 중 (Doing)
    • 원칙적으로 하나의 태스크만 놓을 것
      • 멀티태스크 시 전환 비용 발생 -> 부하
      • 하나에 집중해 어떻게 빠르게 완료할 지에 노력하는게 좋음
    • 긴급한 업무는 따로 레인을 추가해 최우선으로 대응할 것
      • 단, 기존 업무가 전면 중단되지 않도록 주의. 혼자 너무 힘들면 다른 멤버가 도와주기
  • 완료 (Done)
    • 자신이 일정 기간 동안 얼마나 많은 태스크를 수행했는가? 어떤 태스크를 완료하지 못했는가? 회고

 

 

---

오늘의 감상

• 일전에 읽은 [실용주의 프로그래머]에서 고상하게 풀어둔 이야기를 사례로 접하니 좀 더 문제의식을 느끼기 좋은 것 같다.
• 고민의 범위를 스스로에게만 한정시키거나, 옆집 잔디만 푸르러 보이는 등 주인공의 생각 흐름이 마치 나를 사찰한 기분이었다.
  난 어떤 일을 하는 사람이며 무엇을 할 수 있는 사람인가?
  
• 나또한 회고를 한다고는 생각했다. 나름 개인 스케줄러도 관리하며 업무를 기능 단위로 진행하고 리뷰도 한다. 하지만 책에서 지적했던 것 처럼 다음엔 좀 더 '주의'하겠습니다로 끝나는 의미없는 메아리만 남았던 적이 굉장히 많았다. 
• '우리는 팀이라고 하면서도 실제로는 각 멤버가 개별적인 업무나 프로젝트를 담당하기 때문에 서로 교류할 기회가 적다. 즉, 팀이라 부르기만 할 뿐 거의 개개인이 일을 하고 있는 그룹에 지나지 않는다.' 상당히 공감이 가면서 뼈아픈 얘기이다.
• 태스크 보드는 git 의 이슈 상태로 보여지는 ZenHub와 유사해보인다. 하지만 관리가 잘 되진 않지...
  • 혼자서 하루 TODO LIST를 관리하지만, 전날 업무의 감상 및 회고는 내 머릿속으로만, 완료시엔 이슈 close로만 처리한다. 휴대용 화이트보드를 정말 사봐야하나...