원문보기

Joel on Software

점심시간  

Lunch

by Joel Spolsky

 
Thursday, April 28, 2011


 
매일 점심시간을 어떻게 보내십니까? 어디에서 식사를 하나요? 누구와 식사를 하세요? 

  전 매일 팀원들과 점심을 같이 하는데, 정말 멋진 일입니다. 팀의 일원으로 인하는데 매일 함께 점심을 하지 않는다면, 최선의 경우에도 외로움 뿐이죠. 

  많은 대형 IT기업들이 식당을 가지고 있습니다. 가격이 공짜이거나(Google) 저렴합니다(Microsoft). 이런 회사들 안에서 몇몇 팀들은 매일 함께 식사를 하려고 노력합니다. 하지만, 많은 팀들은 그렇지 않습니다. 여러분이 점심시간에 이런 회사들을 돌아다녀 본다면, 몇몇 큰 그룹과, 많은 사람들이 둘씩 함께 먹으며 약속된 "점심 미팅"을 하는 것을 볼 수 있을 것입니다. 하지만, 또한 나홀로 식사를 하는 적지 않은 수의 사람들을 보게 될 것입니다. 아마도 그들은 책을 보거나 그들의 E-mail을 보면서 식사를 할테고, 그렇게 슬퍼 보이지는 않겠지요. 아마도 그들은 점심을 가지고 자기 자리에서 먹기때문에 회사식당에 혼자 앉아 있지는 않을지도 모릅니다. 어쩌면 태생적으로 사람들을 싫어해서 혼자서 먹는 것을 좋아할지도 모릅니다. 또는, 그냥 그렇게 얘기하는 걸지도 모르죠. 

  구글과 마이크로소프트에서는, 회사식당이 너무 붐벼서 혼자 먹는 사람들이 다른 그룹에 끼어 앉아 먹을 수 밖에 없습니다. 종종, 그들이 끼어앉은 그룹의 사람들이 혼자 먹으러 온 사람들을 그들의 대화에 끼어주기 위하여 노력을 하기도 합니다. 보다 많이 보이는 광경은, 혼자 먹는 사람들이 문자 그대로 스마트폰을 가지고 Facebook에 몰두 하고 있는 모습을 보여주어 사회적 접촉을 피하고 싶다는 메세지를 보내는 것입니다. 죄송하게도, 전 여러분에 제 소개 하는 것을 좋아합니다만, 제 페이지를 업데이트하는 것이 너무 중요하네요. 

  어디에서 누구와 점심 식사를 같이 하는가는 제게는 보통사람들이 생각하는 것보다 아주 중요한 문제입니다. 분명하게, 심리학자들이 증언하고, 또 분명하게, 우리의 어린시절, 특히 학창시절, 그중에서도 중학생 시절을 되돌아보면, 어디에서 누구와 함께 식사를 하는 것은 아주아주 중요한 일입니다. 어느 파벌에 속하여 먹는가, 심지어 당신이 그냥 샌님 그룹(Nerd)의 일원이라도, 혼자 먹는 것보다는 훨씬 사람들이 좋아합니다. 혼자먹는 사람들과 괴짜(Geek)들에게는 사람들과 식당에서 함께 식사하는 것도 큰 스트레스 입니다. 

  여러분의 동료들과 함께 식사하는 일은, 제게는, 포기할 수 없는 중요한 일입니다. 이것이 우리가 작은 원탁에 나누어 앉기 보다, 긴 테이블에 함께 앉아 먹는 이유입니다. 이것이 신입이 우리회사에서 일을 시작할 때 식당 한 구석에 떨어져 않는 것이 허락되지 않는 이유입니다. 우리회사에 방문객이 올때면, 그들도 다른 모두와 함께 앉아 먹습니다. 

  심지어 Stack Exchange와 Fog Creek이 완전히 분리된 별개의 회사임에도 불구하고, 우리는 우리의 사무실이 한 건물에 있다는 장점을 이용하여 매일 함께 식사를 합니다. 저는 이런 기회가 있어서 매우 기쁩니다. 많은 사람들이 파벌을 만들어 함께 앉는 경우가 매일 늘어가더라도요. 

  Fog Creek과 Stack Exchange에 많은 사건사고들이 있었지만, 점심식사가 그중의 하나는 아닙니다. 10년전 마이클과 제가 다소 야심찬 "좋은 일터 만들기 (Great work place)" 계획을 만들었습니다. 회사의 첫 날 부터, 함께 식사를 하는 것은 인간미있고 인정이 넘치는 일터를 지향하는 우리의 핵심 가치가 되었습니다. 
 

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


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

