필자는 업계의 여러 사람과 얘기할 기회가 많다.
최근에 한 대형 SI회사의 한 PM과 얘기를 한 적이 있는데 프로세스 상의 큰 문제가 있었고, 실제 프로젝트팀에서는 잘못된 프로세스로 인해서 어려움을 겪고 있었다.
SI회사의 오랜 바람 중의 하나가 "공정분리"이다. 즉, 분석/설계/구현을 분리해서 프로젝트를 진행하는 것이다.
"공정분리"가 되지 않은 상태에서는 분석/설계/구현이 뒤엉켜서 개발을 진행한다.
"공정분리"는 분석을 잘해서 설계자에게 넘겨주면, 설계자는 설계를 잘해서 개발자에게 넘겨주고 개발자들은 설계서 그대로 코딩만 하면 되도록 하려는 것이다.
최근 해외 프로젝트가 증가하면서 분석/설계/구현을 뒤엉켜서 진행할 경우 코딩하는 개발자까지 해외 파견을 해야 한다. 그래서 공정분리는 점점 필수가 되었다.
그래서 진행한 것이 해외에서 "분석/설계"를 잘 해서 넘겨주면 국내에서는 개발자들은 그대로 "구현"만 하면 되도록 하는 프로세스를 만든 것이다.
실제로 이 프로세스는 잘 작동하지 않고 있다고 한다. 그동안 해오던 방법과 역량이 분석/설계를 해도 "구현"은 이와 상관없이 알아서 진행하고 모르면 분석가에게 물어가면서 코딩하던 수준이었다. 이런 상황에서 이 프로세스가 잘 작동할리가 만무하다.
이렇게 공정을 분리하려면 "분석/설계" vs "구현" 보다는 "분석" vs "설계/구현"이 더 낫다.
설계가 구현에 좀더 가깝고, 잘된 분석서를 가지고 충분히 "설계/구현"을 할 수 있기 때문이다.
여기서 또 오해가 있는 것이 설계를 잘해서 넘겨주면 그대로 코딩만 하면 될 줄 아는 것이다. 현실에서는 이렇게 잘 진행되지 않는다. 이렇게 하기 위해서는 설계를 너무 자세히 적어야 하고 실제 구현시 많은 문제를 발견하게 된다.
더 좋은 방법은 설계는 꼭 필요한 만큼만하고 구현에 적당한 자유도를 주는 것이다.
이렇게 제대로 "공정분리"를 하기 위해서 대전제가 하나 있다.
바로 "분석"역량이 뛰어나야 한다는 것이다. 뛰어난 분석가를 많이 보유하고 있어야 한다.
현재의 분석역량은 기껏해야 "기능"분석과 약간의 "비기능"을 분석하는데 그치고 있다. 분석이 무엇인지 짧은 글에 일일이 설명하기는 어렵지만 분석은 이보다 훨씬 크고 어려운 일이다. 비즈니스전략도 포함해야 하고, 설계도 일부 포함한다.
필자의 생각으로는 이 SI회사는 당분간 프로세스의 시행착오를 좀더 겪을 것으로 생각된다. 잘못된 프로세스를 바로 잡는데 시간이 걸릴 것이고, 분석역량을 끌어 올리는 일에 시간이 좀더 걸릴 것이다.
시행착오를 겪는 시간은 짧을수록 좋다.
요즘 써주신 글 중에서 가장 좋은 글인 것 같습니다. ^^
답글삭제보석 같은 키워드들이 많네요. - 자유도, 분석의 중요성 등
분석이 참 중요하죠.
초기 방향을 잘못 잡으면, 팀원이 아무리 열심히 해도 엉뚱한 방향으로 가는구나 하는 느낌이 듭니다.
그나저나 SI는 워낙 넓은 분야를 커버하다 보니,
깊이 있는 분석이란 참 뛰어난 분들의 영역인 것 같고요~
고맙습니다.
제임스님 안녕하세요.
답글삭제SI회사의 분석가들은 분석역량보다는 도메인지식이 뛰어난 사람이 많습니다. 고객의 업무를 고객보다 잘 아는 경우가 많지만 업무지식을 쌓아가는 방식으로 성장하다보니 분석 역량이 떨어져서 고객의 요구사항 파악이 부족하고 스펙관리가 떨어지고 설계/개발자에게 스펙 전달이 잘 안됩니다. 결국에 분석가가 구현단계까지 도움을 많이 줘야 하는 경우가 많습니다.
이러다보니 세계적인 방법론을 도입해서 문서만 수십가지를 만들어도 별로 나아지는 것은 없이 문서를 많이 만들려고 고생만 합니다.
세계적인 방법론보다는 제대로된 분석 역량을 익히는 것이 더 중요합니다. 결론은 전문가에게 배우는 거죠. ^^
설계자와 개발자의 롤이 명확한(철저히 분리된..) 프로젝트를 한 적이 있는데, 설계단계 진행시 설계자 설득하느라 바쁘고 개발단계 진행 시 개발자와 설계자 커뮤니케이션 문제 때문에 아주 골머리 썩었었습니다.-_ㅜ
답글삭제개발자들은 투입되자마자 설계문서를 파악하고 코딩에 들어가야 하는데, 작성가이드를 해 준 설계문서의 항목이 너무 많고 자세하다고 설계자들이 반발.. 하지만 아무리 생각해 봐도 그정도의 설계항목이 본문에 말씀하신 "꼭 필요한 만큼" 이라고 생각이 되어 개발자들이 코딩하려면 그정도는 설계를 해 줘야 코딩들어갈 수 있다고 설득하느라 한참 시간 보내고,
또 막상 개발자들이 코딩 들어가니 왠걸 진짜 "설계문서에 있는 기능만" 구현을 해 놓더라구요. 예를 들면 단위테스트 진행 시 기본적인 유효성검사도 되어 있지 않아 개발자에게 말을하면 "설계문서에 없었다."... 설계자들은 어떻게 그런것 까지 문서화 하냐, 필수입력이라고 해 놓았으면 당연히 유효성체크 해놔야 하는거 아니냐고 서로 싸우고...
본문의 내용이 너무나도 공감가서 한마디 적고 갑니다...
좋은 글 항상 잘보고 있습니다. 항상 감사합니다. ^^
제가 고민하던 내용을 정확하게 짚어 정리해주시니 너무 공감됩니다. 이런 경험들을 기록해두는 것이 매우 중요하다는 생각이 듭니다.
답글삭제안녕하세요. LInE. 님
답글삭제항상 시행착오를 통해서 배우지만, 시행착오를 가장 적게 겪는 것이 중요한 것 같습니다. 시행착오를 겪다가 너무 오랜 시간이 지나기도 하죠. ^^
감사합니다. Manwal님
답글삭제최근 다른 회사와 프로젝트를 진행하게 되었는데, 그 회사에서는 약 3년을 끌어온 개발건이 있었습니다. 전규현님의 글들에 늘 나오는 대로 스펙과 설계 등의 문서는 아예 없고, 개발팀장이 교체될때마다 주먹구구식으로 진행이 되어왔기에 1년을 예상하고 시작한 프로젝트가 3년이 되어도 완결이 안되고 있더군요.
답글삭제이러한 상황에서, SI회사 혹은 컨설턴트를 통해 분석/설계 부터 다시해서 새로 시작하는 것이 나을지요?
내부에 개발자를 채용해서 진행을 하는 것은 많이 지친듯 보입니다. 사람도 요새는 더 뽑기도 어렵구요...
안녕하세요. GF님
답글삭제이미 망쳐 놓은 경우가 가장 어려운 경우입니다.
제가 SI회사도 컨설팅을 하고 교육을 하기 때문에 꽤 아는데 SI회사도 분석/설계 역량이 별로 없습니다.
일단 이대로 진행해서 어떻게든 마무리 하는 방법과 다시 분석/설계를 진행하는 방법을 비교해 봐야 하는데 현재 진행상황이 어느 정도 인지 파악을 먼저 해야 합니다.
분석/설계를 다시 진행하려면 직접 하시던지, 저희회사에 의뢰를 하는 것이 좋을 것 같습니다. 직접 하시면 시행착오를 겪을 수는 있지만 그래도 내용을 잘 아실 것이기 때문에 가능할 수도 있습니다.
혹시 진행하시다가 궁금한 점이 있으면 메일로 문의해주세요. 진짜 답답하시면 제 사무실로 한번 찾아오시면 자세히 설명 드리겠습니다. ^^