대학교 3학년쯤 되면 앞으로 어떤 직장에서 어떤 일을 하게 될 것인가 - 진로 문제와는 조금 다은 - 가 가장 큰 관심사 중 하나일 것이다. 취직을 하게 되다면 어떤 회사에서 어떤일을 하게 될 것인지, 단순한 코더, 웹사이트 관리자 부터 거대한 프로젝트를 수행하고 공공시스템을 설계하는 등의 일까지 어떤 일을 하느냐에 따라 모든 졸업 후의 삶은 거대한 미지수이기 때문이다.

컴퓨터를 전공하는 학생에게 이 책은 정말 큰 정보와 조언들이 되었다. 현업의 다양한 분야에서 일하고 있는 선배들의 이야기면서, 어떻게 공부를 해야 하고, 어떤 자세를 갖고 있어야 하는지 아주 실제적이고 현실적인 충고들이 있었다. 특히 앞으로 읽어할 책들의 목록과 순서를 정해준 부분과 코딩의 재미를 넘어서야 한다는 일곱 분의 공통된 조언들이 기억에 남는다. 1학년 때 처음올 프로그래밍을 배울 때 교수님이 하셨던 말씀들 - 프로그래밍은 예술이다, 설계가 가장 중요하다 - 의 의미를 다시 한번 새겨볼 수 있는 기회가 되었다.

이제, 나도 그 길을 걸어보려고 한다. 쉽지는 않겠지만 이 책을 쓴 선배들이 밤새워가며 부딫히고 지금까지도 도전하는 그 길은 몸은 좀 편하겠지만 동일한 일을 반복하는 관리직, A/S직보다는 훨씬 역동적일 것 같기 때문이다.

  - 2004. 8.

 이제 와서 다시 리류를 읽어 보면, 저 책 조차도 IT란 분야를 충분히 많이 설명하지는 못하고 있었다는 생각이 든다. 지금 내가 하고 있는 일이 IT인지 제조업인지 늘 헛갈리는 상태에서 내 일이 계속 이렇게 흘러갈지 어떨지도 모르겠고... 어쩌면 뭔가 알듯 말듯한 지금 상황이 더 혼란이 가중된 상태일지도 모르겠다. 과연 나는 어떻게 나아갈 것인가? 라는 질문은 여전히 답이 없고 미지수다. 그게 고과나 평가와 얽히는 순간 일하기 싫어저 버린다. 그냥 그냥 하루하루 주어진 - 아니, 별로 명확하게 선이 그어지고 주어진 일도 없어보인다 - 일을 해 나갈 뿐이다.

  하루 하루. 그러나 분명하게. 실력을 쌓고, 어제 보다 오늘 더 나아지고 있다고 믿는 수밖에 없다. 믿을 수 없다면? 믿을 수 있는 길로 나아가야겠지. 경력은 쌓여가지만, 아직도 얼치기 같다는 생각도 많이 한다. 직장이 날 발전시키는 곳은 아닐지도 모른다. 입사 면접 때 들었던 말이 생각난다.

"자넨 회사가 자네를 훈련 시키는 곳이라고 생각하나?" 


  그때는 웃으면서 둘러 댔지만, 지금은 말할 수 있을 것 같다. 

"아닙니다. 직장은 일하는 곳입니다.

 하지만, 직장 생활을 통해서 나아지는 것이 없다면,

그 직장은 좋은 직장은 아닐지도 모르겠습니다. "


그럼, 결론이 난건가? 글쎄.
Posted by 지그프리드 지그프리드
  네번의 연재 끝에 드디어 첫번째 번역을 마쳤습니다. 조엘이 글 자체가 부사를 굉장히 많이 써서 우리말로 읽기 쉽게, 그리고 우리말 어순과 문법에 맞게 번역하는 것이 굉장히 어려웠습니다. 가능한 우리가 사용하는 말로 의역하려고 노력을 했고, 우리말 어순을 지키려고 노력을 했습니다만, 많이 부족할 것 같습니다.

  영리를 목적으로 작성한 글은 아닙니다. 글의 원저자는 Joel Spolsky 임을 밝혀둡니다. 개인적인 영어 공부와 소프트웨어 엔지니어링 공부의 목적을 겸하고 있고, 보다 많은 공학도들이 그의 혜안을 배울 수 있었으면 좋겠다는 의도로 시작한 일입니다. 따라서 모든 종류의 태클은 정중히 사양합니다. 영문 번역에 미흡한 부분에 대한 지적은 얼마든지 환영합니다. 감사합니다.
