[북리뷰] 프로젝트가 서쪽으로 간 까닭은

 

 

 

이책은 달마대사와는 전혀 관련이 없다. 그러나 책의 겉표지는 확실히, 달마대사로부터 착안했다. 책 표지 만큼이나 내용도 익살스럽고 채치있다. 박수치며 공감하게 만드는 힘이 있다. 프로젝트를 의도치 않은 방향으로 보내버리는 86가지 행동 패턴에 대한 소개를 담고 있는 책이다. 이 책을 다 읽게 되면, PM끼리는 <생선 썩는 내>패턴이라든지, <후보 선수 없음> 패턴을 논하거나 <뉴스세탁>패턴을 논하게 될 것이다. 이런 표현들은 모두 이 책에서 소개되는 내용인데, <생선 썩은 내>는 망할 징조가 보이는 냄새나는 프로젝트를 놓고 하는 이야기이며, <후보 선수 없음>은 프로젝트 인력층이 너무 낮아서, 핵심인력이 빠지면 재앙이 닥치는 현상을 지칭한다. <뉴스세탁>은 개발자의 고충이 위로 올라갈수록 점점 희석되어 ‘불가능’이라고 보고 되었던 부분도, 결국 최종 윗선에 보고 될 때에는 ‘가능’으로 바뀌게 되는 현상을 말한다.

 

 

뉴스세탁 과정

 

 

나는 이 책을 통해 PM의 마인드와 회사 차원으로 공감을 갖게 되었다.

우선 PM의 마인드 부분을 살펴보자면, 첫째는 프로그래머가 영혼을 팔아버리는 행위를 풍자한 대목이다. 개발자라고 불리면서 한 가지 언어에만 집착하여, 그 익숙한 언어만를 요구하는 직장을 찾아 헤매는 사람들이다. 심지어는 유통기한이 지난 언어를 고집하는 개발자들. 그들을 이책은 ‘언어에 영혼을 판 프로그래머’라고 말한다. 마음 한 켠이 찔렸다. 최신 언어들이 쏟아져 나오고 있는 현실에서 더 나은 것을 찾아보려는 것이 아니라, 내가 그어놓은 영역 안에서만 찾으려는 그래서 그 성능이야 어떻든, 구현만 되면 끝이라는 안일한 논리가 내게 있는 것은 아닌가 하는 반성을 하게됐다. 어떤 언어든 한 여름의 연애로 치부하자고 이 책은 말한다. 그리고 주어지는 문제에 대해 “이 문제를 풀기에 적합한 기술은 무엇일까?”를 물어야지, “이 기술로 이 문제를 어떻게 풀까?”라고 생각하면 안된다고 말한다.

 

두번째로 공감이 되었던 부분은 <소비에트 스타일> 패턴이다. 고객의 요구사항에 맞추어 목적한 기능은 수행하지만 그 방식이 조잡하거나 짜증스러운 제품을 일컫는다. 최근에 한 프로젝트를 끝내고 고객으로부터 불편사항을 접수받았을 때, 사전에 그 부분에 대한 개선의 여지를 인식하고 있었는데도 무시하고 진행했던 나를 되돌아 봤다. 저자는 다음과 같이 충고한다. “사용자가 제품을 받아들이려면 기능적인 요구사항 못지 않게 비기능적인 요구사항도 중요하다.” (p.109) 비기능적 요구사항의 수위가 늘 네이버 수준이어서 항상 부담이지만, 팀의 가능한 범위 내에서 할 수 있는 것인데도 묵인하고 넘어가지는 말아야겠다.

 

셋번째 공감은 <프로젝트 매춘부> 패턴이다. 이것은 팀이 감당할 수준을 넘어선 요청까지도 수락하는 관리자를 일컫는다. 이런 관리자는 “비겁하다”고 말한다. 개인적인 비판을 피하려고 팀이 성공하지 못할 상황으로 이끌어가는 꼴이다. 처음부터 “아니오”라고 말할 용이가 없어서 일을 그르친다. 이런 패턴을 방지하려면, 업무에 우선순위를 매기고 진행하도록 유도하라고 조언한다. 늘 기한이 끝나고도 남는 잔여과제가 이런 것으로 생겨나는데, 고객과 정확한 선을 긋는 작업을 PM 이 분명하게 해야하지 않겠나 하는 생각을 해봤다.

 

분명한 선을 긋고, 프로젝트 내/외적인 요소를 분리해야할 필요가 있다.

 

