기본이 튼튼해야 높이 쌓을 수 있습니다.

기본이 중요합니다.

 저는 어렸을 때, 검도를 배웠고 사회인이 되면서 다시 검도를 시작했습니다. 10년이 넘는 기간 동안 하나의 운동을 배우는 걸 지속했고 어느덧 소위 웬만한 분들 보다는 잘하는 사람의 단계에 접어든 것 같습니다. 그런데 검도에 대한 깊이가 높아질수록 체감한 것은 기본이 중요하다였습니다.

 아무리 현란한 기술을 사용하고 힘을 늘리거나 속도를 빠르게 높이기 위해 용을 써봐도 결국 중요한 것은 제일 기본이 되는 동작들이었습니다. 실제로도 많은 고단자 분들은 아무리 경기에서 우승을 많이 하는 사람이라고 하더라도 검도의 기본을 얼마나 잘하고 있느냐에 따라 더 높은 경지로 갈 수 있고 없고 가 판가름된다고 말씀하시곤 했습니다. 그리고 지금은 그 의미를 어느 정도 이해해가고 있는 중입니다.

  그렇게 이해를 하다 보니 모든 업이 다 그런 것이 아닐까 하는 생각이 들었습니다. 지금 제가 하고 있는 프로젝트 관리 업무도 말입니다.

 저는 10년 동안 개발자로 일을 하다가 업무를 전향했습니다. 내가 더 하고 싶은 일을 하자라는 생각으로 바꾼 일이었지만 실제 관리 업무를 맡아서 수행할 때는 정말 많은 것들을 알아야 했었습니다.

 개발할 때 내 작업을 관리하기 위한 Jira는 프로젝트를 관리하고 추적하기 위한 용도로 바뀌었고 소프트웨어 요구사항 명세서(SRS, Software Requirement Specification)를 대신해 마켓 요구사항 문서(MRD, Market Requirement Document)나 상품 요구사항 문서(Product Requirement Document), 인수조건 문서(AC, Acceptance Criteria)등을 알아야 했고 소프트웨어 개발 수명 주기(SDLC, Software Development Life Cycle)보다 제품 개발 수명 주기(PD Life Cycle)를 이해해야 했습니다.

 애자일도 과거에 알던 간단한 이해보다 더 깊은 이해를 해야 했었고 단순하게만 알고 있던 스크럼이나 칸반, 스프린트 등도 그 의미를 이해하며 어떻게 해야 작업 능률을 올릴 수 있는지를 겪어가며 배워갔습니다.

 배워야 할 것은 너무도 많았고 프로젝트 관리에 대한 경험은 너무 부족했습니다. 그래서 많이 어려웠고 행여 저의 부족함에 다른 사람들이 실망하거나 불편을 겪고 있는 것은 아닐지 걱정도 많이 했습니다. 그래서 더 많이 배우고 알아야 한다고 생각했고 남들보다 더 노력해야겠다고 생각했습니다.

 그런데 이렇게 겪어가면서 드는 계속 드는 생각은 프로젝트 관리를 왜 해야 하고 잘하기 위해 필요한 것은 무엇일까라는 생각이었습니다. 검도도 결국 기본을 잘해야 더 높은 경지로 갈 수 있는 것처럼 이 업도 제일 기초가 되는 부분을 신경 써야 이루려고 하는 걸 완성시킬 수 있는 게 아닐까라는 생각이 들었습니다. 아무리 최신 도구를 사용하거나 효과가 좋은 애자일 방법론을 적용한다고 하더라도 기본이 되어 있지 않다면 이룰 수 없기 때문입니다.

 프로젝트 관리에 대한 정의를 살펴보면 프로젝트를 성공적으로 완료하기 위해 계획을 세우고 실행하고, 모니터링을 하는 등의 완성을 목표로 움직이는 활동이라고 말합니다. 저는 이 정의에서 제일 중요한 부분은 '성공적으로 완료'라는 부분이라고 생각합니다. 다시 말해 스크럼, 칸반 등으로 업무를 추적하거나 여러 문서를 작성하고 그걸 기반으로 일을 한다고 하더라도 성공적인 완료를 시키기 위해 무엇이 필요한지를 봐야 하는 것이 중요하다는 말입니다.

 어떤 프로젝트의 경우는 빠르게 나가는 일자가 중요할 수 있습니다. 또 어떤 프로젝트의 경우는 완벽한 제품성을 보여줘야 하는 게 중요할 수 있습니다. 어떤 프로젝트는 다양한 기능을 보여줘야 하는 게 우선이 될 수 있고 어떤 프로젝트는 긴 호흡으로 단계별 피드백을 받으며 만들어야 하는 것도 있습니다. 결국 각 프로젝트에게 성공적이기 위해 제일 유리한 방법이 무엇인지를 알아야 하고 그것을 실현시킬 수 있는 방법을 찾아가는 형태로 진행되어야 효과적인 관리가 이루어질 수 있다는 게 저의 생각입니다.

  그리고 그 길을 가기 위해 필요한 것은 함께 프로젝트를 진행하는 팀원입니다. 우리가 어떤 프로젝트가 진행이 되지 않는다고 했을 때, 그 문제의 대부분은 사람과의 문제입니다. 제품 요구사항을 이해하지 못했거나 진행상황이 확인이 되지 않고 서로가 서로의 정보를 드러내지 않는 현상, 저는 이 모든 것들이 우리가 무언가 없는 것이 문제가 아닌 사람과 사람 간의 문제라고 생각합니다. 그래서 팀원 간의 대화가 너무나도 잘 이루어진다면 문서를 만들어 대화하거나 스프린트 단위로 공유하며 일을 하는 것들이 부차적이라는 생각을 합니다. 하면 더 좋을 수 있겠지만 오히려 개개인에게 부담을 준다는 관점도 있기 때문입니다.

 사람들은 프로젝트 관리를 효율적으로 하기 위해서는 어떤 방법론을 적용하거나 어떤 프로세스를 적용해야 그 일을 더 잘 처리할 수 있다고 말합니다. 하지만 저는 그 적용에 앞서 조직이 어떻게 일을 하는지를 확인하고 그에 맞는 방법을 사용해야 하는 게 최우선이라고 생각합니다. 아무리 프로젝트 관리를 잘하는 사람이라고 해도 새로운 프로젝트 앞에서는 새로 시작하는 사람일 테고 새로운 사람들과 함께 할 때는 과거에 잘 적용되던 것도 아예 작용하지 못할 수 있기 때문입니다. 중요한 것은 서로가 서로의 정보를 잘 확인하고 전체를 이해하는 것인데 이미 그 활동이 잘 이루어지고 있다면 무언가를 더 넣는 것은 시너지가 아닌 반대의 효과를 불러일으킬 수도 있기 때문입니다.

 목적과 팀원, 저는 이 두 가지를 기본이라고 생각하고 있고 프로젝트 관리자는 이 기본을 더 바라봐야 한다고 생각합니다. 그리고 이 기본을 위해 무엇이 필요할지를 생각해야 더 효율적인 관리를 할 수 있다고 봅니다.

---

 내가 무언가를 더 잘하고 싶다면 그 기초가 무엇인지를 알고 그 기초를 잘할 수 있도록 더 많이 연습하고 또 연습해야 합니다. 검도가 그런 것처럼 프로젝트 관리도 제일 기본이 되는 성공적인 완료의 기준이 무엇인지,  함께 일하는 사람들은 어떤지를 알아놔야 한다고 생각합니다. 그리고 그 기본을 알았다면 그 기본을 잘할 수 있는 방법을 많이 생각하고 고민해야 합니다. 새로운 애자일 방법론을 적용한다거나 새로운 프로세스를 적용해 보는 것은 그 이후로 생각해 주세요.

 그래야 할 이유는 매우 간단합니다. 내가 더 잘하기 위해서입니다.