태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

인해전술이 오히려 프로젝트를 망친다.

2013.02.11 23:31 by 전규현


잠시 후 Google blogger로 이동됩니다.




일정이 촉박하다고 프로젝트를 빨리 끝내고 싶은 마음에 프로젝트 초기부터 대거 인력을 투입하면 오히려 프로젝트를 망칠 가능성이 더 높아진다.


프로젝트 초기에 분석/설계 단계에는 그렇게 많은 인력이 필요하지 않다.


많은 인력을 분석도 안된 프로젝트에 투입을 하면 놀 수 없는 개발자들이 인터페이스도 정의가 안된 모듈이나 라이브러리를 만들기 시작한다. 이것들 중 대부분은 나중에 다시 만들어야 하고, 이것들을 버리기 아까워서 어떻게든 활용하려고 버티다보면 소프트웨어의 아키텍처가 점점 이상하게 된다.


많은 인력이 투입되는 단계는 구현단계이며 핵심 구현 인력들이 분석/설계 단계에 리뷰어로 참석할 수는 있다.  일정이 촉박하면 분석/설계를 최대한 빨리 끝내고 할일의 범위와 아키텍처를 명확히 한 후에 인력을 투입해야 한다.


필요한 라이브러리를 개발하지 말고 상용라이브러리를 구매하는 것도 일정을 단축하는데 도움이 된다.


가장 안좋은 방법이 프로젝트 초기에 시장통처럼 개발자를 잔뜩 투입하는 것이다. 소프트웨어 개발을 잘 모르는 경영자들이 이런 실수를 종종 하곤 한다.


우리 주변에서 1년짜리 프로젝트인데 10명의 개발자가 투입되면 10명이 12달동안 계속 같이 일하는 경우를 흔히 볼 수 있다. 이렇게 일정 투입 계획이나 현황만 보아도 개발이 얼마나 주먹구구식으로 진행되고 있는지 알 수 있다. 10명의 개발자가 투입되는 프로젝트도 초기 2,3개월 또는 3,4개월동안은 분석/설계를 담당하는 1,2명만 필요하다. 이 프로젝트에서 분석/설계를 담당한 엔지니어는 많은 개발자가 투입되는 구현기간에 같이 구현에 참여할 수도 있고 다른 프로젝트에서 또다시 분석이나 설계를 담당할 수 있다.


이렇게 인력이 효율적으로 순환이 되면 훨씬 적은 인력과 비용으로 많은 프로젝트를 효과적으로 진행할 수 있게 된다.


인해전술로 많은 인력을 투입하는 방법은 해당 프로젝트를 망치는 방법일 뿐만아니라 회사 전체적으로 효율적인 인력운영을 할 수 없게 만든다. 


image by   Boston Public Library



저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/일정

90%에서 끝나지 않는 프로젝트

2011.07.27 22:32 by 전규현


잠시 후 Google blogger로 이동됩니다.





Software 개발 프로젝트에서 일정이 늦어지는 경우는 흔하다. 초기 일정을 완벽하게 맞추어서 끝내는 프로젝트는 구경하기 힘들 정도이다.

그 중 대부분의 프로젝트는 90%까지는 진도가 착착 잘 나가는데 10%를 남기고 나서 일정이 계속 지연되곤 한다. 남은 10%를 끝내기 위해서 90% 끝내는데 걸리는 시간보다 더 오래 걸리는 프로젝트를 보는 것은 그리 쉬운 일이 아니다. 설령 일정에 밀려서 출시를 해도 버그가 많은 알파버전 수준의 제품을 출시해서 고객들의 원성을 사기 일쑤이다.

경영자는 매달 개발자들이 하는 다음달이면 끝난다는 얘기를 반복해서 듣게 된다.

이러한 상황을 개발자들은 그렇게 심각하게 보지 않는 경우가 많다. 하지만 비즈니스를 하는 사람은 이것이 비즈니스를 하는데 얼마나 심각한 문제가 되는지 잘 알고 있다.