Clear 정신 : 영원한 낙관주의

The eternal optimism of the Clear mind

by Joel Spolsky
Tuesday, June 23, 2009

원문보기


  방금,  클리어(Clear)가 문을 닫았습니다.

  문을 닫기 전, 클리어의 사업 방식은 이러했습니다. 200달러로 1년간 회원 자격을 얻습니다. 여러분은 자신이 아주 아주 많이 신뢰할 만한 사람(extra-super trustworthy)이라는 것을 증명하기 위하여 세세하고 많은 배경조사를 받게 됩니다.

  그 댓가로 몇몇 대형 공항에서 교통안전국(TSA : Transportation Security Administration)의 검색대 앞의 줄을 건너뛸 수 있게 됩니다.

  이렇게 해도, 검색 자체를 건너뛸 수는 없었습니다. 여전히 엑스레이를 통과해야 했고, 신발, 벨트, 주머니 속 휴대품, 노프북 그리고 화장실 용품이 들어있는 플라스틱 지퍼백까지 꺼내놓아야 했습니다.

  여러분은 단지 대기열의 맨 앞으로 질러 갈 수 있었을 뿐입니다.

  소수의 사람들만이 가입을 했습니다. 사실, 어떤 공항에서는 대기열의 맨 앞으로 질러가는데 진짜 돈이 더 도움이 되기도 했습니다.

  이것은 클리어의 진짜 사업 계획이 아니었습니다. 진짜 사업계획은 클리어가 여행자들의 세세한 배경조사를 함으로써 아주 아주 많이 믿을 만한 사람들은 보안 검색을 완전히 건너뛰게 하는 것이었습니다.

  실제로는, 교통안전국은 비행기 파일럿들 조차 신뢰하지 않았습니다. 파일럿들도 우리와 마찬가지로 3.5온스 들이 샴푸통 같이특별히 위험한 무언가를 들고 비행기에 탑승하지 않는지 보안 검색을 받아야만 했습니다. 그 이유는, 당연히도, 작은 샴푸 한 병을 가지고도 그들이 폭탄을 만들 수도 있기 때문입니다. 그 폭탄을 이용해서 그들이 조종하는 비행기를 건물로 충동시킬 수도 있겠지요. 제트기 조종석에 앉은 순진한 파일럿들에게는 불가능한 일이지만 말입니다.

  여기서 드러난 것과 같이, 교통안전국은 한번도 검색대를 지나치는 것을 실질적으로 동의한 적이 없었습니다. 결과적으로 클리어가 할 수 있었던 일은 단지 대기열을 건너 뛰는 것 뿐이었습니다.

여기서, 이 점이 재미있는 것인데요, 바로 여기서, 이성적인 사업가라면 이렇게 물을 것입니다. "음, 우리가 진짜로 보안검색을 건너뛸 수 없다면 클리어의 사업 아이디어는 말이 안되는 것 아닌가요?"

  좋습니다. 어쩌면, 대기열의 맨 앞으로 질러가는 것에 요금을 부과했을 수도 있겠습니다. 어쩌면 그들의 사업 모델이 그런 것이었겠죠.

  그렇다면, 왜 여전히 그들이 우리의 배경조사를 하는거죠? 이것은 말이 되지 않습니다.

  사업 환경이 바뀌었습니다. 보안검색을 미리 진행한다는 클리어의 사업 모델은 불가능한 것으로 드러났습니다. 하지만 그들은 어쨌든 그 일을 계속 하고 있었습니다. 어떤 종류의 조직적 기능장애가 환경의 변화를 깡그리 무시하고 손해보는 장사를 계속하게 하였습니까?

  더욱 웃기는 점은, 그들의 사업 모델에서 불필요하고 멍청하기까지한 한 부분만 생략했어도 여전히 수익을 낼 수 있을지도 모른다는 것입니다. 고객의 세세한 배경조사 말입니다.

  클리어에 있는 어느 누구도 생각을 하지 않았습니다. 그들은 사업 모델은 갖고 있었지만, 그 사업모델은 실제로 가능하지 않았고, 모든 사람이 그 점을 알고 있었지만, 여전히 그 일을 부지런히 했습니다. 생각없는 낙관주의지요. 저는 그들에게 경례를 해야 할지 웃어야할지 모르겠습니다.



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


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

원문보기

