<div id="readability-page-1" class="page"><div>
      
        <header>
          <h2 id="page-title" itemprop="headline">
            <a href="https://veluxer62.github.io/explanation/for-better-project-management/" itemprop="url">좀 더 나은 프로젝트 수행을 위하여
</a>
          </h2>
          

  <p>
    
      
      <span>
        
        
        <time datetime="2024-10-17T00:00:00+00:00">October 17, 2024</time>
      </span>
    

    <span></span>

    
      
      

      <span>
        
        
          7 분 소요
        
      </span>
    
  </p>


        </header>
      

      <section itemprop="text">
        
          
        
        <p>이 글은 현재 몸담은 회사에서 프로젝트를 수행할 때 현재보다 나은 프로젝트 진행을 위해 사내에 공유했던 자료를 블로그 언어 톤에 맞춰 작성한 글이다.</p>

<h2 id="시스템화가-필요하다">시스템화가 필요하다</h2>

<h3 id="과거의-노력">과거의 노력</h3>

<p>과거 우리는 애자일 방법론을 도입해서 개발에서 배포까지의 업무 프로세스를 시스템화하기 위해 지속적으로 노력해 왔다. 스크럼을 진행하면서 WBS를 만들어서 각각의 작업자끼리의 일정을 공유하고 조율하며 업무를 진행하기도 하였고.</p>

<p><a href="https://veluxer62.github.io/assets/images/posts/for-better-project-management/wbs.png" target="\_blank"><img src="https://veluxer62.github.io/assets/images/posts/for-better-project-management/wbs.png" alt="wbs"></a></p>

<p>아래와 같이 다수의 프로젝트를 진행하기 위해 어떻게 하면 프로젝트 관리 복잡성을 줄이고 원활하게 프로젝트를 수행할 수 있을지 고민하는 노력도 기울여보았다.</p>

<p><a href="https://veluxer62.github.io/assets/images/posts/for-better-project-management/multi-projects.png" target="\_blank"><img src="https://veluxer62.github.io/assets/images/posts/for-better-project-management/multi-projects.png" alt="multi-projects"></a></p>

<p>위와 같이 다수의 프로젝트를 진행하다 보니 프로젝트 진행 중 요구사항의 변경 관리가 너무 어려워 프로젝트 진행 중 요구사항의 변경을 줄이기 위해 노력하기도 하였다.</p>

<p><a href="https://veluxer62.github.io/assets/images/posts/for-better-project-management/project-template.png" target="\_blank"><img src="https://veluxer62.github.io/assets/images/posts/for-better-project-management/project-template.png" alt="project-template"></a></p>

<h3 id="현재">현재</h3>

<p>그렇다면 현재 우리는 어떠한 모습일까?</p>

<p>3개의 스쿼드로 나누어져서 각각의 우선순위에 맞춰 각자의 일정을 가지고 프로젝트를 진행하고 있다. 이렇게 진행한 프로젝트들이 QA라는 하나의 운동장에 모여 준비운동을 마친 후 세상 밖으로 나오는 형태로 제품의 배포 주기가 형성된다.</p>

<p><a href="https://veluxer62.github.io/assets/images/posts/for-better-project-management/now-project-management.png" target="\_blank"><img src="https://veluxer62.github.io/assets/images/posts/for-better-project-management/now-project-management.png" alt="now-project-management"></a></p>

<h3 id="무엇을-개선하고자-하는가">무엇을 개선하고자 하는가?</h3>

<p>현재의 프로세스가 나쁘다고 평할 수는 없다. 좋다 나쁘다는 주관적인 평가이고 회사마다 그리고 시기마다 다르기 때문에 현재 프로젝트 진행 방식이 큰 이슈 없이 진행되었다면 좋은 프로젝트 관리 방식이라 생각한다.</p>

<p>다만, 직접적이든 간접적이든 프로젝트 관리가 원활하지 않다고 느끼고 있다면 왜 그렇게 느끼는 것인지? 객관적으로 이슈가 없는데 주관적으로 불편함이 크게 느끼는 것인지에 대한 명확한 데이터가 필요하다고 생각한다. 우리가 제품의 문제점을 해결하고자 할 때 데이터를 기반으로 의사결정을 하려고 노력하는 것처럼 말이다.</p>

<p>그래서 우리의 현재 프로젝트의 진행 방식에서 개선해 보았으면 하는 부분이 어떤 것인지 불편함을 유발하는 요소가 어떤 것인지를 정량적으로 판단할 수 있는 데이터를 수집할 수 있어야 한다고 생각한다.</p>

<p>데이터를 수집하려면 지금 개개인의 역량으로 수행하고 있는 프로젝트 수행 단계들을 데이터화 할 수 있는 기반을 마련해야 하고 그 기반이 향후 제시하는 ‘시스템화’이다.</p>

