RND 요구관리자로써의 딜레마

요구관리자는 요구수집,분석,전달,모니터 등의 역할을 가지고 있다

그중 가장 리소스를 많이 낭비하는 업무가 수집과 분석이다

실제 관리 업무는 그렇게 리소스를 할애할 필요가 없다

그리고 업무 수행에 있어서 수집, 분석에서의 딜레마를 가지게 된다


요구사항의 최초 진입점은 다양하다

cs(고객지원), ts(기술지원), sales(영업) 등등

그리고 그들은 한결같이 본인들의 역량 내에서만 요구를 전달한다


가령 cs는 '뭐가 안돼요' 라는 고객의 말을 그대로 전달하기 일쑤다 (고객의 요구를 해결하기 위해 필요한 기술적인 내용이 빠져서 건네져 올때가 있다)
ts는 여기까지 분석은 해봤는데... 이렇게 해보면 되겠죠? (근데 정작 고객이 뭘 원하는지 모르겠다)

sales는 그냥 고객이다


저런 상황에서 reqm업무를 수행하려면 그 사람들을 통해 요구사항을 정제하고 실제 개발집단에 전달해 줄 필요가 있는데...

결국 앞단 사람들의 역량이 높아지면 많은 요구사항들은 그냥 필터링 되어 개발집단에게까지 전달할 필요가 없어진다

RND 최고 윗선들이 바라는 회사 기술조직들의 모습이다


위와 같은 조직도를 위해 필요한게 무엇인지는 모르지만

그런 모습을 갖추려고 그들은 탁상공론과 함께 그동안 무던히도 애써왔다

하지만 결국 지금의 모양새는 각 부서들의 업무 부하를 서로에게 미루려고만 할뿐

아무도 자발적으로 나서서 해당 업무에 대해 적극적인 해결을 하려고 하지 않는다

그래서 개발자가 나서게 된다


이 고민은

내가 경영진이 된다고 했을때도 똑같은 시행착오를 겪게 될 고민같다

결국 사람으로 귀결되는 조직의 문제라고 보인다

내가 안하면 누군가는 해야한다

그래서 서로 눈치보고 배척하고 경계하는 것이다


그리고 객관적인 입장에서 내 업무를 관찰해보면 다음과 같은 결론으로 귀결된다


1. 고객 요구를 수집하는 부서들에게 필요한 사항들을 일러주어 역량을 강화시킨다
- 고객요구의 유형에 따라 필요한 정보들을 최대한 빠르게 사전 수집 가능하다
- 요구 전달 및 분석에 있어 시간 단축이라는 효과를 볼 수 있다
2. 내가 속한 요구관리 부서장도 업무 실적에 민감할테니 요구처리 수치를 높여줄 필요가 있다
- 외부 부서에는 분석에 필요로하는 정보를 바로바로 요청
- 내부 부서에는 수집한 정보에 있어 부족한 부분들과 일정을 피드백 요청
3. 요구사항을 전달받는 개발부서들에게는 최대한 내가 여기까지는 해봤다 라는 원칙으로 전달한다
- 단순한 요구의 내용이 아닌 코드분석 스펙검토 등
4. 최종적으로 고객에게 전달할 내용중 가장 해피한건 '해결했어요~'라는 것이지만
그렇지 못하더라도 우리가 여기까지 노력을 해봤는데 결과적으로 이렇게 밖에 안되네요
라는 말을 할 수 있어야 한다
아니면 이래 이래서 도저히 안되겠네요 라는게 필요하다


결국 고객도 사람이니 사정 얘기하면 들어주겠지

라는 마음으로 업무에 임해야 한다

이정도만 지켜 업무를 수행하면

내부적으로는 팀원들과 외부적으로는 타부서들과의 업무 마찰을 피할 수 있을거라 생각한다