찐 개발자의 퍼실리테이션 도전기 #4-1 워크샵 설계 및 준비

in Culture on Agile


오랜만에 적는 찐 개발자의 퍼실리테이션 도전기 #4. 이번에는 워크샵 설계이다. 이전과는 스케일부터가 다르다.

먼저 이번 글에서는 준비과정에 대해서 적어본다.

왜 워크샵을 할려고 생각을 했을까? 이전 회사에서는 모든 것이 그냥 당연하게 이렇게 일하는구나 라고 생각했던 것이 하나도 이루어지지 않았다. PO님이 Milestone에 대해서 미리 정의를 하고 해당 Milestone을 몇 개의 Sprint로 나눠서 각 Sprint마다 어떤 Story들을 진행해야하는지 미리 다 계획을 짜두셨다. 그걸 개발팀에게 공유를 하고 피드백을 받는 것이 사실상 해당 Milestone의 kick-off가 되었다. 그 시간은 그리 길지 않았다. 그냥 회의실에서 2시간 남짓 정도되는 시간이었으며, 그때까지 세부적인 SRS나 기획문서는 없었다. 그 뒤 각 Sprint보다 1 iteration 앞서서 기획 및 디자인을 하였으며, Sprint 시작 이틀전 (전주 목요일) 오전에 해당 내용들을 공유하였고, 그 다음날부터 Sprint meeting까지 각자 해당 Story를 구현 할 수 있는 세부적인 Jira 티켓을 생성하였고, Planning Poker가 필요없는 경우 (예를 들어서 나의 경우 Server 개발 및 Infra 구성 및 배포를 혼자 진행 하였으므로) Story Point를 미리 결정하였다. Sprint meeting에서 Front-end 작업들에 대해서는 Planning Poker를 통해서 Story Point를 결정하였으며, 각자 휴가 및 미팅, 기타 외부 일정 등을 파악해서 이번 Sprint에 몇 Story Point를 진행할 것인지 정하고 티켓들을 각자 가져오고, 개발팀장이 조율한 다음 시작했다.

나는 좋은 개발 문화를 가진 팀에서 일하는 개발자에게는 너무나도 당연하다고 여길 수 있는 이러한 프로세스가 전혀 없는 곳에 합류를 하였다. 그래서 이런 경험들을 그들과도 함께 공유하고 싶었으며, 이번에 개발팀에서 자체적으로 진행하는 Admin Renewal작업이 이것을 시도하기 좋겠다고 판단하였다. 하지만 PO Role이 따로 없고, 기획자도 없다. SRS문서도 없다. 그래도 기존 시스템을 Renewal하는 것이어서 그나마 예전 코드 및 동작하는 웹사이트가 SRS 역할을 해줄수 있다.

워크샵에서 진행하면서 만들어지는 중간산출물에 대한 정의는 명확하다. 최종산출물에 대해서는 조금 생각을 해 보아야겠지만, 어느 정도까지의 결과물이냐의 차이일뿐 전혀 다른 방향으로 산출물이 나오지는 않는댜. 왜냐하면 이미 과거 제대로 된 프로세스를 경험했기 때문이다. (그 당시에는 그냥 당연하게 받아들여졌던 PO, 개발팀장 님의 역할이었는데, 이게 그렇게나 소중한 것이었구나. 그 분들이 정말 대단한 분들이었구나라고 이제서야 느끼게 된다.)

워크샵 과정을 설계하고 진행하는 것은 태어나서 처음하는 것이다. 물론 엄청 두렵다. 하지만 강렼크한 조언자가 있다. 2021년 1월 현재 대한민국에서 유일하게 국제공인 Master Facilitator 타이틀을 가진 분이 가까이에 있다. 앞으로 이글에서는 이분을 마님이라고 칭하겠다. (집에서 마님으로 모셔서 마님은 아니다. 마스터 퍼실리테이터의 앞글자를 따서 마님이다. 참… 변명 구차하다.) 이정도면 거의 치트키이다. 실패하기 힘든 조건이다. (하지만, 아직은 알지 못했다. 가장 큰 복병은 참여자의 태도라는 것을 ㅠㅠ)

1. 설계

워크샵의 3P가 있다.

Purpose, Product, Participant

1.1. Purpose

먼저 워크샵을 왜 하는가를 생각했다.

  • Visioin, Mission을 공유한다. → 무언가 선택해야 할때 지표가 된다.
  • 일정을 예상한다. → 이번 워크샵에서 만들어내야할 최종 산출물이다.
  • 개발 우선순위를 정한다. → 일정 변경이 힘든 경우 제외할 기능을 미리 생각한다. but, Renewal이라 결국 다 해야한다.

