2011년 2월 16일 수요일

경영진이 너무 촉박한 일정을 제시합니다.

나는 프로젝트 일정에 대해서 항상 "일정은 개발자가 산정해야 한다"고 얘기를 해왔다.

그런데 많은 개발자들과 얘기를 해보면 자신들은 도저히 그렇게 할 수 있는 상황이 아니라고 한다. 일정은 위에서 확정이 되어서 내려오기 때문에 개발자가 정할 수 없다고 한다. 또한 항상 촉박한 일정을 지시하기 때문에 스펙이나 설계는 작성할 수도 없고 코딩부터 한다고 한다. 자신들도 체계적으로 개발을 하고 싶지만 도저히 그럴 시간이 없다고 한다.

경영진이 일정을 제시하는 것과 개발자가 일정을 산정하는 것은 완전히 상반된 얘기가 아니다.

경영진은 어떤 프로젝트를 진행하기 위해서는 일정이 필요하다. 경영진이 일정을 정했다고 해서 불가능한 일정이 가능해지는 것은 아니다. 프로젝트는 들어가야 할 시간은 다 들어간다. 자칫 서두르다가 더 느려질 수 있다.

경영진이 지시한 일정은 경영자의 입장에서 필요한 일정을 제시한 것이다. 이 일정은 변경해도 되는 경우도 있고 절대 변경하면 안되는 경우도 있다.

어떠한 경우라도 이 일정을 지키는 가장 좋은 방법은 개발자가 일정을 산정하는 것이다.

일정을 산정하기 위해서는 스펙을 제대로 쓰고 1,2일 단위로 상세 일정을 개발자가 산정해야 한다. 이쯤되면 전체 일정에서 20~30%의 시간이 지난 시점이 된다.

이때 상당히 정확한 일정이 나오면 경영진이 지시한 일정을 지키기 위한 방법을 강구할 수 있다. 이 일정이 경영진이 제시한 일정과 차이가 없다면 다행이지만 촉박한 일정이라면 스펙을 조정하거나, 개발자를 더 투입할 수 도 있다. 아직 설계, 구현이 본격적으로 시작되지 않았기 때문에 스펙 조정이 가능하고 개발자를 추가 투입해도 상당히 효과가 있다. 

스펙도 조정이 안되고 개발자 추가투입도 어렵고 무조건 밤을 새가면서 일하는 수밖에 없다면 그것도 하루이틀이지 어차피 불가능한 일을 하고 있는 것입니다. 불가능하다는 것을 일찍 알아내는 것도 중요합니다. 불가능한 일을 밀어 붙인다고 가능한 일로 바뀌지는 않습니다. 기적은 일어나지 않습니다.

스펙이 끝날 때까지 손놓고 있는 것이 아니고 스펙을 쓰는 도중에도 일정이 촉박할 것으로 예상이 되면 리스크관리를 통해서 미리 대비를 할 수 있다. 

경영진이 촉박한 일정을 지시했다고 해서 이것을 돌판에 새긴 절대불변의 지시사항으로 생각하고 코딩부터 시작하면 나중에 할 말은 다음과 같은 것들 밖에 없다.
  • 매일 밤새면서 일했는데 못 지켰습니다. 원래 불가능한 일정이었어요.
  • 코딩은 끝났는데, 테스트는 못했습니다.
이런 핑계를 대도 사실 코딩도 안 끝난 경우도 많다. 코딩은 가능하면 늦게 시작해야 기능을 빼거나 변경하기 쉽고 더 일찍 끝낼 수 있다.

경영진은 개발자들이 합리적인 방법을 제시하고 일정을 지켜주기를 원한다. 그래야 비즈니스를 할 수 있기 때문이다.

시간이 부족해서 스펙을 적을 수 없는 것이 아니고 시간을 절약하기 위해서 스펙을 적어야 일정을 지킬 수 있는 방법이 나온다.

경영진이 6개월의 시간을 제시했다면 앞만보고 마구 달리는 것보다는 가장 빠른 시간에 6개월안에 프로젝트를 끝내는 방법을 마련해야 한다. 경영진은 이런 합리적인 방법을 제시하는 개발팀을 후원할 것이다. 가장 빠른 기간에 프로젝트를 일정에 맞게 끝낼 수 있게 방법을 마련하는 방법이 바로 적절한 스펙을 작성하는 것이다.

