태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

이번 프로젝트 내일 끝나?

2011.01.31 13:28 by 전규현


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





SW개발 프로젝트가 언제 끝날지 정확하게 모르는 경우가 허다하다.

프로젝트를 진행하고 있는 개발자나 PM도 이 프로젝트가 언제 끝날지 전혀 감이 안잡히는 경우가 많다. 
하지만 분명한 것은 이 프로젝트가 예정된 종료일까지는 끝나지 않을 것이라는 것은 아주 잘 알고 있다.
이것을 알고 있다면 일정을 연기해야 하는데 언제로 연기를 해야 하는지 알 수 없으니 일정 연기를 요청하기도 어렵다. 일정을 연기 했으면 그 일정은 지켜야 하는데 연기된 일정도 전혀 근거가 없이 그냥 감으로 생각한 일정이기 때문이다. 이런 일정은 또 연기되기 마련이다.

그래서 Due date이 되어서어 끝나지 않음을 알고 일정 연기를 요청하고 한다. 이렇게 촉박하게 일정이 자주 연기가 되면 영업이나 마케팅 부서에서는 도저히 개발팀의 일정을 믿을 수 없어서 자신있게 비즈니스를 하기 어려워진다.

그럼에도 일정이 늦어지고 있는 것을 늦게 알려주는 이유는 미리 얘기를 해봤자 일찍 혼나기 밖에 더하겠냐는 생각때문이기도 하다. 일정이 촉박해지면서 매일 야근을 하면서 열심히 하는 모습을 보여주면 일정을 연기해도 큰게 혼나지 않을 것이라고 생각하곤한다. 

하지만, 경영자 입장에서는 밤새면서 일정 못지키는 프로젝트보다는 6시에 퇴근하고 약속한 일정을 지키는 프로젝트가 훨씬 낫다. 그렇다고 주먹구구로 개발하면서도 일정을 터무니없게 길게 잡으면 곤란할 것이다.

제대로된 조직, 프로세스, 시스템을 갖추고 있는 회사에서 SRS를 적절하게 썼다면 1년짜리 프로젝트에서 1주일 지연이 되는 것을 6개월전에도 알 수 있다. PM은 이런 일정 지연이 생기면 이를 복구하기 위한 다양한 기법들을 사용하게 된다. 따라서 일정에 맞춰서 프로젝트를 마칠 수 있는 가능성은 대단히 높아지게 된다.

더 이상 개발팀에게 "내일은 끝나나?"라고 물어볼 필요가 없다. 개발팀도 신뢰를 회복할 수 있을 것이다.
또한, 더 중요한 것은 6시에 퇴근을 하면서도 프로젝트를 더 일찍 끝낼 수 있다는 것이다.

심정적으로 경험적으로 이것이 믿어지지 않는 분들도 많겠지만, 필요한 만큼 적절히 체계화 된 개발을 하고 SRS와 설계를 적절하게 하면 프로젝트 일정도 지키고 개발자도 행복해진다.

여기서 중요한 것은 적절하게 하는 것이다. 적절하다는 것이 가장 어려운 것 중 하나다.

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