Vision, Mission을 누가 정할 것인가 ? 모두가 같의 논의하기에는 그것만 하나의 워크샵이 되어야 할 정도의 시간이 걸릴 것이며, 내가 비전수립 워크샵의 진행을 할 만큼의 역량은 안될거라 판단되어 누군가 1인이 정해줬으면 한다. 그럼 누가 정해야 할까 ? PO가 정하는게 가장 자연스러울꺼라 생각했다. 그런데 우리에겐 아직 PO가 없다. 그래서 PO를 개발팀장님에게 부탁했다. Tech Lead도 역시 개발팀장님이다. 이 둘이 동일이라는게 일반 프로젝트라면 피해야 할 상황이겠지만, 이번에는 의외로 하겠다.

1.2. Participant

다음으로 참석자들을 생각했다. (Product와 순서를 바꾸었다.)

PO, Tech Lead, Workers, Stakeholders

Workers는 개발팀인원이겠고, Stakeholders(이해관계자)는 사내에서 Admin을 사용하는 전원이다. 이해관계자이자 User(고객)이다. 이들에게 참석을 부탁한다고해서 과연 와줄까 ? 아무도 안와줄꺼라고 생각이 들었지만, 그래도 와 달라고 이야기하는건 의미있는 행동이라 생각했다. 거의 100%의 확률에 가깝게 아무도 안와줄꺼라고 생각했다. (스포를 하자면, 이들이 안와줬으면 워크샵은 완전 망했을 것이다.)

다음으로 워크샵 순서에 대해서 구상을 하였다. 현재 시스템을 Renewal하는 Project이니 만큼 다음과 같은 순서를 생각했다.

  • Opening
  • Objective : 왜 하는가 ?
  • As-Is : 현재 상황이 어떠한가 ?
  • To-Be : 앞으로 어떤 모양이 되어야 하는가 ?
  • To-Do : 그럴려면 뭐를 해야 하는가 ?
  • Closing : 산출물 확인, 회고/소감

1.3. Product

Objective는 앞에서 이야기한 비전/미션이 되겠다. 이건 PO(a.k.a. 개발팀장님)에게 부탁을 드렸다. As-Is는 현재 Admin(사내에서는 Back Office로 불림)에 어떤 메뉴들이 있고, 주로 어느 부서의 누가 사용중이며, 그동안 이렇게 된 히스토리에 대해서 아는 것에 대해서 정리를 개발팀원들에게 부탁했다. 그리고 그 중 1인에게 모아진 자료들을 취합해서 1시간 이내로 발표해 달라고 부탁했다. To-Be에서는 새로 대메뉴, 소메뉴를 생성하는 세션으로 진행하고자 한다. 기존와 크게 변경사항이 없을 것으로 예상된다. 그래서 이 세션은 짧게 진행하면 될 것이다. 그냥 조를 나놔서 산출물을 만든 다음에 피드백 시간을 가지고, 조율하고 최종결과물을 합의해서 만들면 된다. To-Do에서 할 것은 어떤 순서대로 개발할 것인지, 조금은 더 구체적으로 Jira Issue로 Story를 생성하고 Story Point를 Evaluation하면 된다. 이건 워크샵에서의 참여가 아닌 그냥 업무이다. 이건 조를 나누고, 대메뉴 기준으로 업무도 나눠서 분업을 해서 진행하면 될 것이다. 그렇게해서 모든 대메뉴, 소메뉴 별 Story 생성 및 Story Point Evaluation을 하고난 산출물을 이용해서 Sprint에 배치하면 언제쯤 Project를 끝낼 수 있을 것인지 예측이 될 것이다. 그러면 워크샵의 최종 산출물이 완성된다.

1.4. 보완

일단 러프하게 어떻게 진행해야 할 것인지 그려졌다. 여기에서 치트키를 한번 눌렀다. 마님의 패드백을 받았다.

  • As-Is를 혼자서 진행하는 것은 참석자들에게 너무 지루할 것이다. 이걸 참여형으로 만들면 좋겠다.
  • As-Is를 개발팀에서 준비하는게 과연 맞는가 ? User의 목소리가 반영되면 좋겠다.
  • To-Be에서 원래 내가 하기로한 활동에 대해서 이야기를 했고, 좀 더 적절한 방법에 대해서 피드백을 받았음.
  • To-Be에서 뭔가 결정 사항에 대해서 합의가 안되면 ? 누가 결정을 할 것인가 ?
  • 그 결정을 할 책임자를 미리 생각해둬야 한다. 가능하면 개발팀인원보다는 고객인 것이 더 좋다. 여기서는 고객의 목소리가 더 중요하다. (하지만 난 고객의 참여에 대해서는 기대하지 않고 있다. ㅠㅠ)

