JoelOnSoftWare 요약 2

들어가기

JoelOnSoftWare책은 개발뿐만 아니라 팀 관리, 회사 운영에 대해 생각해볼 만한 내용이 많다. 처음에 나와을 때는 현실과 동떨어져 보이는 내용도 많았지만, 최근에는 현실화되는 부분도 있다. 이런 부분을 여러분과 공유하고 싶어서 간단하게 정리해보았다. 저의 주관에 의해 축약하고 정리했기 때문에 왜곡될 수도 있습니다. 자세한 내용은 책을 참고하세요. 개인적 의견은 {...}으로 표시했습니다.

작성자: ospace114@empal.com, http://ospace.tistory.com/

최적화에 애쓰는 개발자들의 노력은 부질없습니다.

성능 문제는 무시하고 쿨한 기능을 먼저 만들어야 긴 안목으로 볼때에 훨씬 경쟁력 있는 제품을 내놓는다.

{ 대부분 성능이 중요한 기능은 생각보다 많지 않습니다. 물론 특정 분야는 예외일 수 있습니다.}

브라우저에 최적화된 코드의 성능 문제는 신경 끄세요.

컴파일러 작성자가 고민할 일이다. OS처럼 웹 브라우저에서도 UI표준이 정의되고 SDK가 제공될 것이다. 빠르게 이동해야 시장에서 살아남는다.

함수로 중복 코드 제거

alert("나는 짜장면을 좋아해!");
alert("나는 짱뽕을 좋아해!");

함수 사용하면 다음 처럼 바꿀수 있다.

function swedishChef(foo){
    alert("나는 " + food + "을 좋아해!");
}
swedishChef("짜장면")
swedishChef("짬뽕");

다음과 같은 코드가 있다면

alert("가재 요리 주문이요.");
putInPot("가재");
putInPot("물");
alert("닭 요리 주문이요.");
boomBoom("닭");
boomBoom("코코넛");

함수를 인자로 넘겨서 사용할 수 있다.

function cook(i1, i2, f) {
    alert(t1 + " 요리 주문이요.");
    f(i1);
    f(i2);
}
cook("가재", "물", putInPot);
cook("닭", "코코넛", boomBoom);

putInPot과 boomBoom을 인라인으로 정의할 수 있다.

cook("가재", "물", function(x) { alert(x + " 끓인다"); });
cook("닭", "코코넛", function(x) { alert(x  + " 졸인다"); });

다른 반복문 예제이다.

var a = [1,2,3];
for(i=0; i<a.length; ++i) {
    a[i] = a[i] * 2;
}
for(i=0; i<a.length; ++i) {
    alert(a[i]);
}

익명 함수로 인자 넘겨서 처리하면

function map(fn, a) {
    for(i=0; i<a.length;  ++i) {
        a[i] = fn(a[i]);
    }
}
map(function(x) { return x*2; }, a);
map(alert, a);

모든 배열에서 하나씩 결합하는 작업도 동일

