인간, 조직, 권력 그리고 어느 SW 엔지니어의 변
국내도서>컴퓨터/인터넷
저자 : 이종국
출판 : 인사이트 2011.03.11
상세보기



 

 적나라한 대한민국 S/W의 현실  

 


● 그동안 S/W 관련된 에세이 혹은 소설 종류는 거의 다 읽은 것 같다. 안철수 교수의 "지금 우리에게 필요한 것은" 부터 임백준 님의 "나는 프로그래머다", "행복한 프로그래밍", "뉴욕의 프로그래머" 같은 에세이, 소설들, 조엘 스폴스키의 그 유명한 Joel on Software 와 그의 책에서 소개하던 다른 S/W 엔지니어링 관련된 책들, "해커와 화가", "데드라인", "프로젝트가 서쪽으로 간 까닭은" 같은 또 다른 저명한 외국인들의 관련 책들까지. 프로그래밍으로 밥을 벌어먹으면서 관련된 책들은 약간의 의무감까지 느끼며 모두 읽었다. 


● 앞에서 든 책들은 모두 외국의, 특히 미국의 S/W 업계의 현실을 반영한 경우가 많다. 심지어 임백준 님의 책들 조차도 뉴욕의 S/W 회사에서 벌어지는 일이다. 내가 매일 겪는 불합리한 상황들과는 - 지금은 많이 지나갔지만, 옜날에 야근이 극심할 때는, "아 이래서 회사에 창문이 안열리는구나" 란 생각 까지 했었다. - 기본적인 전제 자체가 다르다. 아무리 바쁘고 시간에 쫒기면서 돌아가는 곳이 이 S/W 업계라 하여도 대한민국 SI 업계에서 들려오는 소문들과, 내 사촌 누님이 실제로 겪은 일들과,제조업에 기반을 둔 무늬만 IT회사에서 나와 내 동기들과 동창들이 겪는 일들은 앞서 말한 책들의 저자들은 상상조차 하지 못한 일들이다. 


● 이 책, 대한민국의 SW 현실을 다룬 진짜 첫번째 책인 아닌가 싶다. 이전에 "대한민국에는 S/W가 없다" 가 그나마 대한민국의 현실을 다루려고 했었으나, 역시나 저 높은 곳에서 책상물림이 쓴 느낌이었다면, 이 책은 진짜 PM이 수십년간 프로젝트를 진행하면 겪었던 일들이 정말, 적나라하게 적혀 있다. 


● 예를 들면 이런식이다. 어떤 방법론이나 S/W 엔지니어링 이론에 따른 산출물을 만들어 달라고 요구하면 대충그럴듯하게 만들어주면 된다. 어차피 요구한 사람도 그 자세한 내용은 보지도 않을 뿐 아니라 자기 상사에게 그럴듯 하게 보고하기 위한 용도에 지나지 않기 때문이다. 이런 식으로 신랄하게 깐다. 저자와 같이 프로젝트를 진행했던 몇몇 분들은 책을 읽으면서 자기얘기가 나와서 얼굴이 붉어질지도 모른다. 



 

 대한민국 S/W 업계가 개판인 이유 - 결국 조직내 정치싸움 

 

● SI 업계의 권력 피라미드를 그리면 대충 다음과 같다. 정점에 발주사의 CEO가 있고, 그 밑에 경영진 - IT실무부서(감리부서) - 하청업체 경영진(영업부서) - 하청업체 개발팀 순서다. 일은 하청업체 개발팀이 다 하지만, 생색은 발주사의 경영진이 낸다. 중간에 껴있는 모든 사람들은 어떻게든 자기 때문에 프로젝트가 잘 돌아간 것처럼 보이기 위해서 애를 쓰고, 파워게임을 하고, 쓸데없는 문서를 요구하고, 프로젝트 일정을 압박하고, 결국 개발팀의 누군가를 희생양으로 삼으려고 한다. 이 결과, 개발자와 그 가족들의 삶은 피폐해지고, 프리랜서들은 개발 중간에 회사를 떠나고, 심지어 프로젝트가 일정에 맞춰 성공적으로 끝나는 것을 싫어하는 사람들까지 나타난다. 자신의 공적을 내세울 곳이 없기 때문이다. 


● 돈은 개발부서가 번다. 좀 더 정확히 얘기하면, 위에 권력 피라미드에서 구체적인 부가가치를 창출하는 곳은 제일 밑바닥에 있는 개발부서이다. 그런데, 실제로는 경영, 영업부서다 계약을 통해서 매출을 창출하고, 그 이후 개발부서는 이윤을 까먹는 곳으로 여겨진다. 여기서 현시로가 괴리가 생기고, 문제가 발생하다. 


● 역시, 책상물림들이 S/W 엔지니어링이라는 학문을 만들면서 불필요한 문서들이 엄청나게 늘어났다. 문제는 이 문서 산출물들이 본래의 의도는 잃어버린채, 관리부서의 실적을 입증하는 용도로 전락해 버린다. 문서는 만들어지지만, 누구 하나 내용에는 관심도 없다는 얘기다. 실제 프로젝트와 문서와의 상관관계도 큰 관심이 없다. 결국 개발자들에게 일만 많아지고, 일의 집중력만 흐트러뜨리며, 프로젝트 일정만 늦출 뿐이다. 



 

 프로젝트의 진짜 목적은 무엇인가?

 

● 소프트웨어 개발이나 운영, 유지보수의 최종 목적은 그 안에서 일하는 우리의 행복이어야 한다. 

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

드리밍 인 코드
국내도서>컴퓨터/인터넷
저자 : 스콧 로젠버그 / 황대산역
출판 : 에이콘출판사 2009.01.02
상세보기


   일반적인 소프트웨어 프로젝트 실패의 이유  
 

  보통, 소프트웨어 프로젝트가 어려움에 빠지는 것은 개발자들이 충분한 개발시간을 확보하지 못하는데 있다. 이런 사태는 일반적으로 개발에 대하여 가장 모르는 사람 - 사장님, 영업 책임자, 마켓팅 담당자 등 - 이 프로젝트의 일정을 좌지우지 하기 때문이다. 프로젝트와 기술에 대하여 가장 많은 정보를 가지고 있는 사람은 말단 개발자인데, 이 프로젝트 완료까지 얼마나 걸릴지는 가장 적은 정보를 가진 사람들이 결정을 하는 것이 일반적인 문화이다. 이로 인하여 프로젝트는 별 성과를 내지 못하거나, 엉망진창으로 흐르거나, 하청업체와 개발자들을 착취하는 방향으로 흘러가게 된다. 근로기준법 같은 것은 염두에 두지 않는다. 각자 자기 입장에 맞춰 꿈속에서 본 날짜를 데드라인 (Dead line) 이라고 적어내면 그건 정말로 개발자를 죽이는 날짜가 된다. 그래서 이 땅에는 제대로된 개발자일수록 일찍 일을 접는다. 진짜 똑똑한 사람은 기술고시나 의학대학원으로 가버리고 별로 똑똑하지 못해서 다른데 갈 수가 없는 사람들만 남는, 약자생존(弱者生存)의 생태계가 만들어진다. 


   여기, 또 하나의 끔찍한 실패담이 있다   

  그런데, 이 책에서 예로 든 "챈들러" 프로젝트는 정반대의 경우이다. 충분히 경험많고 실력인 개발자들이 있어고, 그들을 전폭적으로 지지해주는 CEO가 충분한 자본과 시간을 투자했다. 개발자간에는 소통이 너무 많아서 문제가 되었고, 일정이 쫒기기 보다는 일정을 다그치는 사람이 없어서 프로젝트가 지지부진했다. 우리가 늘 꿈꿔오던 개발환경이 갖춰진 셈인데, 이것이 독이되어 프로젝트는 처참한 실패의 결과로 남게 되었다. 

  가장 큰 문제는 기획의 부재였다. 무엇이든 다 되는 PIM (Personal Information Management system) 을 기획했지만, 실제로는 무엇을 하고 싶은지 명확히 알지 못했다. 창업자의 머릿속에만 있는 신기루 프로그램 (Vapor-ware)를 만들다가 시간도, 비용도, 인재도, 모멘텀도 모두 잃어버리고 말았다. 

   그럼 우리가 옳은건가?   
 

  확실히, 책으로 묶어 낼 만큼 신기한 실패사례이기는 하다. 우리가 상상해오던, 그런 재미있는 개발자의 놀이터 같은 회사였는데, 개발자들이 도전해볼만한 과제였고, 모든 의사결정과정이 개발자들간의 민주적인 토론에 의해서 진행되었는데, 프로젝트는 처참하게 실패했다. 그렇다고 우리가 옳은 것은 분명 아닐텐데 말이다. 소프트웨어는 어렵다 - Software is hard - 는 명언이 새삼 확인되는 순간이다. 이순간에도 죽을만큼 힘들게 일하고 있는 개발자들에게, 꿈속도 결코 꿈같이 행복하지는 않다고 말하고 싶었던 것일까. 


