[나쁜 팀 문화] 시리즈.. 두 번째..

As Many Tasks As Possible in Parallel (AMTAPP) 는 문장 그대로 가능한 많은 태스크들을 동시에 진행시키는 프로젝트 관리 방식을 말한다. 훌륭한 프로젝트 관리 가이드와는 전면으로 배치되는 정책으로, 특히 Kanban [1][2] 에서는 철저히 경계하고 있다.

이 방식은 현재 내가 속한 팀뿐 아니라 우리 회사의 전형적인 프로젝트 관리 방식이다. 프로젝트가 이렇게 진행될 수 밖에 없는 원인을 몇 년간의 경험을 토대로 유추해 보았다.

1. 프로젝트는 거의 완벽히 블랙 박스에 가려진체 진행된다. 외부인이 실시간으로 과제의 정확한 진행 상태를 확인할 길이 없다. 물론 내부 팀원들에게도 마찬가지다. 프로젝트 투명성에 대한 글은 [3] 를 참조하기 바란다.
2. 프로젝트 생존을 위한 사내 경쟁이 심하다.
   1. 따라서 더 적은 자원으로 더 많은 것을 할 수 있다고 해야지만 프로젝트가 생존할 수 있다. 다른 팀 역시 마찬가지 상황이므로, 서로 자신의 역량 이상으로 최대한 부풀려 홍보한다. 1번 – 프로젝트 투명성 부족 문제로, 과제가 마무리 되거나 팀에서 알아서 중간 결과를 보여주기 전에는 꾸며진 보고 자료만이 프로젝트 평가를 위한 근거의 전부이다. 중간 결과 발표 시에도 잘 되는 시나리오 중심으로만 보여주므로 역시 정확한 상황은 알 수 없다.
   2. ‘나중에 할 것이다’ 보다는 ‘이미 진행 중이다’ 가 더 그럴싸하게 들린다.
3. Big bang 릴리즈 방식을 취한다. Incremental release (iterative development) 에 대한 경험과 인식이 부족하다. 충분히 안정화된 제품은 릴리즈 이전에는 결코 접해볼 수 없다. 오히려 패치 없이도 쓸만한 릴리즈를 하는 것 자체가 희귀한 경험에 해당한다.
4. 소프트웨어 프로젝트의 납기 지연은 당연한 것이라 받아들이다. 2-1 역량 이상으로 부풀려 이야기하기의 좋은 방어책이 된다. 납기를 중요시 하지만 납기에 늦었다 해서 프로젝트가 당장 부러지는 일은 드물다. 그간 투자한 것도 있으니 계속해서 가능성을 보여주기만 하면 프로젝트는 생존할 수 있다.
5. 메니저들은 보통 개발 실무를 하지 않는다. 실제 일할 사람 수가 줄어드는 효과를 내는데.. 우리팀의 경우 약 1/5 정도가 개발 실무를 하지 않고 있는 것으로 보인다.

그 외에도 나열하면 끝이 없겠으나.. 간략히 두 가지로 요약해보면.. 역량 이상의 일을 따냈고, 그래도 다 하고 있음을 강조해야 해야 한다. 결과적으로, 일할 사람 수보다 당장 해야할 태스크 수가 더 많은 상황에 처한다. 하나의 태스크에 둘 이상이 달라붙는 것은 사치스러운 짓이다.

그럼 AMTAPP 방식의 폐단은 무엇일까?

가장 큰 문제로 개발자 간의 의사소통이 단절을 뽑겠다. 내가 하는 일과 옆의 팀원이 하는 일은 관계가 거의 없다. 풀어야할 문제가 다르고 서로 코드를 봐줄 일도 없다. 어려움에 봉착해도 상의할 사람도 없고, 일부러건 몰라서건 대충 만들어 놓아도 당작 동작만 하면 아무도 알지 못한다. 겉으로 잘 드러나지 않는 품질이야 어떻든, 동작만 하면 관리자는 만족해한다. 또한 노하우가 공유되지 않아, 못하는 사람은 계속 못하고, 잘하는 사람의 발전도 더디다.

다음으로는 집중력 저하를 들겠다. 소프트웨어는 순전히 개발자의 사고에 의해 만들어지는지라, 소프트웨어 개발직은 다른 무엇과 비교해서도 고도의 집중력을 가장 요하는  직업 중 하나이다. 불행히도 신은 사람의 두뇌를 멀티 태스킹용으로 설계하지 않았다. 동시에 두 가지 이상을 생각하는 것은 어림도 없고, 심지어 하나 하나 번갈아 처리하는 능력 역시 상당히 떨어진다. 일을 바꿔 집중력 끌어 올리기까지는 수분에서 십수분 이상이 필요하다 – 정확한 수치를 Peopleware [4] 에서 본 듯 하나, 지금은찾아보기  귀찮다

하이라이트는 다른 사람들의 태스크를 만들어내는 태스크를 할당받은 사람들이다. 이들이 일을 열심히 할 수록 다른 팀원들 수십명의 일거리가 눈더미 처럼 불어나 버린다. 코딩하고 결함 잡기도 벅찬 와중에, 문서 고쳐라, 새로운 툴체인 적용해라, 디렉토리 구조 바꿔라, 여기 새 이디엄이 있으니 적용해라, 방금 나온 따끈따끈한 바이너리 당장 테스트해서 보고해라, 보고용 자료 좀 준비해와라, 이것 보고 커맨트 좀 달라 등등 수많은 요청이 쏟아진다. 프로젝트를 이런 식으로 이끌면서 품질은 개발자의 자존심이니 하는 이야기가 나오면 울컥하지 않을 수 없다.

---

References

1. Kanban (wikipedia)
2. One day in Kanban land
3. 프로젝트 투명성
4. Peopleware by Tom DeMarco and Timothy Lister

아름프로님의 블로그 (Click Here) 를 통해 알게되었는데.. 원본 링크는 여기 (Click Here).

Kanban (Click Here) 에 대한 설명이지만, 평소 agile/scrum 등에 관심이 있었던 사람이면 누구나 쉽게 이해할 수 있을 것이다. Kanban 에 의해 추가된 것은 아래 taskboard 의 각 칼럼에 있는 숫자들인데.. 이는 각 칼럼에 동시에 올 수 있는 최대 task 수를 의미한다. 예를 들어, Selected 에는 최대 2개까지 옮겨 놓을 수 있고, 동시 개발이 허용되는 최대 task 수도 역시 2, Deploy 검수는 1개씩만 허용된다. 이 숫자는 경험에 기반해 최적화가 가능하며, 마지막 그림에 보면 Develop 최대 개수를 3으로 늘렸음을 알 수 있다.