요구사항을 정리하는데 난항이 있다. 고객쪽 수행팀장과 실무자 사이에 견해가 다른 것이다. 실무자 중에서도 수행팀에 속한 TFT 직원과 아닌 사람 사이에도 이견이 있었다. 부서 책임자의 결정으로 미뤄지자 그야말로 사안은 장기 계류(繫留)가 되었다. 복잡한 머리를 식히러 잠시 서점에 들러 본 책에 눈에 띄는 그림이 있었다.

사용자 삽입 이미지
이미지: Managing Agile Projects (Robert C. Martin Series)에서 발췌

안과장은 프로젝트에 당위성을 부여한 부서장과 면담하는 시간을 가질 수 있었다. 부서장의 이야기는 명쾌했다. 그리고, 그는 확고한 비전을 가진 사람이었고, 이 프로젝트는 그의 비전이 그대로 투영된 산물이었다. 신념을 가진 사람과 함께 있으면 동화되기 마련이다. 안과장은 마음으로 고객이기도 그를 최대한 도와야겠다고 마음 먹었다. 부서장 면담이 있고 얼마후 실무자들과 협의를 하는데 자신이 자꾸만 부서장 입장을 변호하는 듯한 위치에 서게 된 느낌이었다. 퍼뜩 놀라 잠시 말을 거두었다.

머릿속으로 부서장 입장에서 시스템이 만들어지고 난 이후를 떠올려보았다. 그리고, 시스템을 실제로 활용할 실무자 입장에도 서봤다. 그리고 시스템의 당위성을 사내에 알릴 테스크포스의 역할까지... 그럴수록 상황이 점점 더 명확해졌다. 몇 주가 지난 지금 안과장은 이해관계자를 유형화 해서 바라보는 것이 상황을 얼마나 명쾌하게 해주는지 알 수 있었다. 사실 그러한 깨달음은 별다른 것도 아니다. 학창 시절 배웠던 포터의 5 forces가 그러하고, 아키텍처를 논할 때 항상 언급하는 4+1뷰도 동일한 원리의 다른 표현일 뿐이다.

Diagram of Porter's 5 Forces
이미지 출처: http://www.usdoj.gov/atr/public/hearings/single_firm/docs/219395.htm

전략적 목표를 가지고 조직의 포석을 결정할 사람의 이해와 당장 업무 편의성이 필요한 실무자의 입장이 다른 것은 자연스러운 일이다. 또한, 책임소재를 가진 사람 즉, 프로젝트를 만드는데 일조한 부서와 책임은 없이 향후 시스템 사용자가 되는 부서의 입장은 확연하게 다르다.

기사 내용과는 무관하게 흥미로운 이해관계자 모델링(표현 방식)

출처: 홈에버가 노동자들을 쥐어짤 수밖에 없는 이유.
이올린에 북마크하기(0) 이올린에 추천하기(0)

안과장은 프로젝트 일정 계획만 가지고 상당한 시간을 소비했다. 그런데 고치고 또 고쳐도 마음에 쏙 드는 그런 모습은 아니었다. 각 팀이 수행하는 작업들 사이에는 의존성을 가진 부분도 있고, 그렇지 않은 부분도 존재했다. 결국 일을 잘게 쪼개서 배치해보아야 이른바 Critical Path를 찾을 수 있다. 전체적으로 시스템 개발이 가능하도록 작업을 쪼개서 WBS(Work Breakdown Structure)를 작성했다. 그 위에 주요 지점을 찾아 마일스톤으로 표기한다. 팀별로 작성한 WBS의 작업들을 의존성과 우선순위에 따라 재배치하고 여러 차례 검토를 해서 통합 일정을 만들었다. 안과장은 초기 프로젝트 관리의 한 축인 WBS 작성을 마무리하고 뿌듯한 마음에 퇴근을 한다.

다음날 고객사 표준화팀에서 강제하는 PMS(Project Management System) WBS를 등록했다. 안과장이 맡고 있는 프로젝트는 다수의 다른 프로젝트와 함께 진행되고 있기 때문에 고객들은 엑셀이나 MS프로젝트가 아닌, PMS 시스템을 통해 전체적인 진척도를 감독했다. 워낙에 프로젝트를 동시다발적으로 진행하고 있으니 필요한 시스템이다 싶긴 한데 등록하고 살펴보는 과정이 MS프로젝트를 쓰는 것에 비해 불편한 느낌이 드렀다. 주간보고 시점에서 그때까지의 진척도를 입력해주지 않으면 고객이 보는 화면에는 해당 작업이 지연으로 나타났다. 따라서, 주간보고 시점에는 반드시 진척도를 입력해야 했다. 그런데 한 가지 애매한 점이 있었다. 전사 주간보고가 금요일 오전에 있고, 고객들도 준비 시간이 필요하기 때문에 안과장은 목요일 오전에 주간보고를 해야 했다. 진척도는 금요일을 기준으로 작성해야 하는데, PMS에는 수요일 저녁에 입력해둬야 했다.

