긍정적 사고, 음식의 절제, 규칙적인 운동

개발자가 기획자를 쓸모 없다고 오해하는 이유

live.lge.co.kr/it_casting_3/

개발자들이 기획자에 대해 가지는 편견 중 하나가 바로 ‘기획자가 무엇을 하는지 모르겠다’는 것입니다. 실제 개발자 커뮤니티를 보면 기획자에 대한 불만의 글들을 종종 볼 수 있답니다. 기획자의 기획물이 개발자 본인이 생각하는 수준에 미치지 못한다 등 개발자 본인이 기획을 해도 훨씬 잘 만들 자신이 있다 등 다양한 의견을 볼 수 있습니다. 심지어 기획자들은 개발할 때 귀찮은 작업들을 대신해주는 사람들이라는 의견과 개발자 본인이 기획해도 훨씬 좋은 서비스를 만들 수 있다고 확신하는 개발자까지 있습니다.

이것이 바로 개발자들의 눈에 비춰진 기획자들의 모습입니다. 바로 ‘뜬구름 잡는 사람들 또는 귀찮은 일을 대신해 주는 사람들’이라는 것이죠. 오랜 기간 개발자 생활을 하였던 저도 왜 이런 생각을 하는지 공감하는 부분이 있습니다만 단순히 눈에 보이는 것이 기획 업무의 전부가 아니다라는 것을 제대로 이해하지 못해서 일어난 오해라고 생각합니다. 오늘은 이런 개발자들의 오해를 풀기 위해 기획자들의 기본적인 업무에 대해 소개하고자 합니다.

③ 개발자들이여, 기획자가 하는 일은 생각보다 많다

기획(企劃)은 한자로 ‘도모할 기’와 ‘그을 또는 계획할 획’의 조합으로 ‘계획을 도모하는 것’입니다. 그래서 영어로 기획을 Plan이라고 하지 않고, Planning이라고 합니다. 한 마디로 기획이란 ‘Why to do?’와 ‘What to do?’를 명확히 하는 것으로써 ‘왜 할 것인가?’와 ‘무엇을 할 것인가?’를 결정하는 것입니다. 이에 비해 계획은 ‘How to do?’ 즉, ‘어떻게 할 것인가?’를 정하는 것입니다. 왜 할 것인지를 결정하는 것이 기획이고, 어떻게 할 것인지를 생각하는 것이 계획입니다. 즉, 기획을 다시 한번 더 정의하면 기획자의 의도가 반영된 계획을 도모하는 일이라는 것입니다.

기획의 분야는 너무나 많습니다. 이 중 오늘은 개발자들과 함께 협업하는 분야인 서비스 기획(인터넷, 앱) 분야에 한정해서 기획자의 업무들에는 어떤 것들이 있는지 살펴보겠습니다. 서비스 기획이란 고객에게 웹과 앱을 통해 새로운 서비스를 제공하기 위해 기획하는 일입니다. 이를 위해 다음의 업무들에 참여하고, 내부 의사결정을 내립니다. 물론 회사의 규모에 따라 다음의 업무에 대한 절차와 복잡도는 줄어들 수도, 늘어날 수도 있습니다.

서비스 기획 업무

위 도표에서 보듯이 서비스 기획자는 크게 시장조사, 서비스 기획, 서비스 개발, 서비스 마케팅, 서비스 운영의 단계에 참여하게 됩니다. 많은 개발자들은 서비스 개발 단계의 서비스 기획 1차 이후의 단계에서 기획자들과 협업하지만 기획자들은 하나의 서비스를 만들기 위해 시장조사부터 전략 수립, 회사 내 의사결정 수렴 및 서비스 개발 이후의 단계까지도 많은 영역에서 다양한 부서의 담당자들과 함께 협업을 하고 있습니다. 물론 회사 규모가 작은 경우라면 한 두 사람이 모든 영역을 담당할 수도 있고, 또는 생략하는 경우도 있습니다만 해당 서비스가 커지고, 참여하는 사람이 많아지면 분명 각각의 단계가 서로 다른 사람들에 의해 진행되는 모습을 볼 수 있습니다.

서비스 기획을 단순히 서비스 기능을 정의하고, UI를 그린 후 개발자에게 넘기는 활동이라고 너무 좁게 생각하지 마시기 바랍니다. 물론 개발자들이 보는 결과물은 서비스 기획서, 요구사항 정의서가 전부인 것처럼 보이더라도 이런 결과물을 만들기 위해 내∙외부 조직들과 많은 커뮤니케이션과 협조를 끌어내는 것까지 숨어있는 활동이 많다는 것을 이해하면 좋겠습니다.

때로는 기획자들이 구현 불가능한 터무니 없는 기능을 개발해 달라고 해서 화가 나십니까? 비현실적인 일정과 이미 시장에 있는 다른 서비스와 유사하거나 또는 많은 서비스들의 장점을 마구잡이로 합쳐서 그저그런 서비스처럼 보입니까? 하지만 제대로 된 기획자라면 기획서 한 페이지, 기능 하나를 정의하더라도 이 서비스를 쓰게 되는 고객의 입장에서 어떤 가치와 어떤 영향력을 줄 것인지에 대해 많은 고민을 하고 있는 사람들입니다. 가끔은 그 결과물이 개발자의 눈에는 초라하게 보일지라도 기획자를 존중하고, 고객의 입장에서 서로 같은 방향을 두고 협업한다면 분명 의미 있는 서비스가 탄생할 것입니다. 성공적인 프로젝트, 성공적인 서비스를 위해 기획자의 업무를 조금 더 넓은 시각으로 이해해 보심이 어떨까요?

