[독후감-2012년_1] 조엘 온 소프트웨어를 넘어서

읽은 기간 : 2012.?.? - 9.16

소프트웨어 개발팀은 모두가 다른 일을 하기 때문에 세세하게 관리하려고 들면 ‘차고 빠지기식 시시콜콜 관리 hit and run micromanagement’밖에 안됩니다.

스타벅스에서 카운터를 보거나, AOL에서 전화를 받는 일처럼 따분한 일을 하는 그저 그런 종업원들이 일 잘하는 방법을 스스로 찾을 리는 없습니다.

스타벅스는 고객들이 딱 한 번만 주문하도록 완벽한 시스템을 만들어서 직원들을 교육했습니다. 스타벅스 본사가 만들어낸 이 시스템은 큰 성공을 거두었습니다. 종업원들이 알아서 이런 시스템을 생각해낼 수 있을까요? 절대 못합니다.

관리자라면 시스템을 만들어내야 합니다. 관리자가 왜 돈을 많이 받겠습니까?

보너스나 성과급 지급은 아무 소용이 없습니다. 시스템을 만들어야 하는 관리자들이 돈으로 직원들을 매수해서 직원들을 훈련시킬 책임을 면해 보려는 짓을 하면 안됩니다. 관리자라면 직원들이 일을 잘 할 수 있는 시스템을 만들어 외인동기가 내면동기를 밀어내지 않도록 해야 합니다. 그렇게 하지 않는다면 공포를 조장하거나 명령을 짖어대는 방법이나 다를 게 없다.

 

일체감 관리방법 이 성공하려면 서로를 가족같이 여기는, 결속력이 강하고 끈끈한 조직을 만들어야 합니다. 그렇게 해야 직원들이 조직에 충성ㅎ고, 동료에게 헌신합니다.

그리고, 일체감을 느끼는 직원들이 올바른 방향으로 나아가도로록 필요한 정보를 제공해야 합니다.

 

자바만 가ㅍ르치는 위험한 대학

포인터를 이해하지 못하면, 사실 어떤 운영체제도 이해할 수 없다.

함수형 언어를 이해하지 못하면, 구글에서 엄청난 확장성을 제공한 MapReduce 같은 멋진 알고리즘을 절대 생각해내지 못합니다. <- 포인터와 재귀의 중요성..

포인터와 재귀가 주는 진정한 가치는 따로.

이 2개를 배우다 보면 대규모 시스템을 구축할 때 반드시 필요한 유연한 사고와 포기하지 않는  꿋꿋한 정신 자세를 갈고 닦을 수 있습니다. 이점은 정말 중요. 이 2개를 이해하려면 이성에 따라 판단하고, 추상화하고, 가장 중요하게는 한 가지 문제를 동시에 여러 추상 수준으로 바라보는 능력이 필요합니다. 따라서 이 2개를 이해하는 능력은 뛰어나 프로그래머가 되는 능력과 직결됨.

 

고리타분한 버그수정

http://www.joelonsoftware.com/articles/fog0000000014.html

 

기업 내부용 소프트웨어 프로그래머가 되는 일이 왜 그렇게 거지같을까요?

첫번째, 절대 정도(正道)를 따라 일을 하지 못합니다. 항상 형편에 따라 일을 해야 합니다.

두번째, 프로그램을 웬만큼 쓸만한 정도로 만들고 나면 작업을 바로 멈춰야 함. 핵심 기능이 돌아가고 주요 문제만 해결되면 땡. 더 이상 투자해 봤자 ROI가 안 나온다. 그러니 더 이상 공을 들일 이유가 전혀 없다.

기업 내부용 소프트웨어는 개밥하고 비슷. 개밥을 더 훌륭하게 만들겠다고 돈을 쓰는 사람은 없다. 기업 내부용 소프트웨어는 ‘웬만큼 괜찮게 만들면’ 더 이상 공을 들이지 않아야 합니다.

하지만 제품은 다릅니다. 계속 다듬고, 광내고, 리팩토링하고, 개선해야 합니다. 페이스북에서 일하는 개발자라면 진짜 빠르고 진짜 쿨한 아작스 엔진 기즈모를 최적화하는 일에 한달을 쏟아 부어도 됩니다. 그만한 가칠가 있어요. 이런 노력을 통해 경쟁자보다 더 훌륭한 제품을 만들테니까요.

세번째, 제품을 만드는 회사라면 여러분이 지금 하는 일이 바로 회사 수익과 직결됩니다. 당연히 경영진은 여러분을 세심하게 보살필 수 밖에 없다.

 

