우선순위 조정과 타협점 찾기
항상 더 중요한게 있다는 개발자들
주변에서 충분한 개발자와 기간을 가지고 프로젝트를 진행한다는 이야기는 나는 들어본 일이 없다. 항상 개발자는 부족하고, 일정은 여유가 없다. 지켜본 바로는 3-4년동안 300억이상을 들여 충분한 시간과 돈을 투자한 프로젝트도 마지막에 가서는 “리소스가 부족해서 힘들것 같아요.“라는 이야기가 심심치않게 들린다.
일하면서 습관처럼 사용하는 ‘백로그’라는 용어가 있다. “백로그에 넣어둘게요.” 혹은 ”백로그검토해 봤는데 다 못담을것 같아요.“ 식으로 사용된다. 우리 제품에 필요할 것으로 예상되는 모든것들의 리스트를 백로그라고 부르는데, 벽난로 뒤(Back)에 쌓아둔 통나무(Log) 처럼 아무렇지않게 쌓여진 할것들을 말한다. 우리는 이중에서 ‘지금’ 혹은 ‘이번에‘ 해야할 것들의 목록을 추려서 기획서에 담고 동료들과 기획서 리뷰를 한다. 그런데 그럴때마다 항상 이걸 왜 지금 해야하는지 모르겠다 라던가, 더 급한게 있다는 식의 개발팀 의견이 들려오곤 한다.
시간은 정해져있고, 할 사람도 이미 정해져있다. 지금당장 개발자를 채용한다고해도 몇주는 걸릴테고 협력사나 고객들은 기다려주지 않는다. 이 상황에서 어떤것들을 먼저 처리하느냐는 우리 제품의 품질에 큰 영향을 미친다. 적당한 선해서 협상을 통해 어떤것들을 이번 개발에 담을지 의사결정 해야한다. 왜 이런 갈등상황이 발생하는지 알아보고, 모두가 행복한 선택을 만들기 위해 고려할 점들을 알아보려고 한다.
우선순위 충돌이 발생하는 이유.
생각의 차이는 마찰을 만든다. 우리 제품을 이용하는 고객들이 더 나은 만족감을 얻고 매출이 늘어나고 더 미적으로 아름다워지면서도 기술적으로도 완벽에 가까워지는것을 모두가 원한다. 회사의 처우나 사람이 마음에 안들어서 생기는 갈등은 여기서 논할 수 없다. 그런 경우를 제외하고 같은 길을 걸어간다는 전제하에 충돌이 생기는 몇가지 차이점 발생 구간이 있다.
사업과 기술이라는 관점의 차이가 있다. 사업측면에서 최우선 목표는 고객 니즈를 파악하고 충족시켜 이윤을 얻는것이다. 기술측면에서 중요한건 적정한 기술의 적용과 이를 통해 얻는 안정적이교 효율적인 제품개 발이다. 위험을 감수해서라도 목표를 달성해야하는 관점 안정을 추구하는 관점은 충돌하기 마련이다.
시간을 인식하는 차이도 있다. 최적의 타이밍, 보통은 남들보다 빠르게 시장에 진출해 선점효과를 누려야한다는 입장과 안정적인 품질을 확보하는것이 우선이라는 입장은 제품 출시시기를 선정하는데 충돌을 일으킨다. 애플이 아이폰을 세상에 내놓을때 개발팀은 소프트웨어 문제와 터치스크린 문제로 발표중에 에러가 발생할까봐 조마조마했다고 한다. 그렇지만 발표하는 스티브 잡스의 모습에선 그런 불안감은 보이지 않았다. 둘은 그렇게 다르다.
사람이 없고 시간이 부족하는 핑계로 기술 부채 해결을 우선순위를 뒤로 미루고 비즈니스 요구사항만 챙기다 보면 개발팀은 어느새 감당할수 없는 소스코드를 품에 안게 된다. 이런 일들이 반복되다가 핵심역할을 담당하던 개발자 몇명이 교체되면 더이상 유지보수가 불가능한 상태에 빠져버린다. 반대로 시장에 반응에 날렵하게 대응하지 못하면 사업 자체가 무너질수도 있다. 스마트폰 메신저분야에서 후발주자들이 선점효과를 누린 카카오톡에 밀려 사라진것 같은 사례는 타이밍의 중요성을 보여주는 대표적인 예시다.
또 이런 제약사항이 발생하면 결국 개발자의 야근으로 귀결되는 관성도 충돌을 일으키는 원인 중 하나다. 워라밸을 지켜야하는 개인의 입장으로 안 된다는 이야기를 할 수 밖에 없는 측면도 이해해야 한다.
효과적인 우선순위 선정 방법
자주 언급되고 사용되는 우선순위 선정 방법론들이 있다. 각각의 방법들은 디테일하게 살펴보면 담겨있는 철학이 다르지만 어떻게보면 비슷한 점도 많기때문에 마음에 드는 방법론 한두가지를 습득해 적용하면 좋다. 여기서는 우선순위 매트릭스, MosCoW 방법론, 버블정렬 방법론 등 세가지를 알아본다.
아이젠하워 우선순위 매트릭스 혹은 가치-노력 매트릭스
두가지 요소로 X,Y축을 만들고 그에따라 작업들을 분류하는 방법론이다. 아이젠하워 방법론은 ‘중요성‘과 ’긴급성‘을 축으로 하고, 가치-노력 방법론은 각 작업의 가치와 거기에 드는 노력을 축으로 한다. 각 방법론에 따라 네가지로 작업을 분류할수 있다.
중요하고 긴급한 일 (즉시 처리)
중요하지만 긴급하지 않은 일 (일정 계획 후 처리)
긴급하지만 중요하지 않은 일 (위임 또는 최소화)
중요하지도 않고 긴급하지도 않은 일 (삭제)
높은 가치 - 낮은 노력: 우선적으로 수행해야 하는 작업
높은 가치 - 높은 노력: 계획을 세우고 신중하게 수행해야 하는 작업
낮은 가치 - 낮은 노력: 시간이 남을 때 수행하거나 위임할 수 있는 작업
낮은 가치 - 높은 노력: 우선순위에서 제외하거나 최소화해야 하는 작업
각 체계는 명확하게 우선순위르르 분류할 수 있다는 장점이 있으나, 상황이 바뀌고 시간이 지남에 따라 지속적으로 리스트를 업데이트해야 한다는 특징이 있다.
MoSCoW 방법론
Must have, Should have, Could have, Won’t have 의 앞글자만 따서 만든 용어다. 첫번째 o는 외우기 좋게 덧붙여서 모스크바 방법론이라고 한다. 반드시 해야 하는것(필수요소), 해야하는것(중요하지만 필수는 아닌것), 할수있다면 좋은것, 지금 바로 하지 않아도 되는것으로 작업들을 분류하고, Must에 해당하는 항목부터 처리한다. 네가지로 구분할때 팀원들과 함께 정하며 협업할때 적용하기 쉬운 방법론이지만 각 카테고리 안에서 세부 우선순위를 정하는게 어렵다는 단점이 있다. 또 상황에따라 긴급/중요도가 바뀌는 경우를 유연하게 대처하기 어렵다는 특징도 있다.
버블정렬 방법론
버블정렬은 인접한 두 항목을 서로 비교하는것을 계속 반복해 정렬된 순서를 만드는 알고리즘이다. 이를 우선순위 선정에 적용하기위해 우선 일렬로 모든 작업들을 세우고 인접한 두 항목의 우선순위를 비교해 조금이라도 우선순위가 높다고 판단되는것을 앞으로 당겨온다. 그리고 이를 반복해 최종 우선순위를 만들고 결과의 순서대로 진행한다. 이 방법은 해야할 일들이 너무 많다면 우선순위를 정하는데 드는 시간이 비효율적으로 늘어나지만 직관적이고 이해하기 쉬워 바로 적용해볼 수 있는 장점이 있다.
각 방법론이 큰 차이가 없다고 생각할 수도 있으나 적용해보면 우선순위가 달라지는Task들이 있다. 또 기준을 세워 적용하는 일은 공동의 목표를 추구하는 프로젝트에서 공정성과 효율성을 높이는 현명한 선택이 될 수 있다. 따라서 한 가지 전략을 선택해 적용해보는 것이 좋다.
개발자와 타협점 찾기
개발자들이 이야기하는 우선순위가 높은 Task는 보통 시스템 중단이나 주요 기능의 오작동과 관련된것들이 많다. 이런 이슈들은 P0, P1 수준으로 분류되어 즉각적인 대응이 필요한 문제들이다. 반면, 기획자가 중요하게 생각하는 UI 개선이나 사용자 경험 향상은 개발자 입장에서는 P2, P3 수준으로 인식될 수 있다. 이런 관점 차이를 이해하고 타협점을 찾는 것이 중요하다.
효과적인 타협을 위해서는 먼저 상호 이해를 위한 대화가 필요하다. "왜 이 기능이 중요한지" 그리고 "왜 지금 해야 하는지"에 대한 명확한 근거를 제시해야 한다. “대표님/임원님이 하라고 지시 하셨습니다.” 라는 쉽고 간단한 선택지도 있지만, 이걸 왜 해야하는지 설득하는것이 여러모로 좋다. 실무에선 함께 기획서를 리뷰하기 전에 미리 함께 사전검토 혹은 브레인스토밍을 하는것을 추천한다. 단 몇시간이라도 ‘사전’에 공유하면 함께 기획했다는 느낌을 주고 대화의 밀도가 높아지니 생각이 다르다면 그 이유를 파악하기 더 쉬워진다.
개발자들은 종종 기획자가 원하는 결과를 달성할 수 있는 더 효율적인 기술적 방법을 알고 있을 수 있다. 열린 마음으로 개발자의 제안을 듣고, 함께 최적의 해결책을 찾아가는 자세가 필요하다. 다만 여러 상황을 고려했을때 해야할 일은 명확한 상황에서 개발팀을 설득하려면 다음과같은 방법들이 있다.
우선 단계적 구현 전략을 활용할 수 있다. 모든 기능을 한 번에 구현하려 하기보다는 핵심 기능부터 단계적으로 구현하는 접근법이다. 예를 들어, "이번 스프린트에서는 기본 기능만 구현하고, 다음 스프린트에서 추가 기능을 개발하자"와 같은 제안을 해볼 수 있다. 시간에 쫓겨 진행할 수 없다고 할때 효과적인 방법일 수 있다. 외부 API를 사용해서 적용해야 하는경우 실제 구현은 나중에 하더라도 API검토해서 가능여부까지는 확인해주세요 라는 식으로 접근할 수도 있다.
MVP(Minimum Viable Product) 접근법도 유용하다. 모든 기능을 완벽하게 구현하기보다는 핵심 가치를 제공할 수 있는 최소한의 제품을 먼저 출시하고, 사용자 피드백을 바탕으로 점진적으로 개선해 나가는 전략이다. 상황과 조직 분위기에 따라 이를 받아들이는 조직원들의 생각이 다를 수 있지만 리소스가 제한적인 상황에서 적극적으로 고려할 만 하다. 다만 MVP인 만큼 개발팀 스스로 만족할만한 상태가 아닐 수 있기때문에 품질에 대해 비난하는 일은 자제할 필요가 있다.
의사결정 과정에서 데이터 활용
판단하기 난감한 ”이거 제가 써보니까 영 불편하던데…“ 혹은 ”이게 더 낫지 않아요?“ 라는 대화가 회의중에 오가면 답은 안나오고 당연히 회의 진도도 잘 안나간다. 이때 객관적인 데이터, 특히 숫자는 우선순위 설정에 강력한 도구가 된다. 감정이나 개인적 선호가 아닌, 실제 사용자 행동과 비즈니스 성과를 기반으로 의사결정을 내리면 더 합리적인 결론에 도달할 수 있다.
A/B 테스트 결과는 특히 유용하다. 두 가지 버전을 실제 사용자에게 노출시켜 어떤 버전이 더 좋은 성과를 내는지 측정함으로써, 주관적인 의견 대신 객관적인 데이터에 기반한 결정을 내릴 수 있다. 사용자 피드백 수집과 반영도 중요하다. 실제 사용자들이 어떤 기능을 원하는지, 어떤 문제점을 겪고 있는지 파악하면 우선순위 설정에 큰 도움이 된다. 사용자 인터뷰, 설문조사, 앱 리뷰 등 다양한 채널을 통해 피드백을 수집하고 분석해야 한다.
정량적 데이터(숫자로 측정 가능한 데이터)와 정성적 데이터(사용자 의견, 경험 등) 사이의 균형을 맞추는 것도 중요하다. 정량적 데이터만으로는 파악하기 어려운 사용자의 감정이나 경험을 정성적 데이터를 통해 보완할 수 있다.
갈등 해결을 위한 커뮤니케이션 전략
갈등을 해결해야하는 사람으로서 지금껏 많은 케이스에서 얻은 교훈은 무엇을 이야기할 것인가 보다 언제 이야기하는가가 더 중요하다는 점이다. 그래서 적절한 타이밍을 선택하는 것이 중요하다. 개발자가 한참 집중하고 있을 때 새로운 기능 요청을 하는 등 협상을 하는건 좋은 전략이 아니다. 상대적으로 여유있을때 앞으로 나아갈 방향에 대해서, 현재 갖고있는 우리 제품의 문제에 대해서 이야기를 나누면 술술 풀리는 경우가 많다. 개발 주기와 일정을 고려하여 적절한 시점에 대화 요청을 하는 것이 효과적이다. 특히 앞서 이야기한것 처럼 ‘사전’에 공유하고 협의하는건 그들을 우리편으로 만드는데 필요한 좋은 스킬이다.
또 감정이 아닌 문제 중심으로 접근해야 한다. "왜 이렇게 오래 걸리나요?"라는 감정적인 질문보다는 "이 기능 개발에 어떤 어려움이 있나요? 어떻게 도울 수 있을까요?"와 같이 문제 해결에 초점을 맞춘 질문이 더 효과적이고 설령 도와줄 게 없더라도 심적으로나마 위로가 된다.
마지막으로 최후의 전략으로 BATNA(Best Alternative to a Negotiated Agreement)를 활용 하는것도 협상 기술로서 유효하다. 협상이 결렬될 경우 취할 수 있는 최선의 대안을 미리 생각해두는 것이다. 예를 들어, 특정 기능 개발이 어렵다면 외부 솔루션 활용이나 기능 간소화 등의 대안을 준비해두는 것이 좋다. 차선책을 선택하지 않더라도 생각하고 있다는 것 만으로도 불안한 마음을 어느정도 잠재울 수 있다.
이러한 전략들을 통해 개발자와 기획자 사이의 갈등을 최소화하고, 효과적인 협업을 이끌어낼 수 있다. 결국 양측 모두 좋은 제품을 만들어 사용자에게 가치를 제공한다는 공통의 목표를 가지고 있음을 잊지 말아야 한다.
우선순위 조정의 핵심
해야할 일이 많기 때문에 우선순위를 정하고 이를 관리하며 어떤걸 먼저 할지 다투게 된다. 가능하다면 백로그에 담겨있는것들을 주기적으로 비우는게 좋다. 필자는 스마트폰에 빨간색 알림 배지가 보이면 꼭 해야할 일이 쌓여있는것만 같아서 그 기능은 꺼두는 편이다. 태업을 하는것은 지양해야겠지만 적당히 워라밸을 지켜가며 일할 수 있도록 일을 줄여가야 한다. 이런 면에 있어서 기획자와 개발자는 한팀이다. 서로의 협조를 잘 이끌어낼수록 제품 품질은 올라가고 일하는시간은 줄일 수 있다. 원칙을 세워 우선순위를 정하고 이를 꾸준히 지켜 지속가능한 협업관계를 형성한다면 앞으로 같은 프로젝트를 하는내내 더 행복해지지 않을까 생각한다.
