워크샾하면서 느끼는 것

 

• 간단하다, 쉽다, 그래서 누구나 참여할 수 있다, 배울수 있다
• 일단 해보면 안다
  그래서 계획이 어렵다면 간단한 업무라도 한번 해봐라
  그러면 감이 온다
• 무엇을 어떻게 준비해야하고 얼마나 걸릴지, 막연하고 과연 가능할까 의심도 들지만, 한번 보고나면 금방 이해하고 따로 설명해주지 않아도 알아서 이후를 계획할 만큼 짐작할수 있게된다
• 회의실 앞을 지나는 사람들이 이게 뭐야 하고 관심을 보인다 (일부러 보이게 문을 열어두는 경우도 있다)
• 쉬는시간이나 당일 업무시간 이후에 초대하지 않은 사람도 와서 관심있게 보는사람이 있다 (그냥 두자 이것도 홍보다, 입소문이다)
• 와서 보라고 하지 않아도, 설명해주지 않아도 알아서 본다
• 참석 인원은 해당 분야의 최소한의 인원으로 지정해두면 알아서 관련자들/전문가들을 초대한다
• 팀장이 참석하면 관련된 사람을 알아서 부른다
  팀장이 아니어도 친한 동료 있으면 와서 설명하라고 바로 전화하는 사람도 있다
• 5분정도 설명하고 5분정도 예를 보여주면 바로 스스로할 수 있다
• 심지어 추가로 초대된 다른 동료에게 설명까지 하게 된다 (진행자가 굳이 설명해주지 않아도)
• 해당 조직, 본인의 업무에 대해 이야기하므로 관심이 없을 수 없다
• 다른 문서 등을 굳이 참조하지 않아도 본인이 매일하는 업무이니 자연스럽게 이야기할 수 있다(특별히 무엇을 준비하지 않아도)
• 본인이 이야기할 수 없다면 관련해서 잘 아는 사람을 알아서 초대한다
• ASIS와 TOBE를 순차적으로 고민하고 정리할 수 있다
• 중요한것과 우선순위가 높은것도 색깔 태그를 달아 구분할 수 있다
• 고객사의 업무전문가/IT전문가, 수행사의 PL/설계자/개발자가 몇시간씩 이렇게 다 같이 집중하는 Task가 또 무엇이 있을까?
• 각자의 입장을, 업무를, 고충을 서로 이해하고 배우게된다
• 포스트잇 정도 사는 돈만 있으면, 사람과 장소만 있다면 언제 어디서라도 할 수 있다
• 문서 작업과는 달리, 해놓고 나면 뭔가 뿌듯하다. 일을 하고 있는게 보인다. 뭔가 있어 보인다. 별것 아니지만 무슨 새로운 기법처럼도 보인다
• 이야기하지 않아도 알아서 사진도 찍어간다
• 같은팀이든 다른팀이든 현업들 본인들끼리 활발한 토론의 장이 된다
• [SRD]  고객사 IT, 수행사 설계/개발자, 유지보수 이들끼리의 활발한 토론이 벌어진다
• 처음부터 참여한 사람들은 각자가 만든 소중한 결과물로 받아들여 사진찍고 정리하고 보충하고 보관하려 애쓴다
• 업무구분/조직, 일정, 진행순서 등 거의 대부분의 내용이 벽에 붙어있고 누구나 볼 수 있어 그때그때 관련해서 이야기 나누고 추가/보완해간다 (문서로 되어 있고 파일서버 어디에 있다고 해도 그렇게 열심히 찾아가서 의견달기 쉽지 않다)
• 전지를 붙일 수 있는 벽과 포스트잇 정도면 충분하지만 화이트보드(그림, 자유토론)와 빔프로젝트(ASIS 화면 또는 산출물 등 참조)까지 있으면 더욱 좋다
• 커피, 음료수, 간단한 다과도 함께하면 좋다
• 어떤 분들은 커피를 사다주기도 하고 본인 사무실의 컵과 커피를 가져오기도 한다
• 다소 썰렁하더라도 중간중간 농담으로 분위기가 너무 딱딱해하지 않도록하는것도 중요하다
• 참여자들이 조금만 잘해도 칭찬해주면 분위기도 좋아지고 그 분은 더욱 잘하게 된다
• 처음 준비부터 매일 오전 오후 한번 정도 진행과정을 사진으로 남겨야 나중에 결과 정리하기 좋다
• 해당 파트의 워크샾을 마치고나면 참여했던 모든 사람이 모여서 포스트잇 결과물 앞에서 기념사진 한장 남기는것도 좋겠다
• 하루종일 몇일을 연달아 워크샾하는 일정으로 잡으면 진행하는 사람도 피곤하고 그날 정리/복습/QnA/내부검토/다음 준비 등이 힘들다, 중간 중간 반나절, 하루 정도는 정비할 시간을 갖는게 좋다. 최소한 일주일의 금요일 하루 정도는 정리
• 당일 하루 어느 파트와 무엇을 얼마나 했는지 그날그날 기록으로 남기는게 좋다. 그날 오후 마무리할 때 기억이 제일 잘 난다
• 하루 하루의 기록을 요약 정리하면 워크샾 결과서가 된다. 마지막 결과서 만드는 시간을 그렇게 많이 할애하지 않아도 된다
• 목표수립이나 Event를 작성하는데 약간의 시간이 걸리는 경우 어색한 적막을 방지하기 위해 잔잔한 음악을 준비해도는것도 좋겠다
• [SRD] Microservice에서는 당연하지만 그렇지 않아도 충분히 의미있는 작업이다
• [SRD] 정보공학에서부터 표현하려고한 System Context Diagram 이다. SCD를 왜 그리려 한것인가?
  https://en.wikipedia.org/wiki/System_context_diagram
• [SRD]  내가 만드는 시스템이 주로 인터페이스하는 부분은 바로 UI이고 REST API로 통신한다
  UI외에도 각종 대내외 시스템과 인터페이스하는 부분이 많다
  이걸로 숲을 보고 나무를 하나씩 정의해 갈 수 있다
• [SRD]  한눈에 파악이 된다, 어떠한 툴도 이렇게 조망하기 어렵다
• [SRD]  ES와 마찬가지로 SRD도 5분정도 설명하고 5분정도 예를 보여주면 바로 스스로할 수 있다