[2편] 웹 개발자가 선호하는 기획자.. 그리고 기획안...

 

지난 1편에서는 기획자, 디자이너, 개발자 간의 삼각관계에서 개발자의 입장에서 봤을 때 기획자가 위치해야 할 포지션과 본격적인 기획단계 이전에 개발자와 같이 의논할 수 있는 요구사항 정의서 작성에 대해 이야기 했었는데요, 오늘은 기획자에게 원하는 개발자의 요구사항을 좀 더 이야기 해볼까 합니다.

 

테스트를 꼼꼼이 해야 개발자에게 할 말이 많다.

 

개발을 하면서 제일 정말 제일 아쉬운게 뭐냐고 묻는다면 바로 기획자가 해주는 테스트 입니다.  개발자가 테스트를 병행하며 개발하는 데에는 늘 한계가 있습니다.  일의 부하는 둘째치고 보통 개발자가 테스트를 하는 경우, 업무 성향의 특성 탓인지 어떤 값이 어떻게 들어가야 정확한 값이 나오는지에 대해 누구보다 잘 알다보니, 늘 정답만을 넣게 됩니다. 

 

다시 말해, 잘못된 값을 넣을 때의 상황을 유추하거나 하는 부분에서 기획자에 비해 상대적으로 취약할 수 밖에 없으며, 이러한 업무성향의 차이가 테스트 할 때 자연스럽게 정규절차로 흘러가버리곤 해서 본인이 직접 개발한 서비스 임에도 불구하고 의외로 오류를 찾아 처리하기가 쉽지 않은 경우가 많습니다.

 

 

예전에 항공티켓 세일 프로모션 이벤트를 진행한 적이 있었는데, 이런 경우에는 프론트에서 데이터가 들어오고, 백오피스에서 데이터를 핸들링해주는 관계가 있기 때문에 최대한 많은 경우의 수를 테스트해서 오류범위를 줄여줘야만 했었습니다.  구매자에게서 얻을 수 있는 정보는 발권을 할 수 있는 최소한의 정보였지만, 이 사람이 결제를 하는 순간 함께 맞물려갈 결제에 관련한 데이터는 경우의 수가 다양하게 늘어나게 됩니다.

 

그 결제관련 정보(이 사람이 신용카드로 결제했는지, 얼마를 결제했는지 또는 어떤 카드로 결제했는지 등등..)들은 백오피스에서 모두 열람이 가능해야하며, 그 자료를 가지고 항공티켓 발권을 어떻게 할지 운영단에서 핸들링할 수 있도록 여러가지 상태별로 업데이트 하며 확인해 줘야 합니다.

 

적어도 본인 스스로 구매할 때 결제가능한 모든 옵션(신용카드, 체크카드, 가상계좌, 실시간계좌이체 등)별로 결제해보고, 가상계좌도 실제 입금처리를 해보고, 그에 따라 구매의 상태가 정상적으로 변경되고 있는지, 백오피스에서 체크해보고, 놓친 부분은 없는지 추가해야하는 건 없는지 실제 운영해야하는 담당자라 생각하고 백오피스로도 많은 액션을 취해보아야 합니다.

 

 

또한, 프론트에서는 회원이 사용했을 때 어떤 액션을 어떻게 하느냐에 따라 나와야 하는 메세지는 제대로 나왔는지, 빠진 건 없는지.. 기능상의 오류만이 아니더라도, 기획하다가 놓친 부분이 있어 메세지 전달이 약하다면, 보완하고 요청해서 더 넣는다는지 등, 테스트를 통해 기능에 대한 오류만을 잡는 것이 아니라, 테스트를 통해 기획 상 보완해야하는 부분도 함께 보완해서 시스템을 더 다져줘야 하는 것입니다.  덧붙여 웹표준까지 신경써야 한다면, 크로스브라우징도 체크해 보아야겠죠.(위의 일련과정을 브라우저 종류마다..모두 테스트를 해야하는 것이죠. 아 씨발...)

 

이처럼 테스트 범위가 어마어마하기 때문에 좀 귀찮다는 이유로.. 혹은 나중에 문제 생기면 고치면 된다는 마인드로 제대로 테스트하지 않고 서비스 오픈을 한다는 것은 매우 큰 문제 입니다.  오픈일자가 촉박해 모든 브라우저를 체크할 수 없다면, 어느 브라우저에서는 이러한 기능에 문제가 있다는 것 정도는 기획자도 알고 있어야 운영자에게 전달해주고, 회원에게 문의가 왔을때에도 바로 설명이 가능 할 수 있겠죠.  회사에 따라 QA팀이 있다 하더라도 전체 흐름에 대한 이해는 기획자가 가장 잘 알고 있기 때문에 누구보다도 제일 먼저 꼼꼼이 살펴보고 체크해하지 않을까요?

