산출물, 내라고 하니까 낸다?

어떤 프로젝트에서 있었던 일이다. 설계도구의 Sequence Diagram 을 이용해서 호출관계나 대략적인 로직을 표현할 수 있었다. 각 업무의 로직을 설계하기에는 그정도면 충분하다고 생각했다. 그런데 Class Diagram 이 표현되지 않는다면서 별도의 도구를 이용해서 Class Diagram를 그려야 한다는 것이다.

 

개발표준은 이미 도출되어 Layer별로 R&R도 명확하고, SWA등의 아키텍트도 아닌 각 업무에서 Class간의 관계를 표현할 일이 없을 것 같은데, 그래도 혹시 모르니 물어보았다.

 

“Class Diagram이 어느 때 필요해서 그리려고 하나요?” 

“Class 간의 상속관계나 Dependency 등 정적관계 표현이 필요한가요?”

라고 물었더니 돌아오는 대답이

...
“그렇게 까지는 필요 없을 것 같은데… 달라고 해서요”

이게 무슨 말인가? Class Diagram의 작성 목적이나 필요여부가 중요한 게 아니라 누가 요구하니까 제출하라고 해서 작성해야 한다는 것이다. 

 

'아………. 이건 뭐지' 

과거에도 큰 의미도 없고, 잘 보지도 않을 산출물을 품질이 원한다고, 고객이 원한다고, 그렇게 결정되었다고, 일단 내라는 등의 일이 있었다. 그런 직간접적인 경험을 하면서, 이해하긴 힘들었지만 그 당시 상황을 완전히 무시할 수 없었다. 하지만 지금 십몇년이 지났어도 크게 달라지지 않은 이러한 프로젝트 현장이 아직도 있다는 것이 참으로 안타깝다.

그냥 내라고 하니 낸다고 대답하는 설계자가, 개발자가 안쓰럽기도 하지만 한편으로는 시키는 사람 만큼이나 어느 정도의 책임이 있다고 생각한다. 언제까지 그렇게 끌려만 다닐 것인가? 설득하기 쉽지 않을수도 있겠지만, 그렇다고 별 의미도 없는일에 공수를 들여가며 대충대충 칸만 채우는 무의미한 일을.... 계속할 것인가?

물론 위와 같은 상황을 지시한 사람이 더 큰 문제다. Class Diagram 은 수많은 예 중 하나이고 분석, 설계, 개발, 테스트 단계를 거치면서 수많은 산출물을 무리하게 요구하는 그 결정권자는 한번이라도 생각해 봤는가? QA가 하자니까, 감리가 하자니까, 다른 프로젝트도 그렇게 한다니까 그냥 묵인하는 것인가? 그들이 지시하는 산출물이 무엇에 쓰기 위한 용도이고 그 선후 관계나 실제 설계/개발에 얼마나 도움이 될지 등을 한번이라도 고민해보고 지시하는 것인가?

WBS 각 Task에 포함된 산출물을 다시 한번 살펴보라. 불필요한 것은 없는지, 비효율적인 것은 없는지, 꼭 작성해야 하는지, 실제 일하는데 도움이 되는지, 작성하기는 용이한지, 검토가 실제 이루어질 수 있을지, 더 좋은 방법은 없는지, 작성하기 더 좋은 도구는 없는지 등을...