그래서, As-Is에 대해서 고객들의 소리를 듣는 것으로 정했다. 현재 시스템의 대메뉴, 소메뉴를 전지 2장에 출력해서 벽에 붙인 다음에 거기에 스티커, 포스트잇으로 피드백을 받기로 했다.

회사 분위기상 큰 참여는 기대하지 않는다. 아에 아무것도 안붙어있으면 어쩌지란 걱정도 들었다. 워크샵 1주일 전부터 회사벽에 붙여두었다.

회의실도 다시 한번 점검했다. 책상위치와 의자개수, 사람들이 앉았을 때 앞뒤로 다른 사람들이 다니면서 활동하기 적절한지 (아니면 책상을 좀 옮겨야 할지), 벽이 이젤패드를 붙이기에 적절한지, Draft Agenda, Ground Rule, Parking Board는 어디에 붙일 것인지, As-Is에 대해서 조사한 현황판은 어디에 붙일 것인지 등등 부터 해서 각 활동별로 어디에다가 이젤패드를 붙여놓고 진행을 할지, 먼저 차례에서 했던 산출물을 다음 활동에서는 어디에다가 옮겨 붙여놓고 진행을 할지 등등에 대해서 머리속으로 한번 그려보았다.

2. 당일 아침 준비

워크샵 시작 2시간 30분전에 회사에 도착했다. 원래는 외부에서 했었어야 하는데, 5인이상 사적모임 금지라서 외부 시설 대여가 안되었다. 그래서 어쩔수 없이 사내에서 진행했다. 도착하자마자 오전에 진행할 Ice Breaking 주제를 12장 인쇄하였다. 참석자는 개발팀 8명. 끝. 이겠지만 그래도 이해관계자 2명 정도는 개발팀장에게 부탁해서 섭외를 부탁할 예정이다.

워크샵 당일 아침에 확인하니 그래도 피드백이 아에 없지는 않아서 다행이란 생각은 들었다. 하지만, 이걸 가지고 무슨 이야기를 할 수 있을지 조금 막막하긴 했다.

전에 사놓은 문구류 (이젤패드, 네임펜, 조금은 두꺼운 마커펜, 포스트잇)을 가지고 회의실로 갔다. 오늘 진행할 차례(Draft Agenga)에 대해서 먼저 이젤패드 한장에 적었다. 그런 뒤 미리 생각해 놓은 시간을 거기다가 적었다. 그리고는 Ground Rule을 적었다. 가장 마지막 항목은 미리 적어두지 않았다. 왜냐면 Ice Breaking을 할 주제와 관련이 있으며, 왠지 저것이 적혀있으면 스포가 될듯해서 사람들이 재미를 덜 느낄것 같았다.

그리고, 문구류와 미리 준비한 간식(이라고 썼지만, 사실은 스팀팩에 가까운 소량의 카페인과 다량의 칼로리)을 책상에 배치했다. 그리고 10개의 신호등카드 묶음도 의자 앞에 하나씩 두었다.

그리고 Slack에 시작 30분 전쯤에 관심있으신 분들은 참여해 달라고 메세지를 소극적으로 남겼다.

오늘 오전 9시 ~ 오후 5시까지 컨퍼런스 룸에서 Admin 3.0 Kick-off Workshop이 있습니다. Draft Agenda 로는

  • 메뉴 결정
  • 할 일에 대해서 순서를 정하고 얼마나 걸릴지 예측
  • 전체 프로젝트 기간에 대한 예측 입니다. 개발팀분들 및 관심이 있으신 분들은 9시까지 컨퍼런스룸으로 와주세요. (특히 오전 시간에는 Admin 사용자 분들의 의견이 많이 반영되면 좋겠어요. 많이들 오셔서 의견 내주세효~)

일단 개발팀 분들 중 2명은 늦을거라고 연락을 주었다. ㅠㅠ. 자자.. 그럼 개발팀 6명 + 이해관계자 2명 = 8명으로 시작할 것이라 예상된다. 이제 정말로 심장이 쿵캉쿵캉 뛰기 시작한다.

To be continue…

찐 개발자의 퍼실리테이션 도전기 #4-2 워크샵에서 계속

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)