'PM'에 해당되는 글 1건

  1. 2007.08.10 나는 어떤 개발자 인가? (14)

사용자 삽입 이미지
항상 이런 주제의 글은 논쟁을 불러 일으키지만 한 번 생각해 볼 만한 가치가 있다고 생각합니다. 며칠 전, 회사에서 직원과 중요한 일정에 대한 논의중 큰 소리를 친 적이 있습니다. 현재 개발중인 새로운 프로젝트의 자꾸 일정이 늦어져 최종 일정을 확인하는 자리였습니다. 회사 입장에서 보면 새로운 프로젝트야 말로 현재와 미래의 사업에 있어 아주 중요한 것이기에 그 기대 역시 클 수 밖에 없습니다.  격론을 할 수 밖에 없던 주제들은 다음과 같습니다.


관리자-일정이 자꾸 지연되고 있는 데 이번에 최종 수정된 일정은 가능한가요?
개발자-쉽진않지만 최선을 다하겠습니다. 그런데 이렇게 조급한 일정으로 개발해서 어떤 좋은 결과가 있을까요?
관리자-그렇다면 도대체 좋은 결과를 위한 일정은 어디까지인가요?
개발자-개발자들이 만족하고 , 내부 QA를 거치는 등 내부에서 만족해야 되는 게 아닌가요?
관리자-그렇다면 그 일정이 도대체 언제까지 인가요?
개발자-그거 모르죠. 해봐야 하는 거 아닌가요?

수 년간 개발 프로젝트를 진행하면서 만난 여러 개발자들을 만났습니다. 그런데 곰곰히 생각해 보면 개발 마인드의 개발자 보다는 사업 마인드의 개발자가 자신의 가치를 더욱 빛나게 만들었습니다.  S/W개발회사에서 S/W개발은 전부라 해도 과언이 아닙니다. 그렇다면 그 개발의 승패에 따라 회사의 운명이 좌우되기도 합니다. 가령, 경쟁사가 유사한 서비스를 개발하고 있다면 무엇이 가장 중요 할까요? 바로 이런 경우 타이밍(TIMING)이 가장 중요한 포인트 입니다. 얼마나 먼저 발표하여 시장에 진입하느냐가 중요한 부분인 것이죠. 경쟁에서 이등은 항상 후발자가 되어 더 일등이 되기 위해 항상 더 많은 대가를 지불해야 만 합니다. 물론 이를 위해, 제대로 개발되지 않은 것을 무리해서 출시하는 것도 안됩니다. 이 경우 , 적절한 서비스의 양과 질을 조절하고 후속 작업이 더욱 중요합니다. 바로 이러한 것이 더욱 강조되는 것이 현재의 웹2.0 서비스입니다. 베타 서비스란 것의 의미가 바로 이런 것이죠. 베타 서비스가 결코 완성되지 않은 버전을 의미하는 것이 아닙니다. 사용자와 함께 만들어 나가는 서비스라는 것이 더 중요한 의미입니다. 바로 이러한 의미들을 파악하고 이에 따라 움직이는 개발자야 말로 비지니스 마인드의 개발자 겠죠. 에이질 방법론의 확산의 이면에는 이러한 서비스 로서의 소프트웨어가 큰 역할을 합니다. 이제 소프트웨어 개발자는 패키지를 개발하는 것이 아니라 서비스를 개발하고 있다는 사실을 기억해야 합니다.

다시 제가 관리자로 돌아가 질문을 해 보겠습니다.

-개발에 있어 일정과 계획이란 것이 어떤 의미가 있을까요?
-계획대로, 일정대로 진행되지 못한 프로젝트의 성공 여부는 무엇으로 평가하는 게 맞을까요?
-열심히 , 최선을 다했다는 것이 성공적인 프로젝트의 척도 일까요?