Posted by 지그프리드 지그프리드
logo homepage


  Stack Overflow무료 프로그래밍 Q & A 사이트 입니다. 질문을 올리는 것도 무료이고, 답변을 다는 것도 무료 이고, 글을 읽는 것도 무료, 인덱스를 다는 것도 무료 입니다. 평범하고 전통적인 HTML로 만들어져 있고, 낚시글은 없습니다.(no fake rot13 text on the home page), 쓸데없는 구글 검색에 걸리지 않게하는 기술을 사용하지 않고, 장사꾼도 없고, 질문 당 12.95달러를 요구하는 자바 스크립트 윈도우도 나오지 않습니다. 여러분이 카르마(karma : 지식인의 내공과 비슷한 점수 : 역자 주)를 모으거나 가치있는 명성을 얻어 여러분의 이름 옆에 나타나게 하고 싶다면 사이트에 가입하실 수도 있습니다. 하지만, 그렇지 않다면, 이 사이트는 그냥 무료 입니다. 그리고 빠릅니다. 아주, 아주 빠르지요.

  여러분은 Stack Overflow를 운영하지 않습니다. 정말로요. Stack Overflow는 여러분의 동료 프로그래머들에 의하여 공동으로 만들어지고 유지됩니다. 일단 시스템이 여러분을 신뢰하게 되면, 여러분은 모든 것을 편집(수정)하실 수 있게 됩니다. 마치 위키피디아 처럼요. 여러분의 도움으로, 우리는 좋은 답변들과 상상할 수 있는 모든 프로그래밍 관련 질문들로 이루어진 사이트를 만들 수 있습니다. 어떤 프로그래밍 언어를 사용하지, 혹은 어떤 OS를 여러분이 메인으로 사용하는 지는 중요하지 않습니다. 더 나은 프로그래밍이 우리의 목적입니다.

  우리는 Stack Overflow를 마찰이나 고통없이 사용할 수 있다도록 만들었습니다. 여러분의 프로그래밍 관련 질문들에 대한 정답을 성공의 구덩이에 빠지는 것 만큼 쉽게 (as easy as falling into the pit of success) 찾을  있을 것으로 확신합니다. 아마도 그 길을 따라가는 동안에 약간의 재미도 있을 것입니다.

그래서요? 누가 신경이나 씁니까? 이건 그냥 수없이 많은 다른 웹사이트랑 같은거 아닌가요?

  이 사이트가 뭐가 그렇게 특별하냐고요? 예, 아무것도 없습니다. 정말로요. 이것은 프로그래밍 Q&A 사이트 입니다. 유일한 다른 점은 우리는 위키, 블로그, 포럼, 그리고 디그/레딧 (Digg/Reddit)의 고유한 모든 특성을 통합했다는 것입니다. 혹은, 최소한 우리는 이 사이트를 그렇게 만들었다고 생각합니다.


Venn diagram: Wiki, Digg/Reddit, Blog, Forum

  Stack Overflow는 위 그림에서 가운데 있는 작은 별표(*) 입니다.

  하지만, 희망적이게도, 여러분은 우리가 이야기 하는 것을 스스로 경험하는 동안에 알게 될 것입니다.

당신들은 누구입니까?

  우리는 여러분과 같은, 대단한 소프트웨어를 만드는 일을 사랑하는 소프트웨어 엔지니어입니다. Stack Overflow team은 다음과 같습니다.

picture of Joel Spolsky
Joel Spolsky
New York, NY
picture of Jeff Atwood
Jeff Atwood
El Cerrito, CA
picture of Jarrod Dixon
Jarrod Dixon
Morganton, NC

picture of Geoff Dalgas
Geoff Dalgas
Corvallis, OR
picture of Jeremy Kratz
Jeremy Kratz
Little Rock, AR
picture of Brent Ozar
Brent Ozar
Whitehall, MI


당신의 이야기와 사진은 정말 매력적이네요. 더 알 수 있을까요?

  Stack Overflow FAQ를 확인하십시요. 우리에게 연락하실 필요가 있다면, team@stackoverflow.com 으로 하시면 됩니다.

(끝)

PS. 프로그래밍 하시다가 막히는 부분이 있다면 질문을 올려보세요. 현재 세계에서 가장 유용한 프로그래밍 관련 사이트 입니다. 물론, 영어로 올리셔야 겠지요.

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

원문보기

  Stack Overflow 는 조엘 스폴스키(Joel Spolsky)와  제프 앳우드(Jeff Atwood)가 함께 만든 S/W Q&A 사이트 입니다. 네이버 지식인과 비슷한 시스템이지만, 질적 수준은 전혀 다릅니다. 대부분의 프로그래밍 관련 질문 중 90%가 답변을 얻고 있고, 누구나 로그인 절차 없이 질문을 올리고 답변을 얻을 수 있습니다. (역자 주)


스택 오버플로우 개발자의 날 행사 (Stack Overflow DevDays)

By Joel Spolsky
Tuesday, May 12, 2009

  사람들이 점점 더 스택 오버플로우(Stack Overflow)에 열광하고 있습니다. 사이트를 시작한 지 단 6개월 만에 우리는 매달 3백 50만명의 중복되지 않은 방문자들이 찾아 오고 있습니다. 우리는 현실세계에서 이 위대한 개발자 부족(great tribe of developers)을 어떻게 모이게 할지 고민하기 시작하였습니다.


  우리는 일련의 Stack Overflow 이벤트들을 개최하기로 결정하였습니다. 첫번째 위대한 개발자 부족의 회합은 90% 이상의 질문이 답변을 얻을 만큼 대단히 성공적이었습니다. [Video]

  우리는 다가오는 10월에, 5개의 도시 각각에서 하루짜리 이벤트를 기획하고 있습니다.

  우리는 이 하루짜리 이벤트에 가능한 많은 다양한 주제들을 체워넣기로 결정했습니다. 마치 뛰어난 레스토랑이 선보이는 음식들의 맛을 보는 것 처럼, 우리는 각각의 도시에 여섯 명씩 위대한 강사들을 준비했습니다.

  이 행사는 단순히 자바 컨퍼런스나 닷 넷 컨퍼런스나 루비 컨퍼런스가 되지는 않을 것입니다. 어떤 분은 마이크로 소프트의 새로운 웹 프레임워크인 ASP.NET MVC를 소개할 것이지만, 다른 분은 구글의 새로운 모바일 운영체제인 안드로이드 코드를 작성하는 법에 관하여 이야기를 할 것입니다. 그리고 각각의 도시에서 한분 씩 그 지역의 컴퓨터 과학과 교수님이나 대학원생을 초청해서 학계에서 관심있어 하는 새로운 주제에 관하여 저희에게 이야기 할 수 있도록 할 것입니다.

  자신이 몸담고 있는 분야에서 조금 바깥에 있는 것들을 배우고 싶어하는 똑똑한 프로그래머들이 계시다면, 이 컨퍼런스는 바로 당신을 위한 것입니다. 우리는 Byte Magazine(1970~80년대에 유명했던 컴퓨터 잡지로, 컴퓨터와 관련된 모든 분야를 다루었습니다. 역자주)  정신으로 이 일을 준비하고 있습니다. Byte를 기억하십니까? 방대한 영역의 이슈들과 기술들을 다뤘던 잡지 입니다. 슬프게도, Byte는 사라졌고 그 자리를 Mac 만 다루는 잡지(Mac only magazine), IBM만 다루는 잡지, 심지어 마이크로 소프트 SQL 서버만 다루는 잡지 들이 대신하고 있습니다.


