|
어줍잖은 경험과 개발자와의 대화를 통해 많은것을 느끼곤 합니다
개발자는 "왜 기획을 이따위로 했어"
기획자는 "왜 개발을 이따위로 했어" 따위의
서로 이해할 수 없는 평행선의 간극을 유지한채로 말이죠
개발자는 개발자대로 기획자를 욕할 수 밖에 없는 고충이 있고
기획자는 기획자대로 개발자를 욕할 수 밖에 없는 서로의 고충이
별개의 의견으로 들어보면 둘다 나름의 이유가 있고 설득력이 있습니다.
기획자의 입장으로 프로젝트가 왜 산으로 갈수밖에 없는지 중요한 몇가지를 얘기해보고자 합니다
1. 클라이언트는 눈으로 보여주기 전에는 자기가 요구하는게 뭔지 모름
클라이언트가 만들고 싶은게 있습니다. 근데 그게 대게는 굉장히 모호합니다.
"두근두근 우체통 처럼 랜덤채팅 어플을 만들고 싶다" , "티몬같은 소셜커머스를 만들고 싶다"
이정도만 되도 차라리 낫습니다. 대충 스케치라도 되어 있는 상태거든요
하지만 클라이언트의 요구조건은 어제밤 꿨던 꿈처럼 굉장히 모호합니다
디자인은 깔끔하고 모던하며 심플해야 하고 기능은 초보자도 매뉴얼 없이 한방에 이해할 수 있을 정도의
직관적인 UI여야 하며 완성된 후에도 자기가 요구한 기능은 바로 적용가능할 정도의 확장성이 있어야 합니다.
들어보면 굉장히 그럴듯 하지만 만드는 입장에서는 굉장히 애매합니다.
저 모호한것이 디자인이라면 차라리 괜찮지요. 3개 정도 다른 시안을 들고 가서 각자의 장점을 설명하며
이빨을 막 털면 먹힐때도 있거든요. 근데 기능상으로 모호하면 문제가 굉장히 복잡합니다.
클라이언트는 화면설계서나 디자인을 봐서는 이게 어떻게 구현될건지 잘 이해하지 못합니다.
프로토타입 수준이라도 어느정도 결과물을 내밀어야 그때부터 조금씩 이해하기 시작하죠
3개월 짜리 프로젝트라면 기능상으로 어느정도 구현된 상태에서 클라이언트에게 내밀수 있는 수준은
빨라도 2개월째 정도인데 클라이언트는 어느정도 완성된 프로토타입을 보면서
자기가 생각했던 이상향과 결과물의 차이. 그리고 막상 결과물을 보니 요구조건 미팅때는 생각나지 않았던
기상천외한 아이디어들이 뉴런속 깊은 곳에서 막 쏟아져 나오기 시작합니다.
그 요구조건들은 아예 적용할 수 없을 정도로 기상천외하거나 적용은 가능한데 개발 기간이 부족하거나
그걸 적용하려면 지금 프로젝트를 갈아엎고 새로 시작해야 하는것들이 대부분입니다.
클라이언트의 요구조건이 모호해서 기획자의 입장에서는 어떻게든 구체화를 시키려고 하면 기획 기간이 길어져서
프로그램 개발 기간이 줄어들고 오픈 일정이 빡빡해집니다. 이것도 이것 나름대로 문제지요.
모호한 요구조건을 해결하는 방법은 여러가지가 있습니다.
클라이언트의 모호한 요구조건을 다양한 프로토타입을 제시하면서 최대한 구체화시키던가
경험을 바탕으로 클라이언트가 요구하는 요구조건을 예상해서 그것이 맞는지 클라이언트에게 설명해서 구체화하던가
근데 이렇게 해도 클라이언트의 요구조건은 80% 정도밖에 이수하지 못합니다. 이건 어쩔수 없는 부분이거든요.
자기도 모르는걸 저라고 알겠습니까? ㅎㅎㅎㅎ 대충짐작만 할뿐이지 100% 완벽하게 알수는 없는거니까요
2. 담당자들 사이에 이해관계, 고지식한 윗분들
SI 업체에서 기피하는 3대 클라이언트가 있습니다
지자체, 병원, 학교
위 3개의 클라이언트는 사공이 너무 많습니다. 각자 요구하는것도 원하는것도 다 다릅니다.
그러면 담당자가 서로 이해관계를 조율하고 포기시킬건 포기시켜야 되는데 담당자는 사공들에게 휘둘리기 바쁩니다.
담당자가 젊으면 젊은데로 힘이 없어서 휘둘리고 나이가 좀 있으면 잘 몰라서 모르는대로 휘둘립니다.
학교나 병원 홈페이지를 만드려면 수십명의 담당자를 만나야 합니다.
근데 수십명의 담당자들은 겁나 바쁩니다. 홈페이지를 잘 만들어보려는 의욕이 있는 분들도 몇 안됩니다.
요구조건이 다 다릅니다. 담당자는 막 휘둘립니다. PM는 요구조건을 서로 봉합하고 나름대로 절충안을 찾아서 제시합니다.
자료를 요청합니다. 근데 자료가 잘 안옵니다. 작업과 일정이 점점 지연됩니다.
힘들게 어느정도 결과물을 만들어서 시연을 했습니다. 근데 윗분들이 메인페이지가 마음에 안든다고 합니다.
(그럼 우리가 시안 만들어서 컨펌 받은건 뭔데 ㅋㅋㅋㅋ) 윗분들도 결과물을 봐야 알거든요
꽤나 이상한 요구조건들이 등장합니다. 사장님의 페이지를 부각시켜달라, 메인페이지에 사장님의 얼굴을 넣어달라
전체적인 컬러감이 마음에 안든다. 레이아웃을 바꿔라.
저 요구조건을 들어주면 사이트가 망가질것 같은 강한 촉이 옵니다.
근데 안해줄수는 없습니다. 모든 사람이 마음에 들어도 사장님이 마음에 안들면 끝이거든요.
철밥통인 아랫분들은 사장님에게 절대 대항할 수 없습니다. 사장님이 곧 법이니까요
그래서 PM은 미연에 이러한 사태를 방지하기 위해 초기부터 윗분들과 부단히 컨택을 시도합니다.
근데 담당자가 중간다리 역할을 제대로 수행하지 못합니다. 담당자를 재끼고 사장님과 컨택을 시도할수는 없으니까
일단 최대한 컨택이 가능한 윗선까지 OK를 받아놓고 프로젝트를 진행합니다
그래도 사장님이 마음에 안들면 책임은 PM에게 돌아옵니다. PM 입장에서는 꽤나 억울하지요
요즘 트랜드는 미디어쿼리니 SNS라는 말을 어디서 주워들었습니다. 적용해달라고 합니다.
근데 SNS 계정도 없으시고 운영인력도 없으시잖아요? 우리 사이트가 미디어쿼리 적용이 가능하신지 생각해보셨는지....
트랜드에 겁나 휘둘립니다.
3. 까보기전에는 알 수 없는 다양한 이슈사항들
3개월 짜리 프로젝트가 기획 / 디자인 / 코딩까지 1.5개월만에 순조롭게 마무리되었습니다.
개발만 남았어요. 개발을 시작하게 위해 프로그램 작업을 진행하다보면 다양한 이슈사항이 쏟아지게 됩니다.
이슈사항은 예상 가능한것도 예상 불가능한것도 있습니다. 아무리 뛰어나고 경험많은 PM 이라고
예상가능해서 미연에 대처가 가능한 이슈사항이 7, 짐작도 하지 못한 이슈사항이 3 정도 나옵니다.
이슈사항은 굉장히 다양한곳에서 발생됩니다.
서버, WAS, DB 등등 걔중에는 겁나 크리티컬한것도 다수 존재하지요
짐작도 하지 못한 이슈사항은 대게 굉장히 크리티컬합니다
운영서버는 제우스인데 톰켓으로 개발했다가 운영서버 올렸는데 안돌아간다던가
JDK 버전을 착각해서 개발했다가 뭔가 프로그램이 안돌아간다던가 DB 이관을 하는데 비밀번호가 암호화되어있다던가
PM이 노련해도 개발자가 노련하지 못하면 이슈사항이 발생될수도 있고
개발자가 노련해도 PM이 노련하지 못하면 이슈사항이 발생될수도 있습니다
(사실은 이쪽에서 발생하는 이슈사항이 대게는 더 크리티컬합니다)
그래서 프로젝트는 오늘도 산으로 갑니다. | |
|
등록안내
등록안내
0
0
한미남