소프트웨어 공학은 프로젝트 일정을 단축하고 계획대로 개발할 수 있도록 하기 위한 방법에 온 힘을 기울여 왔다. 소프트웨어 공학에서 다루는 거의 모든 분야는 일정 준수에 포커스를 하고 있다고 해도 과언이 아니다.

남은 10%의 일정이 그렇게 잘 안끝나는 주요 원인들은 다음과 같은 것들이 있다.
  • 스펙을 충분히 제대로 작성하지 않았다. 단순한 요구사항을 가지고 개발자들이 알아서 개발을 한다.
  • 설계가 허술해서 인터페이스가 자주 바뀐다. 통합이 잘 안되서 통합하는데 시간이 많이 소요된다.
  • 상세 일정이 없이 큰 단위의 마일스톤만 가지고 있다. 일정관리는 거의 안한다.
  • 리스크 관리는 해본적도 없다.
  • 제품이 개발되기 전까지 스펙이 공유가 안되서 영업이나 경영층에서 프로젝트 막바지에 제품의 모습을 보고 요구사항을 계속 추가로 요청한다. 
  • 프로젝트 일정에 테스트 일정을 충분히 고려하지 않았다. 테스트 케이스를 제대로 만들지 않고 테스트 인력이 부족해서 테스트 할 때마다 계속 새로운 버그가 발견되서 끝나지를 않는다.
개발 방법론이 라이프 사이클들은 여러가지가 있고 최근에 유행을 타는 것들도 있지만 결국에는 스펙을 상세히 제대로 작성하는 것이 근본적인 프로젝트 일정을 지키는 방법이다. 스펙을 제대로 작성하지 않고 여러가지 기법으로 해결할 수는 없다. 스펙을 작성하는 방법이 어찌되었든 스펙이 정확하고 상세해야 정교한 일정 예측 및 관리가 가능해지게 된다. 이런 경험이 점점 쌓이면 일정을 지키는 프로젝트가 점점 늘어 갈 것이다. 그러기 때문에 스펙을 잘쓰는데는 10~20년의 경험이 필요한 것이다.

대충 개발자들이 알아서 개발해주고 일정은 하늘(개발자인가?)에 맡기는 방법에 익숙해진 개발자들은 이런 정교한 일정관리에 거부감을 가질 수는 있으나 결국에는 일정을 지키는 방법이 개발자의 역량을 향상시키는 방법과도 일치하기 때문에 개발자 손에 달린 프로젝트가 개발자에게 파워를 가져다 준다는 생각은 버리는 것이 좋다.