이러한 컨퍼런스를 여는 것은 정말로 돈이 많이 듭니다. 컨퍼런스 센터는 커피 한동이에 1,000달러를 부르기도 합니다. 이것이 일반적인 개발자 컨퍼런스 참가비가 1,500달러나 하는 하는 이유입니다. 여기에 여행경비, 숙박비, 그리고 여러분의 호텔 방에서 인터넷을 접속하기 위한 73달러가 추가됩니다. 현재의 전세계적인 경제위기 속에서, 단지 가격이 오르지 않았을 뿐입니다. SD West같은 많은 위대한 컨퍼런스들이 취소되었습니다. 살아남은 컨퍼런스들도 참석자 수가 줄어드는 추세입니다.

  그래서, 라이언 카슨(Ryan Carson, 그의 회사는 FOWA와 같이 뛰어난 컨퍼런스를 개최하는 Carsonified 입니다.)과 함께 이 비용들을 어떻게하면 최소화 할 수 있는지 계산해 보았습니다. 결과는, 첨석자 당 99달러 입니다.

  그렇습니다. 이 하루짜리 컨퍼런스는 단지 99달러 입니다. 여러분은 보통의 컨퍼런스보다 적은 비용으로 여러분 팀원 모두를 데려오실 수 있습니다.

  우리는 다섯 도시에서 이 컨퍼런스를 개최합니다. 어쩌면 여러분은 여행을 하지 않으셔도 될 것입니다. 각 도시당 단지 300명의 개발자 분들 만을 모실 수 있는 공간을 마련했습니다.

        10월 19일 샌프란시스코
        10월 21일 시애틀
        10월 23일 토론토
        10월 26일 워싱턴 DC
        10월 28일 런던

  스택 오버플로우 개발자의 날 행사에 지금 등록하십시요. 참석을 원하시는 분들은 많습니다만, 입장권은 제한되어 있습니다. 다섯 도시의 입장권이 모두 순식간에 팔려버릴 것 같습니다.

  다음은 FAQ 입니다.

  누가 강연을 하나요?

  저는 모든 도시에서 강연을 할 것입니다. 제프 앳우드는 샌프란시스코 에서만 모습을 보일 것입니다. 우리는 각각의 도시에 여섯 분의 강사를 모셨습니다.

  어떤 주제들을 다루게 되나요?

  아직 세부 주제까지 정해지지는 않았습니다. 주제는 강연자의 능력에 달려 있습니다. 저는 다음 주제들 중 가능한 많은 것을 다루어 줄 수 있는 강연자를 구하기 위해 최선을 다하고 있습니다.

  ●  안드로이드
  ●  Object C와 iPhone 개발
  ●  구글 App 엔진
  ●  파이선
  ●  jQuery
  ●  ASP.NET MVC
  ●  FogBugz 7.0
  ●  역동적이면서 분산된 버전 관리

  각각의 강연들은 어느정도는 각각의 주제를 소개하는 내용이겠지만, 경험 많은 개발자들(Advanced developers)을 대상으로 한 내용이 될 것입니다. 만약 여러분이 이미 주제에 대해서 알고 계시다면, 말씀하십시요. iPhone 개발과 관련된 것이라면, 복도에서 다른 iPhone 개발자들과 사귀실 수 있을 것입니다.

  모든 도시의 컨퍼런스가 동일한가요?

  정확히는 아닙니다. 몇몇 주재들은 반복되겠지만 - 제 강연은 다섯 도시에서 동일할 것입니다 - 각각의 도시의 강연자와 주제들이 완전히 동일하게 하지는 않을 것입니다. 우리는 최소한 한 도시에 한 명의 그 지역의 강연자를 모시려 합니다.

  저 배고파요!

  저도 그렇습니다. 저는 항상 배가 고픕니다. 아침, 점심 그리고 오후 티타임 간식까지 티켓 가격에 포함되어 있습니다. 이 컨퍼런스의 재미의 절반은 다른 스택 오버플로우 회원들과의 만남이 될 것입니다.

  행사가 어디에서 진행되나요?

  우리는 아직 강당을 예약하지는 않았습니다. 정확한 장소는 추후에 발표할 것입니다. 장소를 예약하는데 어려움이 있다면, 날짜가 조정이 될 가능성도 약간 있습니다.

  Note : 만약 여러분의 회사가 이 도시들에 있고, 300 명이 들어갈 수 있는 강당이 있다면, 여러분을 스폰서로 모시고 싶습니다. 이메일을 주세요. (devdays@stackoverflow.com)

  어떤 복장을 하고 가야 하나요?

  여러분의 스택 오버플로우 아이디와 명성(지식인의 내공과 비슷한 것 : 역자 주)으로 티셔츠를 만드세요. (오른쪽의 예제를 보세요) 이곳에서 주문을 하시거나 직접 만드셔도 됩니다.

  제가 도와드릴 일이 있나요?
 
  아, 물어봐 주셔서 감사합니다. 이 모든 일을 하기 위해서 우리는 많은 도움이 필요합니다.

  ●  우리는 각각의 도시에 자원봉사자가 필요합니다. 이 다섯 도시 중 한 곳에 살고 계시고, 티켓을 체크하거나 그 외에 일반적으로 컨퍼런스에서 유용한 일들을 도와주실 수 있다면, 이메일을 주십시요. (devdays@stackoverflow.com)

  ●  식사와 간식을 지원해주실 스폰서가 필요합니다. 여러분의 회사가 스폰서가 되기를 원하신다면, 이메일을 주십시요. 이것은 슈퍼스타 개발자를 채용할 수 있는 아주 좋은 방법입니다. 스폰서는 컨퍼런스에서 채용 부스를 만드실 기회를 갖게 될 것입니다.

  질문이 더 있습니다.

  알고 있습니다. 이메일을 주시면 Carsonified의 나타샤(Natasha)가 답장을 드릴 것입니다.

(끝)

PS1. 전반적인 내용이나 FAQ의 내용이 많은 한국의 프로그래머들에게는 도움이 되지 않을 내용입니다. 하지만, 많은 분들께 - 특히 학생 여러분들에게 - 외국에서 하는 개발자 컨퍼런스의 분위기를 알려드리고 싶어서 FAQ 까지 번역을 해보았습니다.

PS2. Stack Overflow는 어느새 대단한 사이트로 자리를 잡았습니다. 네이버 지식인이 대학교 1, 2학년 수준의 질문과 답변을 벗어나지 못하는 것에 반하여, Stack Overflow는 개발자들을 위한 커뮤니티로 완전히 자리매김한 모습니다. Stack Overflow에 관한 소개의 글을 번역할 예정입니다. 영어를 잘 하시는 분께는 문제의 해답을 구할 수 있는 또 다른 기회가 될 수 있을 것 같습니다.

2009/04/04 - [조엘 온 소프트웨어(번역)] - 조엘 온 스프트웨어 - 저자에 관하여 (Joel on Soft ware - About the Author : Joel Spolsky)











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


원문보기

Joel on Software


개발자 생태보고서
A Field Guide to Developers

by Joel Spolsky

 
Thursday, September 07, 2006

  - 이전글 보기 : 개발자 생태보고서 1
  - 이전글 보기 : 개발자 생태 보고서 2
  - 이전글 보기 : 개발자 생태 보고서 3

