[회고] L그룹 B계열사 요구사항 정의 회고

이번 프로젝트는 L그룹 B계열사 프로젝트다.

2년전 L그룹의 L계열사 프로젝트에서 개발자로 처음 인사 시스템을 시작했었다.
L그룹 프로젝트는 이번이 두 번째인 것이다.

하지만 이번에는 PL이다.

역활이 완전히 바뀌었다. 

 

이번 프로젝트는 기간이 무척 짧다.

이 짧은 기간에 얼마나 질 좋은 결과물을 만들어 낼 수 있을지 모르겠다.

여하튼 오늘은 요구사항 정의에 대해 간단히 회고를 남겨 보려고 한다.

 

우선 RFP와 PM님이 정리해서 공유해 주신 요구사항정의를 여러 차례  흝어 보았다.

이번 프로젝트에서 하고 싶었던건, 요구사항 문서를 노션으로 정리하는 것이었다.

이 부분에 대해서는 어느정도 정리를 하였으나 이것을 계속 사용할 수 있을지는 의문이다.

일단 프로젝트 내부에서는 요구사항정의를 엑셀로 정리해서 관리하고 있다.

그렇다 보니 내가 혼자 아무리 노션에 잘 정리를 한다고 해도 관리를 이중으로 해야 하는 문제점이 생긴다.

아무리 잘 처리했다고 해도 결국 구멍이 생긴다.

또한 노션에 정리하는 것이 내가 원하던 방식으로 정리가 되지는 않는다는 점이다.

여기에는 노션이라는 툴을 쓰기 때문에 발생하는 여러 가지 특성이 반영될 결과이다.

결과적으로 뭔가 좀더 쓰기 힘들어 졌다는 생각이 든다.

따라서 요구사항정의는 일단 기존의 방식대로 엑셀로 처리 하는게 맞을것 같다는 생각이 든다.

노션에 요구사항을 정리 하는 것은 다른 방식, 혹은 다른것에 초점을 맞추어 생각을 다시 해보아야 할것 같다.

예를 들어 A라는 요구사항이 있을 경우, 이 요구사항에 대한 내용을 정리하고 추적하는 것을 노션으로 하지 말고

요구사항을 처리하기 위한 적절한 어느 프로그램을 선정하고, 그 프로그램에 어떤 요구사항이 있었는지를 정리하는 것이다.

프로그램들은 메뉴와 화면 중심으로 카테고리를 정리하고, 해당 프로그램의 페이지에 요구사항과 이슈사항, 처리했던 내역을 프로젝트 별로 정리 하는 것이다.

이것을 각 요구사항 ID와 연결하면 꽤 그럴듯한 관리 방법이 될것같아 보인다. 

 

그리고 이번 요구사항 정의 인터뷰를 통해 느꼈던 점은 누가 뭐라고 해도 RFP의 내용은 확실하게 짚고 넘어가야 한다는 점이다.

내 앞의 인터뷰에서 까다로운 고객때문에 인터뷰 내내 분위기가 어두웠다는 이야기를 들었다.

이유는 고객들도 요구사항에 대해서 이미 알고 들어왔는데 왜 그 자리에서 다시 요구사항을 하나하나 다 짚어가냐고 따지더라는 것이다.

이 자리에 같이 계셨던 PM님이 내가 들어가는 인터뷰에서는 전체를 다 다루지 말라고 당부 하셨다.

그래서 잘 이해가 되지 않았던 부분과 내용이 애매모호한 부분, 기존에 패키지에는 없었던 부분들 위주로 인터뷰를 진행했었다.

그러다 보니 내가 짚고 넘어가지 않았던 내용들에 대해서 업무 담당자와 나 사이에 이해하고 있는 갭이 상당하다는 것을 나중에야 알 수 있었다.

사실 지금도 어느정도 갭이 존재하는지도 모르겠다.

요구사항정의는 아직 확정도 나지 않은 상태에서 현재 화면 설계를 진행 중이고, 다음주에는 화면설계를 한 것을 가지고 고객에게 리뷰를 해야한다.

 

이거 제대로 할 수 있을지 의문이 든다.