function sum(a) {
    var s = 0;
    for(i=0; i<a.lenght; ++i) {
        s += a[i];
    }
    return s;
}
function join(a) {
    var s = "";
    for(i=0; i<a.length;  ++i) {
        s += a[i];
    }
    return s;
}
alert(sum([1,2,3]);
alert(join(["a", "b", "c"]);

sum과 join은 같은 일로 공통점을 합친다면,

function reduce(fn, a, init) {
    var s = init;
    for(i=0; i<a.length; ++i) {
        s = fn(s, a[i]);
    }
    return s;
}
function sum(a) {
    return reduce(function(a,b) { return a+b;}, a, 0);
}
function join(a) {
    return reduce(function(a,b) { return a+b;}, a, "");
}

함수를 일등 계급인 프로그래밍 언어를 쓰면 훨씬 더 많은 추상화가 가능하다.

처음 보는 언어로 프로그램을 짜거나 남이 짠 코드를 보면 불가사의 그자체

• 학습 1단계를 거치면 코드가 눈에 들어오면서 코팅 스타일을 역설하기 시작
• 학습 2단계로 들어가면, 코딩 표준도 맞는데 거북한 코드가 보임

프로그래머가 겪는 단계

1. 뭐가 깨끗하고 더러운지 구분 못함
2. 눈에 보이는 깨끗함은 이해하고 코딩 표준을 준수
3. 얇은 껍질 밑에 감춰진 더러운 냄새를 맡음
4. 더러운 냄새를 풍기는 코드가 저절로 모습을 드러내는 코딩 표준을 만드는 경지(진정한 예술)

틀린 코드를 틀리게 보이도록 만들기는 훌륭한 코딩 표준이지만 도깨비 방망이는 아닙니다.

없는 것보다 훨씬 났다는 사실만은 분명합니다.

일반 규칙

• 함수를 짧게 유지하라
• 변수는 쓰기 직전에 정의하라
• 매크로를 남발하여 자기만 아는 프로그래밍 언어로 만들지 마라
• goto를 쓰지 말라
• 중괄호로 묶이는 블록은 한 화면에 다 보이게 하라

언어가 가진 특징으로 코드에 뭔가 감춰진 기능이 있을 수 있다.

i = j * 5

c++ 인 경우는 연산자 재정의로 다르게 해석할 수 있다. 어설픈 추상화는 위험하다.

헝가리언 표기

컴파일러가 유용한 타입 시스템이 없을때 헝가리언 표기법은 C 프로그래밍 시대에는 가치가 매우 컸다. 어느 순간 헝가리안 표기법을 나쁜 것으로 만들어졌고, 변수의 의미를 내포하기보다 단순 타입으로 쓸데 없는 접두사를 사용했다.
강력한 타입확인이 가능한 컴파일러와 인텔리센스로 헝가리안은 상상할 초월할 가치가 있다.

아래 코드에서 cleanup을 호출하려면

dosomething에서 예외가 발생할 수 있다면 던질 수 있는 모든 예외를 찾아내야한다.

dosomething();
cleanup();

확인해야하는 예외 checked exception이 덜 고통스럽게 만들지만, 예외가 말의(?) 궁합을 해치게 된다. 예외로 인해 다른 어딘가 코드까지 확인해야 정확하게 동작하는지 확신할 수 있다.

인간의 약점(눈으로 찾지 못하면 머리가 고생)까지 고려한 단순한 장치야말로 정말 믿을 만한 코드를 만든다.

레이몬드 첸 "cleaner, more elegant, and harder to recognize"에서 나쁜 예외 기반 코드와 나쁘지 않은 예외 기반 코드.

{ 뭐든지 잘 사용하는게 쉽지 않다. 예외도 예외는 아니다.}

스타트업 회사가 시작할 때에 꼭알아야하는 세 가지

1. 제품이 어떤 고객이 가진 어떤 아픔을 어떤 방식으로 해결해서 돈을 버는지 설명하지 못하면 시작하지 마세요.
2. 혼자서 시작하지 마세요. 친구 한명에게 아이디어가 뛰어나다는 확신을 주지 못하면 실패할 가능성이 높다.
3. 처음엔 기대 수준을 낮추세요. 첫달에 몇 백달러도 안될 수 있다. 사업은 장담그는 일이다.

소프트웨어는 개발자와 사용자가 나누는 대화입니다.

이런 대화는 소프트웨어 개발보다 훨씬 더 많은 일을 해야 한다. 개발자는 비즈니스와 동떨어진 추상화된 계층에 있다. 추상화된 계층에 있는 개발자들을 위해 실현 계층이 필요합니다. 코드를 제품으로 만드는 조직이다.
개발자가 개발과 점심 메뉴에 집중하지 않고, 서버, 네트워크, 에어콘을 걱정한다면 실패한 관리이다.

개발자는 코드를 생산합니다.

관리조직은 회사가 코드로 먹고 산다는 환상을 만들어야 한다. 관리 조직의 가장 중요한 임무이다. 마이크로소프트는 이런 추상화 작업을 훌륭하게 수행했다.

네단계 성공 공식을 세워서 5년간 현장에서 직접 검증해봤습니다.

최고 근무 환경 → 최고 프로그래머들 → 최고 소프트웨어 → 수익

어떤 회사 CEO는 프로그래머들은 명령을 수행하는 군대일 뿐이다. 품질 보다는 저렴한 가격으로 소프트웨어는 복제 가능하기 복제본에 비용이 분산된다.

아이젠슈태 교수님은 CS32 강의했던 몇년간 데이터를 분석해다. 그 결과 개발 속도가 평균 3~4배 차이가 발생하고 최대 10배 차이가 났다. 상위 25% 학생의 코드 품질은 과제를 늦게 낸다고 해서 떨어지지 않았다. 시간과 코드 품질간에는 상관관계가 없다.

{ 프로세스로 품질을 올리려고 한다. 근데 프로세스가 제대로...}

위대한 프로그래머 한명 대신에 5명을 사용하면 되지 않을까?

브록의 법칙에 따르면 늦어지는 프로젝트에 사람을 더 투입하면 프로젝트는 더 늦어진다. 팀은 가능한 작게 운영하는게 유리하다.

아무리 5명이 위대한 프로그래머 한명보다 뛰어나지 않다.

소프트웨어 회사는 승자독식 체제이다. 현재 애플말고 MP3 플레이어로 돈버는 회사는 없다. 마이크로소프트 말고 엑셀로 돈버는 회사는 거의 없다.
여러분 제품은 너무 훌륭해야 하고 진짜 재능있는 소프트웨어 개발자만이 고객을 끌여들인다.

제대로된 사무실은 개발자의 생산성을 향상시킵니다.

창문이 있는 죽여주는 개인 사무실은 10배는 더 훌륭한 슈퍼스타를 뽑기가 수월합니다. 사랑하는친구와 가족으로부터 떨어져 지내는 곳이니 훌륭해야죠.

요구사항, 건축가들은 개요라고 함

• 문이 닫히는 개인 사무실
• 프로그러매들에게 전원 콘센트를 많이 제공(책상 위)
• 데이터선은 쉽게 재 배선 가능
• 짝 프로그래밍 할 수 있게 함
• 가끔 먼산을 바라보며 눈을 쉴 수 있게 모니터는 벽 쪽으로 붙지 말기
• 편안한 은신처로 퇴근 후 친구를 사무실에서 만나고 싶은 정도이며 숙식을 해결할 때에 성공함

고객이 직접 소스코드를 수정할 수 있다.

수정한 내용을 알려주면 다음 버전에 반영한다. 이 정책으로 고객은 다음 같은 믿음을 가지길 바랬습니다.

• 포그버즈는 제대로 동작한다.
• 혹시라도 문제가 생겼을 때 당장 해결하지 못해 해고당할 처치라면 직접 고치면 된다.
• 직접 고친 내용이 타당하다면다음 버전 포그버그즈에 반영되고 삶은 좀 더 아름다워진다. 오픈소스의 멋진 장점을 접목시켰다.

80/20 법칙이 있다.

80% 사람들은 20%만 사용하기에 20%만 추려서 구현하면 80%고객이 제품을 사준다라는 최면을 건다.

제한된 자원으로 20%기능만 있는 단순한 제품으로 시장을 진입하는 전략이다. 처음에는 성공적이라도 진입장벽이 낮기에 다른 애플리케이션이 등장하고 "더 많은 기능을 원하는" 인간 본성과 싸워 이길수는 없습니다.

37시그널지와 아이팟은 단순한 제품이지만 여러가지 복합적 요소를 모두 갖췄기에 성공했다.

추종자 만들기, 복음전파, 깨끗하고 절제된 디자인, 감성에 호소하기, 미학, 빠른 반응 시간, 사용자에게 즉각 응답 주기, 사용자 모델에 부응하는 프로그램 모델, 뛰어난 사용성, 사용자가 제품을 지배하는 느낌.

이 기능들은 어느 하나도 단순함만으로는 설명할 수 없습니다.

새로운 기능으로 무장한 새 버전출시는 매출신장에 기여.

단순함 선택은 훌륭하다. 오늘 미니멀리스트 미학이 세상을 휩쓸고 있다. 그렇다고 해서 제품에서 일부러 기능을 빼버릴 생각은 하지 마세요.

우아함이란,

강건함은 물론이고 경제성과 품격까지 갖춘 건축 작품이 자기가 설 자리를 굳건히 지키고, 양끝을 연결하고, 피난처를 제공하면서 '저항하는 연극'을 성공리 마쳤을 때에만 비로소 가질 자격을 얻는 품질입니다.
{ “우아함” 얼마나 울림이 있는 단어인가?}

만약, 품격과 경제성 또는 우아함이라는 뜻으로 단순함이란 용어를 쓴다면 끔찍합니다.

경제성이란 힘을 뜻한다. 경제성이란 기능이다. 반면, 단순함을 힘이 부족하거나 기능이 부족하다는 뜻으로 사용한다면 괜찮다. 그러나 특정인이 문제만 해결하는 제품을 만들면 기회는 줄어든다. 잠재시장 점유율도 곤두박질친다.

처음부터 시작하는 대신에 코드에 덕지덕지 붙은 때를 완전히 벗겨내기 위해 리팩토링 정식에 입각해 몇가지 원칙을 정했습니다.

• 아주 사소하더라도 새로운 기능을 추가하지 않는다
• 체크인 상태인 코드는 언제나 완벽하게 동작해야 한다
• 이 작은 논리에 따른 단순한 변환일 뿐, 코드 동작방식은 변하지 않는다.

처음부터 다시 만드는 대신 광만 내서 얻은 장점은 이렇습니다.

• 훨씬 시간이 적게 들었습니다(처음부터 하면 1년을 49주를 단축)
• 새로운 버그를 만들어내지 않는다
• 필요하면 언제라도 작업을 중단하고 제품을 출시할 수 있다
• 일정을 완벽하게 예측할 수 있다(1주일 하면 시간당 몇 라인을 청소하고 얼마나 걸릴지 예측 가능)
• 새로운 기능을 추가하기가 훨씬 쉬워진다. (3주는 벌고 들어감)

{제가 경험에는 개발 과정에 리팩토링이라는 작업을 해본적이 없다. 음성적으로 할뿐이다.}

불특정 다수 고객이 쓰는 소프트웨어를 베타 테스트할 때 필요한 몇가지 비결

1. 완전 공개 베타 테스트는 제대로 진행되지 않는다. 쓸만한 데이터을 얻지 못한다.
2. 일관성을 유지하려는 인간 심리에 호소하면 확실하게 피드백해줄 베타 테스터를 모집할 수 있다. "피드백과 버그 리포터를 즉시 보내겠습니다."라는 항목을 표시하게 하면 사람은 일관성을 지키려고 하기 때문입니다.
3. 전체 베타 테스트는 적어도 8주에서 10주가 걸린다.
4. 베타 테스트에게 2주에 한번 새로운 빌드를 공개할 수 있으면 정말 잘하는 짓이다. 짧게 빌드를 공개하겠다는 욕심은 버리세요.
5. 베타 테스트 기간동안 적어도 네 번은 빌드를 배포해야 한다.
6. 베타 테스트 기간 동안 아무리 사소하더라도 새로운 기능을 추가하지 말라. 추가하는 순간 시계는 8주전으로 돌아간다.
7. 베타 테스트 지원자 가운데 20%만 피드백을 보냅니다.
8. 저희는 어떤 내용이든 피드백을 보낸 사람에게만 소프트웨어를 무료로 제공합니다.
9. 사용기를 세장씩 써 보내는 진지한 테스터가 적어도 100명은 필요하다. 한사람이 담당할 수 있는 한계이다.
10. 베타 테스터 지원자가 있어도 20%만 실제 제품을 써보고 피드한다.
11. 대부분 베타 테스터는 한번 써보고는 금새 흥미를 잃어버립니다. 베타 테스터를 네 개조로 나눠서 각각 다른 빌드를 배포해야 2주 마다 빌드에 쓸만한 베타 테스트 결과를 얻을 수 있다.
12. 기술 베타판과 마켓팅 베타판을 혼동하지 마세요. 지금까지 작업이 기술 베타판이다. 마케팅 베타판은 언론, 유통사, 집필자에게 나눠주는 사전 배포판입니다. 여기서 쓸만한 피드백은 기대하지 마세요. (집필자들은 무지 많은 피드백을 던질 거고 이를 무시하면 책에다가 문제를 붙여 넣을 겁니다.)

다시 언급할 만큼 훌륭한 고객 서비스 제공이 목표

1. 모든 문제를 두 가지 방식으로 바로 잡으세요. 고객의 당장 닥친 문제만 해결. 발본색원해서 다시는 같은 문제가 발생하지 않도록 하는 예방하는 해결.
2. 먼지를 불어버리고 요청하세요. 고객에서 직접 뭔가 확인하라고 요청하는 경우 지시하지 말고 "설정이 제대로 저장되었는지 확인할 수 있게" 설정을바꾼 다음에 원상 복구해보라고 말하는게 좋다.
3. 고객을 팬으로 만드세요. 고객의 실수로 문제가 생겼을 때 바로 잡아 주면 고객들은 문제가 전혀 없는 경우보다 더욱 만족한다. 대부분 고객은 문제가 생기면 분노를 한다. 전화를 받는 순간 팬으로 바꿀 멋진 기회이다.
4. 비난을 받아들이세요. "제 잘못입니다." 이 두마디가 몇 초만에 감정을 완전히 변화시켰는 알 수 없었습니다.
5. 불편한 문구를 기억하세요. 고객하고 말싸움에 승리했군요. 화내지 않게 하는 가장 좋은 방법은 그 망할 문제를 바로 잡는 것입니다.
6. 꼭두각시 놀이를 연습하세요. 고객은 여러분에게 화난게 아니라 여러분이 하는 일에 화가 났다는 사실만 깨달으면 된다. 여러분은 이것만 고민하면 됩니다. "큰일 났는걸, 꼭두각시한테 무슨 말을 시켜서 저 분을 행복한 고객으로 만들지?"
7. 욕심을 내면 얻는 게 없습니다. 6년 동안 아무것도 묻지도 따지지도 않는 환불 정책을 운영했지만 비용은 고작 2%밖에 늘어나지 않았습니다. 그렇지 않으면 카드회사가 대신 환불해주고 수수료를 챙긴다는 사실을 잘 알고 있다.
8. (덤이요!) 고객 서비스팀 직원에게 진로 계획을 제시하세요. 이로 인해 가시밭길 문제를 해결하는 야심차고 똑똑한 괴짜 직원을 뽑을수 있다.

저는 다음 규칙에 따라 제품 출시 주기를 결정합니다.

1. 아무날에 출시일을 정하세요.
2. 기능 목록을 만들고 우선순위를 결정하세요.
3. 일정이 지연되면 낮은 우선순위에 해당하는 기능을 잘라내서 출시일을 맞추세요.

출시일 세가지 접근법

1. 작은 소규모 출시: XP식 접근법(기업 내부의 적은 고객 대상으로 하는 프로젝트)
2. 12개월에서 18개월 주기로 출시: 수천 수백만 고객을 대상으로 하는 상품 (데스크톱 애플리케이션)
3. 3년에서 5년 주기로 출시: 거대한 소프트웨어 시스템이나 플랫폼에 적합(OS, .NET, 오라클, 모질라 부류)

어떤 고객들은 실험용 생쥐가 되는 일을 싫어합니다.

솔루션을 구입하면 자신 요구를 충족시킨 제품을 손에 쥐기를 바란다. 추가로 원하는 바로 순간 완성된 제품 형태를 원한다. 유료 고객이 많다면 배포 횟수를 줄이는 편이 좋다.

고객 반응을 보려고 시시한 프로그램을 출시한다면 별거 아니란 반응이 돌아옵니다.

5년이 지나도 첫인상을 강하게 기억한다. 별다른 기능, 변경 없이 발표하면 거의 가치가 없다고 판단한다.

고객이 수백만 명에 이르고 통합 대상도 수백만 개에 이르는 시스템이라면 아주 드물게 신제품을 출시하는게 좋습니다.

대부부의 시간을 테스트에 사용된다. 하위 호환성을 위해서는 미친듯이 테스트할 수 밖에 없다. 경쟁 구도에 있다면 언제라도 중간 버전을 출시할수 있어야 한다. 괴상한 문제를 다 잡아내지 못한다.

애플리케이션은 사용자가 동작하기로 기대한 동작방식대로 동작해야 한다는 사용성 철칙을 기억하세요.

매주 변경되면 예측이 불가능하고 사용성도 떨어진다. 변경할거면 한번에 왕창 바꾸는게 더 낮다. 사용자도 직감적으로 조심할 수 있다.

제대로된 가격결정을 해야합니다. 해답은 정말 복잡합니다.

경제 이론 약간

제품 가격이 199달러이고 이때 250개 팔린다고 가정합니다. 가격을 249달로 올리면 200명으로 줄었다고 가정하자. 가격을 149달러로 내리면 저렴하니 325개 팔린다고 한다. 그럼 판매 가격은?
수량 최대가 아닌 수익 최대화하는 수익을 계산해보자. 한 카피 증분 비용이 35달러이고, 처음 개발할 때 매몰 비용(sunk cost)가 20만 달러로 고정 비용이다.

"수량, 가격, 증분비용, 단위수익(가격-증분비용), 총수익(단위수익x수량)"

그래서 총수익을 계산하면 가운데 극대값(local maxima)이 220달러가 된다.
399달러로 구매하고 싶다는 고객이 있다. 이를 고려해서 399달러에서 220달러를 뺀 179달러를 소비자 잉여customer surplus라고 합니다. 고객이 얻는가치입니다. 훌륭한 자본가는 소비자 잉여를 가지질 원한다.

349달러보다 더 내고 싶어하는 40분들까지 합치면 수익도 43,105달러에서 48,523달러로 올라간다. 더 저렴한 99달러 잠재고객 450명, 제값구배 고객 233명을 빼니 217명이 남고 이를 합하면 62,411달러가 증가한다.

이게 고객 세분화의 힘이다. 그럼 고객별로 얼마나 낼 수 있는지 물어보고 그대로 가격을 책정하면 79,550 달러가 됩니다.

고객세분화에 우린 이미 익숙하다.

• 경로우대 할인
• 저렴한 오후 영화 관람
• 기묘한 비행 요금

다른 방식으로 브랜드 세분화도 있습니다. 소프트웨어도 프로페셔널과 홈 버전으로 나눈다. 이는 할인 전략이 할증 전략보다 잘 먹힌다는 사실이다.

지금까지 이야기는 거의 틀렸습니다.

{ 여러분은 놀림을 당했습니다. 저도 놀림을 당했습니다.ㅡ.ㅡ;;;}

고객세분화은 고객을 엿먹이는 것입니다.

고객 세분화는 소비자 잉여를 노략질하는데 유용해도 장기 관점에서는 제품 이미지에 심각한 타격을 준다.

고객이 이를 알아채는 순간에 서로 정보 교환하고 얼마나 싸게 샀는지 금세 알게 되고 여러분은 최저가로 팔 수밖에 없습니다.

소프트웨어 회사가 구사하는 두가지 세분화 작전

• 나쁜작전 #1: 사이트 라이선스
  • 극소수만 사용자당 사용료를 내고 나머지는 고정 비용으로 무제한 라이센스를 이용한다. 무제한 라이센스는 가격 민감도가 제일 낮은 고객들에게 소비자 잉여라는 어마어마한 선물이다.
• 나쁜작전 #2: 돈이 많이 있어요?
  • 오라클 영업 출신의 회사에서 이런 행태를 보인다. 가격을 알고 싶으세요? 문의하세요.
  • 고객이 돈을 얼마있는지 보고 돈을 우려내려낸다. 그렇게되면 돈이 없는 고객을 발길을 끊게 되고, 가격 협상이 가능하다는 냄새를 풍겨도 전세는 바로 역전된다.

현금 보유액이 절대 마이너스로 떨어지지 않도록 전체 미래 수익 흐름의 NPV(net present value)를 극대화해야 합니다.

오늘 100달러와 1년 후 100달러 중에 더 가치있는게 오늘 100달러입니다. 이자율에 따라 할인되고 이를 NPV라고 한다. 그럼 지금 부터 3년 동안 5000달러, 6000달러, 7000달러와 4000달러, 6000달러, 10000달러이면 무엇을 선택하겠습니까? 미래 수입을 할인해도 두번째가 더 좋다.

보통 소트프웨어는 다음 세가지 방식으로 가격을 책정합니다.

1. 무료: 오픈소스류(논의 대상이 아님)
2. 싸게: 10달러 ~ 1000달러(영업조직 없이 싼 가격으로 많은 사람에게 판매, 소비자용 패키지 상품과 중소기업용 소프트웨어)
3. 아주 비싸게: 75,000달러 ~ 1,000,000 달러(몇 달 동안 능숙한 영업팀이 파워포인트질 해야 함. 오라클 방식)

1000달러가 넘어가는 순간 신중한 승인 절차가 등장합니다. 비싼 제품을 구매할때 위험에서 자신을 잘 보호해야 합니다. 비싼만큼 의사결정자들이 멍청하지 않아야하기 때문이다.

저렴한 가격은 풀뿌리 판매 지원 고객들이 많으면 더 팔립니다.
가격은 그때그때 달라진다. 정확한 가격은 시장에 내놓고 팔리는지 볼 뿐이다.

엄청난 사실을 또 하나 알려드리겠습니다.

수요 곡선이 우하향한다는 공리조차 믿을 수 없다. 제품정보를 거의 알지 못하면 보통 비싼 제품이 더 좋다고 믿는다.

P.351 SLA 99.99% 업타입을 보증한다고 하면 1년은 525,949분이기에 1년 다운타임은 52.59분을 넘을 수 없습니다.

그러나 1분이라도 넘어가면 푼돈이 되는 위약금을 물어냅다. 이틀 동안 서비스 중단으로 수천달러 손해를 보았는데 T1제공자는 고작 10달러 돌려줬다. SLA는 의미 없습니다.

일어날 경우가 극히 적어도 모든 것을 미리 생각해야 한다.

인터넷 서비스는 검은 백조 문제로 고통받습니다.

검은 백조는 통계 극단에서 발생하는 값이다. 이런 일에 일반 통계 기법을 적용하는게 말이 안된다. 항공사고가 검은 백조이다. 예측할 수 없다.

스윗스팟sweet spot에 도달하려면

도요타 창업주인 사치키 토요타가 주창한 다섯 단계 왜 기법이 필요합니다.

뭔가 잘못되었을 때에 발본색원할 때까지 계속 왜나고 묻고 같은 문제가 발생하지 않게 하는 방법이다.

외부에 문제의 근원을 밝히고 고객드에게 재발 방지를 위해 최선을 다하겠다는 말과 함께 사과하기로 결정했다. 고객은 언제든지 사용료를 환불해주는 권한을 주는 내용도 포함되었다.

우선순위를 정하기 전에 절대 하지말아야할 짓

• 고객 단 한분에게 약속했다는 이유만으로 기능을 구현하지 마세요.. 고객 맞춤형 개발은 어두운 세계이다.
• 언젠가 해야한다는 이유로 기능을 구현하지 마세요. 지금 당장 해야할 가장 중요한 일을 단호하게 결정해야한다.

회의에 다양한 관점을 가진(고객까지) 최소 20명 정도 모여야 의미있다.

• 각자 생각하는 기능을 적어서 회의실에 참석
• 1회전에 각 기능에 뭔지 공감대를 형성하고 모든 기능을 빼먹지 않고 인덱스
• 2회전에서 기능을 자세히 검토하면서 모든 참가자들이 투표(세표 이상받지 못한면 버림)
• 각 기능에 들어갈 비용 추정(빨리 구현되면 1달러, 무지막지한 괴물은 10달러)
• 개발자들은 소,중,대 결정합니다(버그는 '소', 모호한 기능은 '대')
• 각 기능에 가격을 매긴 메뉴판과 모든 참석자에게 50달러를 주고 선택(5달러기능이 마음에 들면 10달러 내도 되고, 마음에 안들면 1달러 내면 됨)
• 직원들이 각 기능에 얼마낼지 평균지출가격을 산출하고 메뉴판에 있는 가격으로 나눔(가장 높은 지출/가격를 찾음)

목록 중에 정말 아니다 싶은 부분은 바꾸세요. 개발 진행하면서 우선순위를 바꿔도 됩니다.

초기예측시간(E)	4	8	1	8	16	합계
무작위 속도(V)	0.6	0.5	0.6	0.6	0.5
E/V	6.7	16	3.3	13.3	32	71.3

참고

[1] 조엘 스폴스키 지음/이해일 옮김, JoelOnSoftWare, 2009.10.23