<h3 id="업무-프로세스의-시스템화">업무 프로세스의 시스템화?</h3>

<p>시스템화는 무엇일까? <a href="https://ko.wikipedia.org/wiki/%EC%8B%9C%EC%8A%A4%ED%85%9C" target="\_blank">Wiki</a> 에서 말하기를 <strong>구조와 행동을 통제하는 규칙들의 집합체</strong>를 말한다. 지금 말하는 업무 프로세스의 시스템화는 <strong>우리가 정량적으로 업무의 진행 상황, 효율성 등을 측정할 수 있는 기반</strong>을 마련하는 것이다.</p>

<h4 id="원인">원인</h4>

<p>그렇다면 앞서 이야기한 것처럼 과거에도 우리는 시스템화를 위한 노력을 한 것처럼 보이는데 왜 지금까지 시스템화하지 못하였을까?</p>

<ul>
  <li>
    <p><strong>참여자</strong>: 업무 프로세스에 대한 좀 더 정확한 평가를 위해서는 프로젝트에 참가하는 모든 구성원이 해당 시스템 안으로 들어와야 한다고 생각한다. 하지만 개발자와 QA만 JIRA를 활용한 작업관리가 되다 보니 산출되는 보고서의 데이터가 충분하지 않았다.</p>
  </li>
  <li>
    <p><strong>번거로움</strong>: 과거의 노력을 살펴보면 프로젝트 참가자들이 작업 관리를 위해 Jira의 Task를 직접 설정하거나 고민해야 하는 프로세스가 많았다. 제품 개발에 집중만 해도 모자랄 판에 프로세스를 위한 노력을 10~20% 투자해야 했기 때문에 번거롭다는 느낌을 많이 주었다고 본다.</p>
  </li>
  <li>
    <p><strong>동기부여</strong>: 작업자가 작업관리를 해야 할 동기부여가 부족했다고 생각한다. 번거로운 작업관리를 해봤자 향후 구성원에게 작업관리에 대한 이득을 느끼지 못했기 때문이다.</p>
  </li>
</ul>

<h4 id="제안">제안</h4>

<p>그래서 과거 시스템화의 실패 요인을 개선하여 우리가 현실적으로 도입할 수 있고 도움이 되는 시스템화를 도입하기 위한 규칙들을 제안해 보고자 한다.</p>

<ul>
  <li><strong>모두의 참가</strong>: 제품개발은 우리가 모두 하는 것이다. 그리고 제품 개발 프로세스는 우리가 모두 참가하고 있다. 그러므로 업무 프로세스의 시스템화를 완성하려면 우리가 모두 시스템의 규칙을 따라야 한다고 생각한다. 과거의 Jira 사용 실태를 보면 주로 개발자의 작업관리 위주로 업무 프로세스를 관리하였다. 그러다 보니 아래 이미지와 같이 구현 단계에서만 업무 생산성을 측정할 수 있었다. 우리에게 도움이 되는 시스템을 구축하고 명확하고 도움이 되는 데이터를 산출해 내려면 이를 위한 규칙을 설정해야 하고 그러기 위해 가장 먼저 해야 하는 규칙이 프로젝트에 참여하는 모두가 프로젝트의 시작에서부터 종료까지 프로세스를 위한 작업 상태 관리, 작업 예측, 목표 설정 등과 같은 모든 프로세스에 적극 참여해야 한다.</li>
</ul>

<p><img src="https://veluxer62.github.io/assets/images/posts/for-better-project-management/measurement-scope.png" alt="measurement-scope"></p>

<ul>
  <li>
    <p><strong>실용성</strong>: 과거 시스템화의 두 번째 실패 요인은 번거로운 설정이었다고 생각한다. 특히, Jira의 에픽 하위에서 스토리를 생성하고 작업을 연결하는 작업은 자동화가 번거로워 직접 손으로 연결해 주어야 하는 불편함이 큰 규칙 중 하나였다. 이는 이상적인 시스템을 구축하기 위한 규칙이었고, 잘 운영되었다면 도움이 되었을 것이지만 번거로움은 생각보다 큰 장애물이었고 아쉽게도 구성원들이 시스템 참여에 있어 큰 방해 요소 중 하나로 여겨졌다. 그러므로 현재 시스템화 프로세스에서는 필수적인 요소만을 골라내어 최소한의 규칙을 설정하고 Automation과 같이 자동화 도구를 이용하여 번거로움을 최소화하여 우리가 추구하는 목표를 효율적으로 달성할 수 있는 시스템을 구축하고자 한다.</p>
  </li>
  <li>
    <p><strong>동기부여</strong>: 좋은 시스템을 도입한다고 하더라도 구성원들이 그 필요성을 느끼지 못한다면, 그것은 단순히 불편한 규칙에 불과할 것이다. 우리는 업무 프로세스를 체계화함으로써 부족한 부분을 개선하고 장점을 더욱 강화할 수 있는 순환구조를 구축하는 것을 목표로 삼고 있다. 효율적인 업무 프로세스는 우리가 고객에게 빠르고 고품질의 제품을 제공할 수 있는 기반이 되어야 한다. 다시 말해, 우리가 좋은 제품을 만들기 위한 노력 중에는 효율적인 업무 프로세스를 위한 노력도 함께 포함되어야 하며, 이를 모두가 인지하고 실천하기 위한 동기부여가 필요하다고 생각한다.</p>
  </li>