장난감들

  비슷한 논리가 다른 개발자들의 장남감들에도 적용됩니다. 여러분의 개발자들에게 최신형 컴퓨터와 최소한 두 대의 21인치 LCD 모니터 (혹은 한 대의 30인치 LCD) , 그리고 아마존에서 그들의 원하는 기술 서적을 무제한 살 수 있는 권리를 주지 않을 이유는 전혀 없습니다. 이것들은 분명히 생산성을 올려주기 때문입니다. 하지만 지금 우리의 논의에서 이 장난감들이 갖는 더 중요한 이유는, 이것들이 채용을 위한 결정적인 도구이기 때문입니다. 특히, 대부분의 회사가 프로그래머들을 부속품이나 타이피스트 취급하는 현실세계에서 더 그렇습니다. "왜 당신에게 그렇게 큰 모니터가 필요한데요? 15인치 CRT 모니터에 문제가 있습니까? 내가 어렸을 때만 해도..."  말하면서 말이죠.

개발자들의 사회 생활


  소프트웨어 개발자들은 보통사람들하고 정말로 다르지 않습니다. 물론, 저도 압니다. 오늘날 개발자들을 전형적인 자폐증상이 있는 괴짜들이고, 사람들과의 관계에 적응하지 못하는 사람들로 생각하는 것은 흔한 일입니다. 하지만, 이것은 전혀 사실이 아니고, 심지어 자폐증상이 있는 괴짜들조차 직장의 사회적 측면을 생각합니다. 이런 점들을 포함해서 말이죠.

  ●  조직안에서 프로그래머들이 어떤 대접을 받는가? 

       그들은 유능한 인력입니까? 아니면 타이피스트 입니까? 회사의 경영팀은 엔지니어들이나 전직 프로그래머들로 구성되어 있습니까? 개발자들이 컨퍼런스에 참석하러 갈 때, 비행기 1등석을 타고 갑니까? (저는 이것이 돈 낭비라고 생각하지 않습니다. 스타(연예인)들은 1등석을 탑니다. 이 사실에 익숙해 지세요.) 그들이 입사 면접을 위해 비행기를 타고 올 때, 그들을 리무진 픽업으로 모셔옵니까? 아니면 그들 스스로 사무실까지 찾아오게합니까? 다른 모든 면이 동일하다면, 개발자들은 그들을 스타 대접하는 회사를 더 좋아할 것입니다.  만약 여러분의 회사의 CEO가 왜 스타 개발자들(prima donna developers)이 계속해서 손목 받침대나 대형 모니터나 편안한 의자같은 것들을 요구하는지 이해하지 못하는 지르퉁한 영업 출신 인사라면, 여러분의 회사는 (개발자를 대하는) 태도를 고칠 필요가 있습니다. 뛰어난 개발자들을 존중하지 않는다면, 여러분은 그들을 얻지 못할 것입니다.  (역자주 : 지르퉁하다 : 못마땅해하며 화내다. grouchy)
        

  ●  그들의 동료는 어떤 사람들인가?

        채용 면접날 프로그래머들이 바짝 주의를 기울이는 것 중 하나는 그들이 만나는 사람들입니다. 그들은 친절한가? 더 중요한 점 : 그들은 똑똑한가(Are they smart)? 저는 Bell Labs의 자회사인 Bellcore에서 하계 인턴쉽으로 일한 적이 있는데, 제가 만났던 모든 사람들이 계속해서 같은 이야기를 했었습니다. "Bellcore에서 일하는 가장 큰 장점은 사람들이다"  라고요. 

         이 말은, 여러분에게 잘라 버릴 수 없는 지르퉁한 개발자가 한명이라도 있다면, 최소한 그를 면접관에서 제외시키십시요. 그리고 활기차고, 사교적이고, 크루즈-디렉터 타입의 개발자가 있다면 그를 면접관에 포함시키십시요. (역자주 : 크루즈 디렉터 : 여객선에서 일하는 선원들은 승객들에게 웃으면서 먼저 인사하고 친절하지요) 이 사실을 기억하십시요. 구직자들이 면접후 집에 돌아가서 어느 회사로 갈지 고민 할 때, 그들이 만났던 사람들이 모두 침울했다면 여러분의 회사에 대하여 좋은 기억을 떠올릴 수가 없을겁니다. 

         덧붙여 말씀드리면, Fog Creek의 최초의 채용 규칙은 Microsoft에서 훔쳐온 것이었습니다. 그것은 "똑똑하고, 일을 되게 하는 사람"(Smart, and Gets Things Done) 입니다. 회사를 시작하기 전부터, 우리는 세번째 규칙을 추가해야 한다는 것을 깨달았습니다. 그 규칙은 "바보는 안됨" (Not a jerk) 입니다. Microsoft 시절을 되돌아보면, 바보가 되지 않는 것은 직장을 얻는데 중요하지 않았습니다. 그럼에도 불구하고, 다른 사람에게 친절하게 대하는 것이 중요하다는 말이 단지 립서비는 아니었다고 확신합니다. 아마도 Microsoft도 지원자들이 바보라고 불합격 시키지는 않았을 겁니다. 사실은, 바보가되는 것이 종종 상급 관리자가 되기 위한 선행조건으로 여겨지기도 합니다. 바보들을 감내하는 회사는 비지니스적 측면에서는 타격을 받지 않는 것처럼 보입니디만, 채용 측면에서는 타격을 받습니다. 누가 바보들과 일하기를 원하겠습니까?  (역자주 : Jerk : 《속어·경멸》 세상 물정을 모르는 사람, 바보; 《미·속어》 = SODA JERK. )


(5부에서 계속)


저자에 관하여




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


원문보기

Joel on Software


개발자 생태보고서
A Field Guide to Developers

by Joel Spolsky

 
Thursday, September 07, 2006

  - 이전글 보기 : 개발자 생태보고서 1
  - 이전글 보기 : 개발자 생태보고서 2