Posted by 지그프리드 지그프리드


원문은 여기에
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은 인간관계의 기술에 대한 정말로 환상적인 입문서 입니다. 이 책은 제가 포그 크릭의 모든 매니지먼트 교육생들에게 모든 일에 앞서서 읽게 했던 책힙니다. 이제는  제가 이 책을 읽으라고 할 때면 모두들 킥킥 댑니다만, 전 그들이 이 책을 모두 읽었다는 사실에 만족합니다. (끝)

 




Posted by 지그프리드 지그프리드
원문은 여기에 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부에거 계속됩니다. 시간이 생각보다 오래 걸리네요.
Posted by 지그프리드 지그프리드
원문은 여기에 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부에 계속 됩니다.
Posted by 지그프리드 지그프리드
원문은 여기에 http://www.joelonsoftware.com/items/2009/03/09.html

How to be a program manager

by Joel Spolsky (Monday, March 09, 2009)

    좋은 프로그램 매니저를 얻는 것은 정말 뛰어난 프로그램을 만들기 위한 비밀 공식 중 하나입니다.  아마도 여러분에 팀에는 좋은 프로그램 매니저가 없을 것입니다. 왜냐하면, 대부분의 팀들이 없거든요.

  WYSIWYG 워드 프로세서를 공동 개발한 뛰어난 프로그래머인 찰스 시모니(Charles Simonyi)는 마르타 스튜어트(Martha Stewart)를 만났습니다. 마르타 스튜어트는 마이크로 소프트의 주식으로 억만장자가 되었고, 우주여행까지 한 사람입니다. 그들은 "맨 먼스 미신(Mythical Man Month)"의 문제를 해결하기 위한 정말 큰 소프트웨어 팀을 만들었습니다. 이 팀은 완전 뛰어난 천재 프로그래머가 상위 레벨의 함수를 만들고, 하위 레벨의 함수에 대한 구현은 초급 프로그래머들에게 넘기는 방식으로 일을 합니다. 이 천재 프로그래머의 직함을 프로그램 매니저(Program Manager) 라고 부릅니다. 시모니는 똑똑했지만, 이 아이디어는 그렇지 못했습니다. 제 생각에, 그 이유는  누구도 초급 프로그래머가 되고 싶지는 않기 때문입니다.

  80년대 후반에 Mac Excel 팀의 프로그래머였던  제이브 블루멘달 (Jabe Blumenthal)은 이 직함을 재활용했습니다. 그는 소프트웨어 개발이 점점 더 복잡해지고 있다는 점과 프로그래머들이 프로그램의 사용성과 유용성을 신장시키기 위해 고민할 시간이 없다는 점을 알고 있었습니다. 마켓팅 팀에서는 고객들의 요구사항에 대해서 시끄럽게 떠들어 댔지만, 그들과 이야기 하고 그들이 MBA-Speak를 구체적인 사양으로 번역할 사람이 없었습니다. 많은 작업량이 필요한 제품 설계 요소에는 여러가지가 있습니다. 사용자와 대화하기, 사용성 테스트하기, 경쟁제품 분석하기, 쉽게 구현하기 위한 방법을 찾기 위해 열심히 고민하기 등. 그러나 대부분의 프로그래머들은 정말로 시간이 없습니다. (시간만 있다면 그들은 이 일들을 잘 해낼 수 있습니다.) 블루멘달은 프로그램 매니저란 직함을 빌려다가 완전히 새로운 일을 하도록 재창조 했습니다.

   프로그램 매니저는 어떤 일을 하는가?

  이제부터  프로그램 매니저가 하는 일들을 살펴보겠습니다.

  1. UI 설계 (Design UIs)
  2. 기능 명세 작성 (Write functional specs)
  3. 팀 간의 업무 조정 (Coordinate teams)
  4. 고객측의 대변자 역할 (Serve as the customer advocate)
  5. 바나나 리퍼블릭(미국의 중저가 브랜드) 의 치노(chinos) 입기
 
  제 프로젝트 매니저로써의 첫번째 과제는 마이크로 소프트의 엑셀의 기능 중 커스터마이제이션 이라고 부르는 사용자 기능(User activity) 이었습니다. 예를 들자면, 스크립트와 매크로 처럼 사용자가 직접 만들어 사용할 수 있는 기능들입니다. 제가 해야 했던 첫번째 일은 사용자들의 요구사항을 알아내는 것이었습니다. 이를 위해서 저는 가능한한 많은 사용자들과 이야기를 나눴는데, 똑같은 이야기가 반복되어 지루해지기 시작할 때까지 고객의 의견을 들었습니다. 저는 어떤 것들이 18개월의 개발기간안에 구현 가능하고 타당한지검토하는데 많은 시간을 들였습니다. 또한 비주얼 베이직 팀과 컴파일러, 코드 에디터, 다이얼로그 박스 에디터 등 엑셀의 메크로 기능에 사용될 수 있는 툴들을 제공해 줄 수 있는지 확인하기 위해 오랬동안 이야기를 나눴습니다. 저는 또 애플(Apple)과 이야기를 했는데, 그들은 애플 스크립트(Apple script)라고 부르는 범용 매크로 언어를 개발하고 있었습니다. 애플 뿐만 아니라 마이크로소프트의 다른 어플리케이션 개발팀들 - 주로 워드(Word), 엑세스(Access), 프로젝트(Project) 그리고 메일(Mail) - 을 만났는데, 이들은 엑셀과 일반적인 기능들은 동일합니다. 이러한 과정들은 대부분 대화, 회의, 이메일, 전화통화로 이루어져 있습니다. 제 삶은 이 일의 흔적이 남아있고, 지금도 전화벨이 울릴 때면 제 사무실에서도 겁에 질린답니다.

 - 2부에 계속 됩니다.