퇴근 길에 좋은 방법이 없을까 골똘히 생각해봤다. 지난 몇 년간 프로젝트에서도 번번히 동일한 문제가 있었다. 일정 측정 시점과 보고 시점의 불일치는 근본적으로 서로 다른 두 개의 시간에서 비롯한다. 하나는 프로젝트를 측정하는 시간이고, 다른 하나는 조직의 시간이다. 프로젝트는 상대적으로 단기간에 구체적인 목표를 가지고 일어나는 활동이다. 반면에 조직 특히, 기업의 경우는 영속성을 지향한다. 안과장은 내심 '역동성을 가진 프로젝트의 특성을 무시하고, 지나치게 조직의 시간에 맞추다 보면 병목이 생기겠다'는데 생각이 미쳤다. 흥미로운 사실은 하나의 조직만 있지 않다는 것이다. 안과장은 고객에게만 보고하는 것이 아니라 자신의 회사에도 조직차원의 주간 보고를 해야했다. 두 조직의 시계는 또 미묘하게 다르다. 다름을 이해하고 나니, 이들의 불일치를 만회할 수 있는 방책들이 떠올랐다.

점검과 피드백을 위해 구분해놓은 '반복(Iteration)' 이라고 부르는 특정 주기가 지났다. 안과장은 팀이 쏟아부은 시간이 알차게 쓰여졌는지 돌아보는 시간을 가졌다. 그리고 계획과 실천이 얼마나 일치하고 있는지도 살펴봤다. 특정 기능을 개발하는 구체적인 작업에 있어서 계획과 실천은 물론 수치 오차는 컸지만, 상대적인 비율은 많이 틀리지 않았다. 그런데 전체적으로 마치 가정에서 설겆이에 비유할 수 있는 지원 작업들에 들어가는 공수는 WBS에서 대부분 누락하고 있었다. 또한, 갑자기 발생한 위험요소나 불거져나온 기술 이슈에 따른 회의로 예측하지 못한 시간이 많이 쓰였다. 다음 반복에 대한 계획에는 이들을 대비하여 일정 공수를 '지원 작업'과 '회의/의사소통' 시간으로 배정해두었다. 이를 통해 다음 반복 이후부터는 회의시간이 차지하는 비중을 통제할 예정이다. 
이올린에 북마크하기(0) 이올린에 추천하기(0)

'회의 시간을 줄이자'라는 구호는 수도 없이 보고 또 들어왔다. 하지만, 프로젝트에서는 다양한 입장을 갖는 이해관계자가 참여한다. 또한, 대다수는 서로 다른 회사나 부서에 속해 있어, 이해 관계뿐만 아니라 일을 해나가는 방식에 있어서도 많은 차이를 보인다. 한 달 넘게 연속으로 치뤄진 회의가 업무에 부담이 될 즈음, 초보PM 안과장의 머릿속에는 슬슬 회의와 회의 사이의 연관성이 그려지기 시작했다.

생각해보면 무척 오랫동안 회의시간을 효율적으로 쓰려고 노력해왔다. PM 바로 옆에서 보좌하던 시절에 의사결정 없이 진행되는 회의에 지치는 것을 개선하려고, 사회자 역할을 마다하지 않던 과거의 일들이 떠올랐다. 때로는 은근히 권위를 내세우거나 노파심에 이야기가 길어지면, PM에 게면쩍을 정도로 말을 끊기도 했다. 하지만, 그때는 회의의 중요성을 잘 몰랐다고 할 수 있다. 그 이유는 단순하다. 그때 안과장은 아직 PM이 아니었기 때문이다. :)


