본문 바로가기

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

프로그램 매니저가 되는 방법 - 2 (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)

  두번째 단계는 비전 선언문을 작성하는 것입니다. 비전 선언문이란 대외 공표 문서 (Broad document)의 한가지 종류입니다. 그 내용은 엑셀에서 비주얼 베이직의 동작예시, 매크로를 어떻게 만드는지에 대한 샘플코드, 빌드를 위한 주요 부분, 그리고 사용자의 문제에 대한 해결책 등 입니다. 이 문서에 대해서 반대의견이 많지 않다면, 저는 문서에 추가작업을 합니데 그 내용으로 더 상세한 스펙을 포함하고, 세세한 부분까지 설명하고, 사용자에게 어떻게 보여야 하는지를 보충합니다.

  이것은 기능명세(Functional spec)이지, 기술명세(Technical spec)가 아닙니다. 이것은 기능명세가 사용자 입장에서 기술하는 것이지, 내부 구현에 관하여 논하지는 않는다는 뜻입니다. (기능 명세에 관해서는 이곳 을 참조하세요.) 프로그램 매니저는 개발팀이 내부적으로 어떻게 구현하는지는 신경쓰지 않습니다. 제가 개발팀 리더인 벤 왈드맨(Ben Waldman)에게 기능명세를 보내면, 그는 그의 팀들과 모여 앉아서 내부적으로 어떻게 구현할 것인지를 논의합니다. 그들은 제가 만든 객체지향 인터페이스와 내부함수간의 매우 간단하고 뛰어난 맵핑 테이블을 만듭니다. 하지만, 이것은 정말로 제가 신경쓸 일이 아닙니다. 저는 엑셀의 내부 동작과 그 구현에 관해서는 정말로 많이 알지 못합니다.

  솔직히 말해서, 저는 눈꼽만큼도 알지 못합니다. 대학을 갓 졸업했을 때부터 저는 개발, 테스트, 문서작성, 마켓팅, 사용성 테스트  등의 일들을 충분히 경험하지 못했습니다.운좋게 마이크로 소프트에는 각 분야별로 많은 경험을 가진 고수들(Gurus)이 있었고, 그들은 오늘날 제가 아는 모든 것을 저에게 가르쳐 주었습니다. 또한 그들은 뛰어난 제품을 실제로 만들었습니다. 예를 들어, 사용자들은 엑셀의 셀(Cell)에서 변수로 값을 카피하고 싶을 때, 다음과 같이 적습니다.

x = [A1]  

  문제는 이 셀에는 숫자가 들어있을 수도 있고, 문자열이 있을 수도 있다는 것입니다. 하지만, 베이직은 얼리 바운드 (Early bound) 언어 입니다. 여러분은 DIM x 를 Integer, Float  또는 String을 사용하기 전에 선언해야 합니다.

  베이직은 동적 타입(Dynamic types)을 지원해야만 하지만, 저는 이것을 구현할 만큼 똑똑하지 않았습니다. 뭐, 문제 없었습니다. 비주얼 베이직 팀의 프로그래머인 톰 코벳(Tom Corbett)이 해결방법을 찾았습니다. 그리고 Variants 와 IDispatch 가 태어났습니다. 베이직은 "덕 타이핑(Duck typing)"과 함께 동적인 언어가 되었습니다. 중요한 점은, 제 일은 문제를 해결할 필요는 없다는 것입니다. 제 일은 고객의 요구사항을 분석하고, 프로그래머들이 그 요구사항의 해결책을 확실히 찾을 수 있도록 하는 것입니다.

  일단 기능명세가 완성되고 개발팀이 일에 착수하면, 제게는 두가지 책무가 남습니다. 첫째, 설계에 대한 모든 질문에 답하고, 같은 질문이 나오지 않도록 그 내용을 다른 팀들에 전파합니다. 둘째, 테스터들에게 기능의 정상 동작에 대해서 설명하고 테스트 계획을 잡을 수 있도록 돕습니다. 문서화 팀을 만나서는 그들이 엑셀의 베이직 스크립트를 위한 좋은 튜토리얼과 참고문서를 작성할 수 있도록 합니다. 지역화 전문가(Localization experts)를 만나서는 지역향 개발을 위한 전략을 세웁니다. 매켓팅 팀과는 VBA 기능의 마켓팅 포인트에 대하여 설명합니다. 사용성 전문가와 만나서는 사용성 테스트 계획을 세웁니다.

  프로그램 매니저는 많은 회의를 합니다만, 문서화 작업은 그리 많지 않습니다. 이것이 대학을 갓 졸업한 초짜 시절부터 지금까지 제가 이일을 계속 할 수 있는 이유입니다. 여러분이 프로그램 매니저가 되기 위해서 꼭 14년 경력의 베테랑 프로그래머가 될 필요는 없습니다. (사실, 14년의 프로그래밍 경력이 있다면 여러분은 더 좋은 사용자의 대변인이 될 수 있을 것입니다.)

 
 - 3부에 계속 됩니다.