물리적 작업공간 (The physical workspace)

  물리적 작업공간에 관해서는 개인 사무실보다 뭔가가 더 있습니다.  한 지원자가 여러분의 회사에 인터뷰를 왔을 때, 그는 직원들이 일하는 곳을 보게될 것입니다. 그리고 그 곳에서 자신이 일하고 있는 모습을 그려볼 것입니다. 만약 사무실이 즐겁고, 밝고, 좋은 동료들이 있고, 모든 것이 새것이고 깨끗하다면 지원자들은 행복한 생각을 갖게 될 것입니다. 만약 사무실이 붐비고, 카펫은 낡았고 페인트 칠되지 않은 벽에 팀 사람들이 줄지어선 사진 위에 TEAMWORK라고 크게 씌여진 포스터가 걸려있다면, 그들은 딜버트(Dilbert : 역자주 : 미국 회사원의 회한을 그린 만화)와 같은 생각을 하게 될겁니다.

  많은 기술 인력들이 일반적인 사무환경에 대해서는 신경쓰지 않는 다는 점은 주목할 만 합니다. 사실, 좋은 사무실의 장점에 익숙해져있는 사람들은 자기 사무실의 일부 단점들을 알아보지 못합니다.

  지원자의 관점에서, 솔직하게 생각해보세요 :

  ●  그들이 우리 사무실의 입지를 어떻게 생각할까요? "버팔로" 라고 말하는 것이 "오스틴" 이라고 말하는 것과 얼마나 다르게 들릴까요? 사람들이 "디트로이트"로 이사오는 것을 정말로 원할까요? 만약 여러분이 "버팔로"나 "디트로이트"에 있다면, 최소한 채용 인터뷰의 대부분을 9월에 시도해 볼 수 있겠습니까? (역자 주 : 우리나라 회사들이 최종 면접을 포항이나 수원, 혹은 탕정에서 하는 것을 생각해 보십시요. 역삼동에 있는 회사와 제주에 있는 회사 중 어느쪽이 채용에 유리할까요?)

  ●  그들이 출근하는 길에 어떤 경험을 하게 될까요? 무엇을 보나요? 그들이 보는 것이 깨끗하고 재미있는 장소인가요? 생화(live)인 팜 나무와 분수가 있는 로비정원이 있습니까? 아니면 슬럼가에 있는 죽어가는 옥수수 화분(corn plants)과 오래전 뉴스위크가 있는  공영치과(government detal clinic) 같은가요?

  ●  그들의 작업공간은 어떻게 보입니까? 모든 것들이 새 것이고 반짝반짝 하나요? 아니면 여전히 거대한 노란색 "TEAM BANANA" 마크를 분할 프틴트로 출력하여 붙여놓고 계십니까? (역자 주 : "TEAM BANANA"는 우리식으로는 "청팀" "백팀" 정도의 흔한 팀 이름입니다. 분할 프린트는 A4 용지를 이어붙여서 큰 그림을 만들 수 있도록 해주는 기능으로 대부분의 프린터가 지원합니다. 별로 돈을 안들이고 만들 수 있지요)

  ●  책상은 어떻게 보입니까? 프로그래머들은 여러 대의 대형 LCD를 사용합니까? 아니면 한 대의 CRT 모니터를 사용합니까? 그들의 의자는 Aeron 제품입니까? 아니면 Staples Specials 입니까? (역자 주 : Aeron은 유명 가구회사 제품입니다. Staples Specials 는 우리식으로 하면 이마트 특별할인제품 정도로 이해하시면 됩니다.)

  제가 잠시동안 유명한 Aeron의자에 대해서 설명드리면, Herman Miller 에 의해서 만들어진 제품입니다. 가격은 약 900 달러 정도 합니다. OfficeDepot이나 Staples의 싸구려 제품에 비하면 약 800 달러 정도 비씨지요.

  이 의자는 싸구려 의자보다 월씬 더 편합니다. 적당한 사이즈의 의자를 잘 조정해서 앉으면 대부분의 사람들은 하루 종일 앉아있어도 불편함을 모릅니다. 등받이와 시트는 망사 형태로, 바람이 잘 통해서 땀이 차지 않습니다. 인체공학적으로 설계된, 고무를 덧된 최신 모델은 매우 뛰어납니다.

  이 의자들은 싸구려 의자보다 오래쓸 수 있습니다. 우리는 6년간의 사업기간동안 모든 Aeron 의자들을 문자 그대로 새 것같이 사용하고 있습니다. 저는 보는 사람마다 2000년에 구입한 의자와 석달전에 구입한 의자의 차이점을 찾아보라고 합니다. 이 의자들은 최소한 10년은 넉넉히 갑니다. 싸구려 의자들은 문자 그대로 몇달 뒤면 부셔지기 시작합니다. Aeron 의자만큼 오래 쓰려면 최소한 네 개의 100 달러 짜리 의자가 필요합니다.

  결국 Aeron의자는 실제로는 10년 이상 사용하는데 500 달러가 드는 것과 같습니다. 1년에 50달러 꼴이고 이는 프로그래머 한 명당 한 주에 1달러의 비용이 드는 것과 같습니다.

  좋은 화장실 휴지도 한 롤에 1달러 정도 합니다. 아마도 여러분 회사의 프로그래머도 일주일에 휴지 한 롤은 사용할겁니다.

  따라서, 프로그래머들의 의자를 Aeron 의자로 업그레이드 해주는 것은 화장실 휴지를 한 롤 더 사용하는 것과 말 그대로 동일한 비용이 듭니다. 제가 단언컨데, 만약 여러분이 화장실 휴지 비용을 올리겠다는 예산 협의회에 올린다면, 그들은 단호히 이렇게 말할겁니다. "쓸데없는 일 하지 마세요. 우리는 다뤄야 할 이슈가 많아요"

  Aeron의자는, 불행히도, 벤처 회사에서 쓰기에는 사치스럽다는 평판으로 빛이 바래 있습니다. 이 의자는 어떻해서인지 닷 컴 버블속에 벤처 투자사의 자금이 낭비되는 일의 부끄러운 상징이 되어버렸습니다. 이 의자는 얼마나 오래 쓸 수 있는지를 생각하면 별로 비싼 것이 아니지만 말이죠. 사실, 의자에 앉아서 하루 여덟 시간을 일하는 것을 생각하면, 심지어 가장 고급 모델을 살 지라도, 고무 받침대와 끝내주는 뒷모습(tailfins)을 갖춘 이 의자를 사용해서 벌 수 있는 돈에 비하여 열라 싼 것입니다.

(4부에서 계속)

[역자 주] 사실, 번역 하는 내내 제 상황이 생각나서 많이 우울해졌습니다. 조엘은 자기 회사에 더 좋은 개발자를 모셔오기 위해서 의자 하나까지도 더 좋은 것을 갖추려고 고민을 하는데, 우리회사는 비용절감한다고 화장실 휴지까지도 더 싼걸로 바꾸고 있거든요. 개발자들이 대접받을 자격이 없는건지, 경영자들이 개발자들을 무시하는 건지... 과연 누가 잘못하고 있는걸까요? 언제나 저를 모셔가려는 사람들이 나올 정도로 뛰어난 개발자가 될 수 있을까요? 어쨌든, 번역은 계속됩니다.


저자에 관하여
Posted by 지그프리드 지그프리드

원문보기

Joel on Software


The new Fog Creek office

 
Monday, December 29, 2008

 - 이전글 보기 : Fog Creek의 새 사무실 - The new Fog Creek Office 1


  소프트웨어 개발자를 위한 위대한 사무실은 두가지 목적을 만족시켜야 합니다. 생산성을 높일 것, 그리고 입사 지원자를 늘릴 것(increased recruiting pull).  프로그래머들에게 제공된  닫히는 문이 달린 개인 사무실은 그들이 코드에 집중할 수 있도록 해줍니다. 코딩을 멈추고 방안의 다른 사람들의 재미있는 대화를 듣는 것을  방지해 주기 때문입니다. 그리고 멋진 사무실은 우리 회사에 지원한 사람들을 열광시키고, 우리회사가 더 매력적으로 보이게 해주고, 우리가 수익성 좋게 프로그램을 만드는데 필요한 뛰어난 개발자들을 고용하고 붙잡아 둘 수 있게 합니다. 이것은 대부분의 다른 소프트웨어 회사들이 기본적은 칸막이 공간 정도를 제공하는 현실에서는 특별한 가치가 있습니다.

 


 새 사무실의 몇가지 특징은 다음과 같습니다.


다수의 밝은 사무실들 : 모든 개발자, 테스터, 프로그램 매니저들은 개인 사무실을 갖습니다. 두 개의 사무실만 제외하고는 모두 밖이 보이는 창문이 있습니다. (다른 두 개의 사무실은 두 개의 유리벽으로 인해 자연광이 많이 들지는 않습니다)

프로그래머를 위해 디자인된 책상 :  작업면 높이를 조절 가능하도록 모터가 달린긴 직선형 책상은 신체에 무리를 주지않으면서 매우 편안합니다. 이 책상 덕분에 여러분은 하루 중 일부는 일어서서 일할 수도 있습니다. 30인치 모니터가 기본으로 제공됩니다. 직선형 책상은 L 자형 책상보다 패어 프로그래밍(Pair programming)과 코드 리뷰에 편리합니다. 모든 책상의 뒷편에는 20개의 전기 콘센트가 있고 대부분의 개발자들은 별도이 컴퓨터를 위한 작은 허브를 갖고 있습니다. 우리의 기본형으로 제공하는 의자는 Herman Miller Aeron 제품입니다. 손님용 의자는 Arne Jacobsen의 유명한 시리즈 7 입니다. 스토리지 받침대(The pedestal storage)는 바퀴가 달려 있고, 쿠션을 올려놓으면 이것도 손님용 의자로도 사용할 수 있습니다.


유리로 된 화이트 보드 : 지우기 쉽고, 아주 잘보이며 얼룩이 남지 않습니다.

