How vs Who

방법론에서는 How가 중요하다. 어떤 분석방법을 사용해서 어떤 툴을 사용해서 설계를 하고 어떤 표준으로 코딩을 하고 등등.. 하지만 로버트의 말은 새겨들을 필요가 있다.  

   "많은 프로젝트의 성공과 실패는 어떻게 수행하는가보다 누가 수행하는가에 따라 결정된다.
    - 로버트 L 글라스, 소프트웨어 공학의 사실과 오해"


짧게 말해 How보다는 Who라는 사실이다. 성공한 프로젝트의 How를 흉내내는건 그래서 별로 효과적이지 못하다. NASA의 프로젝트에 감명을 받았다면 NASA의 방법론을 베낄게 아니라 NASA의 사람을 데려와야 한다. 그럼에도 왜 이렇게 많은 방법론 책들이 있을까 ? 그 의문에 대해 디마르코는 다음과 같이 말했다. 

    "사람들이 업무의 인간적인 측면보다 기술적인 측면에 주로 매달리는 가장 큰 이유는
     기술적인 부분이 더욱 중요하기 때문이 아니라 거기에 매달리는 것이 훨씬 더 쉽기 떄문이다. 
     -톰 디마르코, 피플웨어


기술적인 측면에 매진한 결과는 이렇다. 

     "대부분의 프로젝트는 기술이 아니라 인적 자원과 프로젝트 관리의 문제로 실패한다.
      - R. Thomsett
     "업무에서 발생하는 문제들은 대부분 기본적으로 기술의 문제가 아니라 조직사회학의 문제다. 
      -톰 디마르코, 피플웨어


사실 좋은 프로그래머를 찾는 것은 

      "생산성에 대해 어떤 사람들은 다른 사람들보다 5배나 우수하고
       디버깅에서는 어떤 사람들은 다른 사람들보다 28배나 우수하다.
       - 로버트 L 글라스, 소프트웨어 컨플릭트 2.0


에 의하면 타당하다.  5배가 우수한 사람이라도 5배의 비용이 들지는 않을 것이기 때문이다. 혹시 2배 뛰어난 사람을 구하진 못해도 2배 더 일하게 하는 건 어떨까 라고 생각하는 관리자가 있다면 

      "초과근무 시간 증가는 생상성 감소 기법이다. 스트레스를 받는 사람들은 머리가 빨리 돌아가지 않는 법이다. 
       - 톰 디마르코, 피플웨어

     "아홉 명의 여자가 투입된다고 해서 아기를 한 달만에 낳을 수는 없다.
     - 프레드릭 브룩스, Man-Month의 신화

라는 유명한 격언이 있으니 굳이 다시 해볼 필요는 없다. 사실 대부분의 프로그래머는 이미 주 70-80시간 정도를 일하고 있으니 초과근무가 해법이 아닌것은 분명하다.


이러한 관리자에게 해주고 싶은 말은 앞의 디마리코가 이미 언급하였다. 

     "관리자가 진정해야 하는 일은 사람들에게 일을 시키는 것이 아니라
      그들이 일에 전념할 수 있는 환경을 만들어 주는 것이다.
      - 톰 디마르코, 피플웨어


단순히 프로그래머에게 일하는 시간의 양이 중요하지 않다는 얘기는

      "프로그래밍에서는 평균적인 수준의 노동력을 유지하는 것보다
       영감이 샘물처럼 솟아나는 소중한 순간을 놓치지 않는 것이 중요하다. 
       - 임백준

가 언급하였다.


경력이 비슷한 프로그래머간에도 품질과 생산성의 격차가 생기는 이유는 공장에서 찍어내는 KS가 찍힌 양산품이 아니기 때문이다. 

       "컴퓨터 사이언스를 가르치는 교육이 어떤 사람을 전문적인 프로그래머로 만들지 못하는 것은,
        붓질과 채색방법을 가르치는 교육이 어떤 사람을 전문적인 화가로 만들지 못하는 것과 같다.
        - 에릭레이먼드, 해커와 화가 중



그래서 일찍이 제럴드 와인버그는 이런 말을 했다.

      "모든 프로젝트에는 세가지 문제가 있다. 사람 사람 사람 .
      제럴드 와인버그, 컴퓨터 프로그래밍 심리학