W,
한국에서 기획자와 개발자들간의 불화, 이질감, 오해들은 W 자네도 이미 알고 있으리라 믿네. 함께 100% 협력해도 성공적인 프로젝트가 될 지 안될 지 모르는 마당에 이렇게 삐걱거리는 관계는 회사의 경쟁력에 치명적일 수 밖에 없겠지. 양쪽 얘기를 다 들어봐야 서로의 입장차이만 확인할 뿐 아무런 도움이 되지 않을걸세.
왜냐하면 근본적인 문제는 기획자에게 바라는 산출물에 대한 회사와 개발자들의 요구사항이 명확하지 않다는데 있는 것일세. 즉, 언제부터 기획자들의 ppt 파일이나 doc, 혹은 visio 파일들이 기획 산출물인양 굳어져 버렸는 지. 우선 이런 문서들이 개발에 도움을 주는 지, 부족하다면 무엇을 어떻게 명확하게 요구해야 하는 지. 이런 질문에 대한 연구나 아이디어가 없다는 것은 결국 기획자와 개발자들 그리고 회사의 임원들 모두의 문제인 것일세.
일단 이 두 department간의 불화를 없애고 협업을 높이기 위해서는 개발자들이 먼저 intiative를 쥐어야 하네. 즉, 개발자들이 자기들이 필요한 기획산출물을 명확하게 요구할 수 있는 능력이 되어야 하는 것이지.
이를 위해서 testing tool과 pair programming을 활용하면 좋을 것일세. 즉, 개발자와 기획자가 pair programming기법을 통해서 test 주도 개발 방법을 실천한다면 아주 좋은 효과를 거두리라 믿네. 자네도 알다시피 testing tool은 결국 design툴이지 않은가? 개발자가 unit test 와 acceptance test를 구현해 나갈 때 함께 기획자가 옆에서 기획과 디자인의 input을 주게 하는 것이지.
이를 통해서 얻는 장점은 먼저 지금까지의 "기획먼저 개발 그 다음" 이라는 전통적인 waterfall방법을 벗어날 수 있는 것이 하나요 그리고 개발자에게 직접적으로 필요한 Test라는 산출물이 그 두번째 장점이 되는 것이지. 그리고 기획자들도 알아야 할 것은 자기가 기획한 내용의 30%는 나중에 쓰이지 않거나 변한다는 것을 깨닫고 어떻게 하면 변화하는 고객의 요구사항을 만족시키는 iterative한 기획을 할 수 있는 지를 연구해야만 한다는 것이지.
그리고 자네 회사에서 이런 test 주도 개발을 선택한다면 기획자들의 능력이 올라가지 않는다 하더라도 개발자들의 능력과 최종 프로그램의 품질은 그래도 옛날보다는 나아질 것일세. 내가 이런다고 말을 한다고 기획을 무시한다고 오해는 말아주게 난 누구보다 기획의 중요성을 잘 알고 있지. 현재 자네 회사의 mindset 안에서의 기획활동으로는 개발자와 기획자의 협업향상은 커녕 프로젝트 성공여부도 확신하기 힘들다네.
그리고 더욱 중요한 것은 이 테스팅툴들은 모두 open source들인 경우가 태반이고 내가 볼때는 일반 워드 문서 작성보다는 훨씬 재미가 난다네 개발자와 기획자 모두가 좋아할걸세. 그리고 고객과의 communication도 훨씬 명확해지면서 고질적인 막판 요구사항 뒤집기도 줄어들 걸세. 그건 나중에 내가 solution centric 디자인이라는 주제로 한번 얘기하겠네.
그럼 Y가