</ul>

<h2 id="업무-의존성의-개선이-필요하다">업무 의존성의 개선이 필요하다</h2>

<h3 id="현재의-업무-프로세스">현재의 업무 프로세스</h3>

<p>먼저 현재 업무 프로세스를 다시 살펴보자.</p>

<p><a href="https://veluxer62.github.io/assets/images/posts/for-better-project-management/now-project-management.png" target="\_blank"><img src="https://veluxer62.github.io/assets/images/posts/for-better-project-management/now-project-management.png" alt="now-project-management"></a></p>

<p>현재 업무 프로세스에서 가장 두드러지는 특징은 요구사항을 정의하고 기획서 작성 및 디자인 시안을 작성하는 모든 활동이 <strong>A 단계</strong>에 집중되어 있다는 것이다. 이러한 활동이 우리 전체 업무 프로세스에 아래와 같은 의존성을 유발한다.</p>

<ul>
  <li>
    <p><strong>기획 의존성</strong>: 기획과 디자인의 리뷰에 모든 구성원이 참가한다고 하지만 결국 PM과 PD가 A 단계의 책임과 주도성을 가지고 업무를 진행하고 있다. 그러다 보니 다른 구성원들은 A 단계가 끝날 때까지 다른 개선 작업을 진행하며 대기해야 한다는 비효율성이 발생하곤 한다. 또한 PM과 PD에게 책임과 업무가 몰리다 보니 한쪽은 한가한데 한쪽은 바빠서 야근해야 하는 업무 불균형도 발생하고 있다.</p>
  </li>
  <li>
    <p><strong>일정 의존성</strong>: 앞서 기획에 대한 의존성이 발생하다 보니 스쿼드 또는 회사에서 목표한 일정에 대한 의존성이 발생한다. 즉, A 단계가 길어지면 길어질수록 B 단계와 C 단계의 업무 일정 압박은 늘어나게 되고 결국 후속에 작업하는 작업자들은 A 단계의 일정에 기댈 수밖에 없는 구조가 마련되는 것이다.</p>
  </li>
  <li>
    <p><strong>협업 의존성</strong>: 우리는 현재 A 단계에서 최선을 다해 완성된 기획을 마련한 뒤에 구현을 수행하는 B 단계로 넘어가려고 노력하고 있다. 그러다 보니 A 단계에서 많은 이해관계자와의 협의와 의사결정이 필요하다. 그러다 보니 A 단계에서 수행해야 할 업무 복잡도가 증가하고 그러다 보니 A 단계의 목표 일정을 보장하거나 예측하기 어려워지게 된다.</p>
  </li>
</ul>

<h3 id="프로세스-제안">프로세스 제안</h3>

<p>위에서 말한 의존성을 최소화하기 위한 방법으로 아래와 같이 프로세스 개선안을 제안하고자 한다.</p>

<p><a href="https://veluxer62.github.io/assets/images/posts/for-better-project-management/suggest-project-management.png" target="\_blank"><img src="https://veluxer62.github.io/assets/images/posts/for-better-project-management/suggest-project-management.png" alt="suggest-project-management"></a></p>

<h4 id="변경사항">변경사항</h4>