프로젝트 일정은 10%가 남았다면 진짜로 10%만 더 지나면 끝나야 한다. 

 * 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image from
 http://dimland.blogspot.com/2010_08_01_archive.html 
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/일정 스펙, 일정

  1. 프로젝트 일정 자체가 범위와는 무관하게 비즈니스 목표일정으로 정한 후 최대한 많은 기능을 넣는 프로젝트도 있고, 기획이 되지 않은 상황에서 일정추정을 강요하는 환경도 많이 있습니다. 이런 경우는 어떻게 대처해야 좋을지 혹시 좋은 의견이 있으신지요? ㅠㅠ

  2. 이런 프로젝트는 범위도 불투명한 상황에서 일정이 남는다 모자른다 아무리 싸워도 아무 의미가 없게 됩니다. 개발자들은 막연히 일정이 모자른다고 하지만 또한 대부분 늦어지지만, 초기에는 아무 근거도 없이 동대문시장에서 물건 깎듯이 아규를 하게 됩니다.

    가장 좋은 방법은 최대한 빨리 스펙을 쓴 다음에 근거를 가지고 얘기를 하는 겁니다. 일정의 근거가 명확해지면 기획이나 영업에서 무조건 우기기에도 궁색해지게 됩니다.

    또한 기획도 되지 않은 상황에서의 일정 추정은 무리지만 일단 대략의 일정을 주고 꼭 스펙을 써봐야 정확한 일정을 다시 산정할 수 있다고 강조를 해야 합니다. 이를 잘 이해 못하는 사람들도 많지만 이해를 시켜야 합니다.

    기능을 무조건 많이 넣는 것은 키친씽크입니다. 쓸데 없는 기능을 잔뜩 넣는 겁니다. 스펙을 쓰고 WBS에 근거해서 상세 일정이 나와야 쓸데 없은 기능으로 얼마나 일정이 늦어지는지 근거를 제시할 수 있고 이런 기능은 빼고 출시 할 수 있습니다.

    결국 근본적인 해결 방법이 가장 좋은 방법입니다. 문제는 스펙을 잘 작성하는 것이 소프트웨어 개발에서 가장 어렵다는 것입니다. 꾸준히 경험을 쌓아야 합니다.

  3. 의견 감사합니다. ^^ 고객이 무엇을 하고 싶은지도 모르는 상황에서 스펙을 이끌어낸다는 것은 무척이나 어렵군요 ㅠㅠ. 하지만 이게 바로 경험이고 능력이 아닐까 생각합니다. 말씀하신 부분을 명심해서 실천을 해보도록 하겠습니다.

  4. 한가지 더 말씀드리면 고객이 무엇을 하고 싶은지 모르는 상황은 매우 자연스러운 현상입니다. 특히 우리나라에서는 고객이 전문가도 아니고 노력도 안합니다. 우리나라가 좀 심하긴 하지만 외국이라고 고객들이 그렇게 잘 알지 못합니다.
    그래서 스펙을 제대로 작성하는 것이 어렵고 그게 실력의 차이입니다.
    고객이 잘 모르고 개발팀도 잘 모르면 산으로 갈 수 밖에 없습니다. 코딩하기 전에 스펙을 제대로 적고 개발해야 다 만들어 놓고 기능 추가 변경을 반복하지 않을 수 있고 기간과 비용이 절약됩니다.
    아무튼 코딩은 늦게 할 수록 이익입니다. ^^ 이걸 이해하려면 한참 걸립니다.

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

2011.02.16 22:14 by 전규현


잠시 후 Google blogger로 이동됩니다.





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

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

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

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

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

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

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

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

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

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

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

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

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

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

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by kobiz7

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/일정 스펙, 일정

  1. Blog Icon
    Jake Kim

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

  2. Blog Icon
    루니아

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

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

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

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

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

  5. Blog Icon
    SilliconValley

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

  6. Blog Icon
    SilliconValley

    스펙 작성은 80년대부터 해오고 있습니다.

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

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

  7. Blog Icon
    Jake Kim

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

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

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

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

    시장에 빨리 내놔야 해.

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

  8. Jake님 안녕하세요.

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


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

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

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

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

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

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

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

  11. Blog Icon
    Jake

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

  12. Blog Icon
    SilliconValley

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

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

  14. Blog Icon
    J

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


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


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


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

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


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

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

  15. Blog Icon
    개발20년차

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

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

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

  17. 개발20년차님 안녕하세요.

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

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

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

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

  18. J님 덧붙일 것이 있습니다. ^^

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

  19. Blog Icon
    J

    제가 적은걸 오해하신거 같습니다.

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



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

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

  20. 안녕하세요. J님

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

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

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

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

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

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

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

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

  21. 너무...이상적이지요...
    이상적인 세상에서는 버그도 없겠죠...^^;

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

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

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

  25. Blog Icon
    kampf

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

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

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

  27. 댓글이 본문보다 더 길어져 버린 글이네요 ㅎ

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

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

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

  29. Blog Icon
    최준용

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

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

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

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

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

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

  32. 안녕하세요. 전경헌 사장님

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

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

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

    사실 방법이 없습니다.

  34. 이성열님 안녕하세요.

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

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

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

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

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

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

하루 8시간 일하시나요?

2008.12.16 14:26 by 전규현


잠시 후 Google blogger로 이동됩니다.



하루에 8시간 일하시나요?
그렇다고 프로젝트 일정을 예측할 때 하루 8시간 일을 하는 것으로 계산하십니까?
그러면 프로젝트 일정을 지키기 어려울 것입니다.

보통 아무리 집중해서 일을 한다고 해도 하루에 80% 일하기 어렵습니다.
나머지 20%의 시간은 회의를 하고, 커피도 마시고, Email도 봐야 합니다.
또 2개의 프로젝트에 4시간씩 할당이 되어 있어도, 업무 전환 비용(Context switching cost)를 무시할 수 없습니다.