전규현 개발프로세스 일정, 프로젝트

  1. 적절하게 하는것 이라는 말 적극 공감합니다.
    저희도 제품 마무리 짓고 있는데 아직도 SRS 설계를 하긴 했는데 적절히 안해서 일정이 연기되는 상황을 몇번 겪고나니 참 가슴이 쓰라립니다 ^^

  2. 안녕하세요. 드럼캡님
    SRS를 쓰셨다고 하셨는데, 부족한 것인지 과한 것인지 궁금하군요. 대기업에서는 부족하면서도 과하게 적곤 합니다.
    즉, 필요한 것은 빠지고, 기능은 설명을 너무 과하게 적습니다.
    SRS를 적절히 적는 것은 설계를 하고 구현할 개발자들이 설계를 구현을 무리없이 할 정도입니다. 전혀 물어보지 않고 개발할 수 있는 것은 과도하게 적은 것이고, 너무 많이 물어봐야 하면 부족하게 적은 것입니다. 또한 기능 위주로 적은 것은 빠진 부분이 너무 많아서 나중에 큰 문제가 됩니다.

  3. 항상 그렇지만 적절한것이 가장 중요하면서도 어려운것 같아요.
    그리고 디버깅을 하다보면 다른것들까지 계속 손을 보게 되다보니 일정은 계속 늘어나게 되더라구요.
    그럴때에는 확실하게 이것 까지만 이번 릴리즈에 버그를 잡고
    알려진 버그로 남기는 것도 방법이긴 하지만 크리티컬이라면 이것까지만 잡고.. 이것까지만... 라는
    개발자의 욕심으로 인해서 일정이 무제한으로 늘어나게 되죠 ^^;

    이런걸 보면 저도 개발자이지만 적당하게 선을 긋는 법을 조금더 터득해야 할텐데 매번 아쉬움을 느끼게 됩니다.

  4. 구차니님 안녕하세요.
    개발 일정에 테스트 기간까지 모두 포함해야 합니다. 프로젝트에 따라서 테스트 기간이 구현기간보다 더 긴 경우도 있습니다.

    그런데 흔히 테스트 기간은 너무 짧게 잡아 놓고 마치 구현기간에 거의 출시 가능한 제품을 만들어 낼 수 있을 것 같은 생각을 하곤 합니다.

    구현과 테스트 기간의 비율은 하나의 정답이 있는 것이 아니고 프로젝트의 성격과 난이도에 따라서 달라집니다. 이것을 판단하는데 경험도 필요합니다.

    또한 출시를 할지 말지 결정하는 회의를 Go-live회의라고 합니다. 이 회의를 통해서 버그를 몇개 안고 출시를 할지 고쳐서 출시를 할지 결정하게 됩니다.

  5. Blog Icon
    탁..

    (문제제기에 대해 늘 공감하며 보고 있습니다. 감사합니다) 어떻게 하면 적절히 할 수 있을까요? 프로젝트 예측이라는 게 제겐 참 어려운 일인데. 어떻게 하면 요구사항으로 실제 완성이 되기 까지의 기간을 예측을 할 수 있나요?

  6. 안녕하세요. 탁..님

    프로젝트 일정 예측에 가장 필요한 자료는 SRS입니다. SRS를 제대로 작성하게 되면 각 Task는 1~2일 단위로 쪼갤 수 있습니다. 이를 WBS라고 합니다. 일정이 이렇게 작게 쪼개지지 않고 몇주 또는 몇달 단위로 관리를 한다면 일정을 관리할 수도 없고 늦어지고 있는지 판단할 수 없습니다.

    이러려면 SRS를 잘 적어야 하는데 이는 하루이틀에 가능한 일이 아닙니다. 제대로 방법을 배워야 하고 경험해야 하고 실제 프로젝트에서 수십번 해봐야 합니다. 제대로 적으려면 수년이 걸리고 10년을 적어봐도 계속 더 잘적을 것들이 남아 있는 분야입니다.

    일단 개발해야 할 것을 꼼꼼히 적는 것에 서 출발해보세요. 물론 이것만으로는 스펙(SRS)의 20~30%만 커버한다고 생각하면 됩니다. 그래도 시작은 되죠.

  7. Blog Icon
    bluemonk

    예측이란 틀릴 수 있기 때문에 예측 아닐까요? 주식도 보면 주식 전문가라고 하는 사람들도 시장 예측을 하죠. 대부분 확인 과정이 없어서 그럴 수도 있지만 많은 경우 맡지 않는 것 같습니다. 그들의 예측이 맞지 않을때 왜 맞지 않는데 예측에 대한 책임을 지지 않는 거야 라고 생각한 것도 있습니다. 그러면 왜 그들에게 책임을 지라고 사람들은 묻지 않을까요? 사람들 다 틀릴 수 있다고 생각하기 때문인 것 같습니다. 프로젝트 기간 또한 비슷하지 않을까요? 다들 틀리 수 있다는 가정을 하지 않는데 어려움이 있는 것 같습니다. 무조건 기간을 맞춰야 한다는 문제가 상황을 힘들게 하는 것 같습니다. 선을 그어놓고 당사자들이 맞춰서 뛰어라 하는 상황이 많은 건 아닐까 생각해 봅니다.

  8. Blog Icon
    bluemonk

    또한 프로젝트에 대한 예측과 그에 따른 결과가 어떻게 됐는지. 어떤 부분이 예측을 힘들게 하는지. 어떤 이유 때문에 연기 되었는지에 대한 검증이 없고 또한 그 검증에 대한 소프트웨어 업체간의 정보 공유가 없는 것이 문제이지 않을까요? 그 부분에 대한 노하우가 쌓이지 않고 공유되지 않는 것이죠. 다들 닥친 프로젝트 마치고 유지보수 하는데 여력을 쏟지 그 과정에 대한 검증과 과정에 대한 리부가 없는 시간의 환경 또한 문제인 것 같습니다.

  9. 안녕하세요. bluemonk님

    예측은 틀릴 수 밖에 없죠. 정확한 예측은 프로젝트가 끝날 때 하는 것이라고들 합니다. 하지만 프로젝트 일정과 비용을 전혀 예측할 수 없다면 비즈니스를 할 수가 없죠.

    프로젝트를 시작할 때 하는 예측은 흔히 2배정도 차이가 난다고 합니다. 심지어 5배 이상 차이나는 경우도 있습니다. 하지만 SRS를 쓰고 설계를 하는 과정에서 상당히 정확한 일정을 예측할 수 있게 됩니다. 프로젝트는 우리의 통제하에 있는 것이라도 예측 가능하게 됩니다. 통제권을 잃어버리면 예측이 안되죠. 이렇게 프로젝트가 언제 끝날지 모르는 프로젝트도 허다합니다.

    프로젝트 예측은 개발자들이 하는 것으로 위에서 일정이 고정되어서 내려오면 그냥 열심히 해는 것가지고는 안되고 스펙 기반하에 일정을 단축할 수 있는 다양한 방법을 동원해야 합니다. 이또한 일정이 상당히 정확하게 예측이 되어야 단축할 수 있는 방법도 동원할 수 있습니다.

  10. Blog Icon
    bluemonk

    스펙 기반하에 해야 하는 것이 맞는 것 같습니다. 그 스펙이 바뀐다면 어쩔 수 없는 거 같습니다. 그 스펙이라는게 SRS 를 쓰면서 다시 한번 범위가 검증되는 것도 맞는 것 같습니다.
    사람들은 자연에서 법칙을 찾고 싶어합니다. 그리고 그것을 숫자화(수치화, 수식화) 합니다. 그래야 예측 가능하고 통제 가능하다고 생각하기 때문입니다.
    그래서 앞에 이야기 한데로 숫자화 하는 노력이 필요한 것 같습니다. 법칙이나 조건 같은거라고 할 수도 있겠죠. 다만 이러한 상황 속이라도 예측이 빗나갈 수 있다는 전제는 반드시 존재해야 한다고 생각합니다. 인간도 자연의 일부이니까요. 그 예측이 틀린 것에 대한 책임이 너무 큰 것 같다는 생각이 듭니다. 그 책임이 주로 개발자에게 돌아오는 것 같아서 더욱 그렇습니다. 왜 그런 환경에 대한 부분에 대한 인프라에 대해서는 신경을 쓰지 않으면서 개발자에게만 그주로 그 책임을 묻는 것 같습니다. 프로젝트 예측이 가능하게끔 정보를 쌓고 이를 공유하는 것이 필요하다고 생각합니다.