<ul>
  <li>
    <p><strong>프로세스 단계의 변경</strong>: A/B/C 단계는 동일하지만, 단계마다 세부적인 프로세스는 변경이 된다. 먼저 A 단계에서는 기존에 기획과 디자인을 일차적으로 완료하는 것을 목표로 하였지만 변경되는 프로세스에서는 A 단계에서는 지난 4주 전에 진행했던 프로젝트에 대한 평가를 수행한 후 이를 기반으로 요구사항 수집과 사용자 스토리를 도출하는 활동까지를 수행한다. 다음으로 기존에 A 단계에서 수행하던 기획의 구체화 및 디자인 시안을 작성하는 행위를 B 단계로 변경하였다. 변경되는 프로세스에서는 B 단계를 다시 또 크게 기회의 구체화와 구현하는 단계로 세분화하였다. 다만, 이렇게 나누어지는 단계를 B 단계로 합쳐둔 이유는 기획의 구체화는 한 번에 이루어지는 것이 아니라 구현하면서 구성원들 간의 커뮤니케이션을 통하여 보정하며 완성되는 것으로 생각했기 때문에 하나의 단계로 보는 것이 적절하다고 판단했다. 마지막 C 단계는 기존과 거의 유사하지만 배포 후 회고 단계를 명시적으로 추가하였다.</p>
  </li>
  <li>
    <p><strong>단계별 역할</strong>: 변경되는 프로세스의 두드러지는 또 다른 특징은 바로 구성원들의 단계별 역할이다. 기존에 PM과 PD가 프로젝트의 기획(요구사항 구체화, 디자인)을 도맡아 왔다면 변경되는 프로세스에서는 기획의 역할과 책임을 조금 더 확장하고자 한다. 이를 통해 프로젝트의 기획 의도를 모두가 인지하고 커뮤니케이션 비용을 줄이며 변경 가능성을 최소화할 수 있도록 한다. 또한 단계별 챕터별 역할을 명확히 정의함으로써 모호한 R &amp; R을 최소화하고 서로가 필요한 역할들을 수행할 수 있도록 명문화하였다.</p>
  </li>
  <li>
    <p><strong>세부 단계별 목표일정 설정</strong>: 그림에서 나타나 있진 않지만, 변경되는 프로세스에서 필요한 요소 중 하나는 각 세부 단계별로 목표 일정을 설정하고 해당 기간 안에 프로세스를 마무리 짓는 것이다. 제품의 완성도를 높이기 위한 노력은 우리 조직의 가장 큰 장점이라 생각한다. 다만, 우리에게는 시간은 유한하다. 완성도를 높이기 위한 고민이 깊어지면 깊어질수록 우리의 프로젝트는 그 목적성을 잃을 가능성이 높아질 수 있다. 그래서 우리는 단계별로 목표 일정을 설정하고 이를 지키기 위해 고객의 문제점을 좀 더 뾰족하게 모색하고 가능성이 낮은 위험과 우선순위가 낮은 부가적인 기능에 대한 고민을 줄여 보다 효율적인 프로젝트 수행을 위해 노력했으면 한다.</p>
  </li>
  <li>
    <p><strong>변경 대응 방식에 대한 접근</strong>: 제품에 대한 고민을 진행하다 보면 구현 단계나 심지어 배포 이후에도 의사결정을 수정하고 싶을 때가 있다. 우리가 제품을 사랑하고 열정을 가지고 있다면 이는 자연스러운 현상이다. 그러나 갑작스러운 요구사항 변경은 변경을 대응하는 과정에서 우리는 제품의 높은 수준의 품질과 지속적인 발전을 유지하기 어려워질 수 있다. 따라서 변경 의견은 환영하되, 변경 요청은 정해진 절차에 따라 처리되는 것이 좋다. 예를 들어, 요구사항의 변경은 A 단계까지만 수용하고, A 단계 이후에는 프로세스가 완료된 배포 이후에 재검토된다. 기획의 세부 사항을 논의하는 것은 구현 단계에서도 B 단계에 포함되므로 적극적으로 수용될 수 있지만, 배포가 시작되는 C 단계에서는 더 이상 수용하지 않는다. 대신, 배포 이후에 세부 사항에 대한 변경은 다음 요구사항으로 추가되어 다시 검토된다. 우리는 변경 사항을 최소화하고, 만약 부득이하게 변경이 필요한 경우에는 기록을 남기고 회고를 통해 재발하지 않도록 노력해야 한다. 또한, 다른 이에 의해 규칙이 위배될 경우 변경 사항 기록 등 적절한 조처를 할 필요가 있다. 그리고 이는 회고에서 개선 사항으로 다루어짐으로 써 향후 프로세스가 긍정적으로 변화할 수 있도록 한다.</p>
  </li>
</ul>

<h4 id="기대효과">기대효과</h4>