물론 프로젝트 일정은 프로젝트 관리자 혼자서 마음대로 정할 수가 없습니다.
실제 업무를 담당할 담당자들의 도움을 받아서 일정을 산정하게 됩니다.
이때 담당자들이 산정한 일정을 그대로 받아들이나요? 아니면 스스로의 버퍼를 따로 두시나요?
저는 하루의 업무시간을 보통 8시간*80%로 잡고 일정을 산정합니다. 
그 이유는 다음과 같습니다.

  • 개발자의 기술력은 믿지만, 일정 예측 능력은 믿을 수 없습니다.
  • 프로젝트를 진행하다 보면 항상 예상치 못한 일이 발생합니다.
  • 프로젝트가 막바지로 가면, 특히 통합과정에서의 혼란을 개발자들은 쉽게 생각하는 경향이 있습니다.
  • 과거의 경험으로 보면 예상된 일정보다 빨리 끝난 프로젝트는 거의 없었습니다.

낙관적인 일정도 나쁘지만, 일정을 너무 비관적으로 잡으면 프로젝트팀이 자칫 게을러 질 수도 있습니다. 80%의 시간만을 일하는 것으로 일정을 잡아도 프로젝트가 진행되면 부정확인 일정 예측으로 인해서 초과근무는 자주 일어납니다. 그래도 합리적인 일정으로 산정되었기에 프로젝트 일정을 지킬 가능성이 훨씬 높습니다.

이러한 일정산정을 너무 넉넉한 일정으로 비난하는 경영자나 관리자가 있을 수 있습니다.
하지만 무리하게 촉박하거나 낙관적인 일정으로 일정을 지키지 못하거나 개발자를 너무 혹사하는 것보다는 합리적인 일정이 더 낫습니다.
프로젝트팀에서는 믿을 수 있는 일정을 제시하고 지키는 것이 계획적인 비즈니스를 할 수 있게 하는 원동력입니다.
이렇게 프로젝트팀이 제시한 일정이 신뢰를 받기 위해서는 합리적인 근거 제시와 투명한 프로젝트 진행이 꼭 필요합니다. 


(아래 그림은 프로젝트 초기에 일정 산정이 얼마나 어려운지를 보여주는 그래프입니다. 
프로젝트 초기의 일정은 -50% ~ +200%까지의 오차를 보인다는 의미입니다.
그리고 정확한 일정은 끝나봐야 안다는 거죠.)

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/일정 8시간근무, 일정

  1. 원칙적으로 일정 예측은 개발자에게 맡겨야 한다고들 합니다. 하지만, 어떤 개발자들은 턱도 없이 짧은 일정을 "한번 해보겠습니다"라고 말하기도 하고, 또 다른 개발자들은 온갖 버퍼를 다 고려해서 말도 안돼게 늘어진 일정을 내놓기도 합니다. (그러고는 "예정보다 일찍 끝냈지요?" 라고 말할때는 정말 얄밉습니다.) 그래서 Planning Poker 방법을 한번 도입해 보려 하는데 혹시 해보신 분이 있으면 조언 부탁드립니다.

  2. 헝그리맨님 안녕하세요.
    일정산정은 정말 어려운 일입니다. Planning Poker를 이용해서 일정을 산정해 본적은 없지만, 개발이라는 것이 누가 하냐에 따라서 소요시간이 다르므로 실제로 일을 할 사람이 산정하는 것이 좋지만 일정산정을 잘 못하는 개발자가 많다는 것도 어려움 중의 하나입니다.
    그래도 스펙을 잘 적고, WBS를 잘게 쪼개서 일정을 산정하는 방법이 그중에 정확한 방법입니다.

  3. 레이님? ^^ 소공!!(아직 학생이라 소프트웨어 공학을 소공으로 부른답니다.) 즐겨찾기 하고 자주자주 와서 보고 있어요... 시간산출.. 정말 중요하면서 어려운.. 아르바이트로 홈피를 제작하게 됬는데 언제까지 해주겠다고 약속을 했는데 날이 갈수록 요구사항이 커지니.. 결국 날을 새면서 하게 되더라구요 ㅠㅠ 항상 글 잘 읽고 있습니다~~ 앞으로도 좋은 글 많이 올려주세요~

  4. afeleia님 안녕하세요.
    말씀하신 점점 커지는 요구사항은 소프트웨어 개발 현장에서 가장 자주 발생하면서 가장 큰 문제이기도 합니다. 물론 이를 최소화하기 위한 여러 방법들이 있습니다. 완벽하게 추가 요구사항을 없앨 수는 없어도 줄일 수 있을 때까지는 줄여야죠. 추후 요구사항 분석 관련된 포스팅에서 이에 관련된 얘기도 좀 적어보도록 하겠습니다.

  5. 추가되는 요구사항은 미치고 환장할 노릇이지요. ㅋ

  6. 녹풍님 안녕하세요.
    그래서 스펙을 쓰는 것이 중요합니다. 관리가 필요한 것이고 변경을 최소화하기 위한 노력을 꾸준히 합니다.