* 산 피에트로 성당과 광장 전경(이미지 출처:http://webtour.isuperpage.co.kr/travelinfo/choi_travel_con.htm?ForumID=17&iPage=0&ForumType=AA)

생각을 넓혀 보면 회의의 중요성을 쉽게 부각시킬 수 있다. 서로 다른 이해관계자가 광장에 나서서 논박을 펼치는 고대의 민주주의 정치의 장을 떠올려보라. 그리고, 좀 더 현대적인 이미지를 찾는다면, '100분 토론'은 어떤가? 100분 토론의 묘미는 손석희씨의 절묘한 진행이다. 생각이 거기에 미치자 안과장은 최근 준비하고 있는 새로운 유형의 회의에 대해 떠올렸다. 그것은 바로 스프린트(Sprint)라고 하는 2주 정도의 짧은 작업 단계에 대한 마무리 회의인 애자일 회고이다. 애자일 회고는 단순히 이번 단계에 대한 진척 평가를 넘어선다. 팀 구성원의 감성적인 영역까지 포용할 수 있다는 점에서 꽤나 흥미롭다. 하지만, 얼마나 실효성이 있을지는 확신이 없다.  

애자일 회고 - 8점
에스더 더비.다이애나 라센 지음, 김경수 옮김/인사이트

오후에 한 차례 더 회의를 하고 나서 안과장은 뿌듯했다. 스스로 회의를 주제하는 경우에 한해서는 정해진 시간 안에 준비한 안건에 대한 처리를 모두 할 수 있었다. 민생법안 처리와 같이 중요한 이슈가 아닌 탓이기도 하겠지만, 안건에 대해서는 '무엇이든 결정을 내려야 한다'는 지침을 따른 효과가 슬슬 나타났다.

회의록 쓰는 것은 무척이나 번거로운 일 대표주자이기도 하다. 안과장이 PM이 되자마자 오른팔 역할을 하던 서대리가 주로 회의록을 쓴다. 서대리의 회의록 기술 능력은 거의 녹화에 가깝다. 현장의 상황을 거의 정확하게 글로 기술한다. 회의에 참석하지 않은 사람에게는 정말 유용한 정보로 쓰일 수도 있다. 그러나, 회의 빈도가 잦아지자, 서대리가 점차 회의록 자체를 누락했다. 순식간에 무언가 번쩍 안과장 머리를 스쳐갔다. 안과장은 평소 서대리의 훌륭한 회의록이 꺼림직한 느낌을 갖게 하는 이유를 몰랐다.

회의가 난상토론이 되지 않게 사회자 역할을 했던 것처럼, 회의록도 결정사항 중심으로 간결하게 기술하는 것이 좋다. 단정지을 수는 없지만, 이들 사이에 무언가 불가분의 관계가 있다는 것이 안과장의 직감이었다. 안과장이 주제하지 않은 회의에 있어서도 효율성을 보전하려면 회의록 기술에 있어서도 동일한 기조가 자리잡아 팀의 회의 문화를 이뤄야 할 것이다.

안과장은 퇴근 길에 회의에 대해 확실하게 정리해둬야겠다는데 생각이 미쳤다. '회의 아키텍처', '회의 프레임워크' 등과 같은 알듯말듯한 단어들이 머리속을 유영했다. 그러다가 서로 그물망으로 이어진 회의들이 넓혀졌다 좁혀졌다 하는 모습이 연상되었다. 그제서야 개운한 기분이 들었다. 타이트한 일정에 몰렸을 때, 왜 직감적으로 중요한 마일스톤을 기준으로 거꾸로 회의 일정을 결정했는지 이유를 되짚어 알 수 있었다. 그리고, 거시적으로 회의를 기획하는 것과 마찬가지로, 회의 안에서 의사가 소통하도록 조정하는 역할이 얼마나 중요한지 자연스레 반추했다. 또한, 단기간에 특정 사안에 대해 촘촘하게 회의를 배치해 팀의 집중력을 키울 수 있다는 사실도 알게 되었다. 이는 구체적인 사안에 대해 판단이 어려울 때나 복합적인 결정이 필요할 때, 다수의 팀원이 하나로 뭉쳐 일할 수 있게 했다. 집에 돌아와서 잠자리에 들 때, 회의에 대한 생각을 일단락 지을 수 있었다. 회의만 잘 관리해도 프로젝트의 굉장한 무기를 얻는 것이다.
이올린에 북마크하기(0) 이올린에 추천하기(0)

요즘 제가 프로젝트 관리자 역할을 하고 있는 중인지라 실화를 그대로 담을 수는 없고 해서... 고객사(과거 프로젝트 포함)에 대한 정보를 배제하고 가상의 이야기로 경험을 공유하고자 합니다. 이야기의 주인공은 한동안 차용해쓰던 월간마소 출신 고과장 대신 신인(?) 안과장을 채용합니다.

PM이 된지 이제 꼭 한달. 안과장은 'PM이기 전'과 'PM이 된 후'가 이렇게 다를 줄은 몰랐다. 오랫동안 상관을 보좌하며 PM의 오른팔 역할을 했고, 기술적인 지식에 있어서는 PM보다 못하지 않다고 생각했기에 무척이나 의외였다. 게다가 작년에 참여한 프로젝트에서는 짧게나마 공석인 프로젝트 관리자 업무를 대행하기도 했는데, 그때도 지금과 같은 마음 자세는 아니었다. 누군가 안과장에게 PM이 된 느낌을 물어온다면 '너도 해봐야지 알 수 있어'라고 밖에는 답할 수 없을 것 같다.

마음자세만 놓고보면 프로젝트 구성원을 프로젝트 관리자와 프로젝트 관리자가 아닌 사람으로 볼 수 있을지도 모른다. 경영진(Manager)과 근로자(Employee)로 나누어지는 것과 일면 흡사해보이기도 한다.

안과장은 '왜 모든 PM은 야근을 하는가?'라는 오랜 물음에도 답을 찾았다. PM이 되고 나서 얼마 지나지 않아, 퇴근 시간이라는 경계는 의미가 약해졌다. 어디선가 솟아난 책임감은 당장의 할일은 물론이고, 뒷일에 대한 든든한 준비를 하도록 안과장을 이끌었다. 정말이지 거짓말처럼 안과장은 언제라도 일할 준비가 되어 있는 것이다.

하지만, 안과장이 'PM되기 전'의 마음자세를 잊어가고 있다는 사실은 팀원과 서서히 격리됨을 의미하기도 했다. 안과장은 얼마지나지 않아 그 사실을 알게 되었다.

이올린에 북마크하기(0) 이올린에 추천하기(0)

프로젝트 관리자에 대한 이야기 하는데, 어떤 PM의 역량이 머리속에서 방사형 차트로 그려졌다.1 그러다 평가 기준에 생각이 미쳤다. PMBOK 가이드가 곁에 없어, 구글링을 해보니 괜찮은 컬럼이 나왔다. 개발업체 PM이 아니라 발주업체(갑) PM이고, 최고위층의 관점에 국한한 것이긴 하지만, 현장성이 있어 개발업체 PM에 대해서도 충분히 영감을 줄 것 같다. 7가치 척도만 발췌하면 다음과 같다:

① 명확한 프로젝트 정의와 목표설정, ② 성 공적인 구축전략, ③ CEO의 전폭적인 지원, ④ 역량있는 PM의 선택, ⑤ 노련한 SI업체 선정, ⑥ 전사적인 인적/물적 자원 지원, ⑦ 지속적인 변화관리

컬럼 내용 중에 특별히 눈에 띄는 부분이 있어 추가로 발췌해둔다.

내가 문제를 해결하는 방법은 조금 특이하다. 일단 문제가 발생하면 소속부서에 관계없이 관련자들을 모조리 한자리에 불러 모아놓고 그 자리에서 즉시 해결하는 방법이다. 먼저 돌아가면서 관련자들의 생각을 들어본다. 무엇이 문제인지를 근본적으로 파악하면 해답이 쉽게 나온다. 그러나 즉시 해답이 나오지 않는 경우 어떻게 하면 되는지, 또는 어떻게 해주면 되는지를 물어본다. 또 내가 이렇게 결정한다면 무슨 문제가 있는지 의견을 묻고 가능한 한 그 자리에서 결론을 내린다. 나는 이것을 일망타진법이라고 부른다. 모든 이해관계자가 모인 자리에서 결론을 도출하니까 뒷말이 있을 수 없다. 모두가 알고 있으니까 협조가 되지 않을 수 없고 여럿이 결정을 내리니 시행착오도 적다.

프로젝트 관리를 정치라고 하는 이유와 일맥상통한다. '일망타진'하지 않으면 의사소통 혼선으로 업무에 차질이 생기기 쉽상이고, 다단계 회의를 해서 비효율을 불러오기 쉽다.

  1. 안타깝게 척도를 몇 개로 하더라도 점에 가깝게 그려졌다. ㅡㅡ; [본문으로]
이올린에 북마크하기(0) 이올린에 추천하기(0)

쓸만한