댓글 37개:

  1. 너무나도 당연하고 좋은 말씀이시지만 대부분의 경우에는 이상적인 얘기가 아닐까싶네요. 위에서 일정이 잡혀서 내려오면 개발자는 무슨 일이 있어도 그 일정에 맞추어야 하는 것이 현실이죠. 맞추지 못하면 능력없는 개발자로 인식이 되구요. 경영진이 일정을 제시하고 개발자가 상세일정을 만들어 조율을 한다는 것이 정말 바람직한 과정이지만 현실적으로 얼마나 실천 가능한지 또 하고 있는지 모르겠습니다. 물론 그런 회사도 있기는 하겠지만 대부분의 개발자들에게는 아마 그림의 떡같은 현실이 아닐까 싶네요. 개발자들도 그걸 몰라서 못하는 건 아니거든요. 그렇지 못한 현실에서 어떻게 해야 하는지 조언을 주시는 것이 더 많은 도움이 되지 않을까 싶습니다.

    답글삭제
  2. 저랑은 다른 각도에서 글을 이해하신듯 하군요.
    경영진이 제시한 일정에 맞추지 못하면 능력없는 개발자가 되지만, 일정을 완수하기 위해 개발자가 제시한 요구사항을 경영진이 맞추지 못하면 능력없는 경영진이 됩니다.

    위에 글이 현실적으로 들리지 않는다면 그건 능력없는 경영자 밑에서 일하는 경우거나, 능력없는 개발자거나 둘중에 하나가 아닐까요?

    답글삭제
  3. 포스트를 읽을때마다 드는 생각은 당연한이야기'만' 한다는 생각이듭니다.


    프로젝트기간이 10개월이라고 하고
    3개월동안 계획을 세우고 구현할 기능등 여러사항을 쭉 정리한 후.
    7개월동안 구현할 핵심목록을 정리해서 그걸 중심으로 진행하는게 좋은건 알고있습니다. < 개발자에게 이제는 너무나 당연한 이야기지요. 경험이좀쌓이면 그냥 알게 되기도하고, 경험이 입으로돌다가 책으로 한권 나오고 결국 책들이 무수히 쏟아질정도로 오래 지났습니다.


    10개월짜리 일정에 맞춰 임시로 릴리즈하고 13개월째 완성을 시켰다고 하면.
    현재 우리나라에선 3개월동안 놀아서-> 3개월 지연됐다 라는 이야기가 나올겁니다.
    어떻게 개발자를 충원을해서 10개월짜리 일정을 맞춘다고해도 3개월동안 놀아서 더 인력을 투입해야 했다는 이야기가 나올테구요.
    저 외부에서 보기에 아무것도 안하고 있는것같은 시간을 어떻게 설득하고 납득시키는지가 궁금합니다.


    회사에서 외부 컨설턴트를 부르고 그 외부 컨설턴트가 저런 의견을 주면 쉽진않지만 먹힐가능성이 있습니다만.
    회사내에서 외부로 컨설팅을 의뢰할 정도면 상황이 좋은 (좀 깨인 회사에 돈도 좀 있는)회사입니다.

    하물며 그냥 회사내 개발부서에서 이야기하면 어지간한 이야기는 다 그냥 변명으로 넘어갈껍니다.
    니 전임자 또는 너도 이전에 그냥 쭉쭉짜더니 설계? 뭔소린데 라던가.
    어 해~ 그런데 왠 3개월 1주일만에 끝내 라던가.


    이런부분은 전혀 적지 않으시는것 같습니다.
    컨설팅을 하시면 개발자는 납득을 하는데-> 쓸만한 스펙 작성에 어려움을 겪을것 같고
    관리나 경영쪽에 저 2~30%의 시간을 납득을 못했을것 같습니다.

    언제나 글을 읽으면서 궁금한건 저런 설득을 시키던 경험같은것입니다.

    답글삭제
  4. 너무...이상적이지요...
    이상적인 세상에서는 버그도 없겠죠...^^;

    답글삭제
  5. 김익환씨가 쓰는 책도 그렇고, 경험을 중시한다는 태도는 좋지만 실제 "이러이러해서 이렇게 했는데 이렇게 되어서 이런 교훈을 얻었다"는 이야기가 없고, "이렇게 이렇게 해보면 이렇게 될 것이다 한번 해보라"는 이야기도 없어서 전반적으로 글들이 경험적이지 않은 것 같습니다. 좀 더 구체적이면 좋겠네요.

    답글삭제
  6. 안녕하세요. Jake Kim님
    좋은 의견 감사합니다.
    제가 경험한 것은 다양한 프로젝트와 컨설팅 경험입니다. 거기에 비추어 보면 첫째 제 글은 지극히 현실적입니다. 하지만 경험없이 이렇게 하기는 어렵고 우리나라의 대부분의 소프트웨어 회사에서는 일어나지 않는 현상입니다.
    가장 큰 원인은 개발자들이 코딩은 잘하는데 스펙과 설계를 잘 못쓰기 때문입니다. 실제로 많은 개발자들이 그렇게 못해서 못하는 겁니다.
    왜냐하면 역설적으로 그렇게 할 줄 알았다면 무조건 그렇게 했을 겁니다. 제 경험상 말이죠.
    현실적으로 스펙과 설계를 잘하면 되는데 대부분은 이것을 구체적으로 보여달라고 하면 골프를 잘치는 방법을 글로 알려달라고 하는 것과 비슷한 정도로 설명하기 어렵습니다. 제 책에서도 많은 설명이 있지만 필요성은 인식할 수 있어도 스펙을 잘 적는 방법을 배우기는 매우 어렵습니다.
    그렇다고 그런 노력조차 하지 않으면 10년이 지나도 항상 일정에 허덕일 것입니다.
    항상 스펙에 관련된 얘기는 이슈를 많이 일으키는 것 같습니다.
    이유는 다음과 다음과 같습니다.

    "소프트웨어를 개발하는데 있어서 가장 어렵고도 중요한 것은 무엇을 만드는지 결정하는 것이다. 즉, 스펙을 작성하는 것이다."

    답글삭제
  7. 안녕하세요. 루니아님
    제 경험에 의하면 소프트웨어 개발을 이해하지 못하는 경영자가 정말로 많습니다. 개발자들은 이런 SW를 잘 모르는 경영진에게 이해가 가도록 대응하는 것이 필요한데 개발자도 그런 면에서는 매우 취약합니다.

    답글삭제
  8. 안녕하세요. J님
    현실감이 쭉쭉 느껴지는 의견이군요. ^^
    여러 회사의 여러 개발자들을 만나보면 자주 듣는 얘기들입니다.
    그런데, 그런 회사의 경영자, 개발자들도 스펙을 제대로 작성하는 것을 한번만 보기만 해도 완전히 인식이 바뀌는 것을 자주 봐 왔습니다.
    그동안 생각하고 있었던 스펙, 설계라는 것이 많이 다르다는 것을 경험하기 때문이죠.
    제대로 작성하면 병행 개발도 가능하고 일정도 단축된다는 것을 경험적으로 알게 됩니다.
    그렇다고 하더라도 스펙을 진짜 잘 작성하려면 5년, 아니 10년 이상 걸리게 됩니다. 즉, 많이 작성할수록 계속 실력이 늘게 됩니다.

    하지만 막상 회사 내부에서 경영진을 설득하기란 매우 어렵습니다. 그래서 컨설팅이 어려운 회사는 강연을 통해서 경영진의 마인드를 바꿔주기도 합니다. ^^

    답글삭제
  9. 개발20년차님 안녕하세요.

    김익환 대표님은 실리콘밸리에서부터 27년가 소프트웨어 개발 경험이 있고 저는 17년간 소프트웨어를 개발하고 있습니다. 제 글에 있는 그대로 개발을 해왔고 그대로 컨설팅을 하고 있고 블로그에 글을 쓰고 있습니다. 물론 저는 초기에 시행착오를 한적도 있었습니다.

    제 글중에서 이해하기 쉬운 글들은 툴이나 간단한 기법들에 관련될 것입니다. 그리고 이해하기 어렵지만 더 중요한 글들은 스펙, 설계, 문화 등에 관련된 것입니다.

    골프를 배우는데 책과 글을 통한 영양학이나 체력훈련 방법, 장비 선택 방법은 익히기 쉬운데 진짜 스윙과 게임 방법은 글로는 한계를 가지고 있습니다. 눈으로 보고 배우는 것이 유일한 길입니다.

    실리콘밸리의 소프트웨어 회사에 입사를 하면 항상 보고 배우는 그것이라서 저절로 익히게 되는데 우리나라 현실에서는 그렇지 못하기 때문에 어렵습니다. 안타까운 현실이죠.

    답글삭제
  10. 안녕하세요. kalstein님
    이상적으로 생각할 수도 있겠네요. ^^
    이상적이기 보다는 우리나라에서는 어려운 것이라고 생각합니다. 개발자들이 경험하기 어려운 현실 때문에 힘듭니다.
    그래서 미국에서는 소프트웨어 개발자가 최고의 직업중에 하나인데 우리나라에서는 기피 직업이 아닌가 생각합니다.
    제 Twitter의 소개를 보면 "소프트웨어 개발자가 이 땅에서 최고의 직업이 되는 날을 꿈꾼다"라고 되어 있습니다.
    그런 날이 오겠죠?
    여담인데 과거 버그없는 사용 SW가 하나 있었다고 합니다. ^^
    버그를 찾는 사람에게 상금을 걸었는데 못찾았다고 하더군요.
    그래도 현실적으로 버그 없는 SW는 없겠죠.

    답글삭제
  11. 스펙 작성하는 것과 무엇을 만들지 결정하는 것을 같은 걸로 보시는 것 같은데, 이해가 안되네요. 왜 그 두가지를 같은 것으로 보시나요?

    답글삭제
  12. 본문보다 댓글을 더 재밌게 읽었습니다. ^^ 어느책에선가 '야근은 카드로 물건을 사는것과 같다.'라는 비유를 본적있습니다. 경영진의 마인드가 바뀌는게 최우선이겠네요.

    답글삭제
  13. k16wire님 안녕하세요.
    저도 댓글을 매우 좋아합니다. 여러 개발자들의 의견을 들을 수 있어서 저에게도 매우 도움이 되고 블로그 독자들에게도 도움이 될 것으로 생각합니다.
    항상 시간을 내서 댓글을 달아주는 여러 개발자들에게 감사한 마음을 가지고 있습니다.

    답글삭제
  14. 스펙 작성은 80년대부터 해오고 있습니다.

    스펙 작성하는 것을 requirement engineering과 동일하게 보시나 보군요. IEEE 스탠다드는 오래전에 보긴 했지만 현업과는 거리가 멀어서 그다지 건질만한 것이 없더군요. 최근 requirement engineering 쪽의 발전을 따라오고 있지도 못하는 것 같고요.

    구체적으로 어떤 문서를 추천하시는지 reference를 알려주시면 고맙겠습니다.

    답글삭제
  15. 저는 현재 미국에 있고 스타트업 부터 미국 최대대기업까지 경험을 해봤습니다. 일정에 대해 말씀드리자면 그건 그 회사의 문화내지는 그 프로젝트의 스폰서의 성향에 따라 많은 차이가 있는 것 같습니다.

    며칠 걸릴 작업을 1-2주 주는 관리자도 있고 한달 걸릴 작업을 일주일주는 경우도 있습니다. 미국 회사라고 다 넉넉한 일정을 준다거나 일정을 조율할 수 있다는 인식을 주시는 것은 지양을 해야 하지 않을까 싶습니다. 그런 의미에서 드린 말씀입니다.

    위에 말씀하신 것들이 바람직하다는 것을 모르는 개발자들은 아마 없을 겁니다. 다만 특히 한국적 상황에서 경영자나 윗 사람에게 일정을 조율해야 한다는 것을 설득할 방법을 모르거나 없다는 것이 문제인 것이죠.

    스펙을 쓴다고 설득이 될까요? 그래서 설득이 될 경영자 같으면 처음부터 막장 일정을 제시하지 않겠죠. 개발자가 아무리 스펙을 갖다 밀고 소프트웨어 공학적인 지식으로 설득을 하야시가 경영자의 이말 한마디면 쓸모가 없어지죠.

    시장에 빨리 내놔야 해.

    문제는 항상 시장에 빨리 내 놓아야 하는 경영진을 어떻게 설득을 하는가인데 이는 소프트웨어 공학과는 거리가 있는 문제 같아 보입니다. 그리고 정말 상황이 그렇다면 도리 없는 일 아니겠습니까.

    답글삭제
  16. Jake님 안녕하세요.

    항상 적극적인 의견 제시를 감사드립니다.
    저는 여러 의견을 통해서 항상 배우고 있습니다.
    제 글을 보고 있는 많은 개발자들은 경험과 환경이 매우 다릅니다.
    너무 당연한 것도 모르고 있을 수도 있고 아주 잘 알고 있는 개발자들도 있습니다.
    그래서 주로 가장 많은 한국의 보통 개발자를 주 독자로 생각합니다. 아주 정교한 것은 아닙니다.
    jake님 시각에서 좀 다른 것은 언제든지 말씀해주세요. 이런 대화 자체가 많은 독자에게 의미 있을 것 같습니다.


    한국에서는 대부분은 아무런 근거도 없이 "일정이 모자란다", "일정을 더 달라" 얘기를 하는데 근거가 필요하다는 얘기입니다.
    스펙은 그런 결정을 하는데 도움을 줍니다.

    경영자와 도저히 의사 소통이 안된다면 어쩔 수 없을 것입니다.
    무조건 시킨다고 한달 걸릴 일을 1주일만에 해낼 수는 없을 겁니다. 설령 해냈다고 하더라도 뭔가를 희생했을 겁니다. 품질을 희생했으면 회사가 나중에 손해를 볼 것이고 건강을 희생했으면 내가 나중에 손해를 볼 것입니다.

    상대적으로 미국보다 한국에서 합리적으로 대화가 안되는 경영자가 더 많습니다. 이런 경영자는 스펙이고 소프트웨어 공학이고 필요 없습니다. "이런 경영자를 설득하는 방법" 같은 것은 제가 따로 설명하지는 않습니다. 그런 개발자를 직접 교육하고 설득하여 경영자의 마인드를 바꾼 경험은 많습니다.

    이런 경영자 밑에서 일하고 있다는 것 자체가 피곤한 일이죠.

    답글삭제
  17. 안녕하세요. SilliconValley님
    스펙을 가장 간단하게 표현하는 말로 "무엇을 만드는지 결정하는 것"이라고 말합니다. 이 말이 맞다 틀리다 논쟁을 할 수 있습니다. 스펙의 실체를 정확하게 표현하기는 그만큼 어렵습니다.
    SilliconValley님이 이해가 안되서 여쭤보시는 것인지, 틀리다고 생각하시는 것인지, 다른 의견이 있으신 것인지, 즉 질문의 의도를 좀더 구체적으로 얘기를 해주면 건설적인 토론이 될 것 같습니다.
    스펙을 제대로 이해하려면 스펙을 제대로 다년간 작성을 해오면서 IEEE에서 나온 스펙에 관련된 문서들을 여러번 읽어보면서 음미를 하면 될 것 같습니다.

    답글삭제
  18. SilliconValley님 안녕하세요.
    80년대부터 스펙을 작성해오고 있다면 80년대 말이라고 하더라도 30년 이상의 경험을 가지고 계시는군요. 이미 어느 정도 경지에 오르셨을 것 같은데요.

    "이론이 먼저냐 현실이 먼저냐"는 것도 이슈가 되는데 소프트웨어 공학은 현실이기 때문에 현업과 거리가 멀어서 쓸모가 없는 것은 소프트웨어 공학이라고 보기 어렵거나 다르게 이해하고 있는 경우가 많습니다.
    IEEE 스탠다드 문서들도 현실의 경험을 토대로 만들어진 것들이기 때문에 받아들일 때 적절하게 해석을 해야 할 것으로 생각합니다.
    제 경우를 말씀드리면 10년 전에 봤던 문서를 지금 보면 완전히 다릅니다. 그동안 쌓은 경험 때문이겠죠. 사소하게 읽고 지나갔던 문장들이 눈에 들어오더군요. 10년 후에는 또 달라져 있을 겁니다. 매우 오래된 문서들이지만, 지금도 유용합니다.
    그래서 스펙을 작성하는 실력은 몇 십년이 지나도 계속 발전한다고 봅니다.

    답글삭제
  19. 맞습니다. 그런 경영자나 관리자와 같이 일한다는 것은 정말 고달픈 일입니다. 안타까운 것은 그런 환경이 꽤나 많다는 것이지요. 많은 사람들에게 편리를 제공하는 개발자들이 정당한 대우를 받고 일할 수 있는 환경이 빨리 만들어졌으면 좋겠습니다.

    답글삭제
  20. 댓글이 궁금해서 다시 왔습니다.
    좋은 글은 Facebook으로 사람들에게 추천하고 있는데요.
    반응은 '우리회사 얘기네..' 라는 식입니다.(그런 글들만 추천하니까요.)
    마치 전규현님이 우리회사에 다녔던 분같습니다. &^^&..
    좋은 글들 많이 부탁드립니다..

    답글삭제
  21. "그런 개발자를 직접 교육하고 설득하여 경영자의 마인드를 바꾼 경험은 많습니다."라고 하셨는데, 개발자가 교육을 받고 경영자의 마인드를 바꿨다는 말씀이죠? 그런 경험이 많으시다면, 제 생각에 그 경험 이야기를 해주시는 것이 훨씬 더 유익할 것 같습니다.

    답글삭제
  22. J님 덧붙일 것이 있습니다. ^^

    제가 컨설팅을 한 회사 중에서 가장 작은 회사는 총 직원이 10명 정도에 매출액이 10억 정도인 회사도 있고, 큰 회사는 직원이 몇만명인 회사도 있습니다.
    컨설팅은 돈이 여유가 있어서 하는 것이 아니고 스스로 해내기 어렵지만 꼭 필요한 도움을 외부 전문가에게 도움을 청하는 것입니다.
    이를 통해서 회사가 얻는 이득이 비용에 비해서 훨씬 크다고 생각하는 회사들만 도움을 요청합니다.
    또한 저희는 컨설팅 보람이 큰 회사를 우선 순위 높게 생각하고 있습니다.
    컨설팅이 돈많은 회사가 여윳돈으로 하는 것이 아닌가 오해를 할까봐 말씀드립니다.

    답글삭제
  23. SilliconValley님 안녕하세요.
    경영자의 마인드는 저희가 바꾸는 교육을 합니다. 제 덧글에 오타가 있군요.
    사실 경영자의 마인드를 바꾸는 것은 매우 어렵고 바뀌지 않는 경우도 많습니다. 절대 바뀌지 않는 경영자들도 많지만 바뀔 준비가 되어 있는 경영자들도 많이 만나 봤습니다. 그들은 바뀔 준비가 되어 있지만 방법을 모르기 때문에 이런 저런 시도를 하다가 거의 실패하고 저희를 찾아오는 경우가 많습니다. 그런 경우에는 빠르게 개혁에 성공하곤 합니다.
    저희는 컨설팅할 때 NDA를 맺기 때문에 컨설팅 경험을 직접적으로 얘기를 할 수는 없습니다. 단 일반화 시켜면 언급을 할 수 있기 때문에 앞으로 그런 경험의 글을 올려보는 것을 고려해보겠습니다. NDA에 위배되지 않게 조심해야 하기 때문에 신중할 것입니다.
    제 블로그에는 SW 회사가 바뀌는 것은 경영자에게 달려있고 경영자가 어떻게 바뀌어야 하는지에 대한 글들이 여기 저기 있습니다.

    답글삭제
  24. 댓글이 본문보다 더 길어져 버린 글이네요 ㅎ

    어떻게 보면 이런 상황으로 몰아온 개발자의 "소리없는" No! 가 문제가 아닐까도 싶지만
    칼을 쥐고 있는 쪽은 운영자/경영진 이다 보니 힘없는 개발자에서 힘이 넘치는 개발자로
    탈피를 하지 않는 이상에는 위와 같은 소모적인 논쟁의 끝은 없지 않을까 보여집니다.

    결국은 칼을 쥐는 쪽이 주도권을 잡을테니 말이죠.

    답글삭제
  25. 안녕하세요. kampf
    Facebook ID 좀 알려주세요. 저도 Facebook을 하거든요. 댓글을 좀 보고 싶네요. ^^
    제 Facebook주소는 다음과 같습니다.
    http://www.facebook.com/raymond.jeon

    그만큼 우리나라의 대부분의 소프트웨어 회사가 실정이 비슷한 것 아닐까요?
    제 만나는 회사는 10명이하의 작은 회사에서 부터 직원이 10,000명이 넘은 대기업까지 다양합니다. 하지만 비슷한 문제점들을 가지고 있습니다. 바뀌기에는 작은 회사가 더 유리합니다.

    답글삭제
  26. 구차니님 안녕하세요.
    댓글이 많은 것은 저도 환영합니다. 이를 통해서 개발자들이 어느 부분을 더 어렵게 생각하는지 잘 알 수 있습니다.

    답글삭제
  27. 제가 적은걸 오해하신거 같습니다.

    제가아는상식선에서 어떤 회사라도 돈이 남아돌아서 컨설팅을 의뢰하진 않을것 같습니다.
    컨설팅을 의뢰한다는건 회사의사결정권자가 외부 의견에 따라 회사 내부 방침을 바꿀 생각이 있다고 보입니다. 돈때문에 오늘내일하는 회사도 아닐테구요.
    즉 컨설팅을 하면서 보신 회사는 적어도 프로세스 개선에 관해서는 비교적 설득이 쉬운 회사일 확률이 높습니다. 오히려 의사결정권자가 부른거니 개발부서에서 저항이 더 컸을지도 모르겠습니다...
    어쨋거나 보통회사는 개발부서쪽이 좀더 저런내용을 납득시키기 쉽습니다.



    그리고 경험을 좀 적어달라고 한것도, 쓰신 내용을보면 일이 쉬운회사만 컨설팅을한건가... 라는 생각이 들어서입니다.

    어제까지 날새면서 일을 하던 회사에서 이글을 보고 그대로 따라하면 어떻게 될까요?
    일단 기적적으로 스펙까진 정말 잘 - 한5년차쯤 되는사람이 잡는 수준으로 잡았다고 가정해도 100% 말한 일정 못지키고 깨진다에 표를 던지겠습니다.
    개발자 스스로 과대평가하는것(50%확률로 잘풀리면 끝날일정을 잡는다거나)도 문제지만, 규모가 커서 일이 서로엮이고 복잡한 경우는 프로세스대로 몇번 일이 흘러가며 데이터가 쌓여야 예측한 일정의 정확도가 높아질 수 있습니다. 게다가 이전에 날새면서 한 프로젝트 뒤처리가 안터질리도 없구요...
    적어도 이런 일반적인 이야기정도는 나올법한데 전혀없습니다.
    거의 예전 BBB가 AAA를 상속해서 라고 씌인 언어책을 보는느낌입니다.

    답글삭제
  28. 안녕하세요. J님

    저도 대부분 동의합니다. ^^ 오해라기 보다는 제가 답글을 달 때 이또한 다른 분들도 모두 보기 때문에 1:1 의견 교환이 아니고 여러분들이 보고 있다고 생각하고 적습니다. 그래서 이런 얘기가 왔다 갔다 하는 것이 아주 좋은 현상이라고 생각합니다. 제가 모르는 것도 알게 되는 경우도 있습니다.

    맞습니다. 저희는 거의 대부분 최고경영자가 요청을 해서 컨설팅을 합니다. 또는 개발팀에서 필요성을 느껴서 최고경영자를 설득해 오는 경우도 종종 있습니다. 그리고 컨설팅하기 쉬운 회사는 없습니다. 저희 컨설팅은 개발자부터 경영자의 마인드까지 바뀌어야 하고 몸에 베인 여러가지 습관들은 바꿔야 하기 때문에 받는 입장에서는 어렵습니다. 저항이 심할 때도 많고요. 이는 대기업이나 중소기업도 마찬가지 입니다.
    변화가 그렇게 쉬웠으면 저희가 없어도 회사에서 자체적으로 변화를 했을 겁니다. 저희에게 의뢰를 하는 이유는 변화가 어렵기 때문에 그리고 변화의 방향을 잘못 잡아서 시행착오를 하는 리스크가 너무 크기 때문입니다.

    말씀하신 것 같이 지금까지 밤세워가면서 유지보수에 정신 없던 회사가 기적적으로 나아지기는 어렵습니다.
    악순환의 고리가 시작된 경우라고 볼 수 있습니다.
    이미 나쁜 폼이 몸에 익은 골프 선수는 이를 고치는데 처음부터 배우는 것보다 더 오래 걸릴 수 있습니다.
    이런 경우 "이미 망친 상태"는 제대로 하기 더 어렵다고 합니다.

    컨설팅을 하다보니 "망친 경우 어떻게 해야 할까"라는 의문에 많이 부딪힙니다. 어떤 경우 이미 너무 망쳐서 복구가 불가능한 경우도 많습니다. 하지만 대부분의 경우는 많이 망쳤든, 조금 망쳤든 원칙에 의거해서 회사와 개발자를 변화시키는 방법을 취하고 있습니다.

    많이 망친 경우 시간이 좀 오래 걸리고, 제대로 하고 있었고 다음 단계에 대한 고민을 가지 회사는 정말 잘 적응하고 성장합니다.

    제 얘기가 대부분 원칙을 강조해서 현실에서 멀어 보인다고 느끼는 분들도 많다는 것을 알게 되네요. 이런 경우에도 원칙대로 하라고 강조하는 것을 물러서지는 않습니다. 그방법이 가장 빠르다고 생각하기 때문입니다.

    여기서 원칙은 또 한참 얘기해야 하지만 흔히 알고 있는 정형화 된 프로세스를 말하지 않습니다. 프로세스나 문서를 작성하기 위해서 프로젝트가 더 늦어지면 원칙에서 벗어난 것입니다. 원칙에 대해서는 나중에 또 다루죠. ^^

    이렇게 좋은 의견을 계속 주셔서 정말로 감사합니다. 앞으로도 계속 의견 남겨주세요.

    답글삭제
  29. 댓글이 길고, 여러 사람들과 주고 받았길래 읽어 보았습니다.. 정말 주옥같은 댓글과, 절절한 개발자들의 하소연이 느껴집니다.. 저역시 개발자라로서 같은 생각입니다..용기있게 글을 써주고, 성심껏 답변해주신 개발자들과 전규현님께 감사의 인사드립니다.

    답글삭제
  30. 안녕하세요. 최준용님
    감사합니다.

    답글삭제
  31. 서로 다른 욕구 대부분의 경우 개발자들은 사람과 상호 작용을 다루는 일에 서투릅니다. 경영진은 사람과 친숙치 않은 사람과 일을 함께 하는데 서툽니다. 개발자들은 경영진이 쉽게 일을 생각한다 느끼고 경영진은 개발자들이 일을 성실하게 하지 않는다고 느낍니다. 그런데 정말 그것이 사실일까요? 왜 경영진은 개발팀이 보기에 촉박한 일정을 제시할까요? 경영진의 ‘욕구’를 생각해봅시다. 일반적인 경영에서는 제품의 출시로 매출이 나오면 성공이라 생각하지요. 그래서..

    답글삭제
  32. 이 블로그에서는 소프트웨어 회사 경영진이 주로 악역을 맡는데요. 경영진을 위한 변명도 있어야 할 것같아서 몇자 적어봅니다.

    제가 아는 많은 경영자분들은 일정을 함부로 결정해서 내려보내지 않습니다. 개발을 잘 모르는 사장님들도 자사의 개발팀장이나 지인들에게 어느 정도의 시간이 걸릴지 의견을 구하는 것이 일반적이고요. 계속 변하는 시장 상황이나 경쟁사에 대한 대응 수준, 과거 유사 프로젝트에서의 경험, 자사 개발자의 개발 능력 등도 일정 결정에 중요한 요인입니다. 즉, 막무가내 같이 보이는 경영진이라도 일정을 제시할 때는 뭔가 근거가 숨어있다는 것입니다.

    그래서 경영진에게 촉박한 일정이라고 의견을 낼 때는 본문에서 강조하신 스펙과 같은 근거가 필요하지 않을까 싶습니다. 무턱대고 촉박한 일정이라고 하거나, 데드라인에 다와서 해봤더니 무리한 일정이었다 하는 것보다는 나름의 근거를 가지고 개발팀의 의견을 제시한다면 조기에 일정을 재조정하거나 추가적인 지원을 받을 수도 있지 않을까 생각합니다.

    항상 좋은 글 감사드립니다.

    답글삭제
  33. 안녕하세요. 전경헌 사장님

    개발자가 흔히 촉박하다고 말하면서도 그 근거가 희박한 경우가 많습니다. 전사장님 주변에는 개발을 이해하고 있는 분들이 많은 것으로 알고 있습니다. ^^

    답글삭제
  34. 개발자들이 촉박하다고 얘기하는 근거는 명시적인 스펙 문서나 스케줄은 없지만.. 고참 개발자 같은 경우 자신이 그동한 해온 프로젝트와 이번에 진행할 프로젝트의 작업량을 비교해서 경험상 촉박하도고 하는 경우가 대부분일 겁니다.
    또한 우리나라의 경우 일정 자체가 영업쪽에서 워낙 비현실적으로 짧게 잡고 시작하는 경우가 많기 때문에
    개발자가 촉박하다고 하는 경우는 대부분 촉박한게 사실이죠

    전경헌님 생각이나 경험대로 경영자 분들이 일정을 함부로 결정하지는 않을지도 모르고, 그러고 싶지는 않더라도
    우리나라의 갑을병정 구조에서 일정이 갑쪽에서 결정되어 내려오는 경우가 허다합니다.
    경영자 까지도 선택의 여지가 없는 경우가 많다는 것이죠. 결국 갑쪽에서 일하고 싶으면 일정대로 한다고 하고, 일하기 싫으면 관더라 하는 식으로 나오면..

    사실 방법이 없습니다.

    답글삭제
  35. 이성열님 안녕하세요.

    이렇게 방법이 없이 돈은 벌어야 겠고, 닥치는대로 일을 하면 점점 어려워 집니다.

    방법이 없는 것은 아니고 그 방법을 제시하고 회사를 변화시키는 것이 제가 하는 일입니다. ^^

    스펙을 쓰는 이유는 프로젝트를 시간을 단축하기 위함인데 그럼에도 불구하고 불가능한 일정의 프로젝트는 안하는 것이 좋습니다.
    그래도 진행하고 영업적으로 풀곤 하는데 그렇다면 스펙을 제대로 쓰고 영업적으로도 해결하는 것이 좋습니다.

    결국 어떠한 경우라도 스펙을 적절하게 쓰고 개발하는 것이 좋습니다. 스펙도 없이 무조건 시작했다가 망가지는 프로젝트가 많은데 이런 장님 코끼리 만지는 듯한 프로젝트 보다는 스펙을 제대로 쓰고 합리적으로 개발하는 것이 좋습니다.

    답글삭제
  36. 제가 개발자여서 그런지 왠지 제목만 보고도 답답해지는 글이네요
    (글이 문제가 있다는 뜻이 아니라 그냥 제 상황이 떠올라서요ㅋ)
    제가 경영진이거나 사장이라면 다르게 느껴졌겠죠? ㅎ
    좋은 글 잘 보고 갑니다^^

    답글삭제
  37. 안녕하세요. redred님
    누구의 탓이라기 보다는 서로들 소프트웨어에 대한 이해가 부족해서 그렇습니다.

    답글삭제