웹기획 이해하기 - 강좌12, 개발자들과의 문제를 해결하는법

웹기획 이해하기 - 강좌12, 개발자들과의 문제를 해결하는법

현업에서 기획자와 개발자들이 부딛히는 가장 큰 문제는

첫번째. 기능의 구현가능여부

두번째. 구현기간의 논의

세번째. 기능설계상의 문제로 볼 수 있다.

# 이 기능이 구현 가능할 것인가?

첫 번째로 ‘이 기능이 구현 가능할 것인가?’로 개발자와 기획자의 설전은 시작이 된다. ‘이 기능은 구현 못합니다.’라는 말을 들었을 것이고 그 말에는 여러 가지 이유가 따른다.

1. 기획자가 인공지능의 기능구현을 요구하는 경우

2. 개발자의 태도가 일을 크게 만들지 않으려고 거부하고 보는 경우

3. 기능구현이 정말 어려운경우

4. 현 인력의 능력으로 부족한 경우

그래서 기획자는 수시로 타 사이트를 벤치마킹 해야 한다. 어떤 기능들이 어떤 서비스를 하고 있는지 그게 가능한 건지 가능하다면 다른 사이트들은 얼마만큼 쓰고 있는지, 그래서 나름대로 파악을 해야 한다. 이런 경험적 배경지식을 갖고 기능구현의 여부를 개발자와 논의하는게 협상을 성공적으로 이루는데 많은 도움이 된다. 필자가 개발자일 때 고객의 담당자로부터 정말 인공지능 시스템과 같은 기능의 것을 해달라 요청 받은 적이 있다. 정말 얼토당토 않은 이야기여서 논리적으로 정중히 거절 했다. 그걸 업무로 받아와서 일로 만들어버리면 개발자와의 마찰과 서로간의 신뢰는 급격히 무너지게 된다.

2번과 같은 경우는 1번보다 더 어려운 부분이다. 필자도 이런태도가 많았다고 양심선언 하겠다. 우선 일이 갑자기 주어지면, 개발자들은 충격이 크다. 그래서 일단 거부다! 그래서 기획자는 충격을 완화시켜주는 방법을 구사해야 한다. 미리미리 조금씩 정보를 흘리는거다. 처음엔 ‘어떤기능을 함 생각해 보는데 어떨까 생각한다.’라고 흘린다. 그 다음 번에 ‘이런건 어떨까요?’ 점점 더 다가가는 거다. 그리고 마지막에 설계문서를 가지고 그동안 이야기 했던걸 이렇게 설계했는데 기술적인 검토를 해달라 말하면 보다 쉽게 이 문제를 해결 할 수있다.

엔지니어들은 대부분 일정을 체계적으로 관리하며 수치적으로 표현하길 좋아한다. 그리고 기획자가 한마디 했을 때 그것이 구현가능한지 얼마나 걸리는지 순식간에 파악하며 , 기획자가 ‘구현가능’만을 묻는데도 ‘못한다’ 말하는데 그것은 ‘기능구현이 안 된다’ 이기 보단 나머지 외부환경이 조합된 말일 경우가 많다. 그러니 외부 환경요인에 대한 설명과 같이 설득하는 것이 성공으로 가는 지름길이다.

3,4번의 경우는 오히려 해결이 간단하다. 기능이 정말 어려운 경우는 대안을 찾아야 한다. 대안을 찾는것은 개발자의 몫이기도 하지만 기획자의 몫도 된다. 버터를 쓰면 좋겠지만 마가린을 쓴다해서 크게 다르지 않는 경우가 많다. 문제가 어려울땐 돌아갈수도 있어야 한다. 또한 현 인력의 능력이 부족한경우, 이문제는 굉장히 인사적인 문제이다. 잘뽑는게 우선이겠지만, 그 개발자가 비젼을 가지고 커갈수 있도록 많은 지원을 하는것, 리더로서의 기본이 된다.

