Page History

여기서 언급되는 시나리오는 지난15년간 다녔던 모든회사에서 동일하게 경험한 내용을 바탕으로

가상화한 내용이며 지극히 개인적인 경험과 생각이 포함된 뇌피셜임을 먼저 알려드립니다.

기획 문서의 완성도는 기획자 고민 한명만으로 이루어 낼수없으며, 애시당초  퍼펙트한 기획문서는 보지못하였다.

최신 완성품의 내용을 반영하는 기획서 또한 보지 못하였다. 기획서에는 내가 궁금한 내용이 없을뿐더러,

심지어 작동방식을 반대로 설명하는 경우도 있다. 작동기준으로 기획서를 반대로 다시 업데이트하는것 또한 웃긴일이다.

신규 기획과정에서 공유되지 않는 잘못된 모델이 (모델이 아니고 정확하게는 심혈을 기울인 UX이다.)

비지니스 모델을 반영을 하지 못한채 오랫동안 묵혀서 기획 완성본에 들어가 숨어있으며

언젠가 기획문서가 완성되어 개발시작가능합니다란 소식을 듣게 됩니다.

개발자는  장대한 기획서에서 틀린 그림찾기를 시작하고 만약 이것을 빨리 찾지못한다고하면

잘못된 채로 작동하게되며, 심각한 경우 그것이 왜 잘못인지 알지못한채 마법의 기능이 될수도 있다.

폭포수 모델에서 이것은 개발자의 노력을 퍼부어 해결해 왔기때문에, 당연하게 기획의 잘못으로 돌려야만 했고

기획은 도움 안되고,개발자만이 최종 해결자란 인식이다.  필자의 경험상 이와 같은 문제는 항상 반복되어왔다.

기획서를 보면 비지니스 요구사항을 분석하여 반영되었기때문에 준수해야한다란 생각보다   

비지니스 요구사항이 존재하기나 한가? 한심한 기획서를 많이 봐왔다. 더 잘못된것은 비지니스 전문가를 배제한체,

개발자 해석으로 변경이 일어나고 타협을 한다란것이다.  뭔가 잘못되지 않았는가?

더욱이 비지니스 요구사항을 분석해야 할 기획자가(정확하게는 BA이다),이제는 비지니스 요구사항보다

화려한 UI(목업)을 그리는데 능력을 사용하기 시작하였다. 기획서를 보고해야하기 때문이다.

그리고 최근 목업툴의 발전으로 심지어 프로튼 화면 수준까지 UX가 작동되기까지 한다. 

물론 디자인이 중요할때 UX및 레이아웃을 포함 그것 자체를 기획하는 롤이 있고 중요할수도 있습니다.

DDD에서는 어떠한 롤을 누군가가 해야한다란것을 이야기하지 않습니다. 비지니스 전문가,분석가,개발자 개발에 참여한 모든 사람의 소통을 중요하게 생각합니다. 

만약 기획롤이 불분명하다고 하면, 디자이너보다 BA의 역활에 가까운것이 또는 커뮤니케이션을 통해  마법과같은 비지니스의 본질을 파악하여

개발자에게 전달할수 있는 역활에 가까워야 한다란것이 저의 생각입니다.

DDD는 단 한문장으로 이것을 이야기 합니다.  "문서가 대화를 지배해서는 안된다."

참고자료 : BA의 역활 https://brunch.co.kr/@hyunda/33

DDD에서 이것은 누구탓도 아니다. 다음과 같은 질문을 모두에게 던진다.

도메인과 관련하여 나만 알고 있는것이 무엇이고? 당신은 무엇을 알고있고? 우리는 무엇을 같이 알고 있으며, 앞으로 무엇을 알아내야만 하는가?

그리고 이 과정은 모험과 같아서 끊임없는 탐구라고 정의를 내립니다.

DDD 도입은 해결책이 아닌 해결책을 찾기위한 과정입니다.  그리고 성공/실패라고 정의내리기도 어렵습니다.

DDD가 이야기하는 핵심은 

도메인 전문가로부터 지식을 얻기위해서는 커피한잔이면 충분하다.