템플릿 좀비

프로젝트가 서쪽으로 간 까닭은 책을 읽고서

지식의 저주랄까. 충분한 경험이 없는 상태로 특정 분야의 전문 지식을 배우기만 하면 막상 실무를 할 때 방법론에 집착해서 본질을 망각하고 방법론에 있는 것들을 다 채웠는지에 초점을 맞추게 된다. <프로젝트가 서쪽으로 간 까닭은> 책은 방법론에서 제시한 '템플릿'을 채우는 것에만 관심 있는 사람을 템플릿 좀비라고 부른다. 지난 회사에서 망한 프로젝트를 떠올려보면 (여기서 망함이란 PM으로서 잘하지 못한 케이스를 의미한다) 특정 책이나 아티클에서 배웠던 방법을 실무에 어떻게든 욱여넣으려 했던 것이 큰 실패의 요인이 않았나 생각이 든다.

템플릿 좀비에서 벗어나려면 어떻게 해야 할까. 방법론이 무조건 나쁘다는 것은 아니다. 훌륭한 PM은 방법론의 배경과 용도를 이해하고 상황에 맞게 적절한 방법론을 조합하여 사용한다. 즉, 방법론을 실천하는 것 자체를 목표로 삼는 것이 아닌, 목표를 달성하기 위한 도구로 활용하는 것이 중요하다. 방법론에선 대개 이상적인 상황과 조건을 가정하는 경우가 있기 때문에, 방법론에 숨겨진 전제 조건을 먼저 파악해야 한다. 가령, 흔히 얘기하는 목적조직에서 PM, 디자이너, 개발자가 함께 문제에 대한 솔루션을 도출하는 것을 생각해 보자.

언뜻 보기엔 그럴듯하게 잘 작동된다고 생각하지만 막상 실무에선 PM과 디자이너, 개발자 모두 한 자리에 모여 솔루션을 도출하는 경우는 많지 않다. PM이 먼저 솔루션을 제시하고 디자이너와 개발자가 솔루션에 피드백을 하는 형태로 진행된다. 왜 이런 일이 벌어질까. 이는 조직 문화에서 탑다운으로 솔루션이 나오고 팀에서 바텀업으로 솔루션을 제시할 수 있는 상황이 아니기 때문일 수 있다. 혹은 개발자의 성향이 고객의 문제를 해결하는 것보다 좋은 기술스택, 코드의 재사용성 등에만 관심이 많기에 솔루션을 도출하는데 참여하길 꺼려하는 걸 수도 있다. 또는 PM, 디자이너, 개발자 중 한 사람 이상이 저연차여서 사수의 도움 없이 스스로 일을 하기 어려울 수도 있다. 이런 여러 제약 상황이 있다는 것을 인지하고 방법론에서 말하지 않는 문제들을 어떻게 풀어나갈지를 고민하는 것이 필요하다.