이와 관련하여, 지속적으로 추가되는 요구기능들이 뒤죽박죽 뒤섞이는 <기능스프> 패턴도 유사한데, 이를 피하는 조직의 공통점이 소개되고 있어 인용한다.
1. 프로젝트 목표와 비목표를 최대한 초반에 최대한 분명하게 정의한다.
2. 프로젝트 범위를 선언하고 항상 최신으로 유지한다. 입력 자료와 출력 자료를 명확히 명시한다.
3. 명시된 목표와 무관하고 프로젝트 범위를 벗어나는 요구사항은 단호히 거부한다.
4. 새 요구사항은 변경 제어 절차를 따른다. 변경 제어 절차는 관련 자가 승인했으며, 추적이 가능하고, 프로젝트 목표에 비춰 요구사항을 평가한다. (p.226)

 

지금까지 프로젝트를 수행하는 PM의 입장에서 공감되었던 부분을 살펴봤다. 이제 회사에 대해 공감했던 부분을 말하고 싶다. 사실 이 내용에는 대부분의 기업에 대한 아쉬움이 담겨있어, 자칫 내가 몸담고 있는 회사에 대한 뒷담화로 비춰질 수 있어 조심스러운 부분이기도 하다.

 

공감되었던 것 중의 첫번째는 <아드레날린 중독증> 패턴을 보이는 회사이다. 조직이 미친듯이 바쁘게 움직여야 생산성이 높다라고 믿는다. 그러한 윗선의 편견에 따라, 아랫 사람들은 발바닥에 땀나도록 뛰어다니며 분주한 사무실 분위기를 연출한다.

 

둘째는 지나친 비용절감은 도리어 회사의 경쟁력을 떨어뜨린다는 <몽당연필> 패턴이다. 새로운 연필을 받으려면, 다쓴 몽당연필을 가져오라는 일화에서 나온 패턴이었다. 이러한 과도한 비용절감의 후폭풍은 어떤 것인지 한 번 감상해 보자.

 

- 직원들을 해고하고 남은 동료들에게 모든 업무를 떠넘긴다. 그래서 남은 동료들마저 회사를 떠난다. 결국 업무를 전혀 모르는 값비싼 새 인력을 고용할 처지에 놓인다. - 업무가 과중해서 사람들이 나가 떨어지거나 병가를 내거나 대충 일하거나 불만을 품는다. - 업무 효율을 높이겠다고 사무직을 자른다. 그래서 연봉을 많이 받는 전문가가 연봉을 적게 받는 사무직이 하던 자투리 업무에 시간을 빼앗긴다. - 관리자를 자른다. 그래서 그 밑에서 일하던 직원들이 방향을 잃는다. - 동료가 해고당한 사실에 분개한 나머지 직원들이 회사를 떠난다. (미리 사직을 통보하지도 않는다.) (p.139)

 

 

 

이와 관련하여 비슷한 패턴으로 언급된 <벤>을 말하고 싶다. 매우 유능하고, 열정을 가진 개발자를 일컫는다. 특정인물로 설명하면 훨씬 효과적이어서 저자는 이 사람을 ‘벤’이라고 불렀다. 이런 긍정적인 사람은 관리하기 쉽다. 그러나 관리를 잘못하기가 더 쉽다. “어느 밉상 관리자는 부하 직원이 팀을 떠났을 때 새 인력을 고용하지 않았다. 벤이 일을 좋아하니까 벤에게 일을 몰아주면 되겠다고 생각했다. 관리자는 조금씩 벤에게 일을 떠넘겼고, 업무량이 참지 못할 수준에 이르자, 벤은 일이 싫어져서 팀을 떠났다. 최고 일꾼이 팀을 떠났다는 소리다. 벤보다 관리자가 입은 손해가 훨씬 컸다. 벤은 금방 일자리를 구하지만 관리자는 벤과 같은 인물을 쉽게 구하지 못한다.” (p.233) 회사 경영자 입장에서는 소잃고 외양간 고치는 격이라 아니할 수 없다. 인력에 대한 채용에서 너무 인색함을 드러내면 언제나 이런 상황을 만날 수 있다는 것을 명심해야겠다.

 

셋째는 <전념> 패턴이다. 고성과 개발자를 한 프로젝트에 전념할 수 있도록 두지 않고, 여러 프로젝트에 분산되게 일을 하도록 맡기면, 결국 옮겨다니고 새롭게 마음을 추스르며 일을 하는 데에 소모되는 “맥락 전환 비용”이 발생한다는 것이다. 그래서 저자는 “맥락 전환과 생산성 사이의 관계를 깨닫는 조직은 동시에 여러 프로젝트에 개발자를 투입하지 않음으로써 한 프로젝트에 전념하는 분위기를 조성한다.”(p.240)고 말한다.

 