http://techit.co.kr/8757 - 옛날에는 개발을 더 잘했는데… 

http://allofsoftware.net/entry/%EC%98%9B%EB%82%A0%EC%97%90%EB%8A%94-%EA%B0%9C%EB%B0%9C-%EC%9E%98%ED%96%88%EB%8A%94%EB%8D%B0

우리나라 많은 회사들은 소규모일 때 상당히 개발을 잘 하는 것처럼 보인다. 짧은 기간에 꽤 멋진 Software를 뚝딱 뚝딱 잘 만들어 낸다. 이러한 제품이 시장에서 통해서 회사가 성장을 하게 되면 그 이후로 이상하게 개발이 점점 더 어려워지게 된다.

옛날에는 고참 두 명이 이정도의 Software를 6개월만에 이렇게 잘 만들어 냈는데, 지금은 팀원이 10명이나 되고 프로젝트 기간도 과거보다 더 줬는데, 제품의 버그는 더 많고, 제품도 옛날보다 형편 없어 보인다고 한다. 점점 개발이 더 어려워지는 이유는 무엇일까?

두번째 시스템을 만드는 것은 첫번째 시스템을 만드는 것보다 훨씬 힘들다. 두번째 시스템은 첫번째 시스템을 유지보수 하면서 만들어야 한다. 첫번째 시스템에 버그가 많거나 커스티마이징 요구가 많아서 소스코드 브랜치라도 몇 개 존재하면 유지보수에 많은 노력이 들어가서 두번째 시스템에 많은 노력을 들이기 어려워 진다.

또한 두번째 시스템은 첫번째 시스템과 호환성을 고려해야 한다. 두번째 시스템은 첫번째 시스템을 사용하던 고객들의 수많은 요구를 수용해야 한다. 첫번째 시스템은 간단 명료한 기능의 매력으로 인해서 많은 사용자들이 사용을 했지만, 이를 사용하던 사용자들은 계속 요구사항을 요구하게 되고 이러한 요구사항을 적절히 조절하여 수용하는 것이 쉬운 일이 아니다.

두번째 시스템 개발에는 많은 개발자가 투입되고 특히 초급 개발자가 많이 투입되곤 한다. 소수의 개발자끼리 개발을 할 때는 커뮤니케이션 문제가 별로 발생하지 않았는데, 개발자 인원이 많아지면 기존의 주먹구구 방식으로 똑같이 개발을 하면 문제가 발생하지 않을 수 없다. 초급 개발자들은 자기 역할을 제대로 못하는 것 같고, 일이 효과적으로 분배가 되지 않아서 결국 소수의 고참 개발자들이 대부분의 개발을 하는 결과를 초래하기도 한다.

두번째 시스템은 아키텍쳐를 전면 개편하기도 한다. 첫번째 시스템을 개발해 놓고 계속 유지보수를 하면서 사용자의 요구사항을 하나씩 추가해 나가기 시작하면 기존의 아키텍쳐로는 한계라고 불평을 자주 하게 된다. 특히, 첫번째 시스템을 개발했던 개발자들이 퇴사한 상태라면 더욱 더 첫번째 시스템을 비난한다.

그러면서 두번째 시스템에는 완전히 새로운 아키텍쳐를 적용하곤 하는데, 그동안 엄청나게 많은 노력을 들인 첫번째 시스템을 버리고 기능도 몇 배로 많아진 두번째 시스템에 완전히 새로운 아키텍쳐를 적용하면 첫번째 시스템이 시장에서 안정화되면서 겪었던 시간과 노력의 몇 배를 다시 투입해야 한다. 이런 경우 프로젝트가 지연되기 일쑤이고, 출시 후에도 많은 버그와 고객의 불평으로 상당기간 고생을 하게 된다.

그럼, 어떻게 해야 과거처럼 개발을 착착 해낼 수 있을까?

조직이 커졌다면 당연히 시스템과 프로세스가 바뀌어야 한다.

과거에 소수 인원이 개발할 때는 주먹구구식으로 개발을 했어도 문제가 없는 것처럼 보이지만, 사실은 문제가 똑같이 있었는데, 워낙 인원이 적으니 서로 의견을 활발하게 주고 받으면서 문제를 해결해 온 것이다. 인원이 조금만 늘어도 이런 행운은 기대할 수 없다. 조직에 걸맞는 시스템, 프로세스를 적용해서 체계적으로 개발을 해야 한다.

첫번째 시스템도 이런 과정을 거쳐서 체계적으로 개발이 되었다면, 두번째 시스템 개발자들에게 비난을 덜 들을 수 있었을 것이다. 두번째 시스템 개발자들이 완전 새로 개발하려는 이유 중 하나가 첫번째 시스템에 대한 문서가 쓸만한 것이 없고, 아키텍처가 뒤죽박죽이라서 개선을 못하고 버리려고 하는 것이다.

회사가 켜졌을 때 문제 해결 차원에서 시스템과 프로세스를 갖출 것이 아니라, 1,2명이 회사를 시작하더라도 체계적으로 개발하는 것이 가장 좋은 방법이다. 이미 첫번째 시스템은 점점 뒤죽박죽이 되어가고 조직은 엉망이라면 시스템과 프로세스를 갖추는 일이 먼저 필요하다.