커뮤니케이션 오류

2009.04.19 23:16 by 전규현


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



소프트웨어 프로젝트를 진행하다 보면 수많은 커뮤니케이션의 오류를 발견하게 됩니다.
문서화 되지 않은 수많은 의견과 결정들에 대한 오해와 대화를 하면서 발생하는 표현의 오류는 한 두개가 아닙니다. 이는 비단 프로젝트에서 뿐만 아니라 일상생활에서도 벌어지는 현상이지만, 일상생활에서의 커뮤니케이션 오류는 그렇게 심각하지 않을 수 있지만, 프로젝트에서의 커뮤니케이션 오류는 심각한 손실을 초래하기 때문에 조심할 필요가 있습니다.

따라서 프로젝트를 진행하면서 오가는 대화나 기록은 명확해야 합니다. 미사여구보다는 직설적인 화법으로 핵심을 정확하게 말해야 합니다. 또 하나의 문장은 사실, 의견, 추축, 가정, 결정 또는 정보일 수 있습니다. 그런데, 현재 하고 있는 말이 사실인지 의견이지 명확하게 하지 않으면 수많은 오해가 발생합니다.
 
특히, 의견이나 추측을 사실처럼 얘기하면 다른 사람들은 이를 바탕으로 계획을 세울 수도 있습니다. 또 경영진은 잘못된 결정을 내려서 큰 손해를 보게 될 수도 있습니다. 그리고 가정으로 이미 확인된 사실처럼 얘기하면 프로젝트는 큰 리스크를 안게 됩니다. 

