IT/모바일
제공: 한빛미디어 네트워크 기사
저자: 스콧 버쿤 / 박재호, 이해영 역
출처: The Art of Project Management : 마음을 움직이는 프로젝트 관리 Chapter 13.
프로젝트 관리와 관련한 한 가지 미신을 꼽으라면, 어떤 사람은 일을 잘하는 능력이 타고난 반면 어떤 사람은 그렇지 못하다는 편견입니다. 다른 프로젝트 관리자와 이야기하는 도중에 이런 미신이 튀어나올 때마다, 저는 항상 이 능력에 대해 설명을 요청합니다. 다시 말해 어떻게 이런 능력을 감지해서 분류하고, 가능하다면 다른 사람이 계발할 수 있도록 만드는지 물어봅니다. 토론과 논쟁 끝에, 즉 이 책에서 다루는 여러 주제와 기술 대부분을 고려한 다음에, 대개 우리가 공감하는 유일한 사항은 일을 추진하는 능력으로 귀결됩니다. 자신의 기술과 능력을 다양한 방식으로 조합하고 적용하여 프로젝트를 추진할 수 있는 사람이 있는 반면, 동등하거나 더 뛰어난 개인기를 보유하면서도 그러지 못하는 사람이 있습니다. 일을 추진하는 능력은‘너무나도 다양한 상황에서 촉매제 혹은 책임자가 되는 방법을 아는 능력’과‘촉매제가 되겠다는 용기’의 결합입니다.
어떤 이들은 일을 추진하는 능력을 너무나 중요하게 생각해서, 프로젝트 관리자를 고용할 때 이 능력을 철저하게 따집니다. 다른 자질을 언급하지 않고서는 이 능력을 정확히 정의하지 못하면서도, PM들은 다른 사람에게서 이 능력을 감지하거나 측정할 수 있다고 믿습니다. 예를 들어, 인터뷰에서 면접관은 지원자를 놓고 다음과 같은 질문을 자문해 보아야 합니다.“만일 프로젝트 주요 부분에 문제가 생겼을 경우, 이 친구를 토론이나 논쟁이 벌어지는 방으로 들여보내도 좋은가? 문제가 무엇이든, 상황을 개선하는 방법을 찾는데 기여하리라고 믿어도 좋은가?”몇 차례 인터뷰를 거쳐 답이 아니오라고 나오면, 지원자를 돌려보냅니다. 당면한 상황에 맞게 자신의 지식과 기술을 적용하여 앞으로 나가는 길을 찾아낼 정도로 기민하거나 유연하지 못하다면, 프로젝트에서 살아남기 어려우며, 하물며 성장하기는 더욱 어렵기 때문입니다. 이 장에서는 이런 능력과 더불어, 이런 능력에 관련된 기술과 전술을 다룹니다.
1. 우선순위따라 일하기
PM으로서 저는 목록을 정렬하느라 상당한 시간을 보냅니다. 정렬한 목록이란 중요도 순서로 나열한 열에 불과합니다. 남들은 제가 많은 기술과 지식을 보유하고 있다고 생각하지만, 실제로 제가 하는 일은 목록 정렬뿐입니다. 요구사항, 기능, 버그 등 해야 할 일은 무엇이든 끌어 모아 프로젝트에서 중요한 순서대로 정렬합니다. 여러 시간이나 여러 날에 걸쳐 이 목록을 다듬고 고치고, 새로운 아이디어와
정보를 추가하고, 다른 사람과 토론하고 논쟁을 벌이며, 항상 목록에 허점이 없는지 확인합니다. 그런 다음 목록이 제 모습을 갖추면, 최대한 정해진 순서로 목록을 따르도록 팀을 이끌고 유도합니다. 때로는 하루 동안 내 자신의 일정을 담은 목록일 경우도 있고, 때로는 팀 전체가 여러 주나 여러 달에 걸쳐 해야 할 일을 담은 목록일 경우도 있습니다. 하지만 어느 경우든 절차와 효과는 동일합니다.
제가 목록에 상당한 시간을 투자하는 이유는, 분명한 우선순위가 프로젝트 진행에 근간이 되기 때문입니다. 일을 추진하려면, 더 중요한 일과 덜 중요한 일을 가려내는 명확한 감이 있어서, 이러한 감을 팀 내에서 일어나는 모든 의사소통에 적용해야 합니다. 이러한 우선순위는 모든 전자 편지, 질문, 회의에 반영되어야 합니다. 모든 프로그래머와 테스터는 성공 가능성이 가장 높은 일에 힘을 쏟아야만
합니다. 누군가는 성공 가능성이 가장 높은 일이 무엇인지 파악하고 이 방향으로 팀을 이끄는 임무를 맡아야 합니다.
프로젝트를 지연시키고 많은 시간을 낭비하게 만드는 요인은 목표나 업무 진행순서에 대한 혼동입니다. A라는 사람은 속력 증가에 우선순위를 두고 B라는 사람은 안정화에 우선순위를 두는 상황에서 수많은 오해와 과실이 생겨납니다. 프로그래머, 테스터, 마케터, 팀 전체에서도 마찬가지입니다. 이런 충돌을 피할 수만 있다면, 실제 프로젝트 목표로 향해가는 과정에 더 많은 시간을 투자할 수 있습니다.
이는 우선순위를 놓고 논쟁을 벌여서는 안 된다라는 이야기가 아닙니다. 논쟁을 벌여야 마땅합니다. 하지만 어떤 계획 수립 절차를 사용하든, 논쟁은 계획 수립 초반에 이루어져야 합니다. 개발 단계에서 동일한 논쟁이 계속 불거져 나온다면, 사람들이 결정을 제대로 납득하지 못했거나 결정에 깔린 논리를 잊어버렸다는 뜻이므로, 결정을 내리게 된 이유를 상기시켜야 합니다. 논쟁을 받아들이되, 계획을 수립한 이후에 우선순위를 재고해야 할 만큼 변경된 사항이 있는지 여부부터 먼저 질문하십시오. 별다른 변경 사항이 없다면,(경쟁사 동향, 새로운 그룹 임무, 자원 증감, 새로운 주요 문제점) 결정 사항을 고수하십시오.
어느 일이 어느 일보다 더 중요하다고 동의한 내용을 누구나 볼 수 있도록 우선순위 목록을 벽에다 게시해 둔다면, 이런 논쟁은 금방 끝나거나 아예 벌어지지도 않을 겁니다. 우선순위를 매긴 목록을 통해, 모든 사람들은 결정을 내리게 된 논리체계를 공유하게 됩니다. 목표가 뚜렷하고 이해하기 쉽다면, 목표를 해독할 필요성과 노력을 낭비할 가능성이 줄어듭니다.
그래서 일이 잘 안 풀리고 사람들이 중요한 일에 집중하지 못하면, 저는 이를 제 잘못이라고 여깁니다. 제가 우선순위를 제대로 매기지 못했거나, 이런 우선순위를 효과적으로 전달하지 못했거나, 정해놓은 우선순위를 지키지 못했기 때문입니다. 이런 상황에서는 우선순위 목록에 따라 우선순위를 지키면서 작업하는 방식이 무엇보다 중요합니다.
일반적인 우선순위 목록
항상 우선순위를 매기고 정해놓은 순서대로 작업하면 조정과 변경이 쉬워집니다. 기적적으로 일정에서 시간이나 자원의 여유가 생겼다면, 다음으로 작업할 가장 중요한 항목이 바로 정해집니다. 유사하게, 일정을 줄여야 한다면, 작업을 중지해야 할 가장 덜 중요한 항목이 무엇인지 모두가 압니다. 이런 작업 방식은 매우 중요합니다. 왜냐하면 어떤 상황에서든 가장 중요한 작업을 끝낼 수 있으며, 동시
에 커다란 노력이나 사기 저하 없이도 궤도를 재빨리 수정할 수 있기 때문입니다. 또한 우선순위를 정하는 과정에서 저지르는 실수도 상대적입니다. 작업 항목 10번이 작업 항목 9번보다 더 중요하다는 사실이 밝혀졌더라도 별거 아니지 않겠습니까? 전체 목록이 우선순위에 따라 정렬되어 있으므로, 치명적인 실수를 저지르기 어렵습니다. 게다가 명확한 우선순위를 두고 팀을 여기에 집중시키다 보면, 작업항목 10번에 필요한 시간을 확보하게 될지도 모릅니다.
대다수 프로젝트에서 가장 중요하고도 가장 전형적인 우선순위 목록은 프로젝트 목표, 기능, 작업 항목의 우선순위를 매긴 목록입니다.(그림 13-1 참조) 프로젝트 목표는 일반적으로 비전 문서의 일부이거나,(4장 참조) 비전 문서에서 유래합니다. 기능 목록과 작업 항목 목록은 설계 과정의 산물입니다.(5, 6, 7장 참조) 각 목록은 바로 전 목록에서 우선순위를 상속 받으므로, 우선순위가 분명한 단계까지 거슬러 올라간 후 의심스러운 단계로 내려와서 우선순위를 다시 적용함으로써 분쟁을 하나씩 풀
어갈 수 있습니다. 비록 이 방법으로 모든 논쟁을 해결하지는 못하겠지만, 진짜 중요한 사안이 무엇인지는 아는 상태에서 결정을 내리게 됩니다.
[그림 13-1] 가장 중요한 우선순위 목록 세 가지-중요도 순으로 나열함.
우선순위 목록이 유용한 또 다른 주요 부분에는 버그, 고객 제안, 직원 보너스, 팀 예산 등이 있습니다. 이런 항목 역시 모두 비슷한 방식으로 관리합니다. 즉, 프로젝트나 조직의 성공에 기여할 가능성이 높은 순서로 정렬합니다.(예를 들어, 버그 추적용으로) 사용 중인 도구가 얼마나 복잡한지는 상관이 없습니다. 그저 항목에 우선순위를 매길 뿐이라는 사실을 잊어서는 안됩니다. 사용하는 도구나 프로세스가 우선순위를 매기는 작업이나 순서대로 업무를 수행하는 과정에 도움을 주지 못한다면, 다른 도구나 프로세스를 찾으십시오. 예를 들어, 사람들이 회의실에 모여서 (만일 존재한다면) 어떤 버그를 수정해야 할지 결정하는 버그 선별 행위는 결국 버그의 우선순위 목록을 만들어내는 그룹 절차에 불과합니다. 버그는 그때 그때 개별적인 기준을 적용하기 보다는 그룹으로 분류해야 하며, 이렇게 하는 목적과 효과는 (다른 우선순위화 기법과) 동일합니다.
앞서 소개한 일반적인 우선순위 목록 세 가지를 사용한다면, 이 세 가지 목록이 항상 서로 연관되는지 확인해야 합니다. 모든 엔지니어링 작업 항목은 기능에 연결되어야 하며, 모든 기능은 목표에 연결되어야 합니다. 새로 추가하는 작업 항목은 기능과 목표에 부합해야 합니다. 이런 강제 기능은 무작위 기능 추가를 막아줍니다. VP나 프로그래머가 추가 기능을 슬쩍 끼워넣으려고 한다면, 추가하려는 기능이 프로젝트의 목표에 일치한다고 증명해야 합니다.“부장님, 멋진 기능입니다만, 이 기능이 어느 목표 달성에 도움을 줍니까? 목표를 조정하고 뒷감당을 하든지, 아니면 여기에 힘을 쏟지 말아야 합니다.”의사 결정 시 목표, 기능, 작업 항목이라는 세 단계가 서로 일치해야 한다는 규칙을 팀에게 가르쳐 둔다면, 팀의 집중력을 높이고 시간 낭비를 막을 수 있습니다.
최우선순위와 나머지 전부
일반적으로 우선순위 목록을 두 부분으로 나누는 중요한 선 하나가 있습니다. 위 부분은 우선순위 1, 즉 최우선순위입니다. 즉, 반드시 해야 하며, 안 하면 성공하기 어려운 부분입니다. 아래 부분은 나머지 전부입니다. 우선순위 2와 3도 있지만, 최우선순위와는 완전히 다른 종류라고 이해하십시오. 우선순위 2 항목이 최우선순위로 승급하기는 아주 어렵습니다.
최우선순위 항목은 아주 신중하게 다루어야 합니다. 최대한 작고도 빈틈없는 목록을 만들기 위해 사투를 벌여야 합니다.(이런 원칙은 물론 비전 문서에서 목표 목록을 만들 때도 적용됩니다) 최우선순위 목록에 있는 항목은“달성하지 못하면 우리 모두 사망이다.”를 의미합니다. 있으면 좋겠다 혹은 정말 있었으면 한다라는 항목이 아닙니다. 최우선순위 항목은 가장 직접적이고도 간결하게 프로젝트 목표에 만족하는 방법을 제공합니다. 예를 들어, 자동차를 만든다면 최우선순위 항목은 엔진, 타이어, 변속기, 브레이크, 스티어링 휠, 페달뿐입니다. 우선순위 2는 문, 전면 유리, 에어컨, 라디오가 되는데, 이런 부가 장치가 없어도 자동차를 운전할 수 있기 때문입니다. 우선순위 2 항목이 없어도 자동차의 핵심 기능은 존재하므로, 이런 항목이 빠진 상황에서 자동차를 출시하더라도 여전히 자동차라고 부를 수는 있습니다.
우선순위를 올바로 부여하는 작업은 언제나 매우 어렵습니다. 고객에게 필요 없는 기능이 무엇인지 혹은 어느 기능이 더 중요한지를 놓고 수많은 논쟁과 토론이 벌어집니다. 이런 논쟁과 토론은 바람직합니다. 단지 이 모든 논쟁과 토론은 초기에 벌어져야 합니다. 그런 다음에는 결정한 사항을 밀고 나가야 합니다. 힘든 작업이지만 일단 끝내고 나면, 팀의 의견과 관점 중에서 살아남은 목록을 확보하게 됩니다. 그런 다음에야 목록에 대한 좋은 평판과 지지를 확보해서 앞으로 전진하고 목록을 실행으로 옮길 수 있습니다. 논쟁과 토론으로 목록을 잘 다듬었다면,( “왜 에어컨이 아니라 브레이크를 만들어야 합니까?”처럼) 나중에 사람들이 던질 일반적인 질문이나 도전 중 90%는 대비한 셈이므로, 이런 질문은 재빨리 답해서 해결할 수 있습니다.이미 토론한 내용이므로 타당하지 않은 이유를 알고 있으니까요.
사람들이 뭐라고 하든, 우선순위를 매기는 작업은 항상 지적이라기보다는 감정적이고 심리적입니다. 다이어트로 체중을 줄이거나 허리띠를 졸라매어 돈을 절약하는 행위와 마찬가지로, 원하기는 하지만 필요하지는 않은 뭔가를 제거하려면, 중요한 목표를 향한 수양과 헌신과 집중이 필요합니다.“안정성이 최고야”라고 떠드는 말과 실제로 다른 중요한 사항을 제치고 안정성을 최우선으로 내세우는 행동
은 전혀 별개입니다. 많은 관리자는 (결정) 과정에서 꼬리를 내립니다. 이들은 힘든 결정을 내려야 할 때면 애매한 태도를 취하거나 결정을 지연하고 혹은 결정 내리기를 거부해서, 결과적으로 프로젝트를 실패로 이끕니다. 어려운 결정을 내리지 못하면 발전이 없습니다. 추상적으로, 중요하다는 단어만으로는 아무런 의미가 없습니다. 그러므로 우선순위 목록과 최우선순위를 정해서 리더와 팀 전체가 어려운 결정을 내리고 명확하게 생각하도록 만들어야 합니다.
명확함이야말로 프로젝트에서 일을 추진하는 방식입니다. 모든 사람이 매일 출근할 때는, 자신이 무슨 일을 하는지, 왜 하는지, 자신의 일이 다른 사람의 일과 어떤 관련이 있는지를 명확하게 이해해야 합니다. 팀이 어떤 사항이 다른 사항보다 중요한 이유를 물을때 여기에 대한 명쾌하고 논리적인 이유가 존재해야 합니다. 심지어 상황이 바뀌어서 우선순위를 조정하는 경우에도, 우선순위 목록과 우선순위 매김이라는 근본적인 시스템은 변하지 않습니다.
우선순위는 권력입니다
결코 끝나지 않을 듯한 험악한 논쟁에 참여해본 적이 있습니까? 아마도 엔지니어 절반은 A안을 강하게 밀어붙이고, 나머지 절반은 B안을 강하게 밀어붙였을 겁니다. 하지만 이 순간, 똑똑한 팀 리더가 등장해서 질문을 몇 가지 던지면서 토론을 새로운 방식으로 가르고, 순식간에 모든 사람이 동의하도록 만듭니다. 저는 이런 상황을 많이 겪었습니다. 제가 젊었을 때는 이를 능력 탓으로 돌렸습니다. 다시 말해, 그 관리자나 수석 프로그래머가 다른 사람보다 좀더 똑똑한 탓에 우리가 간과한 사실을 잡아냈기 때문이라고 생각했습니다. 하지만 제가 주의를 좀더 기울이면서, 그리고 나중에 어떻게 그리할 수 있었는지 때때로 물어보기까지 하면서, 비결은 탄탄한 우선순위라는 사실을 깨달았습니다. 뛰어난 관리자는 머리 속에 우선순위 목록을 담고 있으며, 이 목록을 토대로 다른 사람의 토론 방향을 움직이는 능력이 있습니다. 잘 짜여진 우선순위는 권력입니다. 좋은 우선순위는 토론에서 이
차적인 변수를 없애고 당면한 문제에 초점을 맞추고 해결하게 만듭니다.
우선순위를 올바로 잡아두면, 어떤 토론에서든 좀더 중요한 핵심 고려 사항을 위주로 토론하도록 유도하는 질문을 던질 수 있습니다. 이런 유도성 질문은 성공에 대한 모든 사람의 인식을 일깨우며, 가시적으로 세상을 두 가지 관점으로 나눕니다.‘중요한 일’과‘중요하지는 않지만 멋진 일’로 말입니다. 여기에 몇 가지 질문을 예제로 소개합니다.
• 우리가 해결하려는 문제가 무엇이죠?
• 여러 문제가 있다면, 가장 중요한 문제는 무엇이죠?
• 이 문제가 우리 목표와 어떤 관련이 있으며 어떤 영향을 미치죠?
• 우리 목표를 만족하면서도 가장 간단하게 해결하는 방법은 무엇이죠?
별다른 효과를 거두지 못한다 해도, 최소한 대화의 초점을 모두가 동의하는 프로젝트 목표로 되돌릴 수 있습니다. 논쟁이 몇 시간에 걸쳐 계속되었다면, 합의점을 찾는 일이 긍정적인 결론으로 토론을 이끌어갈 최선의 기회입니다.
우선순위에 집중하십시오
프로그래머나 테스터와 이야기를 나누면서 그들의 문제점이나 애로사항을 들을 때마다, 저는 이 친구들이 집중하도록 도와주는 작업이 저의 주된 임무라고 생각합니다. 제 목표는 그들의 업무 보따리에서 부수적인 업무를 제거해서 그들이 일의 순서를 분명히 알게 만드는 겁니다. 특정한 웹 페이지를 구현하거나 데이터베이스 시스템을 명세하는 방법은 1,000가지가 넘지만, 단지 몇 가지만이 목표에 정확히 부합합니다. 이런 사실을 알기에 저는 프로그래머에게 다음으로 시간을 쏟아야 할 업무가 불분명한 경우에는 저를 찾아오라고 독려합니다.
그렇다고 프로그래머나 테스터를 세세하게 관리하지는 않습니다.( “이렇게 해라. 이렇게 하면 안 된다. 아냐, 이런 식으로 해라. 아직 덜 끝냈나? 지금 상태가 어떤가?”) 단지 그들이 필요로 하는 경우 저는 우선순위 결정을 도와주는 사람이라는 사실을 알려줬을 따름입니다. 프로그래머와 테스터는 저처럼 프로젝트를 전반적으로 볼 수 없습니다. 그래서 저는 잠시만이라도 그들이 맡은 업무가 전체 프로젝트에서 어떤 부분을 차지하는지 이해하도록 도와줍니다. 하루 종일 모듈을 디버깅하고 단위 테스트에 매달리는 상황에서 고차원적인 명확함과 재확인과 확신을 얻고 나서 오히려 안심하는 경우가 많았습니다. 우리가 같은 방향을 보고 있음을 확인하기 위해서는 그저 30초짜리 대화로 충분한 경우도 많았습니다.
새로운 정보가 프로젝트에 흘러 들어오면, 저는 (혼자나 아니면 다른 사람과 대화를 통해) 정보를 해석한 후 우리가 신경을 써야 할 사항과 그렇지 않은 사항으로 나누어 우선순위 목록을 만듭니다. 대개는 직전 목록을 갱신해서 새로운 정보에 맞춰 조정합니다. VP가 마음을 바꾸었을 수도 있습니다. 사용편의성 연구를 통해 새로운 문제점을 찾아냈을 수도 있습니다. 경쟁자가 예상치 못했던 변경을 가했을 수도 있습니다. 이런 우선순위는 살아서 숨쉬는 존재이며, 방향이나 목표가 바뀌면 우선순위에도 곧바로 반영해야 합니다.
우선순위를 관리하는 사람은 저였기 때문에, 주요 사안에 팀이 집중해서 실제로 일을 해나가는 환경을 조성할 수 있던 사람도 저였습니다. 어떤 때는 (비전 문서, 그룹사명 문구처럼) 상사가 만들어 놓은 우선순위를 재사용하기도 했습니다. 어떤 때는 모호함이나 예측 못했던 상황에 대응하여 스스로 우선순위를 고안했습니다. 하지만 무엇보다도, 저는 우선순위에 목숨을 걸었습니다. 좋은 프로젝트 관리자에 경의를 표하기 위한 조각상이 있다고 하면, 아마 비명은“명쾌함을 갈망하는 프로그래머, 그대들의 무질서와 혼동과 냉소와 쓰라림으로 뭉친 사안들을 모두 내게로 가져오라.”가 되리라 생각합니다.
저자: 스콧 버쿤 / 박재호, 이해영 역
출처: The Art of Project Management : 마음을 움직이는 프로젝트 관리 Chapter 13.
프로젝트 관리와 관련한 한 가지 미신을 꼽으라면, 어떤 사람은 일을 잘하는 능력이 타고난 반면 어떤 사람은 그렇지 못하다는 편견입니다. 다른 프로젝트 관리자와 이야기하는 도중에 이런 미신이 튀어나올 때마다, 저는 항상 이 능력에 대해 설명을 요청합니다. 다시 말해 어떻게 이런 능력을 감지해서 분류하고, 가능하다면 다른 사람이 계발할 수 있도록 만드는지 물어봅니다. 토론과 논쟁 끝에, 즉 이 책에서 다루는 여러 주제와 기술 대부분을 고려한 다음에, 대개 우리가 공감하는 유일한 사항은 일을 추진하는 능력으로 귀결됩니다. 자신의 기술과 능력을 다양한 방식으로 조합하고 적용하여 프로젝트를 추진할 수 있는 사람이 있는 반면, 동등하거나 더 뛰어난 개인기를 보유하면서도 그러지 못하는 사람이 있습니다. 일을 추진하는 능력은‘너무나도 다양한 상황에서 촉매제 혹은 책임자가 되는 방법을 아는 능력’과‘촉매제가 되겠다는 용기’의 결합입니다.
어떤 이들은 일을 추진하는 능력을 너무나 중요하게 생각해서, 프로젝트 관리자를 고용할 때 이 능력을 철저하게 따집니다. 다른 자질을 언급하지 않고서는 이 능력을 정확히 정의하지 못하면서도, PM들은 다른 사람에게서 이 능력을 감지하거나 측정할 수 있다고 믿습니다. 예를 들어, 인터뷰에서 면접관은 지원자를 놓고 다음과 같은 질문을 자문해 보아야 합니다.“만일 프로젝트 주요 부분에 문제가 생겼을 경우, 이 친구를 토론이나 논쟁이 벌어지는 방으로 들여보내도 좋은가? 문제가 무엇이든, 상황을 개선하는 방법을 찾는데 기여하리라고 믿어도 좋은가?”몇 차례 인터뷰를 거쳐 답이 아니오라고 나오면, 지원자를 돌려보냅니다. 당면한 상황에 맞게 자신의 지식과 기술을 적용하여 앞으로 나가는 길을 찾아낼 정도로 기민하거나 유연하지 못하다면, 프로젝트에서 살아남기 어려우며, 하물며 성장하기는 더욱 어렵기 때문입니다. 이 장에서는 이런 능력과 더불어, 이런 능력에 관련된 기술과 전술을 다룹니다.
1. 우선순위따라 일하기
PM으로서 저는 목록을 정렬하느라 상당한 시간을 보냅니다. 정렬한 목록이란 중요도 순서로 나열한 열에 불과합니다. 남들은 제가 많은 기술과 지식을 보유하고 있다고 생각하지만, 실제로 제가 하는 일은 목록 정렬뿐입니다. 요구사항, 기능, 버그 등 해야 할 일은 무엇이든 끌어 모아 프로젝트에서 중요한 순서대로 정렬합니다. 여러 시간이나 여러 날에 걸쳐 이 목록을 다듬고 고치고, 새로운 아이디어와
정보를 추가하고, 다른 사람과 토론하고 논쟁을 벌이며, 항상 목록에 허점이 없는지 확인합니다. 그런 다음 목록이 제 모습을 갖추면, 최대한 정해진 순서로 목록을 따르도록 팀을 이끌고 유도합니다. 때로는 하루 동안 내 자신의 일정을 담은 목록일 경우도 있고, 때로는 팀 전체가 여러 주나 여러 달에 걸쳐 해야 할 일을 담은 목록일 경우도 있습니다. 하지만 어느 경우든 절차와 효과는 동일합니다.
제가 목록에 상당한 시간을 투자하는 이유는, 분명한 우선순위가 프로젝트 진행에 근간이 되기 때문입니다. 일을 추진하려면, 더 중요한 일과 덜 중요한 일을 가려내는 명확한 감이 있어서, 이러한 감을 팀 내에서 일어나는 모든 의사소통에 적용해야 합니다. 이러한 우선순위는 모든 전자 편지, 질문, 회의에 반영되어야 합니다. 모든 프로그래머와 테스터는 성공 가능성이 가장 높은 일에 힘을 쏟아야만
합니다. 누군가는 성공 가능성이 가장 높은 일이 무엇인지 파악하고 이 방향으로 팀을 이끄는 임무를 맡아야 합니다.
프로젝트를 지연시키고 많은 시간을 낭비하게 만드는 요인은 목표나 업무 진행순서에 대한 혼동입니다. A라는 사람은 속력 증가에 우선순위를 두고 B라는 사람은 안정화에 우선순위를 두는 상황에서 수많은 오해와 과실이 생겨납니다. 프로그래머, 테스터, 마케터, 팀 전체에서도 마찬가지입니다. 이런 충돌을 피할 수만 있다면, 실제 프로젝트 목표로 향해가는 과정에 더 많은 시간을 투자할 수 있습니다.
이는 우선순위를 놓고 논쟁을 벌여서는 안 된다라는 이야기가 아닙니다. 논쟁을 벌여야 마땅합니다. 하지만 어떤 계획 수립 절차를 사용하든, 논쟁은 계획 수립 초반에 이루어져야 합니다. 개발 단계에서 동일한 논쟁이 계속 불거져 나온다면, 사람들이 결정을 제대로 납득하지 못했거나 결정에 깔린 논리를 잊어버렸다는 뜻이므로, 결정을 내리게 된 이유를 상기시켜야 합니다. 논쟁을 받아들이되, 계획을 수립한 이후에 우선순위를 재고해야 할 만큼 변경된 사항이 있는지 여부부터 먼저 질문하십시오. 별다른 변경 사항이 없다면,(경쟁사 동향, 새로운 그룹 임무, 자원 증감, 새로운 주요 문제점) 결정 사항을 고수하십시오.
어느 일이 어느 일보다 더 중요하다고 동의한 내용을 누구나 볼 수 있도록 우선순위 목록을 벽에다 게시해 둔다면, 이런 논쟁은 금방 끝나거나 아예 벌어지지도 않을 겁니다. 우선순위를 매긴 목록을 통해, 모든 사람들은 결정을 내리게 된 논리체계를 공유하게 됩니다. 목표가 뚜렷하고 이해하기 쉽다면, 목표를 해독할 필요성과 노력을 낭비할 가능성이 줄어듭니다.
그래서 일이 잘 안 풀리고 사람들이 중요한 일에 집중하지 못하면, 저는 이를 제 잘못이라고 여깁니다. 제가 우선순위를 제대로 매기지 못했거나, 이런 우선순위를 효과적으로 전달하지 못했거나, 정해놓은 우선순위를 지키지 못했기 때문입니다. 이런 상황에서는 우선순위 목록에 따라 우선순위를 지키면서 작업하는 방식이 무엇보다 중요합니다.
일반적인 우선순위 목록
항상 우선순위를 매기고 정해놓은 순서대로 작업하면 조정과 변경이 쉬워집니다. 기적적으로 일정에서 시간이나 자원의 여유가 생겼다면, 다음으로 작업할 가장 중요한 항목이 바로 정해집니다. 유사하게, 일정을 줄여야 한다면, 작업을 중지해야 할 가장 덜 중요한 항목이 무엇인지 모두가 압니다. 이런 작업 방식은 매우 중요합니다. 왜냐하면 어떤 상황에서든 가장 중요한 작업을 끝낼 수 있으며, 동시
에 커다란 노력이나 사기 저하 없이도 궤도를 재빨리 수정할 수 있기 때문입니다. 또한 우선순위를 정하는 과정에서 저지르는 실수도 상대적입니다. 작업 항목 10번이 작업 항목 9번보다 더 중요하다는 사실이 밝혀졌더라도 별거 아니지 않겠습니까? 전체 목록이 우선순위에 따라 정렬되어 있으므로, 치명적인 실수를 저지르기 어렵습니다. 게다가 명확한 우선순위를 두고 팀을 여기에 집중시키다 보면, 작업항목 10번에 필요한 시간을 확보하게 될지도 모릅니다.
대다수 프로젝트에서 가장 중요하고도 가장 전형적인 우선순위 목록은 프로젝트 목표, 기능, 작업 항목의 우선순위를 매긴 목록입니다.(그림 13-1 참조) 프로젝트 목표는 일반적으로 비전 문서의 일부이거나,(4장 참조) 비전 문서에서 유래합니다. 기능 목록과 작업 항목 목록은 설계 과정의 산물입니다.(5, 6, 7장 참조) 각 목록은 바로 전 목록에서 우선순위를 상속 받으므로, 우선순위가 분명한 단계까지 거슬러 올라간 후 의심스러운 단계로 내려와서 우선순위를 다시 적용함으로써 분쟁을 하나씩 풀
어갈 수 있습니다. 비록 이 방법으로 모든 논쟁을 해결하지는 못하겠지만, 진짜 중요한 사안이 무엇인지는 아는 상태에서 결정을 내리게 됩니다.
[그림 13-1] 가장 중요한 우선순위 목록 세 가지-중요도 순으로 나열함.
우선순위 목록이 유용한 또 다른 주요 부분에는 버그, 고객 제안, 직원 보너스, 팀 예산 등이 있습니다. 이런 항목 역시 모두 비슷한 방식으로 관리합니다. 즉, 프로젝트나 조직의 성공에 기여할 가능성이 높은 순서로 정렬합니다.(예를 들어, 버그 추적용으로) 사용 중인 도구가 얼마나 복잡한지는 상관이 없습니다. 그저 항목에 우선순위를 매길 뿐이라는 사실을 잊어서는 안됩니다. 사용하는 도구나 프로세스가 우선순위를 매기는 작업이나 순서대로 업무를 수행하는 과정에 도움을 주지 못한다면, 다른 도구나 프로세스를 찾으십시오. 예를 들어, 사람들이 회의실에 모여서 (만일 존재한다면) 어떤 버그를 수정해야 할지 결정하는 버그 선별 행위는 결국 버그의 우선순위 목록을 만들어내는 그룹 절차에 불과합니다. 버그는 그때 그때 개별적인 기준을 적용하기 보다는 그룹으로 분류해야 하며, 이렇게 하는 목적과 효과는 (다른 우선순위화 기법과) 동일합니다.
앞서 소개한 일반적인 우선순위 목록 세 가지를 사용한다면, 이 세 가지 목록이 항상 서로 연관되는지 확인해야 합니다. 모든 엔지니어링 작업 항목은 기능에 연결되어야 하며, 모든 기능은 목표에 연결되어야 합니다. 새로 추가하는 작업 항목은 기능과 목표에 부합해야 합니다. 이런 강제 기능은 무작위 기능 추가를 막아줍니다. VP나 프로그래머가 추가 기능을 슬쩍 끼워넣으려고 한다면, 추가하려는 기능이 프로젝트의 목표에 일치한다고 증명해야 합니다.“부장님, 멋진 기능입니다만, 이 기능이 어느 목표 달성에 도움을 줍니까? 목표를 조정하고 뒷감당을 하든지, 아니면 여기에 힘을 쏟지 말아야 합니다.”의사 결정 시 목표, 기능, 작업 항목이라는 세 단계가 서로 일치해야 한다는 규칙을 팀에게 가르쳐 둔다면, 팀의 집중력을 높이고 시간 낭비를 막을 수 있습니다.
최우선순위와 나머지 전부
일반적으로 우선순위 목록을 두 부분으로 나누는 중요한 선 하나가 있습니다. 위 부분은 우선순위 1, 즉 최우선순위입니다. 즉, 반드시 해야 하며, 안 하면 성공하기 어려운 부분입니다. 아래 부분은 나머지 전부입니다. 우선순위 2와 3도 있지만, 최우선순위와는 완전히 다른 종류라고 이해하십시오. 우선순위 2 항목이 최우선순위로 승급하기는 아주 어렵습니다.
최우선순위 항목은 아주 신중하게 다루어야 합니다. 최대한 작고도 빈틈없는 목록을 만들기 위해 사투를 벌여야 합니다.(이런 원칙은 물론 비전 문서에서 목표 목록을 만들 때도 적용됩니다) 최우선순위 목록에 있는 항목은“달성하지 못하면 우리 모두 사망이다.”를 의미합니다. 있으면 좋겠다 혹은 정말 있었으면 한다라는 항목이 아닙니다. 최우선순위 항목은 가장 직접적이고도 간결하게 프로젝트 목표에 만족하는 방법을 제공합니다. 예를 들어, 자동차를 만든다면 최우선순위 항목은 엔진, 타이어, 변속기, 브레이크, 스티어링 휠, 페달뿐입니다. 우선순위 2는 문, 전면 유리, 에어컨, 라디오가 되는데, 이런 부가 장치가 없어도 자동차를 운전할 수 있기 때문입니다. 우선순위 2 항목이 없어도 자동차의 핵심 기능은 존재하므로, 이런 항목이 빠진 상황에서 자동차를 출시하더라도 여전히 자동차라고 부를 수는 있습니다.
우선순위를 올바로 부여하는 작업은 언제나 매우 어렵습니다. 고객에게 필요 없는 기능이 무엇인지 혹은 어느 기능이 더 중요한지를 놓고 수많은 논쟁과 토론이 벌어집니다. 이런 논쟁과 토론은 바람직합니다. 단지 이 모든 논쟁과 토론은 초기에 벌어져야 합니다. 그런 다음에는 결정한 사항을 밀고 나가야 합니다. 힘든 작업이지만 일단 끝내고 나면, 팀의 의견과 관점 중에서 살아남은 목록을 확보하게 됩니다. 그런 다음에야 목록에 대한 좋은 평판과 지지를 확보해서 앞으로 전진하고 목록을 실행으로 옮길 수 있습니다. 논쟁과 토론으로 목록을 잘 다듬었다면,( “왜 에어컨이 아니라 브레이크를 만들어야 합니까?”처럼) 나중에 사람들이 던질 일반적인 질문이나 도전 중 90%는 대비한 셈이므로, 이런 질문은 재빨리 답해서 해결할 수 있습니다.이미 토론한 내용이므로 타당하지 않은 이유를 알고 있으니까요.
사람들이 뭐라고 하든, 우선순위를 매기는 작업은 항상 지적이라기보다는 감정적이고 심리적입니다. 다이어트로 체중을 줄이거나 허리띠를 졸라매어 돈을 절약하는 행위와 마찬가지로, 원하기는 하지만 필요하지는 않은 뭔가를 제거하려면, 중요한 목표를 향한 수양과 헌신과 집중이 필요합니다.“안정성이 최고야”라고 떠드는 말과 실제로 다른 중요한 사항을 제치고 안정성을 최우선으로 내세우는 행동
은 전혀 별개입니다. 많은 관리자는 (결정) 과정에서 꼬리를 내립니다. 이들은 힘든 결정을 내려야 할 때면 애매한 태도를 취하거나 결정을 지연하고 혹은 결정 내리기를 거부해서, 결과적으로 프로젝트를 실패로 이끕니다. 어려운 결정을 내리지 못하면 발전이 없습니다. 추상적으로, 중요하다는 단어만으로는 아무런 의미가 없습니다. 그러므로 우선순위 목록과 최우선순위를 정해서 리더와 팀 전체가 어려운 결정을 내리고 명확하게 생각하도록 만들어야 합니다.
명확함이야말로 프로젝트에서 일을 추진하는 방식입니다. 모든 사람이 매일 출근할 때는, 자신이 무슨 일을 하는지, 왜 하는지, 자신의 일이 다른 사람의 일과 어떤 관련이 있는지를 명확하게 이해해야 합니다. 팀이 어떤 사항이 다른 사항보다 중요한 이유를 물을때 여기에 대한 명쾌하고 논리적인 이유가 존재해야 합니다. 심지어 상황이 바뀌어서 우선순위를 조정하는 경우에도, 우선순위 목록과 우선순위 매김이라는 근본적인 시스템은 변하지 않습니다.
우선순위는 권력입니다
결코 끝나지 않을 듯한 험악한 논쟁에 참여해본 적이 있습니까? 아마도 엔지니어 절반은 A안을 강하게 밀어붙이고, 나머지 절반은 B안을 강하게 밀어붙였을 겁니다. 하지만 이 순간, 똑똑한 팀 리더가 등장해서 질문을 몇 가지 던지면서 토론을 새로운 방식으로 가르고, 순식간에 모든 사람이 동의하도록 만듭니다. 저는 이런 상황을 많이 겪었습니다. 제가 젊었을 때는 이를 능력 탓으로 돌렸습니다. 다시 말해, 그 관리자나 수석 프로그래머가 다른 사람보다 좀더 똑똑한 탓에 우리가 간과한 사실을 잡아냈기 때문이라고 생각했습니다. 하지만 제가 주의를 좀더 기울이면서, 그리고 나중에 어떻게 그리할 수 있었는지 때때로 물어보기까지 하면서, 비결은 탄탄한 우선순위라는 사실을 깨달았습니다. 뛰어난 관리자는 머리 속에 우선순위 목록을 담고 있으며, 이 목록을 토대로 다른 사람의 토론 방향을 움직이는 능력이 있습니다. 잘 짜여진 우선순위는 권력입니다. 좋은 우선순위는 토론에서 이
차적인 변수를 없애고 당면한 문제에 초점을 맞추고 해결하게 만듭니다.
우선순위를 올바로 잡아두면, 어떤 토론에서든 좀더 중요한 핵심 고려 사항을 위주로 토론하도록 유도하는 질문을 던질 수 있습니다. 이런 유도성 질문은 성공에 대한 모든 사람의 인식을 일깨우며, 가시적으로 세상을 두 가지 관점으로 나눕니다.‘중요한 일’과‘중요하지는 않지만 멋진 일’로 말입니다. 여기에 몇 가지 질문을 예제로 소개합니다.
• 우리가 해결하려는 문제가 무엇이죠?
• 여러 문제가 있다면, 가장 중요한 문제는 무엇이죠?
• 이 문제가 우리 목표와 어떤 관련이 있으며 어떤 영향을 미치죠?
• 우리 목표를 만족하면서도 가장 간단하게 해결하는 방법은 무엇이죠?
별다른 효과를 거두지 못한다 해도, 최소한 대화의 초점을 모두가 동의하는 프로젝트 목표로 되돌릴 수 있습니다. 논쟁이 몇 시간에 걸쳐 계속되었다면, 합의점을 찾는 일이 긍정적인 결론으로 토론을 이끌어갈 최선의 기회입니다.
우선순위에 집중하십시오
프로그래머나 테스터와 이야기를 나누면서 그들의 문제점이나 애로사항을 들을 때마다, 저는 이 친구들이 집중하도록 도와주는 작업이 저의 주된 임무라고 생각합니다. 제 목표는 그들의 업무 보따리에서 부수적인 업무를 제거해서 그들이 일의 순서를 분명히 알게 만드는 겁니다. 특정한 웹 페이지를 구현하거나 데이터베이스 시스템을 명세하는 방법은 1,000가지가 넘지만, 단지 몇 가지만이 목표에 정확히 부합합니다. 이런 사실을 알기에 저는 프로그래머에게 다음으로 시간을 쏟아야 할 업무가 불분명한 경우에는 저를 찾아오라고 독려합니다.
그렇다고 프로그래머나 테스터를 세세하게 관리하지는 않습니다.( “이렇게 해라. 이렇게 하면 안 된다. 아냐, 이런 식으로 해라. 아직 덜 끝냈나? 지금 상태가 어떤가?”) 단지 그들이 필요로 하는 경우 저는 우선순위 결정을 도와주는 사람이라는 사실을 알려줬을 따름입니다. 프로그래머와 테스터는 저처럼 프로젝트를 전반적으로 볼 수 없습니다. 그래서 저는 잠시만이라도 그들이 맡은 업무가 전체 프로젝트에서 어떤 부분을 차지하는지 이해하도록 도와줍니다. 하루 종일 모듈을 디버깅하고 단위 테스트에 매달리는 상황에서 고차원적인 명확함과 재확인과 확신을 얻고 나서 오히려 안심하는 경우가 많았습니다. 우리가 같은 방향을 보고 있음을 확인하기 위해서는 그저 30초짜리 대화로 충분한 경우도 많았습니다.
새로운 정보가 프로젝트에 흘러 들어오면, 저는 (혼자나 아니면 다른 사람과 대화를 통해) 정보를 해석한 후 우리가 신경을 써야 할 사항과 그렇지 않은 사항으로 나누어 우선순위 목록을 만듭니다. 대개는 직전 목록을 갱신해서 새로운 정보에 맞춰 조정합니다. VP가 마음을 바꾸었을 수도 있습니다. 사용편의성 연구를 통해 새로운 문제점을 찾아냈을 수도 있습니다. 경쟁자가 예상치 못했던 변경을 가했을 수도 있습니다. 이런 우선순위는 살아서 숨쉬는 존재이며, 방향이나 목표가 바뀌면 우선순위에도 곧바로 반영해야 합니다.
우선순위를 관리하는 사람은 저였기 때문에, 주요 사안에 팀이 집중해서 실제로 일을 해나가는 환경을 조성할 수 있던 사람도 저였습니다. 어떤 때는 (비전 문서, 그룹사명 문구처럼) 상사가 만들어 놓은 우선순위를 재사용하기도 했습니다. 어떤 때는 모호함이나 예측 못했던 상황에 대응하여 스스로 우선순위를 고안했습니다. 하지만 무엇보다도, 저는 우선순위에 목숨을 걸었습니다. 좋은 프로젝트 관리자에 경의를 표하기 위한 조각상이 있다고 하면, 아마 비명은“명쾌함을 갈망하는 프로그래머, 그대들의 무질서와 혼동과 냉소와 쓰라림으로 뭉친 사안들을 모두 내게로 가져오라.”가 되리라 생각합니다.
TAG :
이전 글 : 리눅스에서 사용되는 파일 시스템 소개
최신 콘텐츠