절대적인 정답은 없지만 제가 내릴 수 있는 답은 회사는 수익을 창출해야 그 존재 가치가 있습니다. 그러한 소프트웨어 회사에서 수익 창출은 개발을 통해 이루어 냅니다. 이러한 수익 창출을 위한 준비된 계획에는 기획-개발-품질관리-마케팅-영업 등 여러 파트의 업무들이 포함됩니다. 물론 기간적으로 가장 큰 비중을 차지하는 것이 개발입니다. 만약 개발이 늦어지면 모든 것이 늦어지게 되고 회사의 모든 수익 활동에 큰 영향을 받게 됩니다. 이처럼 일정은 무척 중요한 것 입니다. 개발팀장으로 개발 일정과 계획을 제대로 수립하지 못한다면 자신은 팀장 보다는 개발자로서의 역할이 더욱 맞을 것 입니다. 물론, 수립된 일정이 제대로 진행되지 못할 수도 있읍니다. 이 때도 중요한 것이 일정입니다. 일정대로 진행되지 않는 다면 위기 상황으로서 해당 위기를 해결하기 위한 모드에서 프로젝트를 운영해야 되기 때문입니다. 개발자가 부족하거나 타 팀의 협조가 부족하는 등 모든 것들의 판단은 게획과 일정, 이에 따른 진척도로 판단해야 하기 때문입니다.

개인적으로는 PM교육을 하는 여러 기관들을 봅니다. 그러나 그 곳에서는 형식적인 것을 주로 전발받겠죠. 보다 사업 마인드로서의 개발자는 다양한 분야로 지식을 넓히는 것이 중요하다고 생각합니다. 특히, 자본주의와 회사,경영,관련 시장 이라는 것에 대한 진지한 고민이 있어야 한다고 생각합니다. 외국이나 요즘 학생들은 워낙 이러한 것에 대한 기초 교육이 잘 진행되는 것 같습니다. 제가 만나본 대부분이 휼륭한 엔지니어와 아키텍쳐는 그 누구보다도 해박한 사업과 시장에 대한 지식을 갖고 있었습니다. 개발은 개발만이 아니라 사업이라는 생각을 이해하는 순간 그 개발자는 사업가입니다. 막걸리 생각나네요. 술끊는 중인데....아쉽네요.






Posted by 박재현