왜 서킷 시티는 망했고, B&H는 성공했는가

Why Circuit City Failed, and Why B&H Thrives

망해버린 회사들 중 많은 수가 불경기 때문에 끝난 것은 아닙니다.  그 회사들은 한가지 이유로 망했습니다. 바로 고객들을 푸대접 한 것입니다.

Many companies that have gone bust didn't die because of the recession. They failed for one reason: They treated customers poorly

By: Joel Spolsky

Published May 2009

  지난 1월 서킷 시티(Circuit City : 미국 2위의 가전제품 판매 체인. 우리나라의 전자랜드나 하이마트와 비슷한 회사로 파산할 때 우리나라 삼성전자와 LG전자도 미수금이 상당히 있어서 유명해 졌습니다. 관련 기사를 참고하세요) 가 끝장났을 때, 저는 굿바이 세일에 가는 일로 시간낭비를 하진 않았습니다. 무엇보다, 물론 파산 전에도, 서킷 시티에는 쓸만한 물건이 없습니다. 일년 전에 서킷 시티의 모든 노트북을 살펴봤습니다. 제가 본 것은 모두 거대하고, 보기 흉하고, 반짝 거리는 거라고는 "Intel Inside"나 "Vista Adequate(적용)", "Y2K Ready" 같은 스티커 밖에 없는 모델들이었습니다. 게다가, 서킷 시티의 법정관리인이 굿바이 세일에서 많은 상품들의 가격을 올리도록 했다는 글을 소비자 보고서(the Consumer Reports)에서 읽었습니다.

  솔직히 말해서, 저는 서킷 시티에서는 아무것도 사지 않겠다고 생각하진 않았습니다. 주말이면 별 생각없이 가까운 서킷 시티 매장에 들러 밝은 플자즈마 TV로 된 벽면에 마치 나방처럼 이끌렸습니다. 하지만, 정말로 새 TV가 필요하게 되었을 때 저는 서킷 시티의 판매사원이 정말 용감할 정도로 아는 것이 없고 도움이 되지 않는 다는 것을 알고는 베스트 바이(Best buy)로 도망쳤습니다. 베스트 바이에서는 모든 것을 알고 있는 활기찬 20대 젊은이에게 도움을 받았습니다. 나중에 안 사실이지만, 서킷 시티는 2007년 3,400 명의 가장 경험 많은 판매사원들을 해고 하고 그 자리를 거의 최저 임금을 받는 미숙한 일반인들로 대체했다고 합니다.

  그래서, 저에게는 서킷 시티가 망한 것이 놀라운 소식이 아닙니다. 서킷 시티의 CEO는 E-mail에서 해고의 원인으로 "거시경제의 불경기" 를 지목했습니다. 이 견해는 연합 신문사(The Associated Press)에 의해서 "경제 공황의 확산" 때문에 파산하게 되었다고 반복하여 주장되었습니다.
 
  그런데 말입니다, 저는 경제 상황이 서킷 시티의 파산의 원인이라는 주장을 믿지 않습니다. 그들의 경쟁자를 한번 보기만 해도 현재의 경제상황 하에서도 전자 제품과 컴퓨터 관련 시장은 여전히 호황이라는 것을 알 수 있습니다. 애플 스토어에 가보시면 많은 사람들이 컴퓨터와 아이팟을 사기 위하여 줄을 서 있는 것을 보실 수 있습니다. 하지만 애플이 얼마나 뛰어난 회사인지 말하는 것은 이미 충분히 해 온 일이기 때문에, 여러분에게 또 다른 1류 전자제품 유통회사를 소개해 드리려 합니다. 여러분이 뉴욕에 살고 계시지 않거나, 프로 사진작가가 아니거나 열성적인 카메라 애호가가 아니라면 방문할 일이 없을 만큼 작은 회사입니다. 이 회사의 이름은 B&H 입니다.

  B&H는 1974년에 문을 열었습니다. 이곳은 놀라운 곳입니다. 여러분이 맨해튼에 계시다면, 이 매장을 방문해 보셔야 합니다. 34번가 9번 애브뉴에 (Ninth Avenue at 34th Street) 있습니다. 여러분이 아셔야 할 첫번째 특징은 이곳이 활기차다는 것입니다. B&H는 카메라 매장으로 시작해서 모든 종류의 전문가용 오디오, 비디오, 컴퓨터 장비 등 250,000 이상의 상품을 취급하는 회사로 성장했습니다.  이 회사는 상장되어 있지 않고, 언론 홍보도 잘 하지 않아서 얼마나 성공적인 회사인지 알기가 쉽지는 않습니다. 이 회사의 대변인은 "전반적인 경제 상황을 고려해도, 우리의 사업은 아주 잘되고 있습니다." 라고 말합니다. 매장에는 항상 손님들로 가득 차서 수백가지의 카메라 가방과 조합 가능한 모든 렌즈 부품들을 살펴보고 있습니다. 방에는 망원경과 사하라 사막의 모든 개미들을 바삭하게 구워버릴 수 있을 만큼 많은 렌즈들로 가득 차 있습니다. 제가 본 것 중에서 이곳 외에 지붕 아래에 이렇게 많은 장비들이 있는 장소는 도쿄의 아키하바라 전자상가가 유일합니다.

  얼마나 멋진 가게 입니까. 모든 동작(Operation)이 환상적인 윌리 웡카의 초콜릿 공장 같습니다. (crazy Willy Wonka factory : 동화이자 영화인 "찰리의 초콜릿 공장"에 나오는 난장이들이 일하는 초콜릿 공장) 만약 여러분이 전시되어 있지 않은 상품을 원하면, 판매사원은 컴퓨터 터미널을 통해서 지하에 있는 광대한 창고에 주문을 넣습니다. 잠시뒤면 마치 마법처럼, 엘레베이터와 컴베이어벨트 시스템에 의해서 그 상품이 카운터에 도착합니다. 어떤 상품이 마음에 들어서 구입하려 하면, 판매사원은 녹색 플라스틱 상자에 그 상품을 넣어서 다른 컨베이어 벨트에 실어 보냅니다. 그 상자는 여러분의 머리위를 지나서 픽업 카운터로 갑니다. 그곳에서는 다른 점원이 여러분이 산 상품을 가방에 담아줍니다. 그러는 동안에, 판매사원은 지불 카운터에 보여줄 티켓을 줍니다. 값을 치르고 나면 또 다른 티켓을 받는데, 이 것을 픽업 카운터에 주면 여러분이 구입한 상품을 받게 됩니다.

  처음에는 이 모든 것이 너무 지나치다고 생각했습니다. 하지만 이 것에 대하여 좀 더 생각해본 뒤에는, B&H가 일하는 방식에 관해 이해할 수 있게 되었습니다. 비싼 전자제품과 카메라와 렌즈와 노프북들을 가게 안에 떠다니는 동안, 이 시스템은 기본적으로 다섯명의 직원이 각각의 구매에 연관되게 되는 일련의 주문서와 영수증을 만들어내게 됩니다. 이것은 손님들과 직원들이 물건을 훔치는 것을 줄일 수 있습니다. (역자 주 : 이 시스템의 목적이 꼭 도둑 방지 때문인지는 모르겠습니다. 하지만 B&H의 가장 놀라운 점은 제가 다른 상점과 비교할 필요가 없을 만큼 가격이 싸다는 점입니다.

  아니요. 잠시만요. 가장 놀라운 점은 B&H의 판매사원들이 그들의 상품을 정말로 잘 알고 있다는 점입니다. 제가 최근에 휴대용 디지털 녹음기를 구입했을 때, 판매사원은 몇몇 제품이 2GB보다 큰 메모리 카드와 호환이 잘 되지 않는 다는 것을 알고 있었고, 몇 분 동안 인터넷 서핑을 해서는 제가 사려는 제품이 제가 함께 쓰려는 8GB 메모리 카드와 잘 동작한다는 것을 확인해 줬습니다.

  아니요. 잠시만요. 가장 놀라운 점은 제가 어떤 특정 상품을 사려고 B&H에 갈 때 마다 더 싼 제품에 대해서 말해 준다는 점입니다. 예들들어, 한번은 제가 만들고 있는 인터뷰 영상물 촬영에 쓸 휴대용 비디오 모니터를 사려고 B&H에 들렸습니다. 저는 600 달러를 예상하고 있었는데 판매사원이 "값이 싼 휴대용 DVD 플레이어는 어떠세요? 이 것들도 비디오 입력 단자가 있고, 잘 동작합니다. 이건 100달러도 안해요" 라고 알려줬습니다. 이건 우연이 아니었습니다. "우리 매장의 대원칙은 고객 여러분이 사야 한다는 거부감 없이 오셔서 만져보시고, 느껴보시고, 물어보시고, 여러분의 필요에 관해서 토론해 보실 수 있도록 하는 것입니다."  B&H의 웹사이트에 있는 말입니다.

  하지만, 잠시만요. 컨베이어 벨트, 가격, 똑똑한 판매사원, 더 싼 제품을 추천해 주는 것이 거의 법에 가깝다는 점  - 이런 특징들이 진짜로 B&H의 가장 놀라운 점은 아닙니다. 정말로, B&H의 가장 놀라운 점은 B&H의 오너(Owner)가 보수적인 유대인 - 정확히는 하시딤(Hasidim) - 이라는 점입니다. 매장은 유대교 안식일( Jewish Sabbath)을 지키기 위하여 매주 금요일 오후와 유대교 절기(holiday) 에 닫습니다. 게다가, 매출의 70%를 담당하는 B&H의 웹사이트도 같이 닫습니다. http://www.bhphotovideo.com은 제가 아는 한, 매주말마다 25시간을 닫는 유일한 메이져 온라인 쇼핑몰입니다.

  경쟁자인 서킷 시티 같은 회사가 망하는 동안에도, B&H에는 충성도 높은 고객들로 붐비고 있습니다. 그리고 이 점은 저를 매우 행복하게 합니다. 사업가로써, 사기꾼들의 굳바이 세일에서 가격을 올리면서, 시궁창에 처박히는 동안 정직한 장사꾼이 그들의 사업을 확장하는 것보다 기쁜 일은 없습니다. 고객들을 잘 대하는 것은 정말로 좋은 결과로 돌아온다는 것을 알게 하는 좋은 사례 입니다.

(끝)

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



원문보기

Joel on Software



Animoto





By: Joel Spolsky






  Jan. 02, 2009






  Tom이 Fog Creek의 사진들을 가지고 슬라이드 쇼를 만드는 일에 (Jazz up the slidehsow) Animoto를 쓰라고 추천해 줬습니다. 여기 예제가 있습니다.


  Animoto는 아주 간단합니다. 여러분은 여러장의 사진을 선택하고, 배경음악을 선택하면 이 툴은 동영상 프레젠테이션을 만들어 줍니다. 제가 가장 마음에 든 부분은 사진을 넣는 것이 얼마나 쉬운지, 여러분은 웹에서 가장 인기있는 다섯개의 사진 공유 사이트 중 하나를 선택하기만 하면 됩니다. 그러면 그 사이트에 등록한 여러분의 앨범의 리스트를 보여줍니다. 원클릭으로 사진을 가져올 수가 있습니다.



  이 툴은 30초까지는 (약 15장의 사진 까지는 충분합니다) 무료입니다. 더 긴 영상을 원한다면, 저화질 버전에는 3달러, 고화질 버전에는 5달러 입니다. 좀더 많은 수의 동영상을 만들고 싶어한다면 여러종류의 패키지 상품도 있습니다. 저는 이 모든 것이 너무나 간단하다는 점이 가장 인상적이었습니다. 이 툴은 동영상으로 렌더링하는데 정말 오랜시간이 걸려서 - 거의 여러분의 하루를 다 써야할 정도로 - 아주 많은 수정을 해 보기에는 가만히 기다리는데 지쳐 버릴 것입니다.


(끝)


저자에 관하여

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


Want to know more?

You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.


About the author.

I’m Joel Spolsky, founder of Fog Creek Software, a New York company that proves that you can treat programmers well and still be highly profitable. Programmers get private offices, free lunch, and work 40 hours a week. Customers only pay for software if they’re delighted. We make FogBugz, an enlightened project management system designed to help great teams develop brilliant software, and Fog Creek Copilot, which makes remote desktop access easy.


더 알고 싶으십니까?

  여러분은 조엘 온 스프트웨어를 읽고 계십니다. 조엘 온 소프트웨어는 수년에 걸쳐 소프트웨어 개발과 소프트웨어 개발팀 관리, 유저 인터페이스 설계, 성공적인 소프트웨어를  회사 운영하는 것, 그리고 목용탕의 고무오리에 관한 뛰어난 글들로 채워져 있습니다. 

저자에 관하여

  저는 Fog Creek Software의 공동 창업자, 조엘 스폴스키 (Joel Spolsky) 입니다. Fog Creek Software는 뉴욕 소재의 회사로,  프로그래머들을 잘 대우하면서도 여전히 높은 이익을 낼 수 있다는 것을 증명하고 있습니다. 프로그래머들은 개인 사무실과, 공짜 점심과 주당 40시간 근무를 보장 받습니다. 고객들은 소프트웨어에 만족했을 때만 지불하면 됩니다. 우리는 FogBugz - 대단한 개발팀이 뛰어난 소프트웨어를 만들 수 있도록 도와주는 진보된 프로젝트 관리 시스템 입니다 - 와 Fog Creek Copilot - 데스크탑 PC의 원격 조정을 쉽게 해주는 프로그램 입니다 - 을 만듭니다.


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


원문보기

Joel on Software

Solid State Disks

By: Joel Spolsky

  Friday, March 27, 2009


  FogBugz 개발자 중 한명이 컴파일이 너무 느리다고 (약 30초) 불만을 이야기 했습니다. 느린 컴파일 시간 때문에 복도에서의 칼싸움(Sword fights in the hallway) 이 너무 자주 일어난다는 겁니다. (이미지 참조 - http://xkcd.com/303/) 그는 제게 개발자를 몇주간 투입해서 병렬처리를 통해 컴파일 시간을 끌어올릴 방법을 찾는 것이 어떻겠냐고 제안했습니다. 우리는 모두 멀티 코어 CPU와 넉넉한 메모리를 갖고 있으니까요.

  
  저는 문제해결을 위해 비싸고 귀중한 개발자들의 시간을 투입하기 보다는, 먼저 돈을 써보는 것이 더 좋겠다고 생각했습니다. 그리고, 저는 인텔 X25-M SSD에 관한 아난드(Anand Lal Shimpi)의 최신 리뷰를 막 읽었을 때였습니다. 그래서 저는 여기있는 하드디스크 중 몇개를 SSD로 바꿔서 성능 개선에 도움이 되는지 실험을 해보기로 하였습니다.

  첫번째 실험은 FogBugz 월드 투어를 위해 구입했던 18개월된 구형 IBM Thinkpad X61 노트북을 업그레이드 하는 것이었습니다. NewEgg.com에서 160GB Intel X25-M 하드드라이브가 장착된 신모델을 760 달러에 구입했었습니다.

  여러분의 이전 하드 디스크를 메인 부트(Main boot) 하드 디스크를  새 하드디스크로 교체하는 하는 기술은 파티션, MBR, 그리고 데이터를 완전히 똑같이 새 하드로 복제하는 것입니다. 이 기능을 하는 프로그램이 몇가지 있습니다. 오픈 소스 어플리케이션인 Clonezilla가 있습니다만, 이건 여러분의 시간이 무가치할 때만 진짜 공짜 입니다.

  다른 인기있는 상용 프로그램들 중 제가 사용해본 두가지는 Symantec Norton Ghost 14Acronis Migrate Easy 7.0 입니다.

  Thinkpad에서 고스트와 미그레이트 모두 잘 동작하지 않았습니다. 제 생각에는 아마도 Thinkpad의 MBR에 뭔가 특이한 것이 있는 것 같습니다. 하드 드라이브를 복제하기 위해 시도할 때마다, 부팅이 안됬습니다. 하루하고도 반나절을 여러가지 방법으로 해보다가 날렸습니다. 심지어 우반투(Ubuntu) Live CD로 부팅해서 모든 파일을 복사하는 방법까지 해봤습니다만, 소용 없었습니다. (이 방법은 정상적으로 동작하지 않았습니다. 윈도우는 돌아가는 것처럼 보였지만, 많은 작은 부분들이 실제로는 깨져있었습니다.)

  결국, 저는 포기하고 모든걸 다시 설치할 수 밖에 없었습니다. 재미는 없었지만, 지금 전 더 크고 더 빠른 SSD를 장착한 새 노트북을 갖게 되었습니다.

  한가지 장비는 정말로 유용합니다. Thermaltake BlacX Docking Station 입니다. (이미지 참조) 이것은 2.5인치와 3.5인치 SATA 하드 디스크를 통째로(raw) 구울 (toaster)수 있습니다. 어떤 하드드라이브던지 위에 꽂고 USB 2.0으로 PC에 연결하면, 확실히, 여러분의 하드디스크는 연결된 것입니다. NewEgg.com에서 37달러에 살 수 있습니다.


  간단한 벤치마킹 테스트를 해보았습니다. 여기서 나오는 숫자들을 심각하게 받아들이지는 마십시요. 저는 많은 테스트를 해보지도 않았고, 모든 것을 정확하게 테스트하기는 매우 어렵습니다. 부팅 시간은 2:11 에서 0:34로 줄었습니다. 이 시간은 부팅에서 화이어폭스 브라우져로 (Firfox) Goole.com에 접속하는데 까지 걸린 시간입니다. 6개의 메이저 어플리케이션을 시작하는 시간은 20초에서 10초로 줄었습니다. 일반적으로, 프로그램을 구동하는 시간이 빨라지면 엄청나게 큰 차이를 만들어내며, 이것은 완전히 가치있는 일입니다. 이 작은 노트북은 이제 제가 사용해왔던 컴퓨터 중에서 가장 빠른 컴퓨터가 되었습니다.

  제 다음 실험은 메인 데스크탑(Desktop) Dell Optiplex 745를 업그레이드 하는 것입니다. 이번에는 Acronis Migrate Easy가 한번에 완벽하게 동작했습니다. 문자 그대로, 제가 한일은 하드 드라이브를 복제하고, 컴퓨터를 끄고, 새 하드로 바꿔달고, 끝이었습니다. 짜잔~

  갑자기, 모든 것이 빨라졌습니다. 부팅, 프로그램 시작, 심지어 아웃룩(Outlook)조차 1초 안에 사용할 수 있게 되었습니다. 이것은 정말로 대단한 업그레이드 였습니다.

  하지만... 컴파일 시간은, 음, 그리 많이 빨라지지 않았습니다. 컴파일 시간은 30초에서... 30초로 줄었습니다.

  우리가 사용하는 컴파일러는 싱글 쓰레드(single threaded)이고, 아마도 제 추측에는, CPU 관련된 작업이 IO 관련된 작업보다 훨씬 더 많은 것 같습니다. 뭐, 좋습니다. 우리는 아마도 모든 개발자의 데스크탑을 SSD로 업그레이드 할 것입니다. 왜냐하면 컴파일 외에 다른 모든 것을 팔팔하게(snappy) 만드는 것은 그들의 삶을 향상시킬 것이기 때문입니다. 하지만 여전히 컴파일러를 병렬화 하는데 개발자들의 시간을 들여야 한다는 압박은 남아있습니다.
(끝)

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

원문보기
By: Joel Spolsky

  Published March 2009


이전글 보기 : 생존하기는 얼마나 어려운가 : 벤처 회사의 전략 1 (How Hard Could It Be?: Start-up Static)

  그렇다면, 누가 "섬세한 사기 관리" (Careful morale management) 가능할까요? 그리고 이것은 어떤 효과를 발생시킬까요? 제 생각에는, 경영자는 처음으로 단파 라디오를 가지고 노는 아이와 같다고 생각합니다. 아이는 집에서 라디오를 켭니다. 그러면 무슨 소리가 날까요?

아무 소리도 안납니다. 변화가 없습니다.

이건 좀 실망스럽습니다. 그래서, 아이는 다른 주파수를 맞춰봅니다.

아무 소리도 안납니다. 변화가 없습니다.

아이는 또다시 실망합니다. 아이의 어머니가 다가와서 라디오에 안테나를 연결해 줍니다. 그러면 갑자기, 아이는 방송국의 유령을 잡아냅니다! 그 소리는 아주 멀리서 들려오는 것 같고, 또 무언가 말하는 것 같기도 합니다. 어느나라 말일까요? 상관없습니다. 방송국입니다! 안테나 라구요! 누가 알겠습니까? 아이는 컴퓨터로 뛰어가서 블로그에 안테나가 얼마나 멋진 것인지 적을 것입니다.

  이것은 여러분이 새로운 사업을 시작할 때와 비슷합니다. 아이디어가 떠오를 때나 처음으로 매출을 올린뒤 매상이 늘고 있을 때, 여러분은 처음으로 흥분으로 충만하게 됩니다. (이 시기에는 여러분은 열라 재수없습니다. 추수감사절 가족만찬에서 와인을 잔뜩 마시고는 장모님 앞에서 그녀가 당신의 사업 아이디어를 얼마나 무례하게 무시했는지, 그리고 당신이 수백만 달러를 벌었을 때 장모님에게는 일원 한장 안줄 것인지 하나하나 꼽아가며 말하겠지요.

  사업이 진행되어 갈수록, 수신률을 높이거나 여러분이 좋아하는 다른 방송국을 찾기 위하여 라디오의 여러개의 다이얼들을 조작하기 시작하게 될 것입니다. 그리고 운이 좋게도, 사업의 영역에서, 우리 벤처 설립자들은 가지고 놀 수많은 다이얼들을 가지고 있습니다. 가격, 입지, 직원들, 마켓팅, 광고, 보상정책, 무역 전시회, 상품들, 검색엔진 최적화 그리고 여러분의 예산안에 있는 모든 항목들 말입니다.
 
  여러분이 새로운 레스토랑을 열기로 결심했다고 합시다. 여러분은 가게를 임대하고, 그 곳을 테이블로 채우고, 주방을 식재료로 채웁니다. 그리고 여러명의 웨이터들을 고용하고 손님을 자리로 안내하고 예약 전화를 받을 매니저(Host)를 고용하겠지요. 그리고 나서, 개업식 밤입니다. (여기서 카메라 플래쉬 터지는 소리들을 상상해 보세요)

  바로 이순간, 섬세한 사기 관리에 관해서 창립자는 속으로 생각합니다. "아마도, 인력관리 쪽에서 경력을 쌓는 것도 나쁘지 않을거야"  그러는 동안에, 마음을 굳힌 창립자는 다이얼들을 가지고 놀기 시작합니다. 메뉴를 재고하고, 새로운 프로모션을 시도하고, 가격을 조정합니다. 그리고 그가 알게 될 것은 라디오를 켜는 것과 같습니다. 사업의 어떤 영역은 단 하나의 아주 작은 것에 의해서 망할 수 있습니다. 그리고 아주 작은 조정만으로도 "뿅" 하고는 다시 살아나기도 합니다.

  예를들어서, 우리회사 제품 중 하나인 포그 크릭 코파일럿(Fog Creek Copilot)의 판매추이 그래프(Sales Chart)를 보시죠. 처음에는 우리는 하루에 $10로 요금을 부과했습니다.  그러나 고객들은 처음에 카드를 긁거나, 카드 번호 16자리를 입력하거나. 전신환을 이용하여 결제하는 방법으로 계속해서 이 서비스를 받고 싶어했습니다. 그래프의 초록색 선이 나타내듯이, 우리의 매출은 꾸준했지만 눈에 띄는 정도는 아니었습니다. 그때, 2005년 겨울에, 개발자중 한명이 매달 자동으로 과금되는 서비스에 고객들이 등록할 수 있도록 시스템을 만들었습니다. 우리는 이 월단위 종량제가 고객들에게 작은 편이성을 제공하는 것에 불과하다고 생각했습니다. 뚜껑을 열고 보자,우리 대부분이 이 종량제가 가진 임팩트를 과소평가 했다는 것이 들러났습니다. 붉은 선에서 보듯이, 매출이 급신장 했습니다.

  우리가 종량제 방식의 제품으로 코파일럿을 유지했다면 어쩌면 제품을 포기했을 수도 있습니다. 우리는 다른 종류의 소프트웨어를 만들었지만, 우리가 하나의 제품만 파는 상태였다면, 우리도 모든 사람들이 사기를 잃고 망해버린 다른 벤처회사들과 같이 되버렸을 것입니다. 우리가 깨끗한 소리를 듣기까지 얼마나 남았는지도 모른체 말입니다.

  다행이도 그런 일은 발생하지 않았습니다. 우리가 종량제를 시작한 이래로, 그래프에서 보듯이, 그것은 마치 호주 라디오 방송국의 신호를 잡았는데 날마다 그 신호가 선명해지고 강해지는 것과 같았습니다. 우리는 여전히 다이얼을 돌리고 안테나를 움직이고 있습니다. 우리는 최근에 전체 매출 성장률이 올라 갈 것을 기대하고 매월 정액제 가격을 낮췄습니다. 배심원들은 아직도 결론을 내리지 못하고 있습니다. 하지만, 포그 크릭(Fog Creek)이 큰 성공 거둘수 있게 하는 공식을 우연히 찾아내서 여러분이 그 성공담에 관한 책을 공항 서점에서 읽을 수 있는 날이 올때까지, 저는 계속해서 조정을 해 나갈 것입니다.

Joel Spolsky is the co-founder and CEO of Fog Creek Software andthe host of the popular blog Joel on Software. To read his pastcolumns, go to www.inc.com/keyword/spolsky.
(조엘 스폴스키는 Fog Creek Software의 공동 창립자이자 CEO이며 인기 블로그 Joel on Software의 주인장입니다. 그의 지난 칼럼을 읽고 싶다면, www.inc.com/keyword/spolsky 를 방문하세요.)



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/08   »
        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 31
Total : 313,862
Today : 1 Yesterday : 9