워크플로우: 팀을 바꾸는 쉬운 방법
워크플로우를 도입하며 팀에 변화를 가져왔던 경험을 공유하고자 합니다.
워크플로우는 일하는 방법을 의미할 수도 있고 팀이 약속한 순서일 수도 있다. 누군가에겐 고리타분한 불편함이거나, 속도를 저해하고 효율을 낮추는 방법이라고 생각할 수도 있다.
하지만 나는 워크플로우를 도입하고 팀에 안착시키면서 보다 효율적이고 속도 중심으로 바꾸는 경험을 몇 번 해보고 워크플로우는 팀을 효율적으로 바꾸는 가장 쉬운 방법이라는 인식이 생겼다. (이 또한 편협한 사고일 수 있지만, 지금까지 경험상 그랬다.)
워크플로우를 어떻게 도입했고 이런 경험에서 배웠던 점들을 작성해보고자 한다.
워크플로우는 무엇인가?
본문에 들어가기에 앞서 내가 정의하는 워크플로우는 무엇인가를 먼저 풀고 가고자 한다. 워크플로우는 단순하게 작업을 완료하는 방법이다. RPG 게임을 가져다가 설명해보면 우리가 받은 퀘스트를 클리어하는 방법이다.
1. 퀘스트를 수주받는다.
2. 퀘스트에 대한 목표를 이해하고 수행한다.
3. 퀘스트에 필요한 조건을 달성한다.
4. 퀘스트를 클리어하고 보상을 받는다.
게임에서 퀘스트를 받고 클리어하는 방법을 작성해보았는데, 이것이 내가 생각하는 워크플로우다.
그럼, 팀 내에서 이런 워크플로우는 어떤식으로 동작할까?
1. 작업을 기획하고 작성한다. (백로그 작성 또는 ToDo리스트 작성 등)
2. 작업에 대한 목표를 이해하고 수행한다. (작업 중, In Progress)
3. 작업에 대해 팀에 공유하고 리뷰를 받는다. (리뷰 중, In Review)
4. 작업을 완료한다. {보상은...} (작업 완료, Done)
위에서 설명했던 퀘스트의 순서에서 단순히 퀘스트를 작업으로 바꾸고 문맥에 맞게 글을 조금 수정한 것밖에 없다.
워크플로우는 왜 중요할까?
위의 예시를 보고 너무 당연하다고 생각할 수 있다. "모든 작업은 일을 받고, 수행하고, 완료하지 않는가?"
하지만 생각보다 많은 팀에서 이런 워크플로우를 명확하지 않아 누가 어떤 작업을 어떤 수준으로 작업하고 있는지 파악하기 힘들거나 이제 무엇을 해야하는지 의문을 가진 채 주먹구구식으로 작업을 수행하는 경우가 많다.
워크플로우를 통해 팀원들의 작업 길잡이가 되어주고 무엇을 해야 할지에 대한 고민을 덜어주도록 해야 한다. 내가 수행하고 있는 작업이 어느 정도 진행이 되었으며 어떤 단계인지 명확하게 인지하도록 만들어주어야만 이런 워크플로우는 잘 동작하며 체계적으로 작업을 수행할 수 있다.
개발의 경우 작업 후 리뷰를 통해 팀에 피드백을 받고 지속 가능한 코드베이스를 만들어야 하는데 워크플로우가 명확하지 않다면 누군가를 리뷰를 요청하지만 누군가는 코드베이스에 직접 코드를 커밋할 수도 있다. 또 기획이나 디자인의 경과를 팀과 공유해야하는데 공유없이 작업이 수행되어 처음부터 다시 해야하는 경우가 생길 수 있으며 자신이 이제 무엇을 해야하는지 파악하지 못해 시간을 잘 활용하지 못하는 팀원들도 생길 수 있다.
처음 가보는 길을 어떠한 길잡이 없이 가라고 한다면 우리는 잘 갈 수 있을까? 워크플로우는 이런 처음 가는 길을 잘 헤쳐나 갈 수 있도록 해주는 등대의 역할을 하며, 체계적인 시스템으로 작업자에게 심리적 안정감을 준다. (개인적으로 규율위에 자율이라는 문장이 이 케이스에 딱 맞지 않을까 생각한다.)
이제 예시를 통해 워크플로우가 팀을 바꾸고 효율적으로 변경되었는지 적어보려고 한다.
디거에서 워크플로우를 도입
디거를 운영하면서 항상 잠재적인 불안감이 존재했었다. 지금 내가 잘하고 있는지 우리 팀이 올바르게 나아가고 있는지에 대해서였다. 팀원들 또한 가끔 '우리는 체계가 없다', '일은 열심히 하고 결과도 나오지만 잘하고 있는지 불안하다'와 같은 피드백을 던져주었다.
이런 문제를 해결하기 위해 정통의 방법을 여럿 시도했었다. 엑셀을 이용해 작업리스트를 작성하고 체크하거나 작업이 완료됐을 때 함께 결과를 나누는 등의 방법을 시도해 보았다. 하지만 깔끔하게 문제가 해결됐다는 느낌은 받지 못하고 있었다.
그러던 와중에 지라를 도입하게 되었는데, 초기의 목적은 지라를 통해 스크럼을 도입하고 스프린트를 통해 프로젝트의 속도감을 유지하기 위해서였다.
이 과정에서 자연스럽게 워크플로우를 정의하고 팀 내에 안착하게 되었다. 그러면서 명확한 워크플로우가 주는 안정감을 느끼면서 팀 내에 다양한 긍정적 피드백을 받을 수 있었다. '나의 작업에 대해 명확한 순서가 있어서 이 순서만 따르면 잘 하고 있다는 안정감이 들었습니다.', '워크플로우를 통해 동료가 어떤 작업을 수행하고 있고 얼만큼 왔는지 알 수 있어서 좋았다' 등 일의 순서와 일하는 방법이 정의되고 시스템적으로 도입되자 작업자체의 재미가 증가하고 만족도가 오르는 기대하지 않았던 사이드 이펙트를 경험할 수 있었다.
사실 초기에는 이런 사이드 이펙트를 명확하게 인지하지 못했던 시기도 있지만 시간이 지남에 따라 명확한 워크플로우는 단순히 체계만을 도입하는 게 아닌 다양한 심리적 영향을 미친다는 것을 알 수 있었다.
(사실 상관은 없지만 Flow가 몰입이라는 뜻을 가지고 있는데 몰입 시 심리적 안정감과 편안함을 준다고 한다.)
또한 이런 워크플로우의 도입으로 작업의 투명성이 증진되어 팀간 신뢰도가 오르고 불필요한 소통보다는 프로덕트와 핵심 작업에 대한 소통에 집중할 수 있는 효과도 얻을 수 있었다.
정리
시너지에이아이에서는 더욱 적극적으로 워크플로우를 도입하여 단순히 개발 파트를 넘어 디자인, 기획까지 전방위적으로 워크플로우를 정의하고 도입했다. 이를 통해 모두가 작업의 순서에 대해 추가적인 소통 없이 각자 생산성 높고 프로덕트에 집중된 소통을 통해 보다 효과적으로 작업을 수행할 수 있게 되었다.
(https://studio108.tistory.com/31 해당 링크에서 당시에 도입했던 워크플로우 일부를 확인할 수 있다.)
이런 경험을 통해서 워크플로우를 정의하고 시스템적으로 따르는 것 만으로 팀의 효율을 늘리고 체계적으로 작업하여 같은 소통 시간에 불필요한 논의와 정의를 제외하고 핵심적인 프로덕트 내용과 비즈니스에 대한 고민할 수 있다는 것을 알 수 있었다.
주먹구구식으로 작업을 하고 있어 일을 하고 있어도 불안하고 무엇을 하고 있는지 모르겠다는 생각이 들거나, 언제 어떻게 공유하는 게 좋을지 항상 논의하고 에너지를 소모하고 있다면 명확한 워크플로우를 정의하고 팀 내 도입해 보기를 추천한다.