따라서 프로젝트에서는 구체적으로 가정과 종속관계를 파악하는 활동을 하게 됩니다. 프로젝트를 진행하면서 확인되지 않은 사실이나 결정해야 할 것들 및 종속되어 있는 항목을 찾아서 리스크관리를 해야 하기 때문입니다. 이러한 하나하나가 프로젝트의 리스크라는 것을 생각하지 못하면 지뢰밭을 걷는 것과 같습니다.

이러한 커뮤니케이션 오류를 제거하려면 이 문장이 사실인지 의견인지를 정확하게 구분하여 적는 것이 좋습니다. 특히 누구의 의견이라고 적을 수도 있고, 누구의 결정이라고 표현할 수도 있습니다. 그리고 가정은 언제 확인하고 해결이 될지 계획까지 적는다면 누구나 해당 내용이 확인이 필요한 가정사항이고 상황에 따라서 프로젝트의 위험 요소라는 것을 쉽게 파악할 수 있습니다. 이렇게 직설적이고 확실한 표현이 삭막하게 들릴 수는 있지만, 프로젝트를 진행하는데 있어서는 더 좋은 표현법입니다.

연인에게 이러한 표현법은 안되겠지요? 
당신을 사랑하는데 이 표현이 사실, 의견, 추측, 가정 또는 결정일까요? 이를 구분해서 말한다면 따귀맞기 십상이겠네요.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.  
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/커뮤니케이션 가정, 결정, 리스크, 문서, 사실, 소프트웨어, 의견, 추측, 커뮤니케이션, 표현, 프로젝트

프로젝트 시작부터 개발자가 바글바글

2009.01.23 15:32 by 전규현


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




소프트웨어 개발 프로젝트가 시작되면 바로 개발팀이 구성되어서 개발자들이 바글바글 한가요?
그렇다면 뭔가 개발 체계에 잘못된 것이 없는지 검토를 해봐야 합니다.

개발을 단계(Stage)구분 없이 마구잡이로 하고 있지 않은지?
개발 업무(분석, 설계, 구현)의 구분 없이 섞여서 하고 있지 않은지?
개발자가 별도의 전문성 없이 모든 업무(분석, 설계, 구현, 빌드, 테스트)를 다 하고 있지 않은지?

프로젝트의 각 단계에 따라서 투입되는 인력이 달라집니다. 
소프트웨어 개발 프로젝트에서 흔히 저지르는 실수 중 하나가 프로젝트가 시작되자마자 모든 프로젝트 인력을 한꺼번에 투입해 놓고 프로젝트 끝날 때까지 그 인원으로 계속 진행하는 경우입니다. 

각 단계 별로 필요한 인력과 인원 수가 달라지는데 프로젝트 초기부터 많은 인원이 투입되면, 개발자들이 별로 할 일이 없게 됩니다. 그렇게 되면 요구분석이 완료되지도 않은 시점에 특별한 계획도 없이 코딩도 해보고 설계도 해보고 이것저것을 개발하기 시작하기도 합니다.


