프로그램 매니저가 되는 방법 - 4 (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)
 - 이전글 : 프로그램 매니저가 되는 방법 - 3 (How to be a program manager)

  - 3부에서 계속

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

  프로그램 매니저가 코딩을 잘 한다는 것은 분명히 도움이 됩니다. 예, 이것은 불공평 합니다. 프로그램 매니저는 코딩을 할 의무는 없으니까요. 하지만, 프로그래머들은 상대가 얼마나 똑똑하던 간에, 프로그래머를 프로그래머가 아닌 사람보다 더 존경하는 경향이 있습니다. 코딩을 할 줄 모르면서도 능력있는 프로그램매니저가 될 수는 있겠습니다만, 개발팀으로부터 존경을 얻기 위해 더 큰 부담을 감수해야 할 것입니다.

  개발팀으로부터 존경을 얻는 또 다른 방법은 개발팀과 무엇을 주제로 토론을 하던지 이성과(Intelligence)과 열린 자세(Open-mindedness)와 공평함(fairness)을 보여주는 것입니다. 만약 프로그램 매니저가 멍청한 말을 한다면 프로그래머들은 그를 광대 취급하며 귀를 닫아버릴 것입니다. 만약 프로그램 매니저가 자기 주장만 하거나 감정적으로 일을 한다면 논점은 점점 더 타당하지 못한 방향으로 흘러가서 결국 개발팀의 신뢰를 잃게 될 것입니다. 개발팀도 마찬가지겠지만, 특히 프로그램 매니저는 토론에서 감정을 배제하고 새로운 자료들을 검토해서, 그것에 이점이 있을 때는 자기 주장을 굽힐 줄 알아야 합니다. 마지막으로, 프로그램 매니저가 정치적인 모습을 보일 때 그들은 개발팀의 신뢰를 상실하게 될 것입니다. 예를 들면, 사장님과 개인적인 미팅을 갖는다던가, 토론에 이기기 위하여 개발팀을 분할 정복(divide-and-conquer)하려는 행동들 입니다.

  프로그램 매니저가 개발팀의 신뢰를 잃게 되면 그것으로 끝입니다. 그들은 더이상 효율적이지 못합니다. 프로그래머들은 등을 돌린체 그들이 원하는 방식대로 해버릴 것입니다. 그 결과는 나쁜 코드와 시간낭비로 나타날 것입니다. 왜냐하면, 단지 당신이 무능력한 프로그램 매니저 놀이를 하면서 월급을 축내는 것 뿐만아니라  뿐만아니라, 회의를 소집해서 모두의 시간을 탕진할 것이기 때문입니다. 물론, (좋은 프로그램 매니저 없이는) 그들이 그 시간에 코드를 더 좋게 할수도 없겠지만요.

  명세서라고? 정말? 그건 정말 애자일 방식이 아니야 (Specs? Really? That's so unagile)

  명세서는 정신나간 관료주의적인 문서작업이라고 생각에, 명세서를 작성하지 말자는  많은 개발 조직들이 생겨났습니다. 이분들은 오해를 한 것입니다. 기능명세서를 작성하는 것은 애자일 개발방식의 핵심입니다. 왜냐하면, 이것이 코딩전에 수많은 가능한 설계들을 빠르게 해 볼 수 있게 하기 때문입니다. 코드와 비교할 때, 명세서는 바꾸는 것은 하찮은 일입니다. 명세서를 작성하는 작업이 머리속으로 설계에 대하여 생각하게 만들고, 그 설계의 약점을 빨리 발견할 수 있게 하여 다른 대안을 찾을 수 있도록 합니다. 기능 명세서를 이용하는 개발팀이 더 나은 제품을 만듭니다. 왜냐하면 그들은더 많은 가능한 솔루션들들을 빠르게 찾아볼 기회가 있기 때문입니다. 또한 이러한 개발팀은 코드도 더 빠르게 작성하는데, 왜냐하면 작업을 시작하기 전에 명확한 그림을 볼 수 있기 때문입니다. 기능 명세서는 매우 중요하기 때문에, "명세서 없이는 코드 없다" (\No code Without Spec"는 포그 크릭(Fog Creek)의 몇안되는 업격한 규칙 중 하나로 제정되었습니다.

  명세서의 구체적인 형태는 바뀔 수 있습니다. 모든 기능명세서가 프로그램이 어떻게 동작해야 하는지에 관해서 담고 있어야 합니다. 코드가 내부적으로 어떻게 동작해야 하는지는 기술하지 않습니다. 여러분은 더 높은 수준에서 시작할 수도 있습니다. 비전 선언서 - 한 페이지 안에 새로운 기능에 관혜서 설명한 요점만 남는 것 - 만 작성하는 것입니다. 비전 선언문이 확정되면 , 스토리보드를 작성합니다. 스토리보드는 사용자들이 보게 될 화면의 예시와 함께 어떻게 동작해야 하는지 상세한 설명으로 되어 있습니다. 기능의 종류에 따라, 특히 UI 중심의 기능에는 스토리보드를 작성하면 다 된 것입니다. 그것이 당신의 명세서 입니다. 제이슨 프라이드 씨, (Jason Fried) 이제 가셔도 좋습니다.

    UI 스토리보드로는 숨겨진 동작이 중요한 보다 복잡한 기능을 표현할 수는 없습니다. 이런 기능을 위해서는 좀 더 상세한 명세를 작성해야 합니다. 어떤 경우던지, 명세서를 적는 행위는 여러분이 문제점, 모순점, 설계상의 이슈들을 코드의 첫번째 줄을 작성하기 훨씬 전에 발견할 수 있도록 해줍니다. 그래서 여러분이 코드를 작성할 때 예기치 못한 이슈가 튀어나와서 코드를 다시 작성하거나, 나, 상황이 더 않좋다면,  비효율적인 코드를 작성할 수 밖에 없는 경우를 훨씬 더 줄여줍니다.

  프로그램 매니저가 되는 방법을 어떻게 배우나요?

  프로그램 매니저가 된다는 것은 대부분 배움에 관한 것입니다. 기술에 관해서 배우고, 사람들에 관해서 배우고, 조직을 효율적으로 운영하는 방법을 배우는 것입니다. 좋은 프로그램 매니저는 설계 기술에 대한 엔지니어적인 태도와 사람들의 의견을 하나로 모으고 함께 하도록 만드는 정치적인 능력을 조화시킨 사람입니다. 여러분이 프로그램 매니저로 일하고 계시다면 읽어보셔야 할만한 몇가지 책들이 있습니다. 제가 이야기할 수 있는 한, 스콧 벅쿤(Scott Berkun)의 책 Making Things Happen은 프로그램 매니저가 무엇을 해야 하는지에 관해서 대부분을 다루는 유일한 책입니다. 그러니, 이 책으로 시작하십시요. 스콧은 수년동안 인터넷 익스플로러(Internet Explorer)팀의 프로그램 매니저로 일해왔습니다.

  프로그램 매니저 일의 다른 큰 부분은 유저 인터페이스 설계에 관한 것입니다. 스티브 크룩(Steve Krug)의 Don’t Make Me Think를 읽어보시고, 다음엔 제 책 User Interface Design for Programmers를 읽어보십시요.

  마지막으로, 다소 위선적으로 보인다는 것을 압니다만, 데일 카네기(Dale Carnegie)의 1937에 나온 책, How to Win Friends & Influence People은 인간관계의 기술에 대한 정말로 환상적인 입문서 입니다. 이 책은 제가 포그 크릭의 모든 매니지먼트 교육생들에게 모든 일에 앞서서 읽게 했던 책힙니다. 이제는  제가 이 책을 읽으라고 할 때면 모두들 킥킥 댑니다만, 전 그들이 이 책을 모두 읽었다는 사실에 만족합니다. (끝)