커피 바 (Coffee bar)와 식당 : 에스프레소 기계와 음료수로 가득 찬 냉장고, 끝없이 제공되는 주전부리(Snacks), 그리고 맛있는 점심이 매일 제공됩니다. 모두 함께 점심을 먹는 것은 우리회사의 하이라이트 중 하나 입니다.

거대한 해수 수족관  : 이것은 사무실 중심부에 빛과 색을 입혀줍니다.

다수의 회의공간  : 식당에는 프로젝터와 자동 스크린이 있습니다. (주로 Rock Band 영상을 트는데 사용됩니다. Thanks Jeff Atwood) 여기에는 몇개의 작은 회의용 테이블이 마련되어 있고, 두개의 컨퍼런스 룸과 큰 S 형 쇼파가 있습니다.

도서관 : 구식 종이책으로 가득 채워져 있고, 점심 낮잠 자기에 완벽한 두 개의 가죽 안락의자가 있습니다.
 
샤워실  : (바닦과 천정이 대리석으로 되어있음) 덕분에, 사무실까지 자전거로 출근하거나, 일과중에 운동을 할 수 있습니다.

나무바닥으로 된 주변지역  : 덕분에, 스쿠터를 타고 한바퀴 주변 지역을 돌아볼 수 있습니다. 정숙성을 위하여 사무실 바닦에 카펫을 깔았습니다. 식당은 콘크리트 바닥으로 되어있는데, 그편이 환하고 멋지게 보입니다.

저는 이 글 안에 여러분이 새 사무실 공간을 느낄 수 있을만큼 충분히 어울리게 사진을 배치해 넣지는 못하겠습니다. 하지만 Picsa에 Fog Creek 사무실 사진들을 올려두었습니다. 만약 여러분이 최고의 작업공간을 만들기 위해 50만 달러나 투입한 이론적 배경에 관해 배우고 싶으시다면 "A Field Guide to Developers" 를 읽어보세요.

(끝)


저자에 관하여

ps. "A Field Guide to Developers"도 조만간 번역할 예정입니다.
ps2. 번역 글이 올라가는 중입니다. 개발자 생태보고서 1부 입니다.
Posted by 지그프리드 지그프리드


원문보기

Joel on Software


개발자 생태보고서
A Field Guide to Developers

by Joel Spolsky

 
Thursday, September 07, 2006

  - 이전글 보기 : 개발자 생태보고서 1


  어땠든, 저는 "왜 개인 사무실이 소프트웨어 개발자들의 생산성을 향상시키는가?", "단지 주변의 소음을 줄이기 위해 헤드셋을 착용한 프로그래머가 품질이 낮은 결과를 내놓는 현상", "개발자들에게 개인 사무실을 만들어주기 위한 비용이 생각보다 비용이 많이 들지 않는 것" 등에 관한 논의를 다시 할 생각은 없습니다. 이런 것들에 관해서는 이미 말해왔습니다. (역자 주 : 그는 무려 10년 이상 칼럼을 써왔습니다. 그의 책이나 다른 글들을 찾아보세요.) 오늘은 개발자를 채용하는 일과, 채용에 있어서 개인 사무실의 의미에 관하여 이야기 할 것입니다.




  생산성에 관하여 어떠한 생각을 갖고 계시던지간에, 그리고 평등한 작업 공간에 대하여 어떤 생각을 갖고 계시던간에, 다음 두 가지 사실에는 반론의 여지가 없습니다.

  1. 개인 사무실이 더 상급(Higher status) 입니다.
  2. 칸막이나 다른 공용 공간은 (다른 사람과 같이 있어서) 불편합니다.

  이 두가지 사실에 비추어 볼 때 결론은 프로그래머들은 개인 사무실이 제공되는 직장(Job offer)을 더 좋아한다는 것입니다. 특히, 그 사무실에 닫히는 문과, 창문이 있고 전망까지 좋다면 말이죠.

  불행한 점은, 채용을 쉽게 만들어줄 수 있는 이런 일들을 여러분의 권한으로는 할 수 없다는 사실입니다. 심지어 CEO나 창업자도 벤쳐 투자사에 의지하고 있다면, 개일 사무실을 만드는 일에 제제를 받을 수 있습니다. 대부분의 회사들은 5년에서 10년마다 이사를 하거나 배치를 변경시킬 뿐입니다. 작은 벤쳐회사들은 아마도 개인 사무실을 감당하지 못할 지도 모릅니다. 몇몇 아주 혁신적인 회사들이 있는데, 이 회사들은 종종, 10년에 한 번 꼴로 협의회를 열어서 어디로 이사를 할 것인지, 어떤 곳에서 직원들이 일을 해야 하는지에 관해서 결정을 합니다. 이 협의회에는 사무실 매니저들의 비서들과 큰 건축회사의 실무 설계사들 - 이 설계사들은 "열린 공간이 열린 회사를 만든다"는 건축학교의 동화를 믿는 경향이 있습니다 - 이 참여합니다만, 개발자들이나 개발실에는 문이 닫혀있거나 어떠한 의견도 개진할 수 없습니다. 개발자들에게 개인 사무실을 제공하는 것이 사실상 불가능한 이유에 관한 여러가지 변명들만 늘어놓을 뿐이지요. (역자주 : 종종(often)과 10년에 한번 (once every tem years) 가 한 문장에 나오고 있습니다. 말이 안되지만, 원문이 그렇습니다.)

  이것은 일종의 스캔들입니다. 저는 선한 싸룸을 위하여 계속해서 싸워나갈 것입니다. 하지만, 한편으로 보면, 개인 사무실을 제공하는 것은 불가능한 일이 아닙니다. 우리회사는 정규직(Full-time) 프로그래머들에게 그렇게 하고 있습니다. 대부분의 경우, 심지어 사무실 임대료가 세계에서 가장 비싼 뉴욕에서조차도 해냈습니다. 이 개인 사무실이 Fog Creek에서 일하는 것을 좋아하게 만든다는 데는 의심의 여지가 없습니다. 그러므로, 여러분 모두가 계속해서 이 일이 불가능하다고 주장하시겠다면, 그렇게 하십시요. 저는 그냥 개인 사무실을 제공하는 것이 우리회사의 경쟁력있는 장점이 되도록 유지하겠습니다.


(3부에서 계속)


저자에 관하여

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



원문보기

Joel on Software


Fog Creek Compensation System