<ul>
  <li>
    <p><strong>효율성</strong>: 단계별로 챕터별 역할을 명확히 하고 프로젝트 진행 시 유연하게 대처할 수 있는 기반을 마련해 주기 때문에 프로젝트가 좀 더 효율적이고 유기적으로 진행될 수 있다. 또한 특정 챕터에게 쏠리는 역할과 책임을 분산시킴으로써 상호 간 의존성으로 인한 비효율성을 줄여나갈 수 있다.</p>
  </li>
  <li>
    <p><strong>생산성</strong>: 각 세부 단계별로 목표 일을 지정함으로써 자칫 지나친 완성도를 위한 노력을 절제시키고 합리적인 수준의 품질과 좀 더 명확한 목표를 향한 프로세스 관리가 가능해진다.</p>
  </li>
  <li>
    <p><strong>성장성</strong>: 명시적으로 나누어져 있는 각각의 단계는 프로젝트 진행 시 발생할 수 있는 이슈 혹은 병목구간을 명확하게 집어낼 수 있는 자료를 제공해 준다. 그리고 변경에 대한 지속적인 기록은 배포 이후 회고를 통해 우리가 다음 프로젝트 진행 시 개선해야 할 부분이 어떤 것인지 좀 더 명확하게 확인할 수 있기 때문에 우리의 프로세스는 지속적으로 발전해 나갈 수 있다.</p>
  </li>
</ul>



<p>지금까지 보다 나은 프로젝트를 위한 제안 내용을 소개해 보았다.</p>

<p>물론 회사마다 팀마다 상황이 다르고 프로젝트를 진행할 때 중요하게 생각하는 바가 다르기 때문에 현재 우리 팀에게 맞게 작성된 위 제안 내용이 여러분에게 와닿지 않거나 적절하지 않을 수 있다고 생각한다. 다만, 이글에서 <strong>프로세스의 시스템화</strong>, <strong>의존성 개선</strong>을 통해 프로세스를 좀 더 원활하게 개선할 수 있다는 것을 말해주고 싶다.</p>

<p>아마 많은 회사의 프로젝트 매니저 혹은 관리자가 효율적인 프로젝트 관리를 위해 고민하고 있을 것으로 생각한다. 앞서 소개한 방식이 여러분의 회사 또는 팀에 적절할 수도 적절하지 않을 수도 있지만 결국 기대하는 효과는 같을 것이다. 그러므로 각자 보다 나은 프로젝트 관리 방식을 채택하여 효율적으로 프로젝트를 수행했으면 하는 바람이고, 이 글이 도움이 되었으면 한다.</p>

<p>끝으로 효율적인 프로젝트 관리도 제품을 사랑하는 방법의 하나라고 생각해 주는 분들이 많아졌으면 좋겠다는 생각을 전하면서 글을 마치고자 한다.</p>

        
      </section>

      

      


      
  

    </div></div>

Veluexer’s Blog