오늘도 밤을 세워야 하는 개발자 (야근 탈출)

2008.12.08 16:57 by 전규현


잠시 후 Google blogger로 이동됩니다.



옛날부터 내려오는 경영자들이 믿고 있는 미신이 있습니다.

"개발자의 Output은 근무시간의 양에 비례한다."

말은 아니라고 하면서도 밤에 사무실이 텅 비어 있으면 개발자들이 군기가 빠졌다고 생각하고 주말에 누가 나와서 일하나 확인하러 가끔 사무실에 들르는 사람들이 경영자입니다.

실제로 근무시간에 성과가 비례하는 개발자들이 있다면 공장에서 벽돌 찍어내는 것과 다를 바가 없겠지요.
이 미신은 믿기 싫지만 자꾸 저절로 손이 가는 새우깡처럼 믿게 되고, 회사 조직에서 위로 올라갈수록 더 맹신하게 되나 봅니다.

이러한 이유로 어쩔 수 없이 또는 습관적으로 야근을 하는 개발자가 있다면 십중팔구 미혼이거나 결혼을 했어도 아이가 없겠죠.
이런 정상적이지 않은 생활을 하며 10, 20, 30년간 소프트웨어 엔지니어 일을 할 수는 없겠죠.

나는 "개발은 창의적인 작업으로 그 성과는 충분한 재충전에 나온다"고 믿고 있습니다.

그렇게 합리적인 시간에 개발을 하려면 소프트웨어 개발은 좀더 체계적이고 효과적으로 진행해야 합니다.
지금의 일반적인 경우처럼 일단 프로젝트를 시작해서 개발자들이 능력껏 그럭저럭 진행하는 방법으로는 또 개발자의 야근은 피할 수 없고, 별로 빠르게 끝나지도 제품의 품질이 좋지도 않게 됩니다.

그래서 소프트웨어 개발에 소프트웨어 공학을 적용하는 것이지요.
말은 거창한 것 같지만, 소프트웨어 공학이라는 것이 소프트웨어를 최소비용으로 최단기간에 개발하기 위한 온갖 방법들을 말하는 겁니다. 결코 교과서의 내용이 아니고 현실에서 수많은 회사들이 경험을 통해서 내려오는 방법이고 여러분들도 상당부분은 익히 알고 있는 방법들입니다. 이 블로그의 주제이기도 하고요.

다시 개발자들이 밤을 세지 않기 위한 방법으로 되돌아 와서 그 방법을 알아봅시다.

일단, 경영자의 인식이 바뀌어야 하는 것은 당연한 일인데, 어떻게 손을 델 수가 없는 일입니다.
그리고 나면 아래와 같이 개발자들과 프로젝트팀이 행할 수 있는 3가지 방법이 남습니다.

  • 정확한 일정 예측
  • 체계적인 개발 방법 
  • 합리적인 일정 복구 

