이제 막 관리자 딱지를 붙인 개발자 혹은, 침몰중인 프로젝트에서 도움의 손길을 뻗고 있는 관리자들에게 도움을 주기위한 책이다.
팀장에게 가장 중요한 덕목은 무엇일까? 좋은 관리자가 되기 위해 필요한 것은? 한번도 팀장 혹은 관리자가되어있는 내 모습을 상상해본적이 없었고, 그렇기에 한번도 가져본적 없는 질문들이다. 하지만 이러한 질문에 대한 해답이, 아니 정확히는 그러한 해답을 찾는 과정이 팀원인 내가 팀을 다양한 각도로 바라볼 수 있는 기회를 제공한다고 생각한다. 팀장으로써 그리고 팀원으로써 우리는 프로젝트를 무사히 성공적으로 끝마쳐야 하기 때문이다.
책임감 분산이라는 단어가 등장하는데, 이는 문제가 닥칠 경우 그 문제에 관여된 사람이 많을수록 개개인이 갖게 되는 책임감은 그에 비례하여 감소한다는 것이다. 이를 팀에게 적용해보면, 프로젝트에 문제가 발생 하여도 그 이슈에 대한 할당이 나에게 오지 않으면 다들 큰 책임감을 느끼지 않고, 할당 받은 팀원만(혹은 팀장만)이 큰 부담과 책임감이라는 무게에 눌릴 것이다. 이 주제에 크게 공감되었던 것은, 나 역시도 프로젝트를 진행 하면서, 정작 내가 할당받게될 이슈가 아닌 것에 대해서는 남의 일인냥 방관하는 태도를 갖었던 경험을 해보았기 때문이다.
어떠한 문제가 발생하면, 그에 대한 원인이 있기 마련이다. 문제의 원인을 해결하지 않고 눈앞의 문제를 덮어 버리는대에만 급급해버리면, 지금 당장은 넘어갈 수 있지만 언젠가는 덮을 수 없는 큰 문제로 다가 오게 된다. 코딩에 비유하면, 초기에 잡을 수 있었던 버그를 더욱 키워, 덕지 덕지 반창고만 붙여놓은 읽을 수 없고 크기만 비대해진 코드를 만든것과 같을 것이다.
관리자가 아닌, 팀원인 내가 프로젝트를 성공적으로 끝내기 위해 할 수 있는 일은 무서일까? 그건 아마 팀의 문제를 팀장에게만 전가하는 것이 아닌, 팀원으로써 함께 고민하며 책임을 나누어 갖고 상대가 전하려는 말의 의도를 파악하며 문제의 본질을 꿰뚫어 보기 위한 노력일 것이다.
아래는 이책의 핵심 내용들에 대한 요약이다.
체계적으로 관리받을 수 없고, 프로젝트 관리의 결과가 관리자에 따라 달라지는 것을 보면, 프로젝트 관리는 일종의 기술(Art)이라고 표현 한다.
눈에 보이는 문제가, 진짜 문제가 아닌 경우가 많다. 근본적인 문제를 해결하지 않으면, 또 다른 문제가 발생한다.
책임감을 팀원수 만큼 나누어 갖는 책임감 분산이란, 문제를 나만의것 혹은 다른 팀원만의 것으로 보는 것에서 부터 나온다. 이를 해결하기 위해서는 문제를 공동의 것으로 만들어야 한다. 그 방법은, 팀원이 모두 모인 자리에서 진솔하게 할당된 문제를 이야기 하고, 같이 해결책을 찾는 것이다.
관리자가 문제를 제대로 파악하지 않고, 사람 문제로만 치부해 버리면 적절한 답을 찾을 수 있는 기회를 놓친다.
리팩토링의 가장 큰 이점은 통찰력이다. 볼 수 없었던 내부 구조가 보이며, 이런 통찰력 덕분에 더 나은 코드를 작성할 수 있다.
계획하기의 본질은, 불확실한 것을 예측하려는데에 있다.
현재 상황을 낙관적으로 보게 만드는(왜곡해서 보게 만드는) 퍼센트 진척율보다 개발이 끝난 기능 개수로 진척율을 관리하는 것이 팀 전체를 더욱 현실적으로 만든다.
개발 기능을 잘게 나누어 일의 범위 측면에서 불확실성을 최소화하고, 결과를 확인하는 주기를 짧게 가져가서 시간축에 존재하는 불확실성을 줄인다.
팀의 업무에 가시성을 부여해야 한다. 그러기 위한 방법인정보방열기(Information radiator)는 화이트보드나 프로젝트 룸 벽에 스토리카드 등을 붙여 팀원들에게 프로젝트 정보를 전달 한다. 여기에 남은 개발 기능, 매뉴얼 만들기, 내부적인 행정 절차, 고객과 관련된 업무를 모두 포함시켜야 한다. 그리고 일의 우선순위를 고려해 시간 순으로 배열 하며, 업무 예상 완료일과 담당자를 정한다.
사람 사이의 관계는 한번 형성되면 왠만해서 바뀌지 않기 때문에, 처음부터 긍정적인 관계를 형성하는 게 좋다. 반대로 나쁜 관계를 형성했다면 어떻게든 좋은 관계로 바꿔야 한다. 나쁜 관계는 어떻게든 서로에게 악영향을 끼친다.
팀장은 팀원들이 한 말을 성급하게 해석해서는 안된다. 즉, 감정에 휩싸여 팀원이 한 말을 해석하기 전에 정말로 말하려는 것을 파악하려고 부단히 노력해야 한다.
상위 관리자의 의견이라고 무조건 따라야 하는 것은 아니다. 아울러 팀원들의 의견을 무조건 받아들이는 것도 옳지 않다.
스탠드업 미팅은 팀원들이 돌아가며 어제한일과 오늘한일을 이야기 한다. 오늘 할일을 말함으로써 목표 의식을 심게 되고, 문제점을 이야기할 기회를 통해 팀원이 문제를 함께 공유할 수 있다.
팀장은 촉매다!. 팀장이 소프트웨어 개발에 직접 참여하지 않지만, 팀원들이 최고의 성과를 내도록 지원한다.
프로젝트에는 여러개의 작업이 존재하며, 이런 작업들은 선후 관계가 있다. 선후 관계를 연결하여 생긴 작업 경로중 작업시간이 가장 오래 걸리는 것을 핵심 경로라고 한다. 핵심 경로의 길이가 프로젝트 기간이 되기 때문에, 핵심 경로를 관리하는게 중요하다.
관리자는 개발을 해야 할까?? 이에 대한 답은 존재하지 않으나, 해당 개발 업무가 핵심경로가 아니라면, 관리자가 개발을 해도 된다는게 작가의 생각이다.
협상은 공통의 이익을 찾는 곳에서 시작한다. 그러려면 상대방이 원하는 것이 무엇인지 파악해야 한다.
리더십은 팀장의 과거를 반영하는 거울이다. 목표를 향해 달려나가는 팀원들의 의지를 이끌어 가는 것은 팀장이 한 약속이다. 팀장이 한 약속이 한두 번 지켜져서 두터운 신뢰가 쌓이면 이 팀에는 열정과 신뢰가 넘친다. 리더십을 이루는 기초는 신뢰이다.
계획보다 중요한 것은 계획하기이다. 계획하기라는 행위로, 우리는 미래에 원하는 곳에 도달하기 위해 현재 부족한 것이 무엇이며, 준비해야 할 것이 어떤 것이며, 어떻게 그 곳에 도달할지 생각하는 기회를 갖는다.
훌륭한 계획하기는 세 가지 힘으로 요약할 수 있다. 바로 Foresight(예지력), Insight(통찰력), Hindsight(회고력)이다.
실수를 인정하지 않는 조직문화는 개인이 저지르는 실수와 시스템에서 일어나는 실수를 구별할 수도 없으며, 조직차원에서 해결할 수도 없다. 즉, 실수를 저지른 누구도 조직에 보고하지 않기 때문이다. 따라서 실수를 책망하기보다 실수가 반복되지 않게, 실수에서 많은 것을 배울 수 있는 분위기를 만들어야 한다.
팀장은 고객의 요구사항을 파악하려는 부지런함과 좋은 결과를 내는 습관을 실천하려는 부지런함이 필요하며, 팀원들이 힘들어 하는 문제점이나 고민을 해결해 주려는 부지런함을 갖추어야 한다.