이전글 보기 : 왜 나는 직원들이 임금협상을 하지 못하게 하는가? - Fog Creek의 보상 체계 1

  - 1부에서 계속
 
  같은 레벨에 있는 모두가 같은 임금을 받기 때문에  - 속임수는 없습니다 -  우리는 종종 어려움을 겪습니다. 우리가 더 높은 보수를 위해 임금협상을 요구하는 직원을 추적할 때, 우리의 임금체계가 자체적으로 갖고 있는 문제점이 드러납니다. 종종 이런 일은 능력있는 직원이 우리의 관점에서는 시장임금보다 높은 급여를 받고 있는데도 불구하고 발생합니다. 또 때때로는  고용될 가능성이 있는 사람이 합당한 정도는 연봉을 높이거나 낮출 수 있다고 생각하기 때문입니다. 왜냐하면 대부분의 다른 기업들은 불명확한 임금체계를 갖고 있어서 협상만 잘 한다면 더 나은 연봉을 받을 여지가 있기 때문입니다. 우리는 보통 이런 상황에서 그가 통상적으로 받게될 많은 액수의 1년차 보너스를 보장한다고 말합니다. 여기서 중요한점은, Fog Creek은 대단히 수익성이 좋고, 또한 우리는 너그러운 이익분배제도(Profit-sharing plan)를 시행하고 있다는 점입니다. 따라서 "보장된 1년차 보너스"란 거의 항상 그 직원이 받게 될 이익분배 보너스보다는 적습니다.

  우리의 임금 체계는 노동시장이 경직됬던(tight : 역자주 : 일자리보다 일 할 사람이 적은 상태) 지난 8년간 동안의 시험을 거쳤습니다. 이유를 알면 쉽습니다. 여러분이 100명의 야크 몰이꾼(yak driver) 을 시간당 10달러에 고용한다고 가정해 봅시다. 하지만, 그렇게 되면 티벳 경제는 과열되게 되고 여러분은 야크 몰이꾼을 찾는데 어려움을 겪게 됩니다. 시장가격은 시간당 15달러까지 올라갑니다. 우유부단한 행동은, 15달러에 신입 직원(Rookies)들을 고용하고, 기존 일꾼들(Seniors)이 신입들이 그들보다 더 받고 고용되었다는 사실을 모를거라는 기대를 하는 것입니다.

  만약 여러분이 잘난척 하면서 HR 은어를 사용하기를 좋아하는 분류의 사람이라면, 이것을 전문용어로 임금역전(Salary inversion)이라고 부릅니다. 임금역전은 조직안에서 분쟁을 야기할 수 있습니다. 또한 이것은 관리자와 인사 그리고 직원들사이의 관계를 완전하게 감싸버립니다(Wrap up) . 이것은 좀 우습게 보이기도 하고, 사이비 같기도 합니다만, 저는 정말로 어떤 대기업의 경영자가 그들의 핵심 직원에게 퇴사후 같은 일에 다시 지원하라고 말했다는 이야기를 들었습니다. 왜냐하면 관료주의가 시장에서 경쟁력 있는 수준까지 그들의 임금을 올려주는 것을 거의 불가능하도록 만들었기 때문입니다. Fog Creek에서는 옳은 일을 하기로 결정했습니다. 우리는 노동시장이 경직되면 같은 레벨의 모든 직원들의 임금을 올려줍니다. 이러한 임금인상은 어렵고 비용이 많이 들지만, 대안은 더 않좋습니다. 여러분은 어떤지 모르겠지만, 전 몽둥이가 무섭습니다.

  저는 우리의  임금 체계가 회사의 이익이 줄어ㄷ느느 것을 막을 수 있다고 보장은 할 수 없습니다. 하지만 저는 직원들이, 임금체계가 투명하고 공정하다면, 그리고 승진을 위해 무엇이 필요한지가 명확하다면, 약간 월급이 적어지는 것은 받아들일 의사가 있다고 매우 확신합니다.

  동시에, 여러분이 임금에 대한 많은 불평을 듣는다면 여러분은 임금체계만 들여다 봐서는 안됩니다. 제가 지난 경험에서 얻은 한가지 교훈은, 행복하고 의욕적인 프로그래머들은 그들이 좋아하는 일을 하고 그들이 어른으로써 대접받고 있다고 느낀다면, 심각하게 불공평하게 임금을 받고 있지 않는 한은 돈에대하여 불평하지 않습니다. 만약 여러분이 임금에 대하여 많은 불평을 듣고 있다면, 제 생각에는 그것은 더 큰 질병 - 직원들이 그들의 일에서 개인적인 만족을 느끼고 있지 못하거나 다른 이유로인해 비참한 상태에 있는  - 의 징후일 것입니다.

  끔찍한 상사나 감옥같은 사무실(Workplace)를 대신하기 위해서는 많은 임금이 필요합니다. 그리고 임금을 조정하기 보다는, 직원들을 행복하게 만들기 위해 비금전적인 방법을 선택하십시요. 행복한 직원들은 더 나은 제품을 만들고, 고객들에게 더 나은 서비스를 제공하며 당신의 회사를 성공하게 만들고 많은 수익을 내도록 할 것입니다. 또한 회사의 성공은 여러분이 직원들에게 더 나은 보수를 지불할 수 있도록 할 것입니다. 이것이 선순환의 고리입니다. 이것은 Fog Creek에 적용되었습니다. 여러분의 회사에서도 잘 동작하는지 알려주십시요.