제 경험 상, 개발자는 흐름이 이상하다고 해서 뭔가 앞뒤가 안 맞는다고 해서 이거 이상하니 이렇게 수정하자. 라고 기획자에게 되묻는 경우는 거의 없지 않을까 싶습니다.  프로세스가 좀 이상하다 한 들... 기획자가 이렇게 하고 싶은거겠지. 라고 생각하고 수동적으로 움직이는 편이죠.(다시 한번 말씀드리지만 개발자는 요구한 기능에 이상이 없으면 개발이 끝났다고 생각합니다.)

 

따라서, 테스트를 통해 기능에 대한 오류만이 아니라, 기획을 보완할 수 있는 중요한 시점이라 생각하고 계속 개발자에게 아주 소소한 것부터 끊임없이 전달하고 수정요청을 해야하는 것입니다.  수정요청을 하실때 개발자가 한 명이고 다른 유지보수를 하지 않고 해당 서비스의 디버깅 준비가 되어 있는 상태라면, 그때 그때 수정했으면 하는 부분을 메신저로 계속 요청하시는 것도 방법이겠지만, 기왕이면 1차 테스트를 통한 수정사항 목록을 메일이나 문서로 전달해서 완료가 됐는지 안됐는지 피드백을 받을 수 있도록 하는게 서로에게 좋습니다.

 

개발자도 사람입니다. 

 

텍스트 수정이야 그때그때 할 수 있다지만, 기능상 오류나 프로세스 상의 오류를 잡기 위한 수정요청이라면 시간이 소요될 수도 있을텐데 메신저로 계속 이것도 수정해주세요, 저것도 수정해주세요. 해버리시면 개발자는... 짜증이 날 것이고... 급기야 요청이 쌓이면 열폭 하기도 합니다.  물론 경우에 따라.. 기획자가 꼼꼼히 테스트해서 수정 이슈가 한가득 담긴 수정자료가 많아질 경우, 어떤 개발자는 '그러게 진작부터 기획안을 잘 써서 줘야할거 아니냐.' 라고 짜증스럽게 이야기할 수도 있을 겁니다. 그럴 땐 일단 굽히세요. 잘 구슬려서(제가 이런 표현을 써도 되는것인지 모르겠습니다...ㅠㅠ) 일단 완성도를 높이셔야죠. 개발자가 싫은 소리한다고 절대 적당히 넘어가시면 안됩니다.

 

이런 상황이 반복되면 기획안을 쓰는 사람도 시간이 지날수록 더 꼼꼼히 기획안 작성을 하게 될 것이고, 담당개발자도 이제 누가 주는 기획안이냐에 따라 조금 더 신경써서 개발하지 않을까 싶습니다.  극단적으로 개발자는 서비스의 성공엔 큰 관심이 없습니다. 물론 개발자 모두가 그런 것은 아니겠지만.. 단지 개발을 완료 했을 때, 다시 뒤집거나 많은 내용을 수정해야 하는 기획안에 대해.. 그리고 그런 기획안을 쓰는 기획자에 대해 신뢰하지 않을 뿐입니다.  다시 말해, 날 번거롭게 하지 않을 기획자를 선호한다는 이야기겠죠..

 

 

개발자가 개발하기 쉬운 기획안?

 

언젠가 외주업체에 사이트 리뉴얼을 맡긴 적이 있었습니다.  외주개발자가 개발하는 걸 보고 있는데, 놀라운 상황을 목격했습니다.  개발자가 기획안 없이 개발을 하더라구요.  정확히 다시 말하면 개발자가 기획안을 프린트하지 않은 채 필요하면 그냥 기획안 PPT를 열어놓고 보면서, 코딩된 파일들만을 가지고 개발을 하고 있었습니다.  코딩된 파일은 모두 개발하기 편하게 버튼마다 가야하는 화면 링크가 걸려있었는데요.  종이 아끼려고 기획안을 출력하지 않은 걸까요? 당황스러울 따름이었습니다.

전반적인 리뉴얼 사이즈가 좀 크다보니, 기획안이 책한권 나오는 건 사실이었지만, 그렇다고 기획안도 없이 개발을 하다니요.  적어도 개발자라면 본인이 개발하고자 하는 기획안은 프린트해서 쭉 훑어보고, 이해가 되지 않거나 이상한 부분은 체크해서 담당 기획자에게 문의하고 메모해놓는 걸 기본이라고 생각했던 저 이기에, 그 개발자의 행동은 이해가 되지 않았습니다.

 

역시나 그 개발자는 파일만 틱 열어놓고 개발하다 막히면 물어봤다가, 막상 개발에 집중하다보니 물어봤던 내용의 답변을 잊어버려서, 자기가 질문했었다는 것도 잊은 채 다시 같은 질문을 하더군요. 다른 페이지에서 동일한 화면이 나왔는데, 또 질문을 하고. 같은 대답을 해주는 상황이 벌어졌었습니다.(그 개발자는 기획안을 우습게 알거나, 기획안 따위 보지않고 코딩된 파일만으로도 충분히 개발할 수 있는 자신감 충만한 개발자였는지도 모르겠습니다.)