위 그래프의 핵심은 초기부터 많은 개발자를 투입하지 않는다는 것입니다. 요구분석 단계에 투입되는 개발자는 SRS 작성에 필요한 정보를 제공하는 개발자들입니다. 요구사항의 타당성을 점검하고, 필요 시 프로토타입을 만들어 볼 수도 있습니다. 그런 다음, 설계 단계에서는 설계에 참여하는 인원만 추가로 투입하면 됩니다.
 
테스터가 프로젝트 초기부터 테스트에 참여하는 점을 눈 여겨 봅시다. 테스터 역시 SRS작성에 참여하고, 테스트 요구사항을 제시하고, 각 요구사항이 테스트 가능한지 검토합니다. 요구분석단계에 테스터는 실제로 테스트 계획서를 작성하기도 하고 이를 준비만 하기도 합니다. 

이렇듯 각 단계 별로 인원을 효과적으로 투입해야만 비용을 절감할 수 있으며, 성급하게 프로젝트 후반부에 해야 할 일들을 앞에서 미리 함으로써 발생하는 수많은 문제를 방지할 수 있다. 미리 작성해 놓은 코드가 아까워서 어떻게 하든 프로젝트에 사용해보려고 하지 않겠습니까?

그 외에도 고참 개발자나 신입 개발자나 특별한 구분 없이 모두 모여서 서로 비슷한 일들을 나눠서 일을 하고 있다면 개발 조직의 효율성 및 생산성이 떨어지는 경우라고 볼 수 있습니다. 아직 주먹구구 단계를 벗어나지 못한 상태입니다. 이런 경우에도 프로젝트를 시작하면 모두 모여서 그냥 개발을 시작하죠.

이렇게 개발자들이 프로젝트 초기부터 모두 투입되는 경우는 비용이나 개발 인력 활용 면에서 대단히 불리합니다. 프로젝트가 진행되는 단계에 따라서 인원을 적절하게 투입해야 합니다. 물론 그렇게 하기 위해서는 각 기능조직의 전문성이 갖춰져야 하고, 개발에 필요한 시스템과 프로세스가 필요하며, 개발자들이  문서 작성 능력을 필수적으로 갖추고 있어야 합니다.

이미지출처 : Microsoft Office Online

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

전규현 프로젝트 프로젝트

프로젝트는 연습이 아니다.

2009.01.19 21:00 by 전규현


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




필자는 수많은 소프트웨어를 개발해왔고, 주위에서 여러 프로젝트를 봐왔습니다.
그러면서 성공한 프로젝트와 실패한 프로젝트도 많이 봐 오면서 그 차이에 대해서도 많이 생각해 왔습니다.

물론, 성공한 프로젝트는 모두들 알고 있는 요소들이 있습니다. 
상세하고 꼼꼼한 일정관리, 꾸준한 리스크관리, 인력관리, 품질관리 등등 이미 알려진 것들입니다. 비단 S/W 프로젝트가 아니더라도, 빌딩을 만들 때도 당연히 필요한 프로젝트 관리의 요소들입니다.

그런데, 유독 소프트웨어 개발 프로젝트에서 종종 벌어지는 현상이 있습니다. 이것이 프로젝트에 큰 리스크가 되고 프로젝트를 실패하게 만드는 원인이 되기도 합니다.

이것은 바로 "프로젝트를 연습처럼 생각한다"는 겁니다. 연구, 공부처럼 생각합니다.

"요즘 Python이 인기인데, A모듈에서는 Python을 써야겠다."
"이번 프로젝트는 UML로 설계를 하겠다."
"Flex로 UI를 만들면 쉽다고 하는데, Flex를 쓰자"
"A라는 DB가 빠르고 가볍다고 하는데, 그걸 써보자"
"요즘 B기술이 대세인데, 어차피 공부해야 할 거 프로젝트 하면서 배우자"

실제로 개발자들은 실제 프로젝트에서 많이 배우는 것이 사실이지만, 거의 경험이 없는 기술을 단지 "배우기 위한 목적"이나 "좋아 보여서" 사용한다면 이는 프로젝트에 큰 리스크가 될 수 있습니다.