[사진 출처는 http://www.inc.com/magazine/20090401/how-hard-could-it-be-employees-negotiate-pay-raises_pagen_2.html]
 


(끝)

저자에 관하여

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



원문보기

Joel on Software


Fog Creek Compensation System



Why I Never Let Employees Negotiate a Raise


At Fog Creek Software, every worker at the same level is paid the same salary. And when one gets a raise, they all do



By: Joel Spolsky



  April. 01, 2009


  Fog Creek의 보상 체계


 
왜 나는 직원들이 임금협상을 하지 못하게 하는가?


  Fog Creek Software에서는 같은 수준의 모든 직원들은 동일한 임금을 받습니다. 누군가 월급이 오르면 모든 직원이 같이 인상됩니다.
 


  어느날 당신이 출근했을 때, 휴게실(kitchen)에서 여러분의 직원들의 월급 리스트가 냉장고에 붙어있는 것을 보게된다면 어떤 일이 벌어질까요? 흥분하게 될까요? 여러분의 직원중 절반은 눈물을 흘리고, 나머지 절반은 몽둥이를 들고 (pitchforks : 역자 주 : 원래는 삼지창 처럼 생긴 농기구이나, 문맥상 우리말로는 "몽둥이"가 낫습니다)를 들고 당신 사무실 문 밖에서 기다리고 있는 것을 예상하시나요?

  임금 정보는 특별히 민감하게 받아들여지기 때문에, 고용주들은 이것을 아주 꽁꽁 숨겨둡니다. 어떤 회사는 직원들이 서로 임금을 비교하는 것을 해고 가능한 위반사항으로 정하기까지 합니다. 혹은 표준 고용계약서에 그들의 임금을 공개하는 것을 금지하는 조항을 넣기도 합니다. (미국에서는, 이런 종류의 조항들은 효력이 없습니다. 그런데도 많은 상사들은 그들의 직원들이 이 사실을 모르기를 바라지요). 임금을 비밀로 할때 생기는 문제는, 이것이 보통은 사람들에게 공정하게 임금을 지급하는 것을 피하기 위한 방법으로 사용되기 때문입니다. 그리고 이것은 직원들과 -- 혹은 회사에 좋지 않습니다.

  저와 제 파트너가 Fog Creek Software를 시작했을 때, 우리는 객관적이고 투명한 임금 체계(Pay scale)을 만들고 싶었습니다. 저는 다른 회사의 임금체계들을 조사한 결과, 많은 고용주들이 공식으로 임금을 계산하는 방식(formulaic salary scale)과 회사의 직급체계에 맞춰 일정한 범위를 설정하는 느슨한 방식 사이에서 타협점을 찾으려고 한다는 것을 알게되었습니다. 하지만 저는 이것이 불공평하게 느껴졌습니다. 저는 Fog Creek이 가능한 객관적인 임금체계를 갖기를 원했습니다. 관리자가 임금을 결정할 때 절대로 다른 여지가 있어서는 안됩니다. 그리고 각 레벨애는 동일한 임금만이 있어야 합니다.

  얼마간의 조사 끝에, 저는 Construx라는 시애틀 지역의 소프트웨어 컨설팅 회사가 그들의 웹사이트에 괜찮은 직무체계(professional ladder system)를 공개한 것을 찾았습니다. (여기에서 확인할 수 있습니다) 이것은 저에게 Microsoft의 이전 직무체계를 떠올리게 하였습니다. 제가 거기 있었을 때 꽤 잘 동작했던 시스템 입니다. 우리는 이것을 우리 임금체계의 기본 뼈대로 삼았습니다. 물론, 세부사항은 보강하였습니다. 저는 첫번째 드래프트를 제 블로그에 올리고는 두번째 드래프트를 쓰는데 도움이 된 엄청난 양의 피드백을 받았습니다. 기본 체계는 처음 그대로였습니다.

  Fog Creek의 체계에서는 모든 직원은 레벨을 부여받습니다. 현재, 이 레벨은 8(여름 인턴사원)부터 16(저 : CEO)까지 입니다.여러분의 레벨은 세가지 요소 : 경력, 책임영역, 스킬 셋 - 에 의하여 공식을 이용하여 계산됩니다. 우리가 여러분의 숫자를 결정하고 나면, 여러분은 같은 레벨의 다른 모든 직원들과 같게 됩니다.

  경력 부분은 매우 쉽습니다. 이것은 여러분이 일하고 있는 분야에서 풀 타임으로 일한 연수에의해 결정됩니다. 학교에서 한 일이나, 단순 업무에 의한 경력은 1년 이상은 인정하지 않습니다. 예를 들어, 만약 당신이 리셉션에서 6년동안 일했다면,  당신은 6년 경력을 인정받을 수 없습니다. 저는 단지 1년만 인정할 것입니다.

  영역도 매우 쉽습니다. 당신은 주된 일로써 다른 사람의 일을 돕습니까? 책임지고 있는 당신만의 분야가 있습니까? 아니면 제품 전체를 운영합니까? 우리는 대부분의 직무에 대한 영역점수를 꽤 객관적으로 매길 수 있습니다.
 
  기술을 계량과 하는 것은 약간 더 어렵습니다. 하지만 우리는 초급 프로그래머 (newbie programmer : 소프트웨어 공학의 기본을 배우고있고, 직접 감독(Close supervision)하에 일하며,  제품 코드를 작성하기를 기대하지는 않는다) 부터 숙련된 프로그래머(expert programmer : 작고 큰 프로젝트에서 참여하여 지속적인 성공을 거두었고, 그 프로젝트가 성공하는데 핵심적인 역할을 한다) 까지 공정하고 객관적으로 정의할 수 있게 되었습니다.

  우리의 용어를 정의하고 나서, 우리는 직원들의 경력과 기술과 영역에 따라 레벨을 부여할 수 있는 작은 차트를 만들었습니다.
(표는 여기에 올려져 있습니다.)  그리고 우리는 각각의 레벨에 따른 임금을 정의한  차트를 만들었습니다. 이것이 우리가 직원 한명의 임금을 계산하는 방법입니다.

  일년에 한번, 제 경영팀은 모여 앉아서 모든 직원들의 일을 검토하고 개개인의 레벨을 다시 계산합니다. 그리고 우리는 는 Salary.com 이나 Glassdoor.com같은 온라인 툴을 이용하여 노동시장에서 경쟁력 있는 임금수준을 찾습니다. 그리고는 지난 해 채용을 통해 알게된 구인시장(Job maket)에 대한 우리의 정보를 고려할 때, 각각의 레벨에 대한 임금이 직원들이 계속해서 일하고 싶어할 정도가 되도록 맞춥니다.

 - 2부에 계속 -


저자에 관하여

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


원문보기
By: Joel Spolsky

  Published March 2009


  새로운 비지니스는 단파 라디오와 같습니다. 여러분은 신호가 잡힐 때까지 인내심을 가지고 주파수를 맞춰야 합니다.

  공항 서점의 기업사(business-hagiography) 섹션의 책들 - 아마존(Amazon), 델(Dell), 구글(Google) 그리고 스타벅스(Starbucks)같은 회사들이 다른회사들이 왼쪽(zigged)으로 갈 때 어떻게 오른쪽(Zagging)으로 갔으며 어떻게 그렇게 막대한 수익을 거뒀는지에 관한 이야기들이죠 -  많이 읽다보면 한가지 패턴을 발견하게 됩니다. 이런 책들에 소개되는(profiled) 회사들의 대부분 엄청난 성공을 거둔 케이스이고, 몇몇은 엔론(Enron)같은 종류의 비웃음 거리가 될 정도엄청난 실패  케이스 입니다.

  문제는 이런 기업들중 한가지 모델을 따라하는 것은 쓸데없는 일입니다. 스타벅스의 성공공식 중 어떠한 부분이 수많은 라이벌 회사들이 실패하는 가운데 성공을 이끌어 냈는지 알기 어렵기 때문입니다. 스타벅스의 성공은 정확히 시기에 정확한 방법으로 여러 요소들이 합쳐져서 이루어진 결과입니다. 이중 어떤 요소가 가장 중요한 것인지 알아내는 것은 불가능에 가깝습니다. 아마도 수백 개의 성공하지 못한 커피 체인들의 실패사례를 관찰하고 나서야 무엇이 스타벅스를 구별되게 했는지 관찰할 가능성이 있을 것입니다. 

   투자에 있어서, 성공은 너무 가까이에서 관찰하면서 실패는 전혀 보지 않는 현상은 "패자 배제" (Survivorship Bias : 금융관련 통계에서, 망해버린 회사나 펀드는 더 이상 존재하지 않는 다는 이유로 통계에 넣지 않는 정책을 말한다. 일반적으로, 통계 그래프를 상향 조정, 왜곡하게 된다)으로 알려져 있습니다. 예를 들어, 어디에선가 "펀드 평균 수익률 8.3%" 라는 글을 읽을 때- 제가 방금 만든 겁니다 - 여러분은 이 수익률을 계산할 때 일반적으로 손해가 너무 심해서 파산해 버린 펀드는 계산에 넣지 않는다는 사실을 기억하셔야 합니다.

  몇달 전에는 제 마음속에도 기업에 관한 패자 배제 정책이 있었습니다. 제 회사는 보스톤에서 컨퍼런스를 가졌는데, 저는 제 친구인 제시카 리빙스톤(Jessica Livingston)을 강사로 초청했습니다. 제시카는 작은 앤젤 투자회사인 Y Combinator의 공동 창업자입니다. 이 회사는 두 세명의 괴짜들이 기술 벤처 회사를 시작할 수 있도록 몇천달러의 자금을 제공하는 일을 합니다. 그녀는 30여명의 성공한 벤처사업가를 인터뷰한 "일하는 창업자들" (Founders at Work)란 책을 썼습니다. 그녀가 제게 강연 주제에 관하여 물어왔을 때, 저는 성공한 사람들로 부터 얻을 수 있는 일반적인 교훈이 아닌, 벤처회사가 실패하게 되는 다른(잘못된) 방법들에 대하여 이야기 해주기를 요청했습니다.

  "그건 좀 지루할거에요" 그녀가 말했습니다. "그들은 모두 같은 이유에서 실패했습니다. 그들은 단지 그들의 사업분야에서 일하기를 멈춘거에요." 음, 예. 물론, 그렇겠지요. 대부분의 사람들은 그들의 심장이 뛰기를 멈출 때 죽으니까요. 하지만, 어떤 죽음은 여전히 주당 40시간의 프로그래밍(40 hours a wwek of prime-time programming)을 할 만큼 흥미롭습니다. (역자주 : 마지막 문장은 좀 이상하지요? 주당 40시간의 프로그래밍은 글쓴이의 관점에서 모든 업무를 제쳐둘 만큼 가치가 있다는 뜻으로 쓰인 것 같습니다.)

    그렇지만, 이 문제에 관해서 생각하면 할수록, 제시카가 이야기 한 것을 알 것 같습니다. 왜 벤처회사가 실패할까요? 그녀가 지적했듯이, 그 이유는 일반적으로 의욕(Motivaton)이 상실입니다. 모두들 일상생활도 돌아가고, 벤처회사는 끝입니다. 뻥 소리도 없이, 작은 소리와 함께  사라집니다.

  제시카의 남편이자 Y Combinator의 파트너인 폴 그래함(Paul Graham) 이 주제에 관하여 그의 웹사이트에서 태클을 걸었습니다. "창업자들이 그들의 벤처회사 사업을 접는 가장 큰 이유는 그들이 사기(Morale, 士氣)를 잃기 때문입니다" 그가 웹사이트에 적은 글입니다. "어떤 사람들은 끊임없이 스스로 사기 충만해 집니다.  이런 사람들은 거의 대부분 언제나 성공합니다. 이런 사람들의 반대편 끝에는, 스스로 사기 충만해질 능력이 전혀 없는 사람들이 있습니다. 중간에는 어느정도 사기가 있지만 무한하지는 않은 사람들의 넓은 구간에 있습니다. 이런 사람들은 사려깊은 사기 관리(Morale management) - 와 약간의 행운 - 이 필요합니다.

 - 2부에서 계속 -


 

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 지그프리드 지그프리드

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