영향 범위를 확인하기
최근 일하면서 가장 많이 생각하는 것들
앞선 두 글에서는 일하면서 나에 대해 알게 된 것들에 대해서 썼는데, 이번에는 일하면서 개인적으로 많은 어려움을 겪었던 부분이자 또 앞으로 계속 생각해야 할 부분에 대해서 좀 써보려고 한다. 글로 적어야 조금이나마 체화가 되는 느낌이라, 조금 더 길게 적어보려고 한다.
계획에 변화가 있다면 영향을 미치는 부분을 확인해야 한다
하나의 결정이 이뤄질 때 혹은 결정이 변경될 때, 또는 무언가가 변경되는 경우에 항상 이로 인해 영향을 받는 부분이 어디인지 확인을 해봐야 한다. 하나의 변화, 결정과 관련한 영향 범위를 확인하지 않는다면 예상하지 못한 문제를 마주할 가능성이 매우 높아진다.
계획이 바뀐다면, 바뀌면서 영향을 받는 계획이나 업무가 무엇인지 확인해야 한다. 예를 들어 우선순위 변경으로 인해 업무 계획을 다시 수정해야 하는 경우가 있다. 만약 11월까지 특정 프로젝트를 끝내기 위해 열심히 달리는 와중, 조직의 우선순위 변화로 인해서 새로운 프로젝트가 들어오고, 새로운 프로젝트를 먼저 수행하고, 진행하던 프로젝트를 미뤄야 할 수 있다. 쉬운 경우에는 기존 프로젝트를 멈추고 새로운 프로젝트를 먼저 진행하면서 프로젝트의 진행 순서를 바꿔버릴 수도 있다.
개인 관점에서는 여러 프로젝트가 동시에 진행되는 관계로 모든 구성원들이 여러 프로젝트의 업무를 맡고 있어서, 모두의 업무 계획이 꼬이는 상황이 발생할 수 있다. 이때 누군가에게 일이 몰릴 수도 있고, 누군가는 반대로 밀리는 작업으로 인해서 제때 업무를 진행할 수 없는 경우도 발생할 수 있다.
또한 프로젝트는 보통 서비스 런칭, 고객사와의 약속, 이벤트 런칭 등의 비즈니스 목표와 연관이 있어서, 프로젝트의 순서나 일정이 변경됨에 따라서 비즈니스 타임라인이 변경되어야 하는 경우가 많다(비즈니스와 연관 없이 조직 내에서 자체적으로 목표를 잡고 진행하는 경우도 있지만). 그래서 프로젝트 계획에 변경이 생기면, 비즈니스 계획에도 변경이 생기고, 반대로 비즈니스 계획에 변경이 생기면 프로젝트 계획에도 변경이 생길 가능성이 높다.
이렇게 계획이 바뀔 때, 계획이 바뀜으로써 파생되는 영향이 어디까지 미치는지, 작게는 구성원들의 업무부터 시작해서, 크고 작은 마일스톤들이 어떻게 바뀌는지, 크게는 비즈니스 계획이나 프로덕트 일정들이 어떻게 바뀌는지 등의 영향 범위를 반드시 확인해야 한다.
사실 이런 영향 범위를 확인하는 구체적인 노하우는 아직 배워가고 있는 중이다. 아직까지는 단순하게 누가 어떤 일을 하고 있고, 또 이 일에 대한 공수가 얼마나 걸리고, 공수 파악이 되지 않는 업무라면 언제쯤 공수 파악이 될지 등을 파악하는 연습을 하고 있다. 많은 사람들의 많은 작업 범위를 파악하는 것은 생각보다도 더 어려운 일이다. 레퍼런스도 거의 찾아볼 수 없는 전에 없던 새로운 일을 진행하는 경우 공수 파악 자체도 어려운 경우가 빈번하고, 여러 프로젝트를 동시에 진행하다 보면 예상치 못한 이슈나 업무가 튀어나오는 것이 다반사다. 특히 이런 경우가 제일 어렵다. 예상치 못한 이슈가 발생했는데, 시간은 얼마 남지 않아서 이에 대한 대안을 찾아야 할 때.
단순히 기능 하나, 요소 하나가 그대로 추가되는 경우는 거의 없다
위에서는 프로젝트와 계획 위주로 변경 사항에 대해서 영향 범위를 확인하는 것의 중요성을 말했다. 프로덕트에서도 똑같다. 하나의 기능 혹은 요소가 추가되면, 그대로 하나만 추가되는 경우는 거의 없다. 프로덕트에 한 가지 요소가 추가되거나, 심지어 기존 존재하던 요소가 위치를 바꾸는 경우에도 이와 관련된 영향 범위를 확인하고, 영향 범위에 대한 부분도 반드시 고려해야 한다.
예를 들어서 아주 간단하게, 상품 판매를 하는데 기존에는 결제 수단이 카드 결제만 있었다가, 간편 결제를 추가했다고 하자. 이 경우 주문 페이지에서 간편 결제를 추가한다고 끝이 아니다. 주문 내역 페이지에서도 간편 결제라는 옵션이 나오는지 확인해야 한다. 결제 수단은 두 개가 됐는데, 주문 내역 페이지에서 기존의 결제 수단만 표현한다면 이는 분명한 오류다. 따라서 아주 작은 기능 하나가 추가된다고 하더라도 이에 영향을 받는 부분을 모두 확인하고 이에 대한 기획이 필요하다.
따라서 기능 하나를 추가하거나 변경할 경우, QA도 이런 영향 범위를 모두 커버할 수 있어야 한다. 특정 기능에 대해서 단위 테스트만 하는 것이 아니라, 관련된 부분도 의도한 대로 잘 작동하는지, 기획 때 놓친 부분은 없는지를 확인하기 위해 통합 테스트도 진행해야 한다. 좀 규모가 큰 곳에서는 자동화된 QA 툴을 사용하겠지만, 이런 QA 툴을 활용하기 어려운 스타트업에서는 보통 QA 시트를 직접 작성하고, 흔히 말하는 손 QA를 진행한다. 이런 손 QA를 진행하는 경우, 추가된 기능에 대해서만 테스트를 진행하기 쉬운데, 반드시 영향 범위도 함께 확인을 할 수 있어야 한다.
사실 기능 추가 및 변경에 따른 영향범위 파악은 별 다른 노하우가 있지는 않다. 평소에 꾸준히 프로덕트 이곳저곳을 살펴보고 연관된 기능을 생각해 보면서 프로덕트에 대한 이해도를 높이는 수밖에 없다. 경험이 쌓이면서 더 짧은 시간 동안 영향 범위를 파악할 수 있을 것 같다.
흐름을 먼저 파악하고, 흐름대로 일하기
일의 흐름을 파악하고, 흐름대로 일하는 건 정말 중요하다. 이 흐름을 파악하지 못한 채 일한다면 일이 우당탕탕 흘러가게 되고, 문제가 계속해서 발생할 가능성이 높아진다.
만약 서로 다른 이해관계자들과 함께 일한다면, 가장 중요한 것은 공동의 목표에 대한 합의이다. 이 목표에는 일정을 비롯해 목적, 여러 요소와 사항들이 들어갈 수 있다. 이러한 합의를 건너뛴 채 무작정 일을 시작하게 되면, 당장 일은 진행되는 것 같아 보일 수 있어도, 서로의 의견차이로 인해서 다시 원점으로 돌아갈 수 있는 경우가 발생한다.
예를 들어서 서로 다른 이해관계자들이 모여서 특정 프로젝트를 런칭하자고 합의를 했다면, 언제 어떤 요소를 바탕으로 런칭을 할 것인지에 대한 합의를 봐야 한다. 그렇지 않고 무작정 디테일한 태스크만 진행을 하려 한다면 진행 자체도 쉽지 않고 진행이 된다고 하더라도 앞서 말한 것처럼 원점에서 다시 시작해야 할 수도 있다. 왜냐면 중간 목표에 대한 합의가 되지 않은 상태에서 일을 진행하면 실제로 일을 담당하는 사람들은 뭘 해야 할지 알 수 없어서 자신이 생각할 수 있는 한도 내에서만 일을 하기 때문이다. 이렇게 되면 이해관계자들끼리 생각하는 것이 달라서 시간은 시간대로 쓰고, 처음부터 공동의 목표나 목적에 대한 합의를 촉박한 시간 속에서 진행하고 이를 바탕으로 다시 일을 해야 하기 때문이다.
이는 프로젝트 진행 과정에서도 마찬가지다. 급하다고, 시간이 없다고 일의 프로세스를 건너뛰고 진행하면 나중에 오히려 혼돈이 생길 수 있다. 예를 들어서 기획을 바탕으로 디자인이 나오고 디자인을 바탕으로 개발이 진행될 때, 어느 한 부분을 생략하거나 빠뜨리면 나중에 더 큰 문제로 돌아온다. 워터폴이든 애자일이든 마찬가지이다. 애자일이라고 해서 프로세스를 건너뛰어도 되는 것은 아니다. 애자일은 개발 주기를 좀 더 짧게, 빠르게 가져가는 것뿐이다.
예를 들어서, 프로덕트 내에서 단순한 텍스트 수정이 필요한 경우, 디자인 시안에도 반영이 되어 있어야 하고 이를 바탕으로 개발이 진행이 되어야 한다. 단순히 텍스트 수정이라고 해서, 문서 작성과 디자인을 건너뛰고 개발을 바로 하게 된다면, 나중에는 기획이 잘못된 것인지, 디자인이 수정된 텍스트를 반영하지 못한 것인지, 아니면 기획과 디자인은 제대로 반영이 되었는데 개발이 잘못된 것인지를 파악하기 힘들어진다. 즉, 어떤 것이 원래 기획 의도에 맞는 것인지, 모든 구성원들이 합의한 뒤 진행하기로 한 것인지 알 수 없다. 물론 바쁜 상황과 많은 업무에 치이다 보면 이런 세세한 부분을 놓칠 수가 있다. 그러나 이런 부분도 지키려고 노력해야 나중에 더 큰 혼란을 막을 수 있다.
또 특정 프로젝트를 진행할 때, 보고 혹은 외부와의 커뮤니케이션을 위해서 잘 준비된 디자인 자료가 필요한 경우가 있다. 기획을 건너뛰고, 보고를 위한 디자인을 진행한 다음에, 승인을 받고 바로 개발을 진행하면 개발 과정에서 큰 혼란을 겪을 수 있다. 왜냐면 보고를 위한 디자인은 보이는 것에만 신경을 쓰게 되는 경우가 많고, 그 이면의 정책까지는 놓칠 가능성이 높아지기 때문이다.
사실 현실에서는 급하게 생긴 신규 기획에 대한 보고를 위해서 디자인이 먼저 나오는 경우가 많다. 이럴 경우에도 디자인과 동시에 정책 및 기획이 진행되거나, 디자인 직후 바로 기획이 진행되면 큰 문제는 생기지 않을 수 있다. 다만 디자인을 바탕으로 한 보고 이후 이를 보완하는 정책이나 기획 없이 바로 개발이 들어가는 경우가 문제다. 디자이너와 기획자 사이의 좋은 관계는 한쪽이 먼저 무언가를 진행하면 먼저 진행하는 쪽에서 후속 업무를 요청하고, 또 서로 놓친 부분이 있다면 이를 잡아주는 관계라고 생각한다(꼭 이건 디자이너와 기획자뿐 아니라 모든 서로 다른 직군에서 해당되는 말이긴 하다)
또한 가장 상위 직급자가 시간이 없다는 이유, 또는 어떠한 다른 이유로 중간 관리자를 건너뛰고 실무자에게 직접 지시를 내린다면 이 역시도 프로세스를 무너뜨리는 것이다. 가장 상위 직급이 직접 지시를 내렸기 때문에, 당장 그 일에 대해서는 진행이 되는 것처럼 보여도 이러한 일이 반복된다면, 일을 담당하는 실무자 입장에서는 중간 관리자를 어떻게 대해야 하는지, 또 보고는 누구에게 어떻게 해야 하는지 어려움을 겪기 쉽다. 또한 중간 관리자는 실무자와 최상위 직급자 사이에서 중간 다리 역할을 잘 수행하기도 쉽지 않다. 또 최상위 직급자도 마찬가지로 중간 관리자의 역할에 의구심을 품게 될 수 있다. 결국 중간관리자의 역할이 희미해지면서 조직 체계가 무너지는 것이다.
사례는 다 다르지만, 결국 핵심은 시간이 없다는 이유로, 또 다른 이유로 업무 프로세스를 건너뛰면 더 큰 문제가 생긴다는 것이다. 빠른 실행은 각 프로세스마다의 시간을 최소화하고 프로세스마다의 낭비되는 시간을 줄이는 것이지, 프로세스나 단계를 건너뛰는 게 아니다.
요즘 들어서 가장 많이 느꼈던 것들을 주절주절, 또 조금은 추상적으로 풀어봤다. 너무 디테일한 내용까지 구체적으로 적어버릴 수는 없기 때문에. 위에 쓴 내용들은 이제 머리로는 조금, 아주 조금 알 것 같다. 다만 이것들이 몸에 체화되어서 생각하지 않고 본능적으로 튀어나오기까지는 또 많은 연습과 오랜 시간이 필요할 것이다. 할 수 있는 건 그냥, 이 생각들을 계속해서 놓치지 않고 의식적으로 생각하고 또 실천하는 것뿐, 별 다른 방도가 없는 것 같다. 꼼수, 지름길 같은 것은 없고 정도를 걷는 수밖에 없다는 생각이 점점 더 진해진다.