이 글은 현재 몸담은 회사에서 프로젝트를 수행할 때 현재보다 나은 프로젝트 진행을 위해 사내에 공유했던 자료를 블로그 언어 톤에 맞춰 작성한 글이다.
시스템화가 필요하다
과거의 노력
과거 우리는 애자일 방법론을 도입해서 개발에서 배포까지의 업무 프로세스를 시스템화하기 위해 지속적으로 노력해 왔다. 스크럼을 진행하면서 WBS를 만들어서 각각의 작업자끼리의 일정을 공유하고 조율하며 업무를 진행하기도 하였고.
아래와 같이 다수의 프로젝트를 진행하기 위해 어떻게 하면 프로젝트 관리 복잡성을 줄이고 원활하게 프로젝트를 수행할 수 있을지 고민하는 노력도 기울여보았다.
위와 같이 다수의 프로젝트를 진행하다 보니 프로젝트 진행 중 요구사항의 변경 관리가 너무 어려워 프로젝트 진행 중 요구사항의 변경을 줄이기 위해 노력하기도 하였다.
현재
그렇다면 현재 우리는 어떠한 모습일까?
3개의 스쿼드로 나누어져서 각각의 우선순위에 맞춰 각자의 일정을 가지고 프로젝트를 진행하고 있다. 이렇게 진행한 프로젝트들이 QA라는 하나의 운동장에 모여 준비운동을 마친 후 세상 밖으로 나오는 형태로 제품의 배포 주기가 형성된다.
무엇을 개선하고자 하는가?
현재의 프로세스가 나쁘다고 평할 수는 없다. 좋다 나쁘다는 주관적인 평가이고 회사마다 그리고 시기마다 다르기 때문에 현재 프로젝트 진행 방식이 큰 이슈 없이 진행되었다면 좋은 프로젝트 관리 방식이라 생각한다.
다만, 직접적이든 간접적이든 프로젝트 관리가 원활하지 않다고 느끼고 있다면 왜 그렇게 느끼는 것인지? 객관적으로 이슈가 없는데 주관적으로 불편함이 크게 느끼는 것인지에 대한 명확한 데이터가 필요하다고 생각한다. 우리가 제품의 문제점을 해결하고자 할 때 데이터를 기반으로 의사결정을 하려고 노력하는 것처럼 말이다.
그래서 우리의 현재 프로젝트의 진행 방식에서 개선해 보았으면 하는 부분이 어떤 것인지 불편함을 유발하는 요소가 어떤 것인지를 정량적으로 판단할 수 있는 데이터를 수집할 수 있어야 한다고 생각한다.
데이터를 수집하려면 지금 개개인의 역량으로 수행하고 있는 프로젝트 수행 단계들을 데이터화 할 수 있는 기반을 마련해야 하고 그 기반이 향후 제시하는 ‘시스템화’이다.
업무 프로세스의 시스템화?
시스템화는 무엇일까? Wiki 에서 말하기를 구조와 행동을 통제하는 규칙들의 집합체를 말한다. 지금 말하는 업무 프로세스의 시스템화는 우리가 정량적으로 업무의 진행 상황, 효율성 등을 측정할 수 있는 기반을 마련하는 것이다.
원인
그렇다면 앞서 이야기한 것처럼 과거에도 우리는 시스템화를 위한 노력을 한 것처럼 보이는데 왜 지금까지 시스템화하지 못하였을까?
참여자: 업무 프로세스에 대한 좀 더 정확한 평가를 위해서는 프로젝트에 참가하는 모든 구성원이 해당 시스템 안으로 들어와야 한다고 생각한다. 하지만 개발자와 QA만 JIRA를 활용한 작업관리가 되다 보니 산출되는 보고서의 데이터가 충분하지 않았다.
번거로움: 과거의 노력을 살펴보면 프로젝트 참가자들이 작업 관리를 위해 Jira의 Task를 직접 설정하거나 고민해야 하는 프로세스가 많았다. 제품 개발에 집중만 해도 모자랄 판에 프로세스를 위한 노력을 10~20% 투자해야 했기 때문에 번거롭다는 느낌을 많이 주었다고 본다.
동기부여: 작업자가 작업관리를 해야 할 동기부여가 부족했다고 생각한다. 번거로운 작업관리를 해봤자 향후 구성원에게 작업관리에 대한 이득을 느끼지 못했기 때문이다.
제안
그래서 과거 시스템화의 실패 요인을 개선하여 우리가 현실적으로 도입할 수 있고 도움이 되는 시스템화를 도입하기 위한 규칙들을 제안해 보고자 한다.
모두의 참가: 제품개발은 우리가 모두 하는 것이다. 그리고 제품 개발 프로세스는 우리가 모두 참가하고 있다. 그러므로 업무 프로세스의 시스템화를 완성하려면 우리가 모두 시스템의 규칙을 따라야 한다고 생각한다. 과거의 Jira 사용 실태를 보면 주로 개발자의 작업관리 위주로 업무 프로세스를 관리하였다. 그러다 보니 아래 이미지와 같이 구현 단계에서만 업무 생산성을 측정할 수 있었다. 우리에게 도움이 되는 시스템을 구축하고 명확하고 도움이 되는 데이터를 산출해 내려면 이를 위한 규칙을 설정해야 하고 그러기 위해 가장 먼저 해야 하는 규칙이 프로젝트에 참여하는 모두가 프로젝트의 시작에서부터 종료까지 프로세스를 위한 작업 상태 관리, 작업 예측, 목표 설정 등과 같은 모든 프로세스에 적극 참여해야 한다.
실용성: 과거 시스템화의 두 번째 실패 요인은 번거로운 설정이었다고 생각한다. 특히, Jira의 에픽 하위에서 스토리를 생성하고 작업을 연결하는 작업은 자동화가 번거로워 직접 손으로 연결해 주어야 하는 불편함이 큰 규칙 중 하나였다. 이는 이상적인 시스템을 구축하기 위한 규칙이었고, 잘 운영되었다면 도움이 되었을 것이지만 번거로움은 생각보다 큰 장애물이었고 아쉽게도 구성원들이 시스템 참여에 있어 큰 방해 요소 중 하나로 여겨졌다. 그러므로 현재 시스템화 프로세스에서는 필수적인 요소만을 골라내어 최소한의 규칙을 설정하고 Automation과 같이 자동화 도구를 이용하여 번거로움을 최소화하여 우리가 추구하는 목표를 효율적으로 달성할 수 있는 시스템을 구축하고자 한다.
동기부여: 좋은 시스템을 도입한다고 하더라도 구성원들이 그 필요성을 느끼지 못한다면, 그것은 단순히 불편한 규칙에 불과할 것이다. 우리는 업무 프로세스를 체계화함으로써 부족한 부분을 개선하고 장점을 더욱 강화할 수 있는 순환구조를 구축하는 것을 목표로 삼고 있다. 효율적인 업무 프로세스는 우리가 고객에게 빠르고 고품질의 제품을 제공할 수 있는 기반이 되어야 한다. 다시 말해, 우리가 좋은 제품을 만들기 위한 노력 중에는 효율적인 업무 프로세스를 위한 노력도 함께 포함되어야 하며, 이를 모두가 인지하고 실천하기 위한 동기부여가 필요하다고 생각한다.
업무 의존성의 개선이 필요하다
현재의 업무 프로세스
먼저 현재 업무 프로세스를 다시 살펴보자.
현재 업무 프로세스에서 가장 두드러지는 특징은 요구사항을 정의하고 기획서 작성 및 디자인 시안을 작성하는 모든 활동이 A 단계에 집중되어 있다는 것이다. 이러한 활동이 우리 전체 업무 프로세스에 아래와 같은 의존성을 유발한다.
기획 의존성: 기획과 디자인의 리뷰에 모든 구성원이 참가한다고 하지만 결국 PM과 PD가 A 단계의 책임과 주도성을 가지고 업무를 진행하고 있다. 그러다 보니 다른 구성원들은 A 단계가 끝날 때까지 다른 개선 작업을 진행하며 대기해야 한다는 비효율성이 발생하곤 한다. 또한 PM과 PD에게 책임과 업무가 몰리다 보니 한쪽은 한가한데 한쪽은 바빠서 야근해야 하는 업무 불균형도 발생하고 있다.
일정 의존성: 앞서 기획에 대한 의존성이 발생하다 보니 스쿼드 또는 회사에서 목표한 일정에 대한 의존성이 발생한다. 즉, A 단계가 길어지면 길어질수록 B 단계와 C 단계의 업무 일정 압박은 늘어나게 되고 결국 후속에 작업하는 작업자들은 A 단계의 일정에 기댈 수밖에 없는 구조가 마련되는 것이다.
협업 의존성: 우리는 현재 A 단계에서 최선을 다해 완성된 기획을 마련한 뒤에 구현을 수행하는 B 단계로 넘어가려고 노력하고 있다. 그러다 보니 A 단계에서 많은 이해관계자와의 협의와 의사결정이 필요하다. 그러다 보니 A 단계에서 수행해야 할 업무 복잡도가 증가하고 그러다 보니 A 단계의 목표 일정을 보장하거나 예측하기 어려워지게 된다.
프로세스 제안
위에서 말한 의존성을 최소화하기 위한 방법으로 아래와 같이 프로세스 개선안을 제안하고자 한다.
변경사항
프로세스 단계의 변경: A/B/C 단계는 동일하지만, 단계마다 세부적인 프로세스는 변경이 된다. 먼저 A 단계에서는 기존에 기획과 디자인을 일차적으로 완료하는 것을 목표로 하였지만 변경되는 프로세스에서는 A 단계에서는 지난 4주 전에 진행했던 프로젝트에 대한 평가를 수행한 후 이를 기반으로 요구사항 수집과 사용자 스토리를 도출하는 활동까지를 수행한다. 다음으로 기존에 A 단계에서 수행하던 기획의 구체화 및 디자인 시안을 작성하는 행위를 B 단계로 변경하였다. 변경되는 프로세스에서는 B 단계를 다시 또 크게 기회의 구체화와 구현하는 단계로 세분화하였다. 다만, 이렇게 나누어지는 단계를 B 단계로 합쳐둔 이유는 기획의 구체화는 한 번에 이루어지는 것이 아니라 구현하면서 구성원들 간의 커뮤니케이션을 통하여 보정하며 완성되는 것으로 생각했기 때문에 하나의 단계로 보는 것이 적절하다고 판단했다. 마지막 C 단계는 기존과 거의 유사하지만 배포 후 회고 단계를 명시적으로 추가하였다.
단계별 역할: 변경되는 프로세스의 두드러지는 또 다른 특징은 바로 구성원들의 단계별 역할이다. 기존에 PM과 PD가 프로젝트의 기획(요구사항 구체화, 디자인)을 도맡아 왔다면 변경되는 프로세스에서는 기획의 역할과 책임을 조금 더 확장하고자 한다. 이를 통해 프로젝트의 기획 의도를 모두가 인지하고 커뮤니케이션 비용을 줄이며 변경 가능성을 최소화할 수 있도록 한다. 또한 단계별 챕터별 역할을 명확히 정의함으로써 모호한 R & R을 최소화하고 서로가 필요한 역할들을 수행할 수 있도록 명문화하였다.
세부 단계별 목표일정 설정: 그림에서 나타나 있진 않지만, 변경되는 프로세스에서 필요한 요소 중 하나는 각 세부 단계별로 목표 일정을 설정하고 해당 기간 안에 프로세스를 마무리 짓는 것이다. 제품의 완성도를 높이기 위한 노력은 우리 조직의 가장 큰 장점이라 생각한다. 다만, 우리에게는 시간은 유한하다. 완성도를 높이기 위한 고민이 깊어지면 깊어질수록 우리의 프로젝트는 그 목적성을 잃을 가능성이 높아질 수 있다. 그래서 우리는 단계별로 목표 일정을 설정하고 이를 지키기 위해 고객의 문제점을 좀 더 뾰족하게 모색하고 가능성이 낮은 위험과 우선순위가 낮은 부가적인 기능에 대한 고민을 줄여 보다 효율적인 프로젝트 수행을 위해 노력했으면 한다.
변경 대응 방식에 대한 접근: 제품에 대한 고민을 진행하다 보면 구현 단계나 심지어 배포 이후에도 의사결정을 수정하고 싶을 때가 있다. 우리가 제품을 사랑하고 열정을 가지고 있다면 이는 자연스러운 현상이다. 그러나 갑작스러운 요구사항 변경은 변경을 대응하는 과정에서 우리는 제품의 높은 수준의 품질과 지속적인 발전을 유지하기 어려워질 수 있다. 따라서 변경 의견은 환영하되, 변경 요청은 정해진 절차에 따라 처리되는 것이 좋다. 예를 들어, 요구사항의 변경은 A 단계까지만 수용하고, A 단계 이후에는 프로세스가 완료된 배포 이후에 재검토된다. 기획의 세부 사항을 논의하는 것은 구현 단계에서도 B 단계에 포함되므로 적극적으로 수용될 수 있지만, 배포가 시작되는 C 단계에서는 더 이상 수용하지 않는다. 대신, 배포 이후에 세부 사항에 대한 변경은 다음 요구사항으로 추가되어 다시 검토된다. 우리는 변경 사항을 최소화하고, 만약 부득이하게 변경이 필요한 경우에는 기록을 남기고 회고를 통해 재발하지 않도록 노력해야 한다. 또한, 다른 이에 의해 규칙이 위배될 경우 변경 사항 기록 등 적절한 조처를 할 필요가 있다. 그리고 이는 회고에서 개선 사항으로 다루어짐으로 써 향후 프로세스가 긍정적으로 변화할 수 있도록 한다.
기대효과
효율성: 단계별로 챕터별 역할을 명확히 하고 프로젝트 진행 시 유연하게 대처할 수 있는 기반을 마련해 주기 때문에 프로젝트가 좀 더 효율적이고 유기적으로 진행될 수 있다. 또한 특정 챕터에게 쏠리는 역할과 책임을 분산시킴으로써 상호 간 의존성으로 인한 비효율성을 줄여나갈 수 있다.
생산성: 각 세부 단계별로 목표 일을 지정함으로써 자칫 지나친 완성도를 위한 노력을 절제시키고 합리적인 수준의 품질과 좀 더 명확한 목표를 향한 프로세스 관리가 가능해진다.
성장성: 명시적으로 나누어져 있는 각각의 단계는 프로젝트 진행 시 발생할 수 있는 이슈 혹은 병목구간을 명확하게 집어낼 수 있는 자료를 제공해 준다. 그리고 변경에 대한 지속적인 기록은 배포 이후 회고를 통해 우리가 다음 프로젝트 진행 시 개선해야 할 부분이 어떤 것인지 좀 더 명확하게 확인할 수 있기 때문에 우리의 프로세스는 지속적으로 발전해 나갈 수 있다.
지금까지 보다 나은 프로젝트를 위한 제안 내용을 소개해 보았다.
물론 회사마다 팀마다 상황이 다르고 프로젝트를 진행할 때 중요하게 생각하는 바가 다르기 때문에 현재 우리 팀에게 맞게 작성된 위 제안 내용이 여러분에게 와닿지 않거나 적절하지 않을 수 있다고 생각한다. 다만, 이글에서 프로세스의 시스템화, 의존성 개선을 통해 프로세스를 좀 더 원활하게 개선할 수 있다는 것을 말해주고 싶다.
아마 많은 회사의 프로젝트 매니저 혹은 관리자가 효율적인 프로젝트 관리를 위해 고민하고 있을 것으로 생각한다. 앞서 소개한 방식이 여러분의 회사 또는 팀에 적절할 수도 적절하지 않을 수도 있지만 결국 기대하는 효과는 같을 것이다. 그러므로 각자 보다 나은 프로젝트 관리 방식을 채택하여 효율적으로 프로젝트를 수행했으면 하는 바람이고, 이 글이 도움이 되었으면 한다.
끝으로 효율적인 프로젝트 관리도 제품을 사랑하는 방법의 하나라고 생각해 주는 분들이 많아졌으면 좋겠다는 생각을 전하면서 글을 마치고자 한다.

좀 더 나은 프로젝트 수행을 위하여

댓글