큰 그림

http://www.joelonsoftware.com/items/2007/01/21.html

www.dreamingincode.com

소프트웨어 설계보다 어려운 일이, 여럿이 모여서 하는 소프트웨어 설계.

 

선택=골치

Barry Schwartz는 ‘선택의 역설 : 왜 더 많을수록 더 적어지나 The Paradox of Choice: Why More is Less(Harper Perennial, 2005)’에서 더 많은 선택을 제공할수록 사람들은 선택하길 더 어려워하면서 불만이 커진다고 했음.

 

호랑이를 잡으려면 호랑이 굴에 들어가야지

모든 작업에는 ‘싫지만 꼭 해결해야 하는 아픈 문제’가 있다.

포그크릭이 ‘싫지만 꼭 해결해야 하는 아픈 문제’는 고객이 보유한 서버에 포그버그즈를 설치하는 일. 시장은 싫지만 꼭 해야하는 아픔을 해결했을 때만 대가를 지불합니다.

개인이건 회사건 계속 성장하는 유일한 방법은 꾸준히 자신이 잘하는 분야에서 경계를 넗여가는 것입니다.

정말 멋진 일은 여러분이 ‘싫지만 꼭 해결해야 하는 아픈 문제’를 더 많이 풀면 풀수록, 여러분 사업과 시장 점유율이 건실하게 성장한다는 사실.

 

전략서신

성능문제는 무시하고 쿨한 기능을 먼저 만들어서 치고 나갔던 개발자는 긴 안목으로 볼 때 훨씬 경쟁력 있는 제품을 내놓습니다.

 

틀린 코드를 틀리게 보이도록 만들기

사용자가 보낸 문자열은 us(Unsafe String)로 시작하는 변수나 데이터베이스 칼럼에 저장한다. 변환한 문자열이나 안전하다로 검증된 문자열은 s(Safe string)로 시작하는 것에 저장.

코딩 표준이 모든 보안 문제를 해결하는 도깨비 방망이는 아니지만, 없은 것 보다는 훨씬 낫다는 사실만은 분명. 적어도 틀린 코드를 틀리게 보이게 하는 코딩 표준이 꼭 필요.

Apps Hungarian 표기법 : kind(논리적 의미) :  us, s

System Hungarian 표기법 : type(변수 타입) : l, ul, dw  <- 사용X

시모니 작성 문서: http://msdn.microsoft.com/en-us/library/aa260976%28VS.60%29.aspx

위글을 다듬어서 엑셀팀에게 배포했던 더그 클룬더의 글 http://www.byteshift.de/msg/hungarian-notation-doug-klunder

 

Remarkable(고객이 다시 언급할 만큼 훌륭한) 고객서비스로 가는 일곱단계

1. 모든 문제를 두 가지 방식으로 바로잡으세요.

 - 겉으로 드러난 증상만 처리할 뿐 아니라, 발본색원하기

2. 먼지를 불어버리라고 요청하세요

 - 고객에게 직접 뭔가를 확인하라고 요청해야 하는 상황이 닥치면, 설정을 점검하라고 고객에게 지시하지 말고, ‘설정이 제대로 저장되었는지 확인할 수 있게’ 설정을 바꾼 다음 원상 복구해 보라고 말하는게 좋다. Eg. 키보드 꽂았나요? -> 가끔 먼지 때문에 접촉불량이 일어날 수 있습니다. 키보드를 뽑아서 먼지를 불어내고 다시 꽂아 보시겟어요?

3. 고객을 팬으로 만드세요.

4. 비난을 받아들이세요.

5. 불편한 문구를 기억하세요.

 - 사람들이 여러분에게 화내지 않게 해야 한다.

6. 꼭두각시 놀이를 연습하세요

 - 감정이 상하지 않으면서 화난 고객을 상대하는 비법은 딱 하나. 고객은 여러분에게 화난 게 아니라 여러분이 하는 일에 화가 났다는 사실만 깨달으면 됩니다. 내가 회사일을 상징하는 꼭두각시로 생각.

7. 욕심을 내면 얻는 게 없습니다.

 - 고객을 위한 환불정책

8. (덤) 고객 서비스탬 직원에게 진로계획을 제시하세요.

 - 고객과 이야기하는 사람은 굉장히 유능해야 함.

 

출시일 고르기

왜 자세한 일정을 세울까요? 가장 중요한 이유는 자세한 일정이 기능들을 적절히 잘라내 근거를 제공한다는 점.  낮은 우선순위의 기능은 잘라내므로.