첫째, 정확한 일정 예측입니다. 이는 모순된 문장입니다. 어떻게 예측을 정확하게 하나요? 하지만 예측이란 그때 상황에서 최선을 다해 정확하게 예측을 해야지요. 
당연히 프로젝트가 시작하자마자 정확한 예측은 불가능합니다. 아직 스펙이 정해지지 않았거든요.
그래서 프로젝트가 시작할 때는 대충을 일정을 가지고 시작을 하다가 스펙 작성이 완료되면 스펙을 근거로 1,2일 단위의 정확한 WBS를 작성하여 소요일정과 투입인력을 따져서 프로젝트 일정을 작성해야 합니다.
회사의 모든 관련자들은 프로젝트가 시작할 때 정해진 일정을 진짜 일정으로 봐서는 안됩니다. 스펙 완료 후 작성된 일정을 진짜 일정으로 봐야지요. 이것을 당연히 이해 할 수 있어야 얘기가 되지요.
그리고도 일정은 개발중간에 지속적으로 점검하며 일정이 틀어지면 대응을 해야 합니다. 1,2일 단위로 작성된 일정은 조금만 늦어져도 금방 문제를 파악할 수 있습니다.

둘째, 체계적인 개발 방법입니다. 
이 부분은 책 한 권을 써도 될 만큼 많은 양이고 앞으로 블로그에서 지속적으로 다룰 내용이니 간단히 소개만 하겠습니다. Stage를 따라서 개발을 하거나, Daily Build를 하고, 소스코드관리/버그관리시스템을 사용하고, 피어리뷰/코드리뷰를 하고, 모든 이슈를 투명하게 Open하고, Build를 자동화하는 등 수많은 방법들을 당연히 사용해야 할 것 입니다.

셋째, 합리적인 일정 복구입니다.
프로젝트는 어쨌든 늦어지게 마련입니다.  
다음 그림을 보면 현재 프로젝트 진척이 계획보다 늦어지고 있습니다. 이럴 때 다음 4가지의 방법이 있습니다.


A. 더 낮은 우선순위의 요구사항은 다음 버전으로 연기한다. 
B. 개발자를 추가로 투입한다. 
C. 시간외 근무를 단기간 동안 강제로 시킨다. 
D. 일정을 연기하여 추가된 기능을 수용한다. 

여기서 대부분의 회사가 C를 주로 선택하고 가끔 B를 선택합니다.
C는 단기적으로는 효과가 있지만, 이 기간이 길어지면 별로 효과도 없을 뿐더러 개발자 사기만 떨어지고 회사의 경쟁력도 잃고 개발자도 잃게 되는 방법입니다. 
B는 효과가 거의 없는 것으로 익히 잘 알려져 있습니다. 프로젝트 후반에 개발자를 투입하는 것은 기존에 열심히 개발하고 있는 다른 개발자들에게 방해만 되는 경우가 허다합니다. 기존 개발자들은 이들을 가르치느라고 시간을 허비해야 하고, 새로 투입된 개발자는 별로 성능을 발휘하지 못하며 버그도 많이 만들어내는 경우가 허다합니다.
프로젝트가 늦어지고 있는지 전혀 신경을 쓰지 않다가 프로젝트 막바지에 가서야 한참 늦어지고 있다는 보고를 받고 부랴부랴 대책을 세울 때 선택하는 방법이죠.
가장 좋은 방법은 A입니다.
여기서 중요한 점은 모든 프로젝트를 시작할 때 프로젝트가 늦어질 수 있다는 것을 미리 생각해야 한다는 것입니다.
그래서 스펙의 각 기능은 Priority(우선순위)를 정해줘야 합니다. 그래서 일정이 늦어지면 우순선위가 낮은 기능을 연기하고 프로젝트를 종료하는 것입니다. 그러기 위해서는 개발 순서도 우선순위가 높은 기능부터 개발이 진행되어야 합니다.
이러한 모든 것들이 체계적으로 합리적으로 진행이 되어야 중요한 프로젝트를 하더라도 퇴근 후에 가족과 식사를 하고 아이들과 놀 수 있는 시간이 생깁니다.

