망하는 제품의 흔한 개발 과정

망하는 제품의 흔한 개발 과정

  • 리더 : 요즘 유행하는 대세를 들고 온다. 이것이 대세다!
  • 리더 : 속으로는 이런 것들을 쓰는 사람들은 사회부적응자라 생각하고 본인은 정작 써 본 적이 없다.
  • 기획 : 써 본적은 없지만 들어는 봤다. 이런 것을 쓰는 사람은 격이 떨어지는 사람이라 생각하고, 내가 우아하고도 유럽 명품에 견줄 수 있는 것을 보여주어야 겠다 생각한다.
  • 기획 : 해당 제품군을 모조리 조사한다. 그래서 해당 제품군의 모든 특징을 합한 고질라 같은 것을 그려 낸다.
  • 리더 : 그것만으로는 뛰어 넘을 수 없다고 한다.
  • 기획 : 아이디어를 동원한다. 이제 그 고질라에 스타워즈, 반지의 제왕, 해리포터를 더하기 시작한다. 자신의 상상력의 끝은 어디인가 하면서 스스로 놀라워 한다.
  • 리더 : 고질라에서 빠진 게 없나 살핀다. 다소 억지 스럽지만, 비슷한류의 제품을 가져와 하나 더 붙인다. 이런게 바로 리더의 통찰력이라 으쓱거린다. 기획자의 아이디어를 보고는 기획자가 미쳐 생각하지 못한 경우의 수를 생각해서, 더 복잡하게 만든다. 아직 가르칠게 많다고 생각한다.
  • 개발 : 그런건 못만들어요 불평을 늘어놓는다.
  • 리더 : 내앞에서 안된다는 말은 하지 말라고 하며, 할 수 없다는 것부터 이야기하는 태도가 문제라고 한다. 그리고는, 자신의 인생 역정기를 늘어 놓는다.
  • 개발 : 기획에 대한 조언을 해 줘야 겠다고 생각한다. (사실 해당 제품군을 사용해 본 유일한 사람이다.)
  • 리더 : 넌 아직 인지과학, 심리학을 모른다고 일축한다.
  • 기획 : 파워포인트로 찍어 내는 노가다를 시작한다.
  • 리더 : 문서에서 오타를 찾아 낸다.
  • 개발 : 이 프로젝트는 어짜피 산으로 갈 것이라고 떠들어 대기 시작한다.
  • 리더 : 최근 세미나에서 본 솔루션들을 쓰면 금방 할 것이라고 말한다. 그리고 비싼 돈을 들여 도입을 추진한다.
  • 개발 : 그게 뭔지 모른다. 다만, 대충 들어보니, 그것 보다는 자기간 만들어 놓은 자작 솔루션이 훨씬 더 좋은거라고 속으로 생각한다.(사실 지금 이 상황에 그걸 배워서 만드는 것은 엄두가 나지 않는다) 그리고, 쓰는 척 시늉만 하기로 결심한다. 타인이 만든 것을 사용하는 것은 하수들이나 하는 짓이라 생각한다.
  • 리더 : 개발기간은 3개월이라 한다.
  • 개발 : 불가능한 일정이라 하고, 기획안을 조정하라고 주장한다.
  • 리더 : 나는 어찌 저런 무능하고 게으른 개발자만 옆에 있는지 탄식한다. 나에게 해외 유수기업의 개발자를 붙여주면 단박에 성공 할 수 있으리라 생각한다.
  • 개발 : 투덜거리며 밤 샌다. 불행하게도 고질라를 만들어 내는 과정과 SF 가 붙여 지는 과정은 개발 과정 진행중에 병행해서 발행하는 일이다. 스타워즈를 다 붙여놓으면, 어느덧 스토리는 해리포터로 바뀌어 있다. 다시 밤을 샌다.
  • 리더 : 3개월 후면 다 되어 있겠지 생각을 한다. 개발 과정에는 관심이 없다. 개발이 진행되는 중간 중간, 어제밤 자다가 생각난 환타스틱한 장면을 기획자에게 넣으라고 말한다. 이 장면을 놓쳤으면 이번 제품에 핵심이 빠졌을 거라고 생각하고, 이제라도 넣게 되어 다행이다 생각한다. 그리고, 자신이 얼마나 디테일에 강한가 다시 한번 생각해 본다.
  • 개발 : 코드는 개떡이 되어 간다. 어짜피 이건 내탓이 아니다. 정말 제대로 된 환경에서 했다면, 난 정말 멋지게 해 낼 수 있었을 텐데, 운없이 이런 놈들이랑 팀을 해서 이렇게 된거라 생각한다. 이 제품은 내 손에서 나왔지만, 내가 만든건 아니라 생각한다.
  • 리더 : 3개월후, 생각했던게 안나오자 개발자에게 책임 추궁을 해야겠다 생각한다. 처음부터 태도도 안좋았고, 자기가 말한 것을 구현해 낼 실력도 없었던 사람이었다 생각한다. 후회한다. 이 모든 것은 개발의 문제다. 하지만, 일단 출하한다.
  • 기획 : 자신의 유럽 명품적 감각의 파워포인트를 어떻게 이런 제3세계 제품으로 만들어 냈는지 의아해 한다.
  • 리더 : 다시 시작하자 으쌰 으쌰 해 본다. 그리고, 그 사이 대세가 바뀌지 않았다 살펴 본다.
  • 개발 : 어짜피 이렇게 된거, 처음부터 다시 시작하자고 한다. 나는 다시 내가 만든 것을 들여다 보고 싶지 않다.
  • 리더 : 역시 중요한 것은 사람이다 라고 생각한다.

