Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

필자의 뇌피셜이 궁금하거나 , 태클없는 분만 열어보기를 권장합니다.

Expand
title내용

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

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


기획 문서의 완성도는 기획자 고민 한명만으로 이루어 낼수없으며, 애시당초  퍼펙트한 기획문서는 존재할수 없다란

명제를 가지고 빈번하게 발생하는 시나리오를 예를 들어보겠다.

보지못하였다.

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

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


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

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

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

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

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


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

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

기획서를 보면 비지니스 요구사항을 분석하여 반영되었기때문에 준수해야한다란 생각보다  잘못된것을 당연하게 개발자가 찾아야하는것이고 

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

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


더욱이 비지니스 요구사항을 분석해야 할 기획자가(정확하게는 BA이다),대부분의 노력을 UX를 그리는데 사용하는것을 봐왔다.

상상력을 캔버스에 그려야하는 기획자는 디자이너인가? 기획을 빨리 적용하려고 완료사항을 체크하는것은 PM인가?

IT에서 기획자 롤이 점점 모호해지는것은 사실이다.

이제는 비지니스 요구사항보다

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

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


Image Added

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

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

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

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

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

참고자료 : BA의 역활 그리고 모호해진 기획의 롤은 디자이너가 아닌 비지니스 분석가에 가깝다(https://brunch.co.kr/@hyunda/33)

그렇다고 DDD에서는 어떠한 롤을 지정하지 않는다. 모두가 도메인 모델분석을 위해 소통을 해야한다란것을 강조하고

구체적인 몇가지 방법들이 존재하고 계속 변화중에 있다.

Image Removed

DDD에서 이것은 누구탓도 아니다. 비지니스 전문가와 소통하지 않으며 진행되는 개발과정 자체와그렇게 개발된 자산(개발코드)에서 도메인에 대한 어떠한 통찰력을 알아낼수 없다는것을 지적합니다. DDD는 다음과 같은 질문을 던집니다모두에게 던진다.

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

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

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



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

...