본문 바로가기

조엘 온 소프트웨어(번역)

프로그램 매니저가 되는 방법 - 3 (How to be a program manager)

원문은 여기에 http://www.joelonsoftware.com/items/2009/03/09.html

How to be a program manager

by Joel Spolsky (Monday, March 09, 2009)


 - 이전글 : 프로그램 매니저가 되는 방법 - 1 (How to be a program manager)
 - 이전글 : 프로그램 매니저가 되는 방법 - 2 (How to be a program manager)

대립(Conflict)

   프로그램 매니저가 없다면, 여러분의 뛰어난 프로그래머들은 엉터리 유저 인터페이스를 만들게 될 것입니다. 물론 그들은 "당신이 불칸(Vulcan : 스타트랙) 이라면 쉽게 이해할 것이다" 이란 생각으로 만들었을 것입니다. (역자주 : IF YOU'RE A VULCAN : 스타트랙에 나오는, 감정은 배제하고 논리와 이성으로 만으로 살아가는 외계 종족) 최고의 프로그래머들은 아주 똑똑하지만, 열 여섯개의 한 글자 커맨드 옵션(Command line arguments) (역자주 : copy - X -D 같은 것들)를 사용자들이 기억하기 어려월 할 것이라고는 상상도 하지 못합니다. 이러한 프로그래머들은 그들의 첫번째 아이디어를 그대로 밀고 나가는 경향을 보이는데, 특히 이미 코딩을 시작한 상태라면 더욱 그렇습니다.

 만화 원본 (http://www.ok-cancel.com/comic/4.html)


  소프트웨어 설계 프로세스에 프로그램 매니저가 추가할 수 있는 최선의 일은 프로그램이 어떻게 설계되야 하는지 대안(Second option)을 제시하는 것입니다. 이것만이 "모자른" 사용자들에게 매뉴얼을 읽거나, emacs-lisp 함수르르 스스로 만들거나, 8진수를 암산하는 일을 피할 수 있게 하는 유일한 희망적인 일입니다.

  좋은 프로그램 매니저는 UI 동작에 관한 아이디어를 제실할 것입니다. 그 아이디어는 개발자의 아이디어보다 더 뛰어날 수도 있고, 더 안좋을 수도 있습니다. 그리고, 긴 토론이 시작됩니다. 일반적으로, 프로그램 매니저는 간단하고 사용자가 이해하기 쉬운 것을 원합니다. 예를 들면 텔레파시 UI나 주머니에 넣기에는 너무 큰 30인치 스크린을 넣고 싶어합니다. 반면에 개발자들은 평범한 것들을 코드에 구현해 넣기를 원합니다. 예를 들면, 커맨드 라인 인터페이스(이에 왜 쓰기 어렵다는거지?)나 파이썬 바인딩(Python bindings) 같은 것입니다.

  엑셀 5 프로젝트 중에서 제작 기억하는 기념비적인 토론은 피봇 테이블에 관한 것이었습니다. 개발자들은 피봇 테이블을 스프레드시트의 드로잉 레이어 (Drawing layer)위에 띄워(float) 놓고 싶어 했습니다. 반면에, 프로그램 매니저는 스프에스시트의 셀의 오픈쪽에 살리고 싶었습니다. 이 토론은 정말 정말 오래 계속 되었고, 마침내 프로그램 매니저가 이겼습니다. 하지만, 최종 설계는 각각의 의견보다 훨씬 더 좋은 것이었습니다.

  이러한 토론이 서로를 존중하면서 사실에 기반하여 이성적으로 진행되기 하기 위해서는 프로그램 매니저와 개발자들이 동등한 입장에 서는 것이 매우 중요합니다. 만약 개발자들이 프로그램 매니저에게 문제제기를 할 때, 토론 중 어떤 점이 매니저의 마음에 안들면 매니저는 "됬어. 그만해. 그냥 내 방식대로 하지" 하고는 토론 전부를 무시해 버릴 것입니다. 그들이 동등한 입장에 서 있다면 이런 일은 일어날 수 없겠지요. 이건 법정과도 약간 비슷한 면이 있습니다. 법정에서는 한쪽에 치우친 판사를 허용하지 습니다. 또한, 공평한 토론 절차를 통해서 진실이 드러날 것이라고 믿습니다. 마찬가지로, 프로그램 매니저와 개발자 간의 토론도 어느 한쪽이 불공평한 이점(Advantage)이 없을 때에 비로소 공평해 집니다.

  이것이 중요한 점입니다. 당신이 11학년에 다니는 샐리(Sally)에 대해서 떠올릴 때, 그녀가 지금 어디에 있는지 궁금해 하지 않겠습니까? 기운 내십시요. 그녀는 스콧데일(Scottsdale)에 사는 바이오테라피스트고, 공화당원입니다. 자, 주목하십시요. 프로그래머들이 프로그램매니저에게  문제제기를 하지 못한다는 것은 개발팀장(혹은  CTO나 CEO)이 명세(Spec)을 만드는 사람이 될 수 없다는 뜻입니다.  (역자 주 : 1. Sally 이야기가 갑자기 왜 나왔을까요?. 이해할 수가 없습니다. 2. 이 단락의 내용을 부연하자면, 개발팀장이나 CTO, CEO 같은 사람은 개발자와 동등한 입장에 설 수 없으므로, 개발자들이 함부로 문제제기를 할 수가 없게되고, 이런 사람은 프로그램 매니저로 적절하지 못하다는 얘기 입니다.)

  많은 회사들이 저지르는 첫번째 잘못(Number one mistake)은 프로그래머들의 관리자가 명세를 작성하고 제품 설계를 하는 것입니다. 이것이 잘못인 이유는 이사람이 한 설계는 공평하게 검토될 수가 없고, 그로 인해서 문제제기와 토론이 있을 수가 없게 되어 만족할 만큼 좋은 설계가 나올 수가 없습니다.

  저는 이점을 힘들게 배웠습니다. 포그 크릭 소프트웨어(Fog Creek Software)에서, 저는 스스로 프로그램 매니저가 되어 많은 일을 했습니다. (역자 주 : 글쓴이는 포그 크릭의 창립자이자 CEO입니다.) 그리고 이 것은 사람들이 제 잘못을 지적할 때마다 계속해서 걸림돌이 되었습니다. 우리회사는 큰 회사가 아니었지만, 마침내 진짜 프로그램 매니저를 둘 만큼은 커졌습니다. 지금은 댄(Dan)과 제이슨(Jason)이 프로그램 매니저로 일하고 있고, 프로그래머들은 그들과 논쟁하기를 좋아합니다.

  물론, 프로그램매니저와 관계까 동등할 때도 프로그래머들은 우위를 갖기를 원합니다. 이런 일이 몇번 있었는데, 한번은 한 프로그래머가 프로그램매니저와의 논쟁에 제가 개입해 줄 것을 요청한 일이 있었습니다.

  "누가 프로그램을 짜지요?" 제가 물었습니다.
 
  "접니다."

  "좋아요. 그럼 누가 소스 관리 서버에 체크인(Check in)하지요?"

  "그것도... 저지요."

  "그러면, 정확히 뭐가 문제지요?" 제가 물었습니다.

  "당신이 최종 제품의 한 비트(bit) 까지 통제할 수 있는 막강한 힘이 있는데 무엇이 더 필요하십니까? 왕관이라도 씌워 드릴까요?"

  보시다시피, 이 시스템은 프로그램 매니저에게 프로그래머들을 설득해야 만 하는 부담을 안겨줍니다. 어떤 면에서는 프로그래머가 논쟁하기를 포기하고 프로그래머가 내키는 대로 막 짜버릴 위험성도 있습니다. 그러므로 능력있는 프로그램 매니저가 되기 위해서는 (a) 정당성이 있어야 하고, (b) 프로그래머 들로 부터 존경을 받아야 합니다.존경을 받을 때 비로소 당신이 정당하게 일하고 있다고 프로그래머들은 이야기 할 것입니다.

  어떻게 존경을 받을 수 있을까요?

 - 4부에거 계속됩니다. 시간이 생각보다 오래 걸리네요.