Posted by 지그프리드 지그프리드

  네이버에 이런 질문이 올라왔다.

안녕하세요 컴퓨터프로그래머가 되고싶은 중3 학생입니다

 

저는 초등학교 6학년때부터 컴퓨터프로그래머에 푹빠졌습니다

 

그리고 그생각만 가지고 보니 중3 이였습니다

 

저는 워드프로세서 1,2,3 ITQ 한글, 파워포인트 정보처리기능사 자격증을따냈습니다

 

하지만 자격증만으론 안되고 C언어 C++ JAVA 등 여러가지를 공부해야합니다

 

하지만 저는 중학교입학할때부터 컴퓨터공부를 전혀하지 않았습니다

 

자격증만 있고 확고한 자신감만있으면 된다고 생각한저였으니까요

 

지금은 공부할 마음이 생깁니다

 

어떻게하면 컴퓨터프로그래머가 될수있을지

 

또 어떻게공부해야지 나의 진로를 갈수있을지

 

도와주세요..


 뭐 도와주고 싶은 생각이야 든다만, 과연 프로그래머가 뭐하는 사람인지 잘 모르고 있는 것 같다는 생각이 먼저 들었다. 그래서 이렇게 답변을 달았다.

열심히 공부해서 좋은 대학에 가세요

컴퓨터프로그래머가 되고 싶다면, 가장 기본적인 조건은 대학교에서 컴퓨터를 전공하는 것입니다. 대부분이 회사들이 컴퓨터공학 전공이나 컴퓨터과학 전공의 학위를 요구하기 때문입니다. 좋은 프로그래머가 되고 싶으시다면, 중학생인 지금은 컴퓨터관련 자격증이나 C언어를 공부하는 것은 아무 의미가 없습니다. 그런 공부는 대학에 가서 하셔도 충분합니다.

  컴퓨터 프로그래머는 "어떤 문제를 해결하기 위한 알고리즘을 만들어서, 그 알고리즘을 컴퓨터 언어를 이용해 컴퓨터가 이해할 수 있는 프로그램을 만드는 사람"을 뜻합니다. 지금 질문자님께서 생각하시는 부분은 컴퓨터 언어를 이용해서 프로그램을 만드는 부분만 생각하고 계신 것 입니다. 하지만 실제로 좋은 프로그래머는 문제를 해결하기 위한 좋은 알고리즘을 만드는 사람입니다. 그리고 좋은 알고리즘을 만들기 위해서는 생각이 깊고 현명한 사람이 되어야 합니다. 생각이 깊고 현명한 사람이 되기 위해서는 좋은 대학에서 체계적인 교과과정에서 따라서 열심히 공부하는 것이 가장 필요한 일입니다.

 다시 말씀드립니다만, 지금 중3이라면 학교 공부 열심히 하시는 것을 권해드립니다. 수학과 영어를 열심히 하시는 것이 특히 중요합니다. 그래서 좋은 학교를 가세요. 특히 우리나라는 좋은 학교와 그렇지 않은 학교 사이에 수준차이가 많이 납니다.

  너무 현실적인 답변이었을까? 사실 지금 내가 하는 일도 프로그래머는 이런 일을 한다고 소개하는 수많은 에세이들과 비교하면 노가다에 더 가깝다는 생각도 든다. 좀더 정신노동, 창조적인 일을 하길 원하는데 실상은 그렇지 못한 면이 많다. 내 실력도 그런 일을 할 만큼 뛰어나진 않다고 느끼고 있고. 무엇보다 대학 때 배운 것들이 국제적인 기준에서 너무 수준이 낮았다. 만약 내가 아르바이트로라도 프로그래밍을 하지 았았다면 난 지금보다도 실력이 한참 모자라는 얼치기 개발자에 불과했을 것이다.

  요즘의 대침체 이전에 미국의 최고 장래성있는 직업은 S/W Engineer 였고, 석사 출신 신입의 초봉이 평균 10만 달러에 육박했었다. 대한민국의 프로그래머는 여전히 3D와 화이트칼라의 경계를 걷고 있고, 대우는 많이 부족하다. 거기에다 동종업게 이직금지라는 노예제도까지 존재하고 있다. 공생전 같은 글이 괜히 나오는 것이 아니라는 뜻이다.

 개인적으로, 프로그래밍을 정말 좋아한다. 이 일은 The Mythical Man Month에서 나오는 것과 같이, 새로운 것을 만드는 창조적인 일이고 아름다운 코드를 만든 예술적인 일이다. 목수가 책상 다리에 못을 박고서 예술적으로 박았다고 느끼는 지는 모르겠다. 하지만 프로그래머들은 코드를 몇줄 적어놓고 "아름답다" 고 말한다. 프로그래머는 사람의 언어 대신 컴퓨터의 언어로 글을 쓰는 작가들이기도 하다. 그래서 난 이 일을 사랑하는 것 같다.

 프로그래머가 되고 싶다면, 이 일을 얼마나 사랑할 수 있을지 고민을 좀 해보는 것이 필요하다. 정말 해주고 싶은 말은 이것이다.
Posted by 지그프리드 지그프리드

BLOG main image
일상, 프로그래밍, IT 그리고 직장생활, Dive, 여행 by 지그프리드

카테고리

Class List (402)
Studies (30)
Exercise & Quizz (10)
Term Project (0)
ECIM list (Help!) (10)
Issues & News (0)
Gossip about IT & Job (22)
Tools (2)
Think about the Justice (23)
Book Review (170)
조엘 온 소프트웨어(번역) (28)
Diary (87)
Vacations (9)
Clash of clans 클래시 오브.. (11)

글 보관함

달력

«   2019/06   »
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30            
Total : 313,389
Today : 12 Yesterday : 11