필자는 개발자들에게 늘 강조하는 것이 "프로젝트는 연습이 아니다.", "프로젝트는 검증된 기술을 가지고 하는 것이다."입니다. 물론 검증된 기술과 아닌 것의 경계는 모호하지만 이는 경험으로 판단해야죠. 충분히 성공할 수 있는 기술의 조합으로 프로젝트를 해야죠. 그렇다고 하더라도, 프로젝트 중간에는 수많은 변수들이 있어서 성공이 보장된 것이 아닙니다. 아직 검증이 안되었지만, 프로젝트에 꼭 필요한 기술이라면, 미리 또는 요구분석 시에 Prototype을 만들어보면서 검증을 하는 것이 좋습니다. 모든 기술을 다 검증할 필요는 없지만, 검증이 필요한 기술을 프로젝트에 직접 사용할 경우 실패할 수도 있습니다.

또 개발자들이 충분히 연습이 되어 있지 않아서 능숙하게 사용하지 못한다면, 일정을 지연시키는 큰 원인이 됩니다. 이런 경우는 이미 익숙한 옛날 기술을 사용하는 것이 나은 경우가 많습니다. 

Research Project라면 얘기가 다르죠. Research Project의 목적은 연구이기 때문에 검증 안된 기술을 얼마든지 사용해도 되죠. 이 경우 요구사항의 상세도도 일반 프로젝트와 다르고 일정의 중압감도 다르기 때문에 기술에 집중할 수 있습니다. 평상 시에 크고 작은 Research Project를 자주 수행해야 실제 프로젝트에 적용할 수 있는 기술을 풍부하게 보유할 수 있습니다.

프로젝트를 연습이라고 생각한다면, 프로젝트 실패로 가는 지름길로 가고 있는 것입니다. 자신이 지금 어떤 프로젝트를 하고 있는지 잘 구분해야 합니다.

이미지출처 : Microsoft Office Online

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

전규현 프로젝트 프로젝트

  1. 글 잘 읽고 갑니다. :)

  2. 우울한딱따구리님 반갑습니다.
    들려주셔서 감사합니다. 새해 복많이 받으세요.

소프트웨어 프로젝트는 누가 진행하는가?

2008.11.12 15:31 by 전규현


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






안녕하세요. 조성경님. Ray라고 합니다.
블로그에 쓰신 글을 보고 동감을 하면서 제 의견을 몇자 덧붙여 봅니다.

소프트웨어 프로젝트를 진행하기 위해서는 여러 전문가가 필요하죠.
프로젝트관리자도 전문가여야 하고, 개발자들도 소프트웨어 전문가여야 하고, 분석/설계/테스트/빌드/UI/Techpub 등 많은 전문가가 있어야 하죠.
물론 프로젝트 규모에 따라서 혼자서 이 모든 일을 다하는 경우도 있고, 수백명이 각각의 업무를 나눠서 하는 경우도 있습니다.
확실한 것은 혼자서 뚝딱뚝딱 만드는 것과는 다르다는 것이죠.
그런데, 우리는 전문적이지 못한 사람들이 모여서 프로젝트를 진행하는 경우를 허다하게 봅니다.

그런 이유는 간단합니다. 
그렇게 일을 해왔기 때문에 전문적인 지식을 배울 기회를 별로 보기 어렵고 그러다 보니 후배들에게 별로 가르칠 것이 없는 악순환이 계속 됩니다.
그래서 코딩 기술과 몇가지 Domain 지식만을 가지고 욹어 먹게 되는 경우가 많죠.

이런 기반이 잘되어 있는 회사에 들어가서 몇년 일하는 것만으로도 충분히 배울 수 있으나 그런 회사가 그렇게 많지 않는 것은 안타까운 일입니다.

조성경님이 경험했던 "소스보세요", "서버만들어" 이런 현상은 아주 흔합니다.
회사의 지식이 문서화 되어 있지 않고 소수의 머리속에 있고, 
소프트웨어 프로젝트를 진행하는데 가장 중요한 스펙의 중요성을 잘 모른 것이지요.

이 글에서 말하려고 하는 요지는 소프트웨어 엔지니어라면 단순히 코딩, 요소기술, Domain 지식에 매달리지말고, 소프트웨어 엔지니어로서 갖춰야 할 다양한 지식의 전문가가 되어야 한다는 것입니다.