흥하는 제품의 흔한 개발 과정

  • 리더 : 자신에게 꼭 필요했던 핵심가치(기능)을 발견한다. 현존하는 타 제품에서는 발견할 수 없기에, 만들어야 겠다고 결심한다.
  • 기획,개발 : 자신도 꼭 필요했던 것이라 생각하고, 만들면 정작 자신이 가장 큰 혜택을 받을 것이라 생각한다.
  • 리더,기획,개발 : 다 같이 모여서 기존 제품들을 맹렬히 비판해 낸다. 왜 다 이렇게 될 수 밖에 없었는지 생각해 본다.
  • 개발 : 관련된 기술을 조사한다. 그리고, 조사한 결과를 공유한다.
  • 기획 : 수없이 많은 기술을 가지고, 두개의 연결(조합)을 시도한다. 전혀 상관없을 것이라 생각했던 두가지 기술을 합하니, 매우 멋진 모습이 되었다.
  • 리더 : 이 멋진 조합이 핵심가치를 구현하는 결정적 요소가 아니면, 버리자고 한다. 핵심가치에만 촛점을 맞춘다.
  • 개발 : 핵심가치를 구현할 가장 단순한 방법을 찾는다. 구현이 단순할 수록 생각치 못한 일이 발생할 가능성이 줄어 든다.
  • 리더 : 개발된 시제품을 써 본다. 하루고 이틀이고 계속 써 본다. 불편한 점을 찾거나, 그 보다 더 단순하게 할 방법을 생각해 낸다.
  • 개발 : 반복적으로 만들어 낸다. 구현 방법이 단순하였기에, 이 반복과정이 고통스럽지 않다. 이 반복과정을 더 쉽게 할 수 있는 방법을 계속 추가해 낸다.
  • 기획 : 이 단순한 핵심가치를 제공하는 이 제품이 생각보다 많은 곳에서 응용될 수 있다는 것을 찾아 낸다.
  • 리더 : 기쁘지만, 처음 생각한 것에 집중하기로 한다.
  • 리더 : 충분히 만족스러운 상태가 되면 제품으로 출하한다. 충분히 고민한 것이기 때문에, 아주 오랫동안 다시 이 문제를 생각할 필요가 없을 거라 생각한다. 누군가 흉내내면서 새로운 것을 덧붙여 내거나 변형을 시켜내도 크게 신경 쓰지 않는다.
  • 기획 : 현재까지 이룩한 것에서 최소한의 노력으로 추가할 수 있는 핵심가치를 다시 찾기 시작한다.
  • 리더 : 역시 중요한 것은 사람이다 라고 생각한다.

