매주 회고를 하기로 다짐한 후 처음으로 한 주를 건너뛰었다.
'매주'라는 주기 덕분에 작심 3일은 돌파했지만..
어차피 전주였는지 이번주였는지 분간이 안 가는 상태이기에 기억을 더듬으며 2주치 회고 레지고..
현실의 의사결정은 별로 아름답지 않다.
프로젝트를 진행하면서 숨 쉬듯이 무언가를 결정해야한다.
회의 시간, 내용부터 각 회의의 결정사안들까지
'의사결정을 어떻게 해야하는가?'라고 누군가한테 질문을 받으면 대답하기 어렵지 않았다.
- 상대방의 의견을 존중한다.
- 내 의견과 근거를 명확히 정리하여 공유한다.
- 의견을 종합하여 현재 상황에서 가장 합리적인 결정을 내린다.
존중, 명확, 합리적 등 이상적인 단어로 대충 표현해버리면 되기 때문이다.
하지만 적어도 내가 경험한 현실의 의사결정은 그렇게 아름답지 않았다.
열심히 얘기를 하다보면,
'이 얘기를 왜 하고 있는 거지' 싶은 순간이 있다.
같은 얘기를 반복해도 진전이 없다고 생각되기도 한다.
우테코 시작부터 페어프로그래밍을 하며 의사 결정을 연습했다.
당시 듣던 말 중 하나는 '충돌을 피하지 마라' 였다.
의사결정 과정에서 쉽게 타협하지 말고, 각자의 의견을 충돌하는 경험을 해보라는 것이었다.
늘 그것에 충실했지만, 이번엔 좀 지치기도 했다.
어쩔땐 그냥 타협할까 싶다가도 찝찝한 마음과 이유없이 내 의견을 묵살하는 것이 싫어서 고집을 부리기도 했다.
덕분에 의사결정에 소모하는 시간과 에너지가 상당했다.
팀원 모두 의사결정의 비효율에 동의했고, 개선이 필요하다고 생각했다.
그래서 다음과 같은 방법을 적용해보기로 했다.
- 모든 결정은 최종적으로 다수결의 원칙을 따른다.
- 결정을 못 한 사람이 결정을 위해 조사해볼 시간이 필요하다면 제공한다.
- 결정에 동의할 수 없다면, 동의하지 못 하는 사람이 더 권위있는 사람의 조언을 구해온다.
- 매 회의에 담당자를 배정한다.
- 담당자는 회의가 원활히 진행되는데 필요한 준비, 진행, 결정사안에 대한 기록을 담당한다.
- 고정 회의 시간을 정하고, 나머지 시간은 논의를 위해 필요한 내용을 각자 준비한다.
회의 시간과 준비 시간을 명확히 분리하여, 회의 도중 정보를 조사하는 비효율을 제거했다.
또 결정에 대해 모두를 납득시킬 수 없다고 판단했다.
모든 결정에 대해 모두가 납득하는 아름다운 의사결정은 존재하지 않는다.
현실의 의사결정은 카오스인 것 같다.
발작 버튼을 통제하기
아버지 피를 물려받아서 그런지 감정 버튼이 눌리는 시점들이 있는 것 같다.
그래서 대체로 내가 무시받는다고 느껴지면 감정 조절이 어렵다.
놀랍게도 월요일 회의를 하다가 그런 순간이 있었다.
프로젝트 하면서 싸우기도 하고 우는 사람도 있다는 얘기를 이해를 못 했는데, 덕분에 명확히 이해할 수 있었다.
흥분하거나 어떤 포인트에 기분이 나빠지기 시작하면 상황을 잘 못보게 된다.
예를 들어, 누군가 하기 싫은 티를 내는 것이 기분 나빠지면 그 상황 자체에 불만을 가지게 된다.
쟤는 왜 저런 걸 티내지?
라고 생각한다.
근데 정말 이상적인 해결책을 생각해본다면,
그 사람이 하기 싫은 이유를 파악하고 해결해주는 것이다.
하기 싫다고 느끼는 작업을 내가 해줄 수도 있고,
지쳐있다면 휴식을 제안할 수도 있다.
회의에서도 똑같이 어떤 시점부터 상황을 보지 못했다.
상대방의 의견을 납득하지 못했고,
얘기하는 과정에서 기분이 나빴다.
그러다 어떤 기능이 정적 페이지를 제공하냐? 라는 이상한 논쟁을 하기 시작했고,
내가 잘못된 지식을 가지고 있다는 듯한 상대방의 태도에 흥분해버렸다.
솔직히 지금 시점에도 내가 틀린 주장을 했다고 생각되지 않는다.
나는 알아주는 고집불통 대마왕이기 때문이다.
그럼에도 뛰어난 사람들은 좀 더 젠틀하게 상황을 해결할 수 있었을 것 같다.
어쩌면 시작이 나였을 수도 있다고 생각한다.
생각해본 해결책 중 하나는 반박할 때 조금 더 말을 신경써서 하는 것이다.
반대 의견을 낼 때, 상대방의 주장이 완전히 쓰레기라는 듯이 말하면 내 입장에서도 오기가 생길 것 같다.
상대방의 의견에 대해 이해하고 동의하는 부분을 먼저 언급하고 말을 시작해보면 좋을 것 같다.
억지로 함께하는 것도 의미가 있을까
프로젝트 시작 전부터 개인적인 목표가 있었다면, 프로젝트 팀원들과의 유대감이다.
심리적 안전감이 완벽하게 형성된 팀원들과 함께 프로젝트를 진행하고 싶었다.
지난번 매트와 커피챗을 한 이후로 매주 회고의 시간을 가졌으면 좋겠다고 생각했다.
그래서 주변 사람들에게도 프로젝트 시작하면 매주 회고와 회식을 진행할 것이라고 장난스레 얘기했다.
프로젝트를 시작하니 얘기를 꺼내는 게 생각보다 쉽지 않았다.
결정하고 작성해야할 것들이 계속 존재했다.
회고는 분명히 필요한 행위지만, 우리가 해야할 일들을 해결해주진 않는다.
해야할 것들이 남아있고, 서로 얘기하는 데 지친 모습이 보이는 상태에서 회고하자고 얘기하지 못했다.
나도 생각이란 걸 더 하기 싫었기에 회피한 것 같다.
팀 단위로 신청할 수 있는 '최고의 팀은 무엇인가' 워크숍이 기회라고 생각하여 신청했었다.
그 자리에서 처음으로 회고의 필요성을 공유할 수 있었다.
매주 금요일마다 팀 규칙과 진행에 대해 회고하자는 규칙을 세웠다.
하지만 뜻대로 진행된 금요일은 없는 것 같다.
유일하게 의미있는 회고 시간이었다고 생각한 건, 갈등의 폭발이 새어나왔던 날이다.
흥분을 감추지 못했던 날, 의미없는 대화가 계속 이어졌다.
그래서 머리 식힐 겸 회고를 하게 됐다.
모두가 문제를 느끼는 상황에서, 그 문제에 대해 얘기를 하기 시작했다.
내가 느끼는 문제를 다른 사람도 느낀다는 것이 한 편으로는 놀라웠다.
그리고 꽤 의미있는 대화가 이어졌다.
매주 회고를 하는 건 이상적이다.
지금 내가 하고 있는 것도 그런 면에서는 이상적이다.
하지만 회고가 의미있는지는 별개인 것 같다.
형식적으로 임하는 회고는 의미가 없다.
지금 나도 의미없는 행위를 하고 있을 수도 있겠다.
팀 회고가 정말 의미있게 진행되려면, 참여하는 모두가 필요 이상의 진지함을 가져야 한다.
그리고 그것에 도움이 될 수 있는 건, 모두가 느낄만한 불편함을 인지하고 언급할 수 있는 능력이라고 생각한다.
폭포수 탈출법: 흙탕물 기어가기
레벨3 시작부터 세뇌받던 내용 중 하나는 '빠르게 실패하라'이다.
빠르게 사용자 반응을 보고, 결과를 통해 방향을 수정하는 것이 목표였다.
프로젝트를 진행하다 보면 마음대로 되지 않는 게 362개 정도 있는데, 그 중 하나가 진행 속도이다.
매 번 이번주까지 XXX하자 라는 목표를 세우지만, 지켜본 적이 없다.
금요일에 밍글링 데이를 하며 코치에게 질문할 수 있는 시간이 있었다.
일정이 매번 미뤄지고 진행속도가 지연된다는 문제를 공유했다.
거기서 꽤 좋은 해결책을 얻었다.
- 가용 리소스 파악하기
매주 스프린트마다 우리가 얼마나 시간을 쓸 수 있는지 생각해보는 것이다.
돌이켜 보면, 늘 목표만 있고 우리의 시간은 생각해본 적이 없다.
어떤 주는 제출해야할 문서와 참여해야할 워크숍이 많아서, 실제 프로젝트에 투자할 수 있는 시간이 적었다는 것을 알았다.
그래서 우리가 쓸 수 있는 시간을 바탕으로 해낼 수 있는 목표를 선정하는 것이 중요하다는 걸 알았다.
- 프로젝트 목표가 무엇인지 인지하기
이번주엔 대체로 코드 설계 관련 논의를 했다.
계층별 테스트 코드, dto 변환 위치 등 코드 일관성을 위한 규칙을 논의했다.
코드 설계는 대부분 정답이 없는 문제라는 것을 알지만, 규칙 통일을 위해 논의에 시간을 썼다.
특히 서비스 계층의 단위테스트 필요성에는 더 많은 시간을 소모했지만 결정이 나지 않았다.
하지만 과연 그게 그렇게 중요할까?
프로젝트의 목표가 사용자를 유치하고 관찰하고 근거로 사용하는 것이라면,
테스트 코드가 어떻게 짜여있든 무슨 상관이지?
프로젝트를 진행하면서 정말 크고 작은 것들을 결정해야 했고,
이를 위해 논의를 진행했다.
그러다 보니 다들 지치기도 했다.
어떤 결정이 필요한지, 얼마나 노력을 소모해서 의견을 맞춰야하는지 판단하는 기준이
프로젝트의 궁극적인 목표가 될 수 있다는 것을 알았다.
어떤 결정에 대해 중요하게 생각하거나 본인이 기술적으로 관심있는 사람이라면,
그 사람의 의견을 좀 더 존중해줄 수 있다.
또 우리 프로젝트의 궁극적 목적에 중요하지 않는 사안이라면
어느정도 타협할 수 있다.
또 그 결정을 되돌리는 비용이 크지 않다면, 조금 과장해서 가위바위보로 정해도 된다고 생각하게 됐다.
학부시절부터 애자일 방법론을 듣고, 현대 개발자는 애자일 방법론을 따라야한다고 생각했다.
하지만 프로젝트를 진행하다보면, 초기 단계의 완벽한 설계, 규칙 명시 등을 포기하지 못하게 된다.
애자일 방법론을 따르는 개발은 그렇게 우아하지 않을 거란 걸 깨닫는 요즘이다.
그리고 나도 조금 더 지저분한 흙탕물에서 구를 용기가 필요할 것 같다.