제 책(소프트웨어 개발의 모든 것)에서도 이에 대한 내용을 상당히 다루고 있습니다.
앞으로 전문가로서 갖춰야 할 지식에 대해서 블로그에 계속 포스팅을 해나갈 겁니다.

감사합니다.


 난 자율따위는 믿지 않는다.
10개월이 걸리는 프로젝트A가 있다고 하자. 프로젝트A를 10개월에 끝낼 수 있는 능력을 실제로 가진 10명을 모아 따로 프로젝트를 진행하게 한다. 조건은 다음과 같다.

>> 어떠한 간섭도 없고 10개월 후 결과물을 보여준다.

10개월 후 제대로 프로젝트를 완료한 사람은 몇명이나 될까? 나는 많아야 한두명이 기대에 충족하는 결과를 내놓을 것이라고 본다. 실력이 모자란 사람은 없지만 자신을 관리할 수 있는 사람은 드물기 때문이다. 개인적인 경험에 의존한 결론이기는 하지만 당분간 이 생각을 바꿀것 같지는 않다.

내 경험과 다른 이들의 증언을 종합해보면 2~3개월 이상의 긴 일정을 툭 던져놓고 신경 끄는 관리자들이 있다. 이런 경우는 십중팔구 실패나 일정지연을 유발한다. 이때 실패는 작업자와 관리자중 누구의 잘못이 더 클까? 내 기준으로는 100% 관리자의 잘못이다. 만약에 이런 실패가 없다면 관리자는 존재 가치가 없다. 모든 조직에 관리자가 있다는 사실 자체가 스스로 뭔가를 알아서 하는게 쉽지 않다는 증거인데도, 이를 무시한다.

첫 회사에서 내가 받은 첫 주문은 "소스 보세요", 두번째 회사에서는 "서버 만들어"였다. 그래서 소스를 보고 고치고, 서버를 만들었다. 이 과정으로인해 나는 몇번의 큰 실수를 한다. 내가 그렇게 해왔으니까 남들도 그렇게 하면 되는 줄 알았고, 그렇게 못하는 남들을 제대로 이해하지도 못했다. 그리고 그렇게 하지 못하는 사람들을 낮게 평가했다. 지금 생각해보면 그냥 부끄러운 과거일뿐이고, 그 사람들에게 진실로 미안한 마음이 든다. 그때는 내가 미숙했다.

다시 프로젝트A를 진행하는 10명으로 돌아가보자. 프로젝트를 성공적으로 끝낼 한두명이 나머지보다 낫다는 점은 두말할 가치가 없다. 그러나 나머지 사람들이 쓸모없는 사람이냐라고 묻는다는 그건 절대 아니다. 단지 그들이 잘 못하는 부분이 들어났을 뿐이다. 좋은 관리자라면 그들을 이끌고 목표를 향해 나갈 줄 알아야하고, 경우에 따라서는 그들이 더 좋은 결과를 만들기도 한다.

왜 이런 구질구질한 얘기를 했냐면 오전에 있었던 엔진쪽 인원에 대한 평판 조회(reference check) 대답때문이다. 평가를 간단히 요약하면 엔진 연구하라고 했는데 1년이 넘도록 제대로된 결과를 만들지 못해서 해고했었다고 한다. 따져 묻고 싶은게 많았는데 그리 친한 사이도 아니라서 더 물고늘어질수는 없었고 잡다한 생각들이 들었다.

1년이 넘도록 결과물을 얻지 못했을 때 관리자는 뭘 했으며, 1년이 넘게 기다려야 했을까?
그 사람이 1년 넘는 기간동안에 진짜로 한 일은 뭘까?

이러한 생각에 대한 내 대답이 바로 이글이다. 계속 해고하면서 자기 스스로 관리가 가능한 스타 플레이어를 채용할 운을 시험해보는 것은 관리자 스스로가 무능하다는 자백과 다를게 없다. 그러니 이거 보세요, 분석하세요, 공부하세요 이런 말은 고만하자.

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

전규현 프로젝트 프로젝트

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

티스토리 툴바