업무 프로세스에 대한 고찰

일단 동기부여가 중요하다고 생각하는데 말이지

인트로

내가 스타트업에 처음 취업했을 때도 그렇고, 지금 회사에서도 그렇고, 심지어는 주변의 많은 재직자 분들과 얘기했을 때 많은 사람과 회사들이 업무에 있어 애자일한 스탠스를 채택하고 있음에도 불구하고 제품을 개발하는데 거쳐야 하는 프로세스가 많아 산출물이 나오는 속도가 더디다는 말을 한다.

이번 글은 에센셜 스크럼이라는 책을 통해 애자일을 학습하며, 여러 조직의 업무 프로세스에 대한 경험에 주관을 섞어 작성한 글이다.

---

우리는 어떻게든 일은 할 수 있다.

애자일하게 업무가 진행될 때의 장점은 분명하다. 대부분 스크럼 프레임워크를 사용하니 1) 웬만해서 스프린트 주기(2~4주)마다 산출물이 나오고, 2) 심리적 안정감이 생긴다.

그리고 계획 주도 개발(Plan-driven development) 방식과 달리 3) 가변성과 불확실성을 인정하고 움직이기 때문에, 보다 유연하고 리스크에 강하다는 장점도 있다.

사실 애자일하게 일을 하든 워터폴스럽게 일을 하든, 스크럼을 쓰든, 칸반을 쓰든 어떻게든 일은 할 수 있다. 다만 협업자(특히 개발자)가 내적 동기가 갖춰지지 않고, 조직에서 자기조직화가 더이상 발생하지 않는 상황에서도 억지로 '애자일스럽게' 일하는 것이 과연 효과적인 것인지가 의문이다. 실제로 내가 좋아했던 회사들이 자신들이 운영하는 제품이 시들어가고 있음에도 그 관성에서 벗어나지 못하며 시들어가는 것도 보았고 말이다.

생기를 잃어가는 조직

내가 느낀 조직의 업무 형상들이 시간이 지남에 따라 발생하는 문제는 회사에서는 자기조직화가 발생할 정도의 동기부여가 쉽지 않다는 것이다. 그리고 동기 부여가 되지 않는 구성원의 입장에서는 단순하게 산출물만 뽑아내는 작업을 반복할 뿐이다. 이는 워터폴의 병폐라고 말하는 것이 애자일에서도 동일하게 나타날 수 있다는 생각이 든다.

※ 자기조직화: 외부로부터 자극 등 에너지가 드나들며 개별요소들이 상호작용을 하게 되고, 이를 통해 스스로 새로운 계층의 조직(질서)을 만드는 것

특히 동기부여하는 것이 개발자들에게 더 적용되기 힘든 것 같은데, 1) 조직이 크든 작든 개발자가 자신의 성과를 추적하기 쉽지 않은 것이 첫 번째고, 2) 결국 자신들의 산출물이 회사에서의 보상과 연결되기 때문에 그들은 보수적인 스탠스를 취할 수 밖에 없는 것이 두 번째 이유일 것이다. (마치 OKR과 유사하지 않는가? 조직은 구성원들에게 챌린지한 목표를 세우라고 하지만 결국 평가와 보상에 이를 연결을 시키려 하다 보니 구성원들은 챌린지할 수가 없다.)

했던 것 같은데 이걸 또 하고 또 하고 또 하고 또 하고

결국에 상황에 적응하기 위해 애자일의 본질과는 조금 먼, 워터스크럼 등 이형의 프레임워크가 나오고 있는 것이라고 생각한다.

※ 워터스크럼: 워터폴+스크럼이 합쳐진 말. 업무 프로세스의 일부분에서는 워터폴 형태를 띠면서 개발을 진행할 때는 스크럼 형태를 띠는 형태.

이렇게도 일 해보고 싶다.

한번 해보고 싶은 업무 형상은 1) 제품 관리자, 디자인 마스터(디자인 Assets 관리), 개발 마스터(Code 품질 관리), 프로젝트 관리자 등 각 Master를 두고, 2) 각 구성원들이 솔로 혹은 페어 단위로 기획, 디자인, 개발을 다 쳐내는 구조다. 즉, 스크럼 프레임워크의 골자는 유지하지만 구성원들의 역할을 보다 단순화 시키고, 권한을 더 많이 쥐어주는 것. (강재윤 대표님의 레브잇에서 말하는 Ploblem solver와 결이 비슷할 수도 있다. 다만 그들보다는 역할의 범위가 작고, 할 일이 보다 명확하다고 생각한다.)

업무 프로세스와 역할이 굳어지면 전문성은 보다 깊어질 수 있어도 매너리즘에 빠질 수 있다고 본다. 그리고 IT 제품을 만들기 위해 기획자, 디자인, 개발자의 역할을 나누는 것이 되게 어렵고, 명확한 역할 정리는 되려 그들을 부품화 시킨다고 생각한다.

생각하는 흐름은 아래와 같다.

1. 제품 관리자는 전체적인 제품의 방향을 설계하고 백로그를 그루밍을 리드한다.

  1) 1차 그루밍은 제품 관리자가 직접 진행한다. 1차 그루밍에서는 백로그들의 카테고라이징을 목표로 빠르게 진행한다.

  2)  2차 그루밍은 각 카테고리(서비스 영역)의 담당자들과 함께 진행하며, 증분한 제품의 형상, 목표, 우선순위 등을 산출한다.

  3) 솔로 혹은 페어는 각자 담당하는 서비스 영역(모듈)이 있어야 한다.

2. 솔로 혹은 페어로 빠르게 아이디에이션 하며 분석과 상세 기획을 진행하고, 디자인 마스터가 만든 디자인 Assets으로 화면을 그린 후, 코딩, 노코드, 로우코드를 활용해 1차 산출물까지 내놓는다.

3. 제품 관리자와 함께 기능(제품 증분)의 싱크를 맞춘다.

4. 이후 각 마스터들이 디자인과 코드 품질 등을 체크 -> 피드백 -> 검증 과정을 거쳐 배포한다. 이후 반복.

내가 바라는 기대 효과는 1) 구성원들이 스스로 기획(상상)한 것이 산출물로 나오는 과정을 겪으며 지속적으로 동기부여를 받는 것과 2) 속도감이다.

최초에 개발자가 기획, 디자인을 하던 것이 각 영역이 기술 발전으로 인해 알아야 하는 지식과 일의 양이 많아져 세분화되었다면, 이제는 다시 기술 발전으로 인해 하나로 합쳐지는 게 가능하지 않을까 하는 생각에서 나온 발상이다.  페어 코딩(Pair programming)을 실제로 보면서 든 생각이기도 하고.

피그마, 지라 등 툴의 범용성과 노코드/로우코드의 산출물 퀄리티가 상승하고 있는 세상에서는 꿈꿀 수 있지 않을까?

※ Doing Agile, Being Agile이라는 말이 있다. 애자일을 하지 말고, 애자일하게 되라는 것. 애자일의 본질은 결국 효과적인 개발을 위한 마인드셋이다.

ⓒ 327roy