위와 같이 합리적이고 체계적인 절차에 의한 데이터를 근거로 경영층에 보가 되고 투명한 개발진행이 경영층에 신뢰를 준다면 하루 8시간 근무하는 날이 점점 늘어 날 수 있을 것입니다.

개발자 혼자서 할 수 있는 일은 결코 아니고, 회사가 조직, 프로세스, 시스템등 모든 것이 바뀌어 나가야 가능한 일입니다.

이미지출처 : Microsoft Office Online

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/일정 8시간근무, 소프트웨어, 소프트웨어 개발, 소프트웨어 공학, 일정

  1. Blog Icon
    붉은칼

    이상적인 환경이네요. 아웃소싱, SI 업계에서는 조건부터 잘못되서 적용이 안될거 같고, 금융 또는 IT 대기업 사내 소프트웨어 연구실 정도면 어느정도 현실화 될지도. 아마 괜찮은 회사에서는 벌써 적용될지도 몰르고. 그러나, 99% 개발자에겐 그림의 떡일듯. 불쌍한 우리회사 개발자들..--;
    실력있는 개발자 같으신데 기회가 되면 창업한번 해보세요. 다양한 경험을 통해 좀더 현실적인 답을 찾아내시길~

  2. 저희 팀이 보편적인 프로젝트라고 보기는 힘들지만, 분명 SI 업계의 아웃소싱 프로젝트에서 위 내용을 토대로 진행을 해서 야근을 없앴습니다.
    팀원 중 2명은 야간 대학원에 다니기 까지 하고 있습니다.
    중요한 일이 무엇인지 판단을 하고, 고객이 원하는 것이 무엇인지 정확하게 판단하는 것과 구현을 분리하지 않고 일하는 것, 작업을 잘게 쪼개서 예측가능하게 하려는 노력은 현실적인 답을 만들어냅니다.

  3. 영회님 안녕하세요.
    역시, 이 댓글 하나만 봐도 영회님과 그 개발팀이 어느정도의 실력과 경험이 있는지 알 수 있겠네요.
    말은 쉽지만 실제로 그렇게 실행하고 있다는 것은 이해의 단계를 넘어서 내제화를 이루고 있다고 할 수 있습니다. 감사합니다.

  4. 붉은칼님 안녕하세요.
    우선 밝혀둘 것이 있습니다. 저는 소프트웨어 개발컨설턴트로서 대한민국의 어떠한 개발자와 비교해도 부족하지 않은 개발 및 컨설팅의 지식과 경험이 있습니다. 수백만명이 쓰는 제품, 전세계인이 쓰는 제품, SI등 다양한 분야의 경험을 풍부하게 다 가지고 있습니다. 제가 쓰는 글들은 모두 경험에서 나온 글들입니다. 또한 저희 펌에서는 한국과 미국에서의 20년이상의 소프트웨어 개발에 대한 다양한 노하우를 가지고 있습니다. 그냥 단순히 보고 들은 내용을 옮기는 것으로 오해하지 마시길 바랍니다.

    제가 컨설팅을 하면서 만난 거의 모든 회사는 "우리회사는 다르다"라고 합니다. SI다, 금융이다. 이유는 많지만 사실을 다 똑같습니다. 원리는 같다는 얘기입니다. 99%의 개발자에게 그림의 떡이 아니고 99%의 개발자에게 가능하고 그래야 더 품질이 좋은 제품이 개발되고 회사의 경쟁력이 더 높아집니다.
    8시간 근무를 하는 이유도 더 개발을 잘하고 빨리 하기 위해서임을 명심해주시면 좋을 것 같습니다. 잘 이해가 안되면 붉은칼님에게는 정말 좋은 기회인 것 같습니다. 소프트웨어 엔지니어링이 가져올 좋은 개발환경에 대해서 앞으로 제 블로그를 지속적으로 관심을 가지고 봐주세요. 점점 더 구체적인 글들을 작성해 나갈 겁니다.
    감사합니다.

  5. Blog Icon
    Jake

    저도 동감합니다. 저도 지금까지 거친 회사에서 항상 개발 프로세스를 체계화 해 보려고 노력했지만 (지금도 하고 있습니다) 항상 나오는 말은 "우리는 그런거 적용 못해" 라는 겁니다. 하지만 한가지 짚고 넘어가고 싶은 부분은 Ray 님의 말씀처럼 원리는 다 같다고 할 수 있겠지만 원리와 현실의 차이는 무시할 수 없다고 생각합니다.
    따라서 원리나 원칙을 적용하고 그에 따르도록 하는 것 보다는 그 회사의 특수성을 이해하고 받아들여 그에 맞게 차용(adopt)하는 것이 가장 현실적이고 바람직하지 않을까 하는 생각입니다.
    아시다시피 미국회사라고 야근 없는 것 아니고 주말에도 일할 때도 많습니다 - 전 미국에 있습니다. 개발자란 직업의 특수성이라고 생각합니다. 제 처제는 게임회사 그래픽 디자이너인데 프로젝트 마감일 다가오면 집에도 못가고 주말에도 밤새서 일합니다. 하지만 릴리즈 후에는 2주 - 3주 정도의 휴가를 받습니다. 고생 후 그만큼의 보상이 따른다는 것이 한국과의 다른점이라고 생각이 됩니다. 이는 IT 업계뿐 아닌 사회 전반적인 문화의 차이가 아닐까 하는 생각이 되네요.

  6. Jake님 안녕하세요.
    정확한 말씀입니다. 평소에 제가 하는 말이죠.^^
    Jake님은 한번 만나뵈고 싶은 분이네요.
    앞으로 좋은 교류 지속되기 기대합니다.

  7. 미국의 개발자들은 야근을 안하는가? 하는 오해가 있을 수 있습니다. 미국의 개발자들도 야근을 많이 하기로 유명합니다. 하지만 우리와는 경우가 좀 다릅니다. 대부분 체계적으로 개발을 하는데도 야근을 많이 하는 거죠. 특히 MS는 야근을 많이하고 그만큼 많이 보상해주죠. 많이주고 많이 뽑아먹기로 유명합니다.

  8. 정말 공감이 가는 글입니다. 이 글은 경영자 필독입니다.

  9. HannaKim님 안녕하세요.
    소프트웨어 엔지니어링에 관심이 많으신 분을 만나서 반갑습니다. 앞으로 좋은 얘기 많이 주고 받으면 좋겠습니다.
    감사합니다.

  10. 좋은 말씀 잘 보고 갑니다. 선택할 위치에 있는 분들의 뿌리깊은 잘못된 사고방식이 합리적으로 바뀌었으면 좋겠는데, 개발자 출신의 관리자들도 똑같은 생각은 가지신 분들이 많으니 요원한 일로 보이기도 합니다. 하지만 점점 좋아지겠죠? ^^

  11. cozydev님 안녕하세요.
    개발자가 좀더 전문적이어야하지 않을까요? 주먹구구식으로는 경영자를 납득시키기는 어려울 것 같습니다.

  12. Blog Icon
    다른개발자

    뭐 워낙 대단한분들이 모이신거 같은데 읽다가 저도 생각을 한줄 표현할까 해서 올립니다만...
    환경이 열악한건 사실이죠..근데 환경이 언젠가는 좋아지겠지라는 생각과 그런날이 올까? 라는 생각이 주를 이루는데요...?너무 환경탓을 하기 보다는 자신에게 주어진 환경을 자기가 만들어 갈수 있다는 생각을 가지는것이 중요하다고 생각합니다. 저도 적지않은SI 경험을 가지고 있지만...SI하면서도 일빨리 끝내고 일찍가는 개발자 많고요... 일잘하면 요새는 관리자도 특별히 근태 터치 안합니다.물론 기본적 근태는 지켜줘야죠 9시 출근 6~7시 퇴근 그러다가 일주일에 한두번정도는 8~9시 퇴근 이정도면 처자식과 가정생활 하면서도 충분히 SI에서도 개발자로 생활 가능하다고 보는데요..

  13. 안녕하세요.
    잘하고 계시는 것 같습니다. ^^ 사실 SI나 팩키지나 소프트웨어 개발의 기본은 거의 같죠.

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

티스토리 툴바