기획을 위해 개발을 배워야 할까요?

요구사항 정의를 위한 개발 과정의 이해

기획의 기술에 여러가지가 있겠지만, 기본적인 하드스킬 중 하나가 구체적인 요구사항을 정리할 수 있는 능력이라고 생각됩니다. 많은 분들이 개발자와 소통을 위해 개발을 배우거나 이해하려고 하는데, 개발자와 소통을 하는 가장 기본적인 포멧은 요구사항 명세라서 요구사항만 잘 정의되고 정리된다면 이런 부가적인 소통의 이슈들도 많이 줄어들 거라 생각됩니다.

이런 이유로 ‘제품이 만들어지는 과정과 구조’를 이해하면 구체적인 요구사항 정리에 도움이 됩니다. 개발자가 개발을 배우는 것은 일단 문제없는 코드를 만들거나, 대용량 트래픽을 고려한 구조를 설계하거나, 추상화 구조화를 잘 해서 유지보수에 효과적인 코드를 만들거나 하는 ‘효과적’인 개발을 위한 목적의 학습일 때가 많아서, 개발자가 되기 위한 학습코스와 제품을 정의하기 위한 코스는 조금 다르지 않을까 합니다.

그래서 ‘개발을 배우는게 좋을까요?’ 라고 물어보는 후배가 있다면 ‘개발을 배우는 것보다, 요구사항들이 해석이 되고 제품으로 구현이 되기 위한 사고의 과정’을 이해하려고 하면, 직접 개발을 배우는 것보다 효과적이지 않을까 하고 제안을 합니다. 예를들어, 어떤 ‘서비스를 만든다’ 하면 아래의 고민들을 하게 됩니다.

[정보의 구조]

* 어떤 정보를 저장을 하지

* 이 정보가 다른 정보와 어떤 관계가 있는지 : 참조인지 복사해서 가지고 있는지

* 나중에 어떤 정보가 추가될까

[화면 정의]

* 화면의 구성은 어떻게 되나

* 해당 정보가 없을 때는 그 영역이 사라지나

* 로그인 / 로그아웃 상태마다 다르나? 아직 서버에서 정보를 받아오지 못 하면 뭘 보여주나

* 어느 시점에 정보를 가져와서 화면을 바꿔주나

  

[동작들]

* 알림 푸시 같은 것들은 어느 시점에 나가나?

* 아침 9시 일괄로 푸시가 나가는 시나리오가 있나?

* 삭제를 하거나 탈퇴를 하면 어떻게 되는 것이지

* 이 정보를 바꾸면 모든 다른 사람들이 이 바뀐 정보를 바로 보여야 하나? 나중에 변경되도 되는 것인가?

이런 것들은 큰 덩어리의 주제들이고, 그 속에서 더 구체적인 상황 하나하나를 계속 쪼개서 만들어나가는 과정입니다.  즉, 행위로 따지면 ‘구현’이라는 단계를 위해 ‘요구사항’ 속에서 파악하려는 요소들이 무엇인지를 미리 알고 있으면 기획단계에서 고려하여 정리를 하면 동일한 요구사항이 미스 없이 전달될 수 있을 거에요.

이렇게 코딩하는 기술을 배우는 것보다 요구사항들이 어떻게 해석이 되고 어느 요소가 판단의 기준이 되는지를 다양한 케이스들을 통해 학습해 나가면, 나중에 고객과 시장의 요구사항을 효과적으로 제품으로 전환할 수 있지 않을까 합니다. 

그런데, 사실 가장 중요한 것은 '무엇이 가장 고객의 어려움을 풀어낼지에 대해 결정'하는 일입니다. 이런 내용은 TPM 이라고 불리는 새로운 역할이 하기도 하고, 경험많은 시니어 개발자가 알아서 정리해서 필요한 요구사항을 다시 문의할 수도 있습니다.  

그래도, 우리는 일당 백을 해야하는 언제나 부족한 리소스의 상황에서 살아남아야 하기에, '제품을 효과적으로 만들기 위한 기획의 기술' 이라고 해두죠. 이런 '실무적인 기술'이 도움이 된다고 판단되면 세부적으로 어떻개 기획이 개발에 영향을 미치는지 이런 저런 케이스를 통해 정리해보려고 합니다.