두번째로 구현기간에 대한 논의 이다. 사실 정확한 구현기간을 따지는 것은 쉬운일이 아니다. 개발팀이 어떨땐 일이 잘 풀려 빨리 끝날수도 있지만 어떨땐 정말 안될때도 있다. 그래서 그 폭이 어느정도 일정한 개발팀이 유능한 개발팀이라고 할 수 있다. 우선 개발자에게 말을하면 두배정도의 시간을 이야기 한다.(물론 다 그런것은 아니다.) 개발자가 일부러 그러는 경우도 간혹 있지만 사실은 그렇지 않다. 기존에 해보지 않던 기능의 경우 사실 개발자 자신이 부담이 되어 기간을 단축 시킬 수 있을지 없을지 순간적인 판단을 하기가 어렵게 된다. 그런데 여기서 문제가 된다. 좀더 정직한 개발자라면 기간이 단축되면 미리 이야기 해줘야 하나 그렇지 않고 이미 개발이 되었음에도 끌어앉고 있는 경우를 많이 보아왔다. 그래서 수시로 일정과 진행상황을 보고 받아야 한다.

위와 같은 경우라면 알아도 모른척 믿음으로써 넘어가주는 것이 중장기적으로 서로간의 신뢰를 쌓는데 도움이 된다. 우선 믿자. 그런데 약간의 악의적인 개발자들이 문제이다. 일부러 3배, 4배 이상의 개발 시간을 이야기 한다. 단순히 5분만에 끝날수 있는 사소한 것들도 1주일씩 끌수 있다는 것이다. 그래서 기획자는 많은 개발자들로 부터의 인맥을 갖거나, 프로젝트의 경험으로부터 기간산정을 할 수 있어야 한다.

그리고 일을 처리할때 보통 우선순위에 따라 처리를 하라 말한다. 여기에 약간의 오류가 있는데 무조건적인 우선순위를 따지는 것은 방법이 아니다. 단기간에 끝날 수 있는것은 업무의 우선순위보다 앞서야 한다. 빨리처리할 수 있는것은 빨리 처리하도록 요구하는 것이 필요하다. 그래야 일이 전체적으로 깔끔하게 처리가 된다.

# 고객을 위한 설계는 어떻게?

세번째로 기능 설계상의 문제이다. 어떻게 설계하는것이 유저들이 좋아 할것인가? 문제이다. 개발자들은 개발하기 쉬운방법을 중심으로 그것이 유저들이 좋아하는 것이라 착각하는 경우가 있다. 이를 논리적으로 설득할줄 알아야 한다. 그렇기 위해서 유용성공학(유저빌리티)의 연구서적이나 자료를 많이 참고해야 한다. 또한 HCI이론을 참조하는것도 한 예이다. 많은 논문을 참조해 논리적으로 만들자, 또 베스트 프랙티스를 많이 접해 봄 으로써 간접적지식을 얻을 수도 있다. 물론 내가 직접 서비스 해 가면서 노하우를 취득한다면 금상 첨화라 하겠다.

방법은 논리적으로, 경험적으로(간접이든 직접이든), 이론적으로 반드시 풀어가야 한다. 적당한 타협은 적당한 웹사이트를 만들 수 밖엔 없다. 적당! 이라는 단어는 웹기획자가 절대적으로 피해야 할 단어이다.

적당히 하면 적당한 사이트가 나온다.

기획자가 개발자랑 부딛히는 세가지 이야기에 대해 간략하게 풀어보았다.

가장 중요한 문제는 개발자들이 무엇으로 스트레스 받는지 아는 것이고 그들이 어떤생각으로 어떤언어로 이야기 하는지 배워야 한다. 지금 잘 모른다면 확실히 배우자.

내 글이 조금이라도 개발자들의 마음을 이해하는데 도움이 되었으면 한다.

개발자들의 생각을 이해하고

그들의 언어와 기획자의 언어를 통합해 하나의 언어를 만드는 작업은

그 어떤 작업보다 중요하다.

새로운 언어를 만들어내자.!!