“망하는 제품의 흔한 개발 과정”에 대한 163개의 댓글

  1. 대부분의 개발환경은 망하는 제품의 케이스이고, 흥하는 케이스는 누구나 꿈에 그리던 모습이군요. 그래서 비공감입니닷.

  2. 망하는 케이스의 리더와 기획자의 모습이 대부분이 아닐까 싶네요. 하지만 흥하는 케이스 자체가 굉장히 개발자 입장에서 쓰여진 포스트네요. 저는 개발센터 (디자인,개발,기획) 총괄만 10년정도 경험했는데요. 위에서 망하는 케이스에서 실제로 성공하는 경우가 상당히 많습니다.

    문제는 정도의 차이입니다. 대부분의 리더와 기획자 개발자간의 갭은 있지만 그게 어느정도이고 어떻게 풀어나가느냐가 중요하겠지요. 그래서 리더도 기획자도 개발방법론 공부를 해서 개발자나 디자이너를 지시가 아닌 실력으로써 리딩해야 합니다. 그래서 목표지향점에 대한 생각의 갭을 많이 줄여야 합니다.

    리더와 기획자에 대한 실망감이 극대화된 포스트라서 좀 아쉽습니다. 저도 실제로 API를 이용한 개발이면 제가 직접 저작원과 API에서 지원되는 기능정의서를 요약하고 개발자가 심공을 부리거나 하면 그때 이렇지 않냐 협의하면서 진행합니다.

  3. 장시간의 프로젝트 시간을 필요로 하는군요.
    개발비 산정이 안될거 같아요.
    리더의 생각이 중요하기는 한데,
    우리 SI 환경에 발주자는 그런 생각이 전혀 없다는게 문제군요.
    내부 개발자들을 활용해서 하는 리스크 없는 일에 적합한거 같네요. ㅎㅎㅎ
    용두사미가 우리의 환경입니다. ㅜㅜ

  4. 그렇게 “망”하게 만드는 사람들을 신나게 욕하기 전에 그 사람들이 회사에 붙어있도록 노동시장을 경직시켜놓은 사람들이 누구들인지 생각해 봐야 하지 않나요.

  5. 어느 분야던
    유능한 사람들은 처음에 잘못 배치가 되더라도 자신의 능력을 Signaling을 잘 해서
    신속히 유능한 동료들과 같이 일할 수 있는 곳으로 옮깁니다..

    무능한 사람들만이 남아서 일할 능력은 없으니 서로 손가락질을 열심히 해야겠죠

    아니다 싶으면 바로 옮기는 것이 답입니다.
    옮길 능력이 있을 때 얘기지만..

  6. 여기서 얘기하는 ‘흥하는 제품’의 기준은 그냥 상업적인 성공을 얘기하는게 아닌것 같습니다.

    예를 들어 갤럭시S, 아이온의 성공 같은 것을 얘기하는 게 아니라
    아이폰,와우의 성공 같은 것을 얘기하는 것으로 보입니다.

    패러다임을 바꾸고, 누구도 인정할 수 있는 그런 성공 말이죠.

  7. 다양한 분야에서 공감하시는가 보군요. 너무 극단적이라고 하시는 분도 계시지만 이런글은 핵심만 찝어서 부풀려야 보는이한테 강한 임팩트를 줄 수 있는거니까 이해해야지요. 숲을 이야기하기 위해 손가락으로 가르킨거니까 숲을 보아야겠지요. 손가락이 조금 못 생겼으면 좀 어떻습니까 ^^

  8. 사람이 중요하다…
    두산에서 쓴 이야긴지…
    왠지 “사람이 미래다.” 두산의 것을 보는듯하네요
    뭐 저는 “범죄가 미래다.”라고 두산을 까기도 하지만…

    위에는 농담입니다.ㅋㅋㅋ

    그리고 내용은 아주 잘 봤습니다.

  9. 망하는 회사 리더라도 사람이 중요하다는 것을 마지막에 깨닫는건 그나마 다행이네요.
    사람이 중요하다는걸 모르는 리더들이 너무 많으니까요…

  10. 오오 깨달은 바가 많습니다.
    어떤 좋은 컨셉도 모든 이의 동감을 얻기는 불가능하겠지요. 그럼에도 불구하고 결국 실현해내는 모습을 배워야겠다고 생각했습니다.

  11. 공감… 제가 다녔던 모회사에서 1~2주(max 1달) 프로젝트로 시작해서 위에서 처럼 뭐 붙이고 뭐 붙이고 계속 그러다가 1년동안 죽어라 야근 했는데도 완성 못해서 출시도 못한적 있습니다.
    정말 간단한 걸로 시작해서 결국 울트라 캡숑 거대한 고질라가
    만들어지려고 하니 프로젝트가 성공하겠습니까.. ㅠㅠ

  12. Leon 님// 제가 생각하는 사람이 중요하다라는 말은 두 측의 의미가 다른 것 같습니다.

    망하는 회사는 자신은 완벽한데 다른 사람이 못따라주니 ‘잘하는’사람을 쓰는 것이 중요하다인거 같고, (원망형)

    흥하는 회사의 경우 사람들이 협동이 잘되어서 일이 잘 해결되어서 사람이 중요하다라고 말하는 것 같습니다. (감사형)

  13. 저도 기획자인데 대박 공감.. 오타를 찾아낸다 ㅋㅋㅋㅋ 기획서는 보지도 않고 열심히 오타 찾아내고 꾸사리 주고.. 나중에 되서야 야 이런게 기획에 있었어? 지가 컨펌하고 지는 오타 외에는 보지도 않는 ㅋㅋㅋ

  14. 좋은 글입니다. 잘보고 갑니다.
    우리회사가 망할 곳을 향해 치닫는것 같다는 생각을 하니..
    가슴이 멍해지네요.. 이 글에 포함되는 흥하는 회사아 몇곳이나 있을지 궁금합니다.

  15. 수많은 연구원들의 연구행태와도 크게 다르지 않는것 같습니다.
    다만 출판된 논문이 널리 읽히느냐 읽히지 않느냐의 차이가 있을뿐…
    목표 지향적인 연구보다는
    방법 활용적인 연구를 따르는
    작금의 세태를 꼬집기도 좋은 내용인 것 같습니다.
    좋은 글 잘 읽었습니다.

  16. 망하는 과정은 실감나는데 흥하는 과정은 너무 픽션이네요.

    기획은 솎아내고 빼는 과정이다.. 라는 것만이라도 잘 이해하는 실권자가 없으면 다 소용 없습니다.

  17. 저는 아래의 것이 공감이 갑니다 회사가 시작을 할때부터 함께했기 때문에 단둘이서 시작해서 10명 이하까지는 정해진 룰이 없어도 서로가 의사소통이 가능하여 안되는것을 고치고 왜 그런지 찾아 냈었지만 인간이이 늘어나면 늘어날수록 소통은 줄어들고 서로를 탓하게 됩니다. 시작은 후자였으나 사람이 늘어나지만 시스템은 2명이서 일할때와 같으니까 망할때의 테크를 타게 되었습니다. 가장처음에 개발한 제품 지금도 팔리고 있으며 그후로 개발한 제품들도 간간히 팔려옵니다만..사람이 늘어나면서 개발된 제품은 회사 욕만 먹이고 개발 안하느니만 못한 물품이 되어 없애버린게 몇개인지 기억도 안날 지경입니다…..

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.