Dev Note

찐 개발자의 퍼실리테이션 도전기 #4-1 워크샵 설계 및 준비에 이어서…
워크샵 시작
드디어 9시가 되었다. 나를 포함한 개발팀 5명과 다른팀 3명이 앉아있었다.
너무 시작시간을 일찍 잡았나?
오전 세션들은 개발팀보다는 Stakeholder(사내 admin 사용자)의 의견이 더 중요한데 3명이나 참여해줘서 너무 고마웠다.
Opening
참석자들이 갑작스러운 질문에 당황할 수 있을거라고 생각하여 개발팀에게는 “워크샵의 목적과 기대사항”에 대해서 생각해오라고 미리 이야기해 두었다.
먼저 “오늘 뭐하러 오셨어요?”라고 물어보았다. 개발팀 대부분은 그냥 회의한다고 해서 왔다고 했고, Stakeholder들은 Back Office(=admin)를 개선하는 자리라고 들었다고 했으며, 개발팀장님은 “점심으로 초밥을 대접하기 위해 왔다”는 말로 위트를 보여주었다.
“무엇을 기대하느냐?”는 질문에 대한 개발팀원들의 답변은 기억이 안 나는데 그냥 평범한 대답이었던 것 같고, 이 워크샵을 준비한 나로서는 힘이 빠지기도 했다. Stakeholder 중 최근에 합류한 C-lv. 한 명은 Admin 시스템을 아직 잘 몰라서 알아보러 왔다고 했고, O부서 두 분은 그동안 건의하려고 생각했던 사항들을 이야기하러 왔다고 했다.
그런 뒤 나는 Draft Agenda를 가리키면서 “통상적으로 프로젝트를 시작할 때 To-Be와 To-Do: Priority까지는 PO가 준비하는 것이며, 다음 단계들은 개발팀이 결정하는 사항들이다. 하지만 이번 프로젝트에서 우리는 PO없이 시작해야 하므로 전 과정을 함께 해보기 위해서 워크샵을 준비하였다.”고 워크샵의 취지를 설명하였다. 즉, 여기 모인 모든 사람들이 PO가 하는 일을 체험하게 되는 것이다.
Ice Breaking: Saying
아이스 브레이킹은 다음의 질문이 적힌 용지를 이용하여 진행하였다.
오늘 내가 긴급하게 나간다면 __________때문일 것이다.
참석자들이 할 일은 저 빈칸을 채우는 것이다. 모두 작성한 것을 확인한 뒤에 종이 오른쪽 아래에 자신의 싸인을 하라고 요청했다. 사람들은 아무런 의심없이 싸인을 하였다. 각자 작성한 것을 읽어달라고 한 뒤, 종이를 벽에 붙이도록 하였다. 그리고나서 “정말로 저 이유가 아니면 절대로 못 나간다”고 협박?을 했다. 여기서 사람들이 빵! 터졌다. 그렇게 반응이 좋을 거라는 기대를 안 했는데 다들 아뿔싸!하는 느낌이었나보다. (역시 마님은 초고수!)
Ground Rule
Ground Rule은 4가지를 미리 준비하였다.
적극적으로 즐겁게 : 어차피 오늘 워크샵은 긴 시간동안 힘들것이다. 이왕 할 거 적극적으로 즐겁게 하자. 그래야 시간이 빨리 간다.
Yes, and : 타인의 의견을 존중하자. 여기서 Yes는 “당신 말이 맞습니다”가 아니다. “당신의 의견을 이해핬다”는 뜻이다. 그리고 and로 자신의 의견을 이어가는 것이다. No, but과 같이, 아~ 그게 아니야. 이렇게 해야해. 와 같은 자세를 자제해 달라는 뜻이다.
편안하게 : 개발팀원들과 회의를 해보니 화장실에 가고 싶어도 못가는 사람들을 많이 보았다. (내가 이상한건가? 난 그냥 다녀오는데…) 그래서 눈치보지 말고 언제든지 다녀오라고 쓴 말이다.
여기는 회사가 아니다. : 여기는 회사이지만 마치 멀리 떨어진 워크샵 장소인듯이 생각하라는 의도였다. 자신이 써 붙인 사유가 아니면 못 나간다고 다시 한번 협박?했다. 이점은 진지하게 궁서체로 이야기했다.
Parking Board의 위치와 용도에 대해서도 이야기했다.
이쯤 진행되니 Stakeholder 4명과 개발팀 한 명이 더 들어왔다. 생각보다 많이 와주어서 좀 놀랐다!
Objective
Objective(프로젝트의 목적)을 PO(개발팀장님)에게 준비해달라고 사전에 부탁했다. 장표 6장 정도 분량이었다. 왜 Renewal 작업을 해야하는지, 무엇을 원하는지, 우리의 목표는 뭔지, 무언가 결정을 할때 어떤 기준으로 해야하는지 등에 대해서 쉽고 간결하게 잘 공유해 주셨다.
As-Is
먼저 참석자들에게 벽에 붙여놓은 Back Office 현황 조사 보드에 대해서 의견을 물었다. 개발팀장님은 생각보다 피드백이 너무 적어서 사람들이 관심어 없다고 생각이 들었는데 실제로 많이 참석해주어서 놀랐다고 했다. 피드백이 기대보다 적었던 이유는 stakeholder 각자 권한에 따라 볼 수 있는 메뉴가 제한적이었기 때문이었다. stakeholder들은 저 정도면 거의 대부분 의견을 내 준 것이라고 이야기해 주었다.
원래는 현황조사 판을 보며 추가 피드백을 받으려고 하였지만, 그것 보다는 참가자들에게 전체 메뉴를 보여주는 게 더 중요하다는 판단이 들었다. 그래서 즉석에서 프로세스를 변경하여, 개발팀 한명에게 부탁해서 Back Office 전체 메뉴에 대해 설명하도록 부탁했다. 그는 친절하고 길지않게 시스템의 모든 메뉴들을 설명해 주었다. 또한 그에게 test server에 모든 메뉴를 다 볼 수 있는 계정을 하나 만들어 달라고 하여 참가자들과 공유했고, 오늘 워크샵을 진행 중에 뭔가를 결정할 때 언제든지 들어가서 보고 참고하라고 했다.
이때 쯤되니 이제 개발 전원이 도챡했고, Stakeholder들도 10명 정도가 참석하였다. 너무나도 고마웠고, 너무나도 당황스러웠다.
To-Be : Categorization
이제 대메뉴를 새로 만드는 활동을 진행했다. 조를 나누기 위해서 며칠 전 어디선가 우연히 본 질문이 기억나서 그걸로 밸런스게임을 했다.
당신은 이직을 하게 되었습니다. 연봉이 10% 올라가는 대신 출퇴근이 왕복 1시간 걸리는 회사와 연봉이 50% 올라가는 대신 출퇴근이 왕복 4시간 걸리는 회사 중 어디를 선택하겠습니까 ? 10%는 파란색, 50%는 빨간색 신호등 카드를 들어주세요. 하나.둘.셋!
거의 반반이었다. 몇 명만 이동시켜서 두 팀을 만들었다. 각 조별로 모든 부서 사람들이 최소 1명은 포함되게 이쁘게 잘 분배되었다.
각 조별로 이젤패드에 포스트잇으로 대메뉴를 적어서 붙여달라고 했다. 기존 시스템과 거의 변화가 없을거라 예상했기에 10분만 주었다. 그런데 예상과는 다르게 적극적으로 의견을 나누는 소리가 많이 들렸다. 참여형 워크샵의 전형적인 모습이 보여서 놀라웠으며, 참여자들에게 고마운 생각이 들었다.
10분 뒤 각 조별로 발표를 했고, 신호등 카드로 의견을 물었다.
녹색 : 아주 잘했다. 훌륭하다.
노란색 : 대체적으로 잘했다. 조금 보완이 필요해 보이기는 한다.
빨간색 : 아주 중요한 것이 빠졌다. 저렇게 되어서는 안된다.
참가자들이 상호 의견교환을 잘해서 내가 개입할 일이 거의 없었다. 새로운 의견이 많이 나와서 예정된 시간을 초과했지만 그냥 두었다. 왜냐면 참석자들이 충분히 이해하는 것이 더 중요하다고 판단했기 때문이다. 충분한 의견을 들은 다음에 두 조의 산출물을 참고하여 최종 합의안을 작성하였다.
이렇게 이번 세션의 최종 산출물이 완성되었다.
To-Be : Action Items
이젤패드 1장에 대메뉴 하나를 타이틀로 적어서 벽에 붙였다. 이번에는 대메뉴 별 소메뉴를 구성할 차례다. 2인 1조로 진행하려고 계획했으며, 가능하면 개발자 + 이해관계자 조합으로 하고자 하였다. 먼저 참여자들을 개발자, 이해관계자로 나누어 서도록 하고 눈치게임을 했다. 기대처럼 드라마틱하게 활발하게 일어나지는 않았다. (사실 기대도 안했다. ㅠㅠ) 아주 썰렁하지만 어쨌든 겹치는 사람이 딱 한번 있었는데, 그건 둘 다 개발자였다. 대체로 앞번호를 이해관계자들이 다 가져가고 뒤에 개발자들이 남았다. 그 순서를 이용하여 개발자 한 명과 이해관계자 한 명으로 짝을 붙여주었다.
소메뉴에 대한 브레인스토밍은 한 번에 너무많은 아이디어들이 나오는 경우 정리하기 어려울 것 같아서 몇 번의 라운드로 나누어 진행을 하기로 했다. 한 라운드는 조별로 3분 동안 포스트잇을 이용하여 우선 소메뉴 2개만 붙이도록 했다. 그런 뒤 모두 함께 의견을 나누었다. 주로 무엇을 어떤 의미로 붙였는지, 내용을 이해하는데 초점을 맞추었다. 그리고 다시 라운드를 반복하는 식으로 진행을 했다. (마님의 아이디어다.)
피드백 시간에 많은 질문이 나왔고 그 과정에서 비슷해 보이는 메뉴를 합치고(Grouping), 다른 대메뉴로 옮기는 등의 행동들이 자연스럽게 나왔다. 정말 아름다운 모습이었다.
그렇게 3라운드를 진행하니 대부분 다 나온것 같다는 의견이었다. 그래서 마지막 라운드를 진행하면서 포스트잇 개수 제한없이 아직 없다고 생각하는 것을 모두 다 붙여달라고 했다.
마지막으로 피드백을 받고 있을 때 점심이 도착했다. 무조건 빨리 결론을 내고 Lunch Break를 가져야 겠다는 압박을 받았다. 사실 이전 라운드에 중요한 피드백은 다 나왔으니, 여기서 조금 빠르게 진행해도 큰 무리는 없을 거라 판단했다. 그래서 최종적으로 확인을 한 후에 Lunch Break를 가졌다.
Ice Breaking : Game
점식식사 직후라 모두 졸릴 것이라고 생각하고 간단한 게임으로 오후 Ice Breaking을 가졌다. Improv라는 즉흥연기 수업에서 배운 게임으로 Zip! Zap! Zop!과 Oosh! Bang! Pow! 이렇게 2가지를 준비했다. 두 개 모두 단순한 게임이 아니라 그룹 커뮤니케이션에 대한 교훈이 있는 게임이다. 매우 성공적이지는 않았지만 일부 참석자들의 적극적인 참여로 끝까지 진행했다는 데 위안을 삼았다.
To-Do : Priority
이제 개발 순서를 정해야한다. 여기서부터는 이해관계자들의 참여가 크게 중요하지는 않았는데 이때 오전에 참석하지 않았던 기획자 한 명이 들어왔다. 나는 그가 나타난 이유를 대충 알 것 같았다. 왜냐하면 점심시간에 개발팀장으로부터 그가 이 워크샵에 대해서 안 좋게 생각하고 있다는 말을 전해들었기 때문이다. 빨리 개발을 끝내야하는데 저렇게 사람들 모아놓고 의견을 구하면 신규기능들이 많이 나올 것이며 그걸 반영하면서 개발하려면 시간이 더 오래걸릴 것이라는 의견이었다. 맞는 이야기다. 우리도 신규기능을 우선순위에 두고 진행을 할 생각은 없었다. 오전 개발팀장의 Objective 발표를 통해서 기존 시스템을 빨리 sunset하는 것이 목표라는 점을 분명히 했다.
이 분의 우려를 빨리 해소해 주는게 좋을것 같아서 그 발표를 보여주면서 우리의 목표도 다르지 않음을 설명해 주었다. 즉 지금 나온 의견들 중 기존 시스템을 대체하는 기능을 우선으로 개발할 것이며, 기존 시스템을 빨리 sunset하고 신규 시스템 오픈 후, 추가 기능들에 대해서 개발할 것이라고 이야기했다.
이번 세션은 조를 나누지 않고 전체 토의로 진행했다. dependency 있는 항목들에 대한 의견을 받았다. 대메뉴별로 개발하기 전에 선행되어야 할 것이 무엇인지 참석자들에게 물고 의견을 차트에 기록하였다. 그렇게 전체 대메뉴에 대해서 의견을 모은 후 개발 순서를 정했다.
To-Do : Story Evaluation
이번 워크숍의 최종 목표는 프로젝트 일정을 산출하는 것인데, 좀더 정확한 일정 산출을 위해서는 Story Evaluation이 도움이 된다.그리고 Story Evaluation은 원래 각 Sprint 시작 시 팀원들이 하는 일인데, 이 과정을 훈련할 필요가 있었기에 워크숍에서 같이 다루게 되었다.
먼저 1 story point의 정의를 함께 내렸다.
그런 다음 쉬운 대메뉴 하나를 같이 진행했다. 페이지 구현에 필요한 UI Component를 포스트잇에 적어서 한 곳에 모았다고, 소메뉴 별로 서버, 웹페이지 story를 Jira에 생성하였다.
이렇게 대메뉴 하나를 시범으로 같이 진행하고, 참석자를 2인 1조, 총 3개조로 편성하여 소메뉴가 가장 많은 3개를 대메뉴를 나누어 진행했다. 작업을 하다가 모르는 항목이 나오면 해당 항목을 작성한 이해관계자를 찾아가서 이야기를 듣고 story point를 산출해 달라고 했다. 작업시간은 1시간을 주었다. (한 조는 신규 기능이 많아서 이해관계자의 설명을 듣는 데 시간이 걸렸다.) 작업결과를 화면으로 공유하면서 상호 피드백 시간을 가졌다.
첫 라운드가 끝나고 다음 라운드를 진행하기 전에, 신규 기능들은 기존 기능들을 모두 개발 한 후에 진행할 예정이니 이 자리에서 너무 자세하게 파악할 필요가 없음을 안내했다. 시간이 부족하여 결론이 안 난다면 Parking Board에 ‘미결 사항’으로 적어 두기로 하였다. 이번에도 1시간을 주었지만 1라운드에 진행한 것에 비해 작업량이 적어서 비교적 빨리 끝났다.
To-Run Sprint
파악가능한 모든 소메뉴들에 대해서 story point를 모두 계산하였다. 이제 sprint를 정의하고 각 sprint 별로 우선순위에 따라 Jira issue를 배치만 하면 된다. 워크숍 기획단계에서는 아주 심플한 일이라고 생각했는데, 막상 하려니 생각보다 시간이 훨씬 많이 걸릴 것 같았다. 달력을 보면서 sprint를 정의하고, 휴일을 계산하고 등등의 과정을 하는데 시간이 훨씬 더 많이 걸릴것 같았다. 일단 지금 나를 포함하여 모든 참여자가 지쳐있을 것이라는 점도 고려했다.그래서 러프하게 계산을 시도했다.
우리는 story point를 시간으로 계산하지 않았다. 그런데 sprint를 계산하려면 story point를 시간으로 변환해야 한다. 그래서 아래와 같은 사항들을 의논하여 시간으로 환산했다.
1 story point는 얼마나 걸릴지?
작업자는 몇명일지?
sprint의 기간은?
운영 업무의 비중은?
휴가자의 비중은?
그렇게 계산하니 7 sprint 정도가 나왔다.
일단 이것으로 최종산출물을 만들어낸 것으로 하고 Closing으로 들어갔다.
Closing
최종 산출물의 내용을 다시 확인하였다. Parking Board에 있는 사안들도 모두 확인하였으며, 오늘 진행된 워크샵을 회고하고 소감을 나누었다. 타부서 사람들이랑 같이 뭔가를 한 것이 새로운 경험이었다는 평이 많았다. 그렇게 워크샵을 원래 예정되었던 5시보다는 30분 정도 일찍 마쳤다.
나의 회고
고객의 눈높이에서 항상 생각해야 한다.
Back Office 사용현황조사를 할때 메뉴를 개발팀의 의견대로 구성하였다. 현재 Back Office가 사내에서 2개의 버전이 운영중이다. 그 2개의 메뉴 중 겹치는 것에 대해서는 2.0 버전 기준의 메뉴로 현황판에 적었다. 하지만 사내 유저들은 대부분 1.0을 많이 사용하고 있었다. 그래서 2.0의 메뉴를 보고 자기가 사용했던 것이 어느 메뉴인지 못 찾겠다는 피드백이 있었다. 최대한 고객이 이해하기 쉽게 해야겠다는 생각이 들었다.
현장은 계획대로 돌아가지는 않는다.
워크숍 현장에서는 어떤 돌발 상황이 생길지 모른다. 그래서 가능한 백업플랜을 미리 준비하는 것이 좋다. 만약 의견 조율이 제대로 안 되면 누구에게 결정권을 줄 것인가, 참석자의 비율이 예상한 것과 다르다면 조 편성을 어떻게 할 것인가와 같이 미리 준비 가능한 것들도 있고, 이번 워크샵의 As-Is 세션처럼 추가 의견을 듣는 것으로 준비를 했지만, 참여자들의 이해도를 높이는 것이 더 중요하다고 판단하여 계획을 변경하고 다르게 진행하게 되기도 한다.
그래서 목적달성을 한 것일까?
개발팀 동료들에게 Milestone 설정, Story 새성 등 PO 작업의 일부를 체험하게 하였다. 아직 Sprint로 작업을 한 경험이 없는 친구들이라 직접 story point를 측정하는 것도 진행했다. 목적을 완전히 달성했다고는 볼 수 없겠지만, 이제 sprint를 시작하기 위한 사전 준비는 끝났다. 나머지 과정들은 sprint를 진행하면서 차차 진행해도 된다는 것에 위로를…
나의 소감은?
처음으로 워크샵을 설계하고 진행까지 해봤다. 내 인생에 있어서 커다란 전환점이 될 것이라 믿어 의심치 않는다. 내 커리어에 있어서 두번째 큰 전환점이다. 첫 번째는 이전 회사에서 정말 완벽한 소프트웨어 개발팀의 프로세스를 경험하고, 좋은 동료들과 보낸 1년 남짓한 시간이다. 이건 내 개발자 커리어에 그 어떤 시간보다 소중했고, 그 이후의 나는 확실히 다른 사람이 되었다. 이번 워크샵을 통해 나는 타인의 말을 이해하려고 노렸했고, 내 말을 상대방이 잘 이해하고 있는지 점검하게 되었으며, 잘 이해시키기 위해서 어떻게 해야하는지 고민하게 되었다. 내가 이런 고민을 하고 있는 것 자체가 믿기지 않는다. 아마 나보다도 나를 알던 다른 사람들이 더 놀랄것 같다. 뿌듯하다.

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

댓글