네번째는 <까먹은 교훈> 패턴이다. 프로젝트를 마치고 시행착오를 기록해 두지 않아, 매번 반복되게 겪는 현상을 말한다. 성공한/실패한 이유를 검토하려 하지 않는다면 발전이 없을 것이다. 저자는 다음과 같이 충고한다. “용감한 회사가 사후분석으로 이익을 얻는다. 그들은 자신들의 접근방식과 프로세스와 조직 구조를 면밀히 검토할 용의가 있으며, 기꺼이 변경할 의사도 있다. 이런 조직은 일하기가 즐겁다. 자신이 변화를 일으킬수 있는 기회는 조직 문화에서 구성원들이 특히 소중하게 여기는 가치다.” (p.348)

 

프로젝트 수행과 관련된 수많은 책 중에서 이 책이 갖고 있는 장점은 당연히 이러한 공감요소에 대한 용어정리가 아닌가 싶다. 탁월하다. 시간이 가도 이 공감의 정서는 없어지지 않을 것이다.

 

밑줄 친 나머지 부분들...

 

회의에서 다른 회의 일정을 잡는다. 실패하는 회의가 모두 이렇게 끝난다. (p.28)

 

지금 몸 담은 조직이 다음 조건을 하나라도 만족한다면 이미 그런 보모가 있을 지도 모르겠다. 1) 약속을 따로 잡지 않아도 상사와 만나기 쉽다. 2) 소소한 잡무에 많은 시간을 뺏기지 않는다. 3) 개방적인 환경이다. 사람들이 자기 생각을 솔직히 털어놓고 서로에게 배운다. 4) 관리자가 교육과 훈련을 필수로 여긴다. 5) 새로운을 아이디어를 토론할 시간이 별도로 마련되어 있다. (p.38)

 

멀리 떨어져 있으면서 신뢰를 주고받기는 어렵다. 뉘앙스, 자신감, 풍자나 빈정, 의도, 신념, 절망감과 무력감, 열의, 거짓을 알아채기도 어렵다. 이런 미묘한 차이를 잡아내지 못한다면 절름발이 의사소통이 이루어진다. 서로 큰 그림은 소통하지만 그로부터 결론을 내리기가 망설여진다. 이런 결점을 안고서 프로젝트를 진행해도 괜찮을까? 물론 괜찮다. 단지 한 곳에서 일하는 만큼 효율적이지 못할 뿐이다. (p.50)

 

약한 팀을 움직이는 동력은 성공하겠다는 열의가 아니라 비난을 피하겠다는 두려움이다. (p..83)

 

기록은 대화가 보존하지 못하는 기억을 보존한다. 결정을 기록하면 결정에 참여하지 않았던 사람과 결정에 참여했으나 구체적인 내용을 잊어버린 사람에게도 결정과정을 전달 할 수 있다. (p.166)

 

시스템을 설계하려면 시스템과 환경을 이어주는 인터페이스를 알아야 한다. 시스템으로 들어가는 입력과 시스템이 내놓는 출력을 알아야 한다. 입력과 출력에 합의하지 못하면 프로젝트는 준비단계를 벗어나지 못한다. 문제 경계를 정하지 못했으니까. 입출력에 합의한 후에야 시스템 기능을 정의할 수 있으니까. (p.189)

프로젝트 관리자에게 가장 중요한 목표는 ‘일정 내에 안전하게 프로젝트 목표에 도달하기’다. 정확한 보고서는 목표를 달성하는 수단에 불과하다. 결코 목표 자체가 아니다. (p.214)

 

요구사항 수집가가 제품이나 서비스를 효과적으로 명세하려면 고객의 업무를 배워야 한다. 하지만 흔히 세 가지 이유로 고객은 자신의 지식을 제작자에게 제대로 전달하지 못한다. 첫째, 고객은 자신의 업무에 너무도 익숙하여 뻔한 사실을 언급하지 않는다. 제작자가 당연한 알리라 가정하는 탓이다. 둘째, 고객들은 의사소통 기술이 부족하다. 그래서 제작자에게 유용할 정보를 선뜻 제공하지 않는다. 셋째, 고객들은 자신이 필요한 내용을 잘 모른다. 직접 보기 전에는 진짜로 무엇이 필요한지 파악하기 어려운 탓이다. (p.275)

 

개발자를 고용할 때는 품질과 혁신이 조직의 성공에 얼마나 중요한 요소인지 자문할 필요가 있다. 최고의 품질과 혁신을 얻으려면 진정으로 뛰어난 개발자가 필요하다. 개발자를 ‘유감스럽지만 어쩔 수 없이 고용할 자원, 인건비가 적을수록 좋은 자원’으로 취급한다면 뛰어난 개발ㅈ를 유치하고 키우고 보유하기 어렵다. (p.291)

이렇듯 시각적인 방법으로 자신이 중요하게 여기는 정보를 부각하고 남들에게 중요하게 봐달라고 요청할 정보를 강조하는 방식으로 팀원들 모두가 피드백을 주고받을 기회를 얻는다. (p.314)