댓글을 달아 주세요

  1. Favicon of http://blog.gloridea.net BlogIcon Gloridea 2007.08.10 12:15  댓글주소  수정/삭제  댓글쓰기

    "그거 모르죠. 해봐야 하는 거 아닌가요?"
    라는 말은 일정을 산정할 수 없다거나 하는 말은 아닌 걸로 들리네요. :-) 진짜 하고 싶은 말로 번역하자면, "무리한 일정(진짜로 무리한지 여부는 차치합니다.) 으로 쪼임당하는 것에 지쳤습니다. 이제 더이상 일정 가지고 나를 괴롭히지 마세요. 더이상 일정과 관련한 어떤 약속도 하고 싶지 않습니다." 쯤 되지 싶네요. 그런 태도가 옳다는 얘기는 아닙니다만, 그런 태도를 비난만 하는 것도 문제 해결을 위한 방법은 아니라고 생각됩니다.

    또 하나, 지난 WebAppsCon 2007에서 흥미있게 기억하던 토론 내용 중 하나가, 과연 Time To Market Advantage가 비즈니스에 있어서 결정적인 요소였느냐 하는 것이었습니다. 더 구체적인 토론이 이루어지지 않아서 아쉬웠습니다만.

    납기라는 것은 기능 및 품질과 trade off적인 특징이 강합니다. 한편으로는 품질이나 기능은 상품이기도 하지만 개발자의 자존심이기도 합니다. 이러한 부분을 계속 억누르고 일정만을 무리하게 강요받은 상황은 아닌지도 생각해볼 수 있겠구요. (언급하신 내용이 그러한 상황이었다는 말이 아니구요.)

    그리고 하나 더, 사업가적인 마인드를 가진 개발자의 뒤치다꺼리를 해야만 하는 개발자적인 마인드를 가진 개발자들을 가끔 보았습니다. 쉽게 말해, 일 벌리고 스포트라이트는 다 받고, 똥 치우는 일은 남에게 넘기고 도망가는 경우죠. 항상 사업가적 마인드가 좋은 것만도 아니라고 생각됩니다. :-)

    저도 역시 논쟁의 여지가 많은 글에 여러 전제를 생략하고 리플을 달려니 좀 조심스럽네요. 가능성에 대한 진단 차원에서 읽어주시면 감사하겠습니다. ㅎㅎ

    • Favicon of https://wisefree.tistory.com BlogIcon 박재현 2007.08.10 14:43 신고  댓글주소  수정/삭제

      장편의 댓글 작업중 날라갔네요.. 간략히 요약하면 꺼꾸로 정해진 목표에 따라 개발을 하는 경우도 있지만 ,씽크프리에서는 전시회 준비를 빼고는 개발은 개발팀에서 일정 수립을 합니다. 그런데 개발담당자가 수립된 일정을 신뢰할 수 없고 지켜지지 않는 다면 아마 소프트웨어 회사는 제품이나 서비스를 출시할 수 없습니다.

    • Favicon of https://wisefree.tistory.com BlogIcon 박재현 2007.08.10 14:45 신고  댓글주소  수정/삭제

      또한 이렇게 출시하기로 한 제품이나 서비스의 출시 지연은 회사의 성장에 치명적인 요인으로 작용하기도 합니다. 물론 이 때, 품질이 중요하겠죠. 그러나 이러한 품질은 개발자의 자존심을 말하는 것은 아닙니다. 왜냐하면 정도의 차이가 있어서 그렇치 모든 개발자는 신이 아니기에 버그를 만들어 냅니다. 물론 우수한 개발자가 20배 월등 하다고 합니다.

    • Favicon of https://wisefree.tistory.com BlogIcon 박재현 2007.08.10 14:47 신고  댓글주소  수정/삭제

      이러한 품질은 개발자만의 몫과 책임이 아니라 내부 품질 담당부서와 더불어 사용자와 함께 해나갑니다. 바로 이런 과정이 서비스 업그레이드입니다. 이러한 운영과 업그레이드를 얼마나 짧게 효과적으로 하는 가가 현재 회사와 개발자의 능력이자 경쟁력이라고 생각합니다.

    • Favicon of https://wisefree.tistory.com BlogIcon 박재현 2007.08.10 14:50 신고  댓글주소  수정/삭제

      결론적으로, 누가 스포트라이트를 받는 가라는 보다는 이를 통해 회사가 성장하고 그 결과가 공평하게 분배되는 가가 중요하다고 생각합니다. 가령, 이노디자인의 디자인은 누가 할까요? 실제 대표디자이너 혼자가 아니라 소속된 디자이너가 합니다. 그러나 대표 디자이너의 브랜드 만으로도 회사가 유명해지고 성장하면 모두에게 이득이라고 생각합니다. 이러한 것도 능력이니까요. 저는 제가 한 고생을 누가 갖느냐 보다는 회사가 성장해서 수익을 내는 시스템을 얼마나 빨리 갖느냐가 더 간절합니다.

  2. Favicon of http://blog.naver.com/p1ngp1ng BlogIcon p1ngp1ng 2007.08.10 18:09  댓글주소  수정/삭제  댓글쓰기

    두분이 지적하신대로 이것은 논쟁의 연속이고 정답은 없는것 같습니다.
    지금도 날밤까는 개발자들이 많습니다. 물론 관리자도 마찬가지죠.
    이를 한편에선 능력이 없어서 늦게까지 한다고 생각할 수 있게 또 다른 쪽에서는 일정에 비해 작업량이 많다고 주장할 수 있읍니다. 이건 닭이 먼저냐, 알이 먼저냐를 논쟁하는 것과 같다고 봅니다.
    동일한 사물을 놓고 바라보는 시야가 다르기 때문이겠죠. 필자가 지적한대로 관리자입장에선 사업마인드 개발자를 원할것이고 개발자 입장에선 개발현실을 감안한 사업추진하는 경영자를 선호할 것입니다.
    끝없는 논쟁속에서 이바닥의 개발자들은 오늘도 날밤까겟지만, 서로 이해하며 적절한 접점을 찾으려는 노력과 감정을 상하지 않게 신뢰하는 문화를 만들어 가는게 어떨지...

    • Favicon of https://wisefree.tistory.com BlogIcon 박재현 2007.08.10 18:40 신고  댓글주소  수정/삭제

      S/W올림픽이라는 이매진컵 2007에서 우리나라 팀이 결선지출에 올랐다고 합니다. 그 만큼 국내 개발자들의 자질은 뛰어나다고 생각합니다. 그리고 이들 개발자는 시간이 흘러가면서 관리자라고 말하기도 하는 고참 엔지니어가 됩니다. 이 사이를 이어가는 것은 신뢰라는 데 동의합니다. 그리고 그 신뢰는 믿음이고 믿음이란 목표를 위해 최선을 다해가는 모습니다. 관리자와 개발자는 적대적 관계가 아닙니다. 모두 회사의 직원이고 동료입니다. 단지 진행하는 일을 바라보는 시각에 차이가 있을 뿐이죠. 그 시각이 무척 중요합니다. 비지니스 시각없이는 조직을 꾸려 갈 수 없기 때문이기도 합니다. 망한 조직에서 의미있는 것은 아무것도 없기 때문입니다. 개발자던 관리자던 회사가 잘돼야 행복한 것 아닐까요^-^

  3. Favicon of http://ash84.blogi.co.kr/tt BlogIcon ash84 2007.08.12 23:34  댓글주소  수정/삭제  댓글쓰기

    다시 한번 개발자에 대해서 생각하게 되네요. 흠..

  4. 관퉁 2007.08.16 18:35  댓글주소  수정/삭제  댓글쓰기

    재미있는 논쟁입니다.
    싱크프리에 무엇을 개발하는 건지는
    모르지만...
    회사의 발전을 위해서는 좋은 일입니다...
    하나 싱크프리의 기술이 언제까지나
    한컴의 독보적인 기술이라고 자만만 하실겁니까?
    온,오프라인 상에서는 오직 싱크프리뿐이라는
    얘기는 단지 지금 이 싯점의 얘기지요...
    어느 순간에 상상할 수 없는 기술을 가지고
    다른 기업에서 추월할 수도 있지요...
    싱크프리가 지금껏 수익모델로 자리를
    잡았습니까?
    지금이라도 글로벌한 기업과 제휴를 하는것도
    좋은 방법중의 하나겠지요...
    네이버오피스의 지연과 구글 제휴가 않되는
    중요한 사유가 있는것 아닐까요?
    아직은 한컴에 계신 개발자 여러분들 중에는
    독보적 천재성을 가진 글로벌한 개발자와
    사업자가 없는것 같습니다...

    • Favicon of https://wisefree.tistory.com BlogIcon 박재현 2007.08.17 10:58 신고  댓글주소  수정/삭제

      어떤 분야든 미래의 잠재적인 경쟁자가 나와 시장을 평정할 수 있겠죠. 구글이 그랬고 , 구글 역시 영원하지 않을 것 입니다. 그게 바로 현실이니까요. 웹 오피스분야도 마찬가지 이고 현재 독보적인, 수익을 내는 회사는 아직 없습니다. 그나마 씽크프리에서 NHN같은 제휴 모델과 현재 베타 운영중인 프리미엄 유료화, 서버 에디션같은 수익 모델을 시도하고 있습니다. 성공/실패의 여부를 떠나 의미있는 작업이고 결과도 좋을 것으로 생각합니다. 아울러 오해를 하시는 부분을 설명해 드리면 네이버 오피스는 지연되는 것이 아닙니다. 내부 일정에 의해 진행되고 있고 조만간 선보에 될 것입니다. 그리고 구글 제휴 엮시 이해관계가 다르면 안될 수도 있는 것이구요.

      씽크프리는 한컴의 자회사이지만 한컴이 아닙니다. 씽크프리는 나름대로의 문화를 갖고 있는 회사이고 , 독보적인 천재성을 갖은 글로벌 개발자가 어떤 사람인지는 모르겠지만 서로들 모자란 부분을 도와면서 지금껏 개발을 해봤고 앞으로도 그럴 생각입니다. 아마 그 기반이 열정이라고 생각합니다. 자만하지도 않고 자만할 위치도 아니라고 생각합니다.

      광퉁님의 글을 보면 어느 정도 씽크프리에 대해 아시는 분 같습니다. 그런데 이왕이면 좀 더 객관적으로 의견을 주시면 도움이 될 것 같네요..^-^

  5. 관퉁 2007.08.18 23:14  댓글주소  수정/삭제  댓글쓰기

    한컴 싱크프리의 급발전을 정말로 간절하게 원하는 사람중의 한사람 으로 올해초 구글과의 제휴설에 사실 많은 기대를 하였습니다. 회사의 입장으로 최선의 선택을 했겠습니다만 개인적인 생각으로 아직은 국내에서만 인지도가 있는 한컴에서 독자적으로 싱크프리를 키우기 보다는 구글 같은 세계적인 회사와 제휴를 하면 웹 오피스의 전 세계적인 확산에 기여도 하고 회사도 크게 발전할 수 있겠구나...하는 생각을 했습니다. 그런면에서 네이버와의 제휴는 정말 반가왔습니다. 진도가 많이 늦어지는 감이 있지만...
    국내에선 네이버오피스로 해외에서는 구글 싱크프리(?)로 웹오피스를 평정하면 좋지 않을까요? 어자피 MS와 대적하는 마당에는 검은 고양이, 흰고양이 가릴게 뭐이 있겠습니까?
    위의 내용들을 보면 개발하시는 분들이 좀 더 사업적인 마인드를 가졌으면...마음입니다. 물론 관리자도 개발자의 입장을 많이 고려해야 겠지요...개발의 과실 운운 하는것은 보기가 좀 그렇습니다. 회사의 발전을 위해서 좀 더 폭넓은 시야가 필요하지 않을까요?

    • Favicon of https://wisefree.tistory.com BlogIcon 박재현 2007.08.22 10:50 신고  댓글주소  수정/삭제

      네 말씀감사합니다. 구글과의 제휴는 저도 여러모로 아쉽지만 현재에도 더 많은 기회는 열려 있다고 생각합니다. NHN과 같이 멋진 파트너들이 여러 나라에 있기 때문입니다. 제가 글을 포스팅한 것은 누구의 과실보다는 제 십년이 넘게 이 분야에서 일하면서 비지니스 마인드라는 것이 중요성을 새삼느끼기에 입니다. 씽크프리에서는 앞으로도 철저히 비지니스 마인드를 모두에게 요구할 것 입니다. 초소한 제가 여기에 몸담고 있는 한은요...회사가 잘 되면 다 해결될 일이지요. 조만간 좋은 소식 들려드리겠습니다. 꾸벅

  6. Favicon of http://snowboy.hybird.net BlogIcon Snowboy 2007.08.21 10:38  댓글주소  수정/삭제  댓글쓰기

    요구사항을 면밀히 분석하고, 이를 바탕으로 정확한 개발 범위와 작업 단계를 명확히 하는 과정이 동반되지 않은 상태의 일정 계획은, 당연히 높은 변경 가능성을 내포할 수 밖에 없지 않을까 싶습니다. 큰 범위에 대해 한번에 계획하고 변이를 늘려가는 방법 보다, 명확한 범위의 작은 업무들을 반복적으로 수행하면서 규모와 안정성과 완성도를 늘려가는 방법을 취하시면 Time to market과 서비스 안정성이라는 두마리의 토끼를 조심스래 같이 노려볼 수 있지 않을까 싶네요. ^^

    • Favicon of https://wisefree.tistory.com BlogIcon 박재현 2007.08.22 10:45 신고  댓글주소  수정/삭제

      그런 에이질 방식이 웹 서비스 개발에서는 유리합니다. 그런데 그런 방법을 효과적으로 하기 위해서는 모든 멤버들이 숙련돼야 하고 그 철학을 잘 이해해야 합니다. 그래야 효과가 있습니다. 그게 참 어려운 것이지요.. 전체를 알고 작은 조각을 세밀하게 하는 작업은 팀장,팀원 등 전체 역량이 조화롭게 있어야 합니다.