하지만 결과적으로 기획안에 대한 이해가 없으니 서비스 전체에 대한 이해도 없고, 본인이 말한 개발일정을 지키지도 못할 뿐더러 앞으로 남은 개발범위 조차 가늠하지 못하더군요. 그 개발자는 초반 기획하는 동안 다른 프로젝트에 투입됐다가, 인력이 부족해 뒤늦게 투입되었고, 본인이 맡은 부분은 백오피스만 해야했기 때문이었는지 데이터가 어떻게 들어오는지, 다른 서비스와의 유기적인 관계에 대해서는 관심이 없고 본인이 개발해야하는 부분에 대해서만 보고 있었습니다.

개발자의 Attitude가 맘에 안 들었지만, 사실 그 개발자에게 보다 화가 난 상대는 외주기획자였습니다.  뭐 회사에서 어떤 상황이었는지 모르겠습니다만, (어쩌면 이 프로젝트 말고 다른 프로젝트를 같이 하고 있었겠는지도 모르겠습니다.) 개발자가 그런 상황이었다면 그런 개발자를 끌고 갈 수 있는 사람은 기획자 입니다. 기획안을 넘겨줬다고해서 본인의 역할이 끝난 건 아니라고 생각합니다.

 

결과도 중요하지만, 무언가에 임하는 자세도 중요합니다.

 

중간에 투입된 개발자라면 더더욱 기획안에 대한 이해를 할 수 있도록 기획자가 지속적으로 관심을 가지고 이야기하고 설명을 했어야한다고 생각하는데(결국 개발자를 앉혀놓고, 저희 기획팀장님이 들어가서 일일이 설명하고 이해시키는 모양으로 가고, 개발일정 때문에 개발범위가 큰 부분에 대해 기획적인 요소를 축소해가며 일정 내 개발 할 수 있도록 끌고 가야만 했습니다.) 

 

물론 잘잘못을 따진다면 기획안을 숙지하지 않은 개발자의 잘못이 더 크다고 할 수 있지만, 정작 서비스가 오픈되고 문제가 생겼을 때, 가장 큰 책임을 지는 사람이 바로 기획자 입니다.  때문에, 해당 기획안을 작성한 기획자라면 본인이 작성한 기획안이 끝까지 잘 마무리될 수 있도록 관심을 가지고 지켜봐야 하며, 가능하다면 전체 리뷰만으로 기획에 대한 설명을 하는 것이 아닌, 꼭지 단위로 취지와 주요 기술적 포인트를 짚어주는 게 바람직한 기획자의 역할이라 생각합니다.

개발자가 개발하기 쉬운 기획안이란건 없습니다. 그냥 기획안은 나쁜 거... 기획안은 개발자를 위해 혹은 디자이너를 위해 작성하는게 아니니까요.  제 관점에서의 기획안은 누군가를 위해 누가 보라고 작성하기 보다는 서비스에 대한 기획자의 생각을 시각적으로 전달하기 위해 정리해놓은 것이라고 생각합니다.(물론 이러한 의견은 지극히 주관적인 개발자 입장에서 입니다.) 

 

하지만 차선책으로 선택할 수 있는 방법은 있습니다.  본인이 기획하고자 하는 서비스에 대한 이해를 개발자에게 전달하려면, 요구사항을 정의할 때부터 개발자를 배제하고 이야기하는게 아니라, 담당 개발자가 있다면 늘 아이디어를 공유해주시고, '자 내가 이런걸 생각하고 있어...'라고 지속적으로 어필하고, 인지할 수 있게 해주세요.

 

기획 아이디어는 있는데 기능상 구현이 될 지 안될 지에 대해 넌지시 가능한지 물어보면서, 당장할 건 아니지만 이런 비슷한걸 하려고 하는데 가능할지? 등등... 그리고 난 후, 해당 내용이 담긴 기획안을 작성해서 개발자에게 전달한다면, 개발자가 잘 이해하고 있는 기획안은 될 수 있을 겁니다...

 

 

미시깽. 토끼같은 귀여운 딸래미 둘과 사과같은 남편과 살고 있는 웹개발 13년차.  아이러브스쿨과 SK커뮤니케이션즈 등을 거쳐, 국회입법조사처와 한국지역정보개발원에서 IT관련 빡센 행정업무를 경험하고, 세훈항운(주)에서 다시 웹개발을 시작, 자회사인 (주)온필에서 기술개발팀장으로 있으면서, 여행업이라는 새로운 분야에 대해 배우는 마음으로 시스템 개발에 매진 중.