37signals logo Getting Real Overview

Buy the book

Buy Getting Real in PDF or paperback.

Job Board

Gig Board

Looking for design, copywriting, or programming help with your project? Check the Gig Board.

Getting Real


소개 chapter 1

Getting Real이란?

성공적인 웹어플리케이션을 만들고 싶으세요? 그럼 이 "Getting Real"을 적용하세요. Getting Real은 보다 작고, 빠르고, 좋은 소프트웨어 구축을 위한 방법입니다.

Getting Real의 이점들

Getting Real은 문제에 봉착했을 때, 아이디어 차원에서 문제를 해결하기보다는 실제 구현의 차원에서 문제를 해결하기 때문에 좋은 결과를 도출해 줍니다. 이것은 현실을 파악하고 처리할 수 있도록 해 줍니다.

Getting Real은 실제의 화면 구현적인 측면에서 함수 정의서나 다른 임시적인 자료보다 앞서갑니다. 기능 정의는 합의한 환상이지만 실제 웹 페이지는 현실이기 때문입니다. 그리고, 그 현실적인 부분이 유저가 실제로 보고 사용하는 것입니다. Getting Real 덕에 중요한 부분을 보다 빠르게 찾아낼 수 있습니다. 바꾸어 말하면, 당신은 추상적인 개념이 아닌 구체적인 것으로부터의 판단을 통해 소프트웨어를 만들어낼 수 있습니다.

마지막으로, Getting Real은, 웹 기반의 소프트웨어에 이상적인 구현 방법입니다. 소프트웨어를 상자에 채우고, 업데이트를 보낼 때까지 1년 내지 2년을 기다리는 방법은 이제 과거의 것입니다. 인스톨 기반의 소프트웨어와 달리, 웹 어플리케이션은 하루하루 기준으로 진화 개량할 수 있습니다. Getting Real은 이런 모든 가치에 대한 혜택에 영향을 줍니다.

< 칼럼> 훌륭한 소프트웨어를 만들려면 …

훌륭한 문장은 간결하다. 문장에 불필요한 말이 들어가지 않고, 단락에도 불필요한 문장이 없다. 같은 이유로, 도면도 쓸데 없는 선이 있으면 안되고, 기계에도 쓸데 없는 부품이 있어선 안 된다. 이를 통해 제작자는 문장을 짧게 만들거나 혹은 상세 설명을 피하면서 윤곽만을 언급함으로도 모든 것을 전할 수 있다.

—From "The Elements of Style" William Strunk Jr. (윌리암 스트렁크)


비대화는 그만

낡은 방식：장황하고, 관료적이고, 우기가 이걸 함으로 해결될 수 있는 프로세스. 흔히 있는 결과：비대화 됨, 평범한 물방울처럼 쉽게 잊혀지는 소프트웨어

Getting Real에 의해 줄일 수 있는 것들...

훌륭한 소프트웨어를 개발하기 위해서, 큰 돈이나 거대한 팀, 또는 긴 개발 사이클은 필요 없습니다. 그런 것들은 대체로 스피드가 늦고, 애매하고, 수정할 수 없는 어플리케이션이 태어나는 것입니다. Getting Real은 반대의 접근 방식을 취합니다.

이 책을 통해 우리는 당신에게 아래와 같은 것들을 보여줄 것입니다.

이 책은 큰 그림을 그리는 아이디어에 초점을 맞추고 있습니다. 당신이 섬세한 코드나 CSS의 트릭으로 수렁에 빠지지 않게, Getting Real 프로세스의 주요 아이디어나 철학을 중심으로 소개하겠습니다.

이 책이 당신한테 적합한 책일까요?

당신은 큰 아이디어에 흥미를 가지고 임하고 있는 기업가, 디자이너, 프로그래머, 기획/마케터 입니다.

당신은 종래의 규칙이 더 이상 적용할 수 없다는 한계를 느낍니다. 해마다 시디롬으로 소프트웨어를 배포하고 있습니까? 2002년도에 출시된 버전의 수가 몇 개나 되나요? 당신은 개발하고, 출시하고, 수정하고. 다시 이것을 정리하고 반복하는 것 입니다.

혹은 애자일(agile) 개발 방법론이나 비즈니스 구조를 확립하지 않았지만, 진지하게 공부하고 싶어하는 사람일 수도 있습니다.

당신이 이러한 사람이라 생각된다면, 이 책은 당신을 위한 책입니다.

Note: 이 책은 주로 웹?어플리케이션 구축을 목적으로 한 내용입니다만, 이 책이 많은 아이디어는, 소프트웨어 개발 이외에도 적용할 수 있습니다. 작은 팀?조직의 개념이나, 신속한 프로토타이핑, 반복의 예측…이라고 한 많은 아이디어가, 기업?집필?웹디자인?음악 활동이라고 하는 수많은 창조적인 활동에 도움이 되는 것입니다.. Getting Real은, 결코 IT 분야의 일부에게만 적응되는 것이 아니고, 한번 이해하면, 인생의 여러 분야에서 그 개념을 응용할 수 있습니다. .


37signals 소개

하는 일

37signals는 단순하고 간결한 소프트웨어를 개발하는 작은 조직입니다. 우리는 그룹의 협업이나 조직 관리에 도움을 주는 제품을 제공하고 있습니다. 350,000명이 넘는 개인과 중소기업에서 우리가 만든 웹 어플리케이션을 활용하고 있습니다. "월스트리트 저널"의 Jeremy Wagstaff 씨는, "37signals 의 제품은, 아름답고 우아하고 직감적으로 사용할 수 있는 심플한 툴로 화면 구성은 마치 고문실과 같은 소프트웨어로 보인다."라는 평가도 받고 있습니다.우리의 제품은 당신을 고문을 가하는 것은 없을 것입니다.

일 처리 방식

요즘 소프트웨어는 너무 복잡합니다. 필요 이상으로 많은 기능에 버튼까지, 게다가 쓰기 위해 익혀야 할 것도 많습니다. 우리 제품에는 일부러 경쟁사 보다 적은 기능을 담았습니다. 보다 똑똑하게, 보다 기분 좋게, 자신의 스타일로 일을 처리할 수 있고, 보다 쓰기 쉬운 제품을 만듭니다.

우리의 제품

우리는 이 책의 출판 시점에 다섯 개의 제품을 판매하고 한 개의 오픈 소스 웹 어플리케이션 프레임워크를 개발하고 있습니다.

Basecamp 프로젝트 관리를 목표한 대로 이끌고 가는 어플리케이션입니다. Gantt chart나, 화려한 그래프, 무거운 현황 기반의 스프레드?시트 대신에, Basecamp는 메시지, To-do 리스트, 심플한 일정표, 협업 문서 작성 및 파일 공유기능을 제공합니다. 수십 만 사용자는 이 제품을 높게 평가하고 있습니다. Salon.com 의 Farhad Manjoo씨로부터 "Basecamp는 웹 소프트웨어의 미래를 대표합니다."라는 말도 받고 있습니다.

Campfire 심플한 비즈니스용 그룹 채팅 툴입니다. 리얼타임의 커뮤니케이션 툴로서 그룹 채팅의 중요성이 인정되어 도입하고 있는 기업도 증가하고 있습니다. 종래의 메시저는 1대 1의 즉석 대화를 하기엔 훌륭하지만 한 번에 세 사람 이상이 대화를 나누기에는 끔찍합니다. Campfire는 이런 문제 뿐만 다른 수 많은 문제를 해결했습니다.

Backpack 개인용 태스크 관리 어플리케이션입니다. Backpack은 "간단한 25단계로 인생을 정리하세요"라고 말하는 혼란스럽고 복잡한 소프트웨어의 대안입니다. Backpack 의 심플한 페이지, 노트, To-do 리스트, 휴대폰/ 메일 기반의 알림 기능은, 지금까지의 아날로그 태스크 관리로 고생을 해결해 줄 수 있는 새로운 아이디어 상품입니다. 월스트리트저널의 Thomas Weber(토마스 웨버)씨는, 태스크 관리 소프트에서는 제일가는 것, 뉴욕타임즈의 David Pogue(데이비드 포그) 씨는, "매우 쿨한" 조직 관리 툴 이라고 언급했습니다.

Writeboard Writerboard를 이용하여 혼자 혹은 다른 사람과 함께 글을 쓰고 공유하고 고치고 비교할 수 있습니다. 지금까지의 번접한 워드프로세서를 대신하는 새로운 문서 작성 도구입니다. Daring Fireball사의 John Gruber씨는 "Writeboard는, 지금까지 본 가운데 제일 알기 쉽고, 심플한 웹어플리케이션이다", 또 웹의 전도사로서 알려진 Jeffrey Zeldman씨는, "37signals는 또 했다!" 라는 찬사를 받았습니다.

Ta-da List To-Do 리스트 정리?온라인 관리 어플리케이션입니다. 리스트는 개인용, 또는 공용으로서 다른 사람과 쉽게 협업할 수 있습니다. 태스크 관리에 이보다 더 간단한 방법은 없습니다. Ta-da List 사용자는 벌써 십만 개 이상의 할 일 목록을 등록했습니다. 세부 항목은 백만 개를 넘습니다.

Ruby on Rails는 개발자를 위한 풀 스택의 오픈 소스의 웹 프레임워크로서 실제의 어플리케이션을 빠르고 쉽게 개발할 수 있도록 해줍니다. 레일즈는 여러분이 아이디어에 전념할 수 있도록 바쁜 일을 처리합니다. "Ruby on Rails는, 놀랄 만한 것입니다. 비유한다면 쿵푸 영화 감상입니다. 여러 개의 바쁜 프레임워크 체제가 작은 신참자를 때려 주려 했으나, 반대로 신참자의 창조적인 다양한 방법으로 얻어 맞는 것과 같은 것입니다."라고, O’Reilly 출판의 Nathan Torkington씨가 코멘트하고 있습니다.

보다 많은 제품과 회사 안내의 자료는 www.37signals.com에서 확인 하세요.


Caveats, disclaimers, and other preemptive strikes

본문에 들어가기 전에 앞서 Getting Real 에 대해 자주 듣는 불만 사항에 대해 먼저 짚고 넘어가고자 합니다.:

"이 테크닉은 우리에게 적합하지 않습니다."

Getting Real은 37signals 의 조직에 꼭 맞는 시스템입니다. 다시 말하면 결코 이세상의 모든 프로젝트에 적용할 수 있는 것이 아닙니다. 만약 당신이 무기 시스템 및 핵 제조 공장, 몇 백만 명의 고객 전용의 은행 시스템이나, 생활이나 금융권의 중요한 시스템을 구축하는 경우는, 우리의 방임주의적인 자세에 주저하겠지요. 그러나 과감히 해 봅시다. 그리고 필요한 대책을 강구하면 좋습니다.

또 Getting Real은 모두 적용해야 하는 것이 아닙니다. 비록 당신이 Getting Real의 전체를 받아 들여지지 않는다고 해도, 그 몇 개의 아이디어를 손에 넣을 순 있을 것입니다.

"37Singals이 Getting Real의 아이디어를 개발하지 않았잖아요."

우리는, 결코 이러한 기술을 발명했다고는 말하지 않습니다. 우리의 컨셉의 상당수는 오랫동안 주위에서 거론되었습니다. 우리가 말하고 있는 내용이 옛날 어딘가의 블로그에서 읽었거나 20년 전의 책에서 읽은 것 같은 것이라고 생각해도 화내지 말아 주세요. 분명히 있을 수 있는 일입니다. 이러한 테크닉들은 모두 37signals의 유일한 것이 아닙니다. 중요한 점은 우리가 일을 어떻게 개선해서 성공으로 이끌었는가 하는 점입니다.

"너무나 흑백논리에서 이야기 하고 있습니다."

우리 어조가 잘난 척 하듯이 들리더라도, 참아 주십시오. 우리는 적당히 얼버무리는 표현보다 분명한 표현 쪽이 좋다고 생각합니다. 그것이 건방지고 오만하게 보인다 하더라도 괜찮습니다. 경우에 따라선 애매한 표현보다는, 다소 도발적인 표현이 좋습니다. 물론 이러한 규칙을 확장하거나 파기해야하는 경우도 있습니다. 그리고 몇 개의 전략은 여러분 환경에는 맞지 않을 수도 있습니다. 여러분의 판단력과 상상력에 맡기십시오.

"우리 회사에서는 적용할 수 없어요."

Getting Real을 적용하기에는 회사가 너무 크다구요? Microsoft조차도 Getting Real을 적용하고 있습니다. (당신의 회사가 Microsoft보다 더 큰지 의심이 되는 군요).

비록 여러분 회사를 통상적으로 큰 조직 구조와 장기 스케줄로 운영하고 있다 하더라도, Getting Real 도입의 여지는 아직 있습니다. 우선은, 큰 조직 단위를 작은 단위로 분해하는 것입니다. 너무나 많은 사람이 관련되는 경우, 실제로는 아무것도 할 수 없습니다. 간결하면 간결할수록 업무를 더 빠르고 더 낫게 수행할 수 있습니다.

Getting Real은 일종의 설득력도 필요합니다. Getting Real 프로세스를 당신의 회사에 적용해 보세요. 동료에게 이 책을 보여주고, 여러분이 짧은 시간에 작은 팀으로 성취할 수 있는 실제 결과를 보여 주세요.

Getting Real이 새로운 컨셉을 낮은 위험, 낮는 비용으로 시험할 수 있는 방법인 것을 그들에게 설명해 주세요. 이 컨셉을 증명할 수 있도록 큰 프로젝트를 작은 프로젝트들로 나눌 수 있다는 것을 보여주시고, 실제 데모 결과를 보여주세요.

혹은, 대담하게 가고 싶다면 스텔스처럼 비밀리에 진행하세요. 레이더에 걸리지 않게 비행한 후 실제 결과의 데모를 하는 겁니다. 이것이 Start.com의 팀이 Microsoft에서 Getting Real을 적용한 방법입니다. "나는 Start.com 의 팀워크를 보았습니다. 그들은 승낙을 구하지 않습니다. 그들에게는 지원 공격을 해 주는 상사가 있었고, 그들은 한 번에 조금씩 예산을 요청하고, 그것을 실행하여 피드백에 대응을 합니다"라고 Microsoft의 기술전도사(Technical Evangelist) 인 Robert Scoble (로버트 스코블)이 얘기합니다.

- Microsoft사의 "Start.com" 도입 예

대기업에서는, 프로세스와 회의는 당연한 절차입니다. 무엇이 고객에게 있어서 "옳은" 것인지에 대한 협의 결과를 도출하기 위한 기능 설계와 상세 안의 협의를 이끌어 내는데도 몇 개월이 걸립니다.

그리하여 딱 맞게 짜여진 소프트웨어는 좋은 접근 방법입니다, 하지만 웹에서는 상상 이상의 이점이 있습니다. 그냥 도입하세요! 그것이 올바로 되었는지 고객의 의견을 들으세요. 만약 올바르지 않다면, 당신에게 고치라고 할 것이고, 여러분이 원한다면 그날 바로 고쳐 적용할 수 있습니다. 고객 목소리보다 더 큰 것은 없습니다. 장황한 회의와 논쟁을 거듭하며 추진하는 방법은 이제 그만하세요. 그냥 적용하고 문제의 핵심을 증명해 보이세요.

실행하는 것보다 말하는 것이 훨씬 쉽다구요?

수 개월짜리 계획은 필요 없습니다.
몇 개월짜리 스펙 기술은 필요 없습니다. 스펙 정의는 기초의 부분에서 끝내고, 상세한 부분은 개발 단계에서 찾아내 개선하십시오. 개발 시작 전에 모든 이슈에 대해 해결하지 않아도 되고, 모든 세부내역을 밝혀 내려고 하지 않아도 괜찮습니다.

적은 기능을 적용하되 품질은 검증하십시오.
많은 기능을 가지고 완전 새로운 개편 형태의 빅뱅 방법론은 필요 없습니다. 고객이 소화할 수 있는 작은 기능만 개발 해 주십시오.

작은 버그가 있다면, 서서히 버그를 잡습니다. 유저의 피드백이 빠를 수록, 결과는 좋아집니다. 아이디어는 계획서 상으로는 좋게 들릴 수 있어도, 실제로는 그렇지 않은 것도 있습니다. 아이디어가 틀리다는 근본 원리를 더 빨리 발견할 수록 좋습니다.

고객의 피드백의 대응이 빨라지기 시작하면, 고객과의 관계가 구축됩니다. 목표는 고객이 원하는 것을 구현함으로써 고객을 확보하는 것임을 기억하세요.

—Sanaz Ahari (사나즈 아하리) 프로그램 매니저 Start.com, Microsoft

출발점 chapter 2

적은 구현(Build Less)

경쟁 상대보다 적은 구현

전통적인 명언은 경쟁 상대에게 이기기 위해서는 그들보다 하나 더 하지 않으면 안 된다고 합니다. 상대의 제품에 4가지 특징이 있다면, 우리는 5개 (또는15개, 또는 20개)의 특징이 필요하다. 상대가 x 만큼의 비용을 사용했다면, 우리는 xx 만큼의 비용이 필요하다. 그들이 20을 가지고 있으면, 우리는 30이 필요하다.

이러한 기능 추가 형의 냉전 발상은 쓸데 없습니다. 이러한 방식은 제품을 만드는데 많은 비용이 들고, 방어적이고, 편협한 방식입니다. 방어적이고 편협한 기업은 앞을 내다보지 못하고 뒤만 보게 됩니다. 그들은 결코 주도권을 쥐지 못하고, 누군가의 흉내를 낼 뿐입니다.

만약 그러한 기업을 만들고 싶은 것이라면, 이 책을 지금 덮어버리는 편이 났습니다.

그러면 무엇을 해야 할까요? 바로 "less (보다 적은)"입니다. 경쟁 상대보다 적게 만들어서, 그들을 이기는 것입니다. 간단한 문제를 해결하고, 어렵고 까다로운 문제는, 다른 이들에게 남깁시다. 1개 기능을 늘리는 것이 아닌, 1개 기능을 줄여 보세요. 더하는 것보다 덜하게끔 시도해 보세요.

이 책을 통해서, 우리는 이 "보다 적은"의 개념을 소개하고 있습니다. 그 전에, 시작하는 분을 위해 "보다 적은"을 설명해 보겠습니다.:


무엇이 당신의 문제인가요?

스스로 소프트웨어를 개발한다.

소프트웨어 개발에 제일 좋은 방법은, 자기 자신의 문제를 해결하려고 하는 것입니다. 스스로 고객 사용자층이 되면, 무엇이 중요하고 무엇이 그렇지 않은가를 알게 됩니다. 거기서부터, 상식의 벽을 깨는 제품의 첫 출발을 하게 됩니다. .

여기서의 핵심은 당신은 혼자가 아니다라는 것입니다. 즉, 당신이 이 문제에 봉착하게 되면 같은 배에 타고 있는 수십만 명의 사람도 마찬가지라는 겁니다. 이것이 당신의 시장 market 입니다. 간단하죠?

Basecamp는, 1개의 문제로부터 시작되었습니다. 디자인 회사인 우리는, 프로젝트에 대해 우리의 고객들과 간단히 커뮤니케이션 하는 방법이 필요했습니다. 우리는 직접 고객을 위한 Extranet을 만들어 적용해 봤습니다. 그러나 프로젝트 갱신이 필요할 때마다 HTML을 수작업으로 처리해야 했기에, 제대로 할 수 없었습니다. 이러한 프로젝트 사이트는 마치 신선미가 없는 느낌이 나버렸고, 결국 그만두게 되었습니다. 일을 부드럽게 해야 할 아이디어가 결과적으로 역효과가 되어, 클라이언트에도 폐를 끼쳐 버린 적도 있었습니다.

거기서, 우리는 다른 방안을 모색하기 시작했습니다. 그러나, 우리의 주위에 있는 툴은 1) 필요로 하고 있는 기능이 없거나 혹은 2) 필요 없는 기능투성이로 (예를 들면 과금, 어려운 접근 방법, 차트, 그래프 등등.) 결국 스스로 만드는 것이 좋겠다라는 하는 결론에 이르렀습니다.

스스로 직면한 문제를 해결할 때, 당신은 열정적으로 그 툴을 개발할 수 있습니다. 핵심 키워드는 열정입니다. 열정은 당신이 정말로 사용하고 싶고, 잘 해 나가고 싶은 그런 것입니다. 그리고, 다른 사람으로 하여금 그것에 대해 같은 열정을 느낄 수 있게 하는 최고의 방법이 됩니다.

가려운 곳을 직접 긁어라.

오픈 소스 진영에서도 오래 전에 이 진리를 깨닫다 — 오픈 소스 진영에서도 "가려운 곳을 직접 긁어라."라고 얘기하곤 합니다. 오픈 소스 개발자에겐 그들이 원하는 것을 직접 구해서 다른 이들에게 그 방법을 알려주면, 더 많은 혜택을 얻을 수 있다는 의미로 통용됩니다.

새로운 어플리케이션의 디자이너 혹은 개발자로서 당신은 매일 수많은 작은 결단을 그때마다 매일 하게 됩니다. 파란색 혹은 녹색? 1개 표 혹은 2개 표? 정적인가 동적인가? 폐기할지 복구할지? 등등 이러한 결단을 어떻게 내면 좋은가? 만약 이것이 중대한 결단이라면 조언을 요청하게 되지만, 나머지는 스스로 예상하지 않으면 안 됩니다. 이러한 자신의 결단이나 예상이 어플리케이션의 일부가 됩니다.

개발자로서 나는 이런 일은 싫습니다. 소프트웨어에 내가 추가하여 넣은 코드들은 작은 수준의 시한폭탄의 스트레스가 됩니다. 가려운 곳을 직접 긁는 오픈 소스의 개발자의 경우, 이러한 스트레스에 고민하지 않습니다. 그들의 유저가 문제의 90%정도는 무엇을 해야 하는지 정확한 대답을 제시해 주기 때문입니다. 그렇기 때문에 회사에서 힘들게 개발을 하고, 집에 돌아가서도 오픈 소스의 프로젝트에 참가할 수 있습니다. 그게 쉬는 것입니다.

—Dave Thomas, 실용주의 프로그래머

필요는 발명의 어머니

Campaign Monitors 의 소프트웨어는 실제 필요에 의해 만들어졌습니다. 몇 년 전부터 우리는 e-Mail 마케팅의 방법에 대해서 여러 가지 고민하고 있었습니다. 어느 툴은 x와 y는 할 수 하지만, z는 할 수 없었고, 또 다른 툴은 y와 z는 할 수 있지만, x는 할 수 없었습니다. 우리는 결코 만족할 수 없었습니다.

결국 우리는 시간을 들여 우리가 원하는 환상적인 e-Mail 마케팅의 툴을 만들기로 했습니다. 우리는 굳이 모두가 사용할 수 있는 툴보다는 우리와 우리의 고객이 보다 편리해지게 끔 되는 툴을 만들기로 결정했습니다.

그러면서 알게 된 것은 기존의 제품들의 기능에 대해 만족하지 못하는 것은 우리 외에도 많다는 것이었습니다. 우리는 어떤 디자인 회사라도 사용할 수 있도록 소프트웨어를 조금 수정하였고, 소문은 퍼지기 시작하였습니다. 6개월이 되기 전에 수천 명의 디자이너들이 Campaign Monitor를 사용하여 그들의 고객들에 email 뉴스레터를 발송하게 되었다.

—David Greiner, 창업자, Campaign Monitor

신중해져야 한다

책을 쓸 때는, "재미있는 이야기"이상의 것이 필요합니다. 이야기를 전하려는 열정이 필요하며, 어떤 방식으로든지 약간의 개인적인 투자도 필요합니다. 2년, 3년 혹은 여생을 같이 살아야 한다고 생각해 보세요. 신중해질 수 밖에 없습니다.

—Malcolm Gladwell, (from A Few Thin Slices of Malcolm Gladwell)의 저자

스스로 투자하라.

투자 유치는 차선책이다.

사업을 시작한 후 초기의 최우선 사항은 대부분 투자가로부터의 자금 투자입니다. 하지만 외부로부터 자금을 투자 받기 시작하면, 그들의 요청에 따를 의무가 생긴다는 것을 잊지 마세요. 기대는 높아지고, 투자가는 조속한 자금 회수를 원합니다. 안타깝지만, 이러한 요구로 인해 제품의 수명이 짧아지는 경우도 있습니다.

최근에는 사업 운영에 필요한 자금이 그렇게 많이 필요하지 않습니다. 하드웨어는 저렴해 졌고, 인프라 부분의 소프트웨어는 대부분이 오픈 소스로 무료로 구할 수 있습니다. 무엇보다도 열정은 돈과 바꿀 수 없는 중요한 것입니다.

자신의 손안에 있는 자금만으로 완성할 수 있는 것을 시작하세요. 심사 숙고해서 무엇이 실제 필수적이고, 없어도 되는지 결정하세요. 10명보다 3명이 무엇을 할 수 있을까요? 1억 원보다 2천만 원으로 무엇을 할 수 있을까요? 6개월보다 3개 동안 무엇을 할 수 있을까요? 직장을 가지고 있으면서도, 정말로 만들고 싶은 어플리케이션을 자유시간에 추진하려면, 어떻게 하면 좋을까요?

제약으로부터 창조는 이루어집니다.

한정된 자원으로 시작할 경우 제약에 따른 압박감이 점차 강해집니다. 이것은 좋은 현상입니다. 제약은 곧 혁신을 불러 일으킵니다.

제약이 줄 수있는 또 하나의 이점은 아이디어를 미루지 않고 보다 빠르게 실행할 수 있도록 해준다는 것입니다. 시작 시점 후 1 개월 혹은 2 개월 후에 그 아이디어로 잘 해 나갈 수 있을지를 알 수 있게 됩니다. 만약 잘 할 수 있다고 판단될 경우 외부 투자 자금이 없어도, 스스로 계속해 갈 수 있습니다. 만약 아이디어가 형편 없다면, 다시 원점으로 되돌아 갑시다. 수 개월 또는 수 년 후가 아닌 지금 길을 갈 수 있게 됩니다. 그리고 쉽게 되돌아올 수도 있습니다. 탈출 계획이라는 것은 투자자가 개입되면서 책임을 피하기 위해 생겨난 말입니다.

만약, 눈앞의 이익을 위해서 소프트웨어를 형편없이 만들면, 금방 티가 납니다. 그렇기 때문에 당신 및 고객이 오랫동안 사용할 수 있는 품질 높은 툴을 만드는 것이 중요합니다.

2가지 방법

[Jake Walker(제이크 워커)는 투자가로부터의 자금을 받아 Disclive라는 회사를 설립하고, 자신의 자금으로는 The Show라는 회사를 또 하나 설립하였습니다. 그 두 개의 방법의 차이가 무엇인지 그 차이점을 들어봅시다.]

첫번째 회사[Disclive]는 : 문제의 근본은 모두, 자금 융통 그 자체가 아니고, 그 돈에 대한 여러 가지 소문에 대한 것입니다. 기대는 정말이지 높습니다. 직원끼리 급여에 대해 이야기하기 시작하고, 제품을 만들어 파는 것이 모티베이션이라는 둥, 혹은 초기 투자자가 그들의 투자금을 회수하기 위한 조치를 취할 것이라고 얘길 하기도 합니다. 첫 번째 회사의 경우에 대해 우리의 목적은 회사를 크게 보이게 하는 것이었습니다. 전혀 불필요한 것이었지요.

후자의 회사[The Show]는 : 우리는 보다 적은 비용으로 약간의 시간만 더 투입하면 보다 나은 제품을 만들 수 있다는 걸 깨달았습니다. 그리고, 우리는 사람들이 바로 구매하기보다는, 좋은 품질을 위해 약간 기다려줄 수 있다는 것에 우리가 가지고 있던 자금을 투자하여 모험을 해 보았습니다. 그리고 회사는 아직도 소규모입니다 (이 자세는 향후도 계속해 가겠지요) 그 최초의 프로젝트 이래 우리는 스스로 여태껏 외부 자금투자유입 없이 자체 자금으로 운영할 수 있었습니다. 벤더와의 계약을 약간의 창의적으로 함으로써, 큰 돈을 들이지 않고도 운영할 수 있었습니다. 성장하고 판매가 늘어남은 물론, 재무적으로도 성정하고 이익을 계속 내는 형태로 유지되었습니다.

— Signal vs. Noise의 교훈

일정과 예산은 고정시키고, 범위를 유연하게 하세요.

예산과 일정 범위 내에서 완료하세요.

일정과 예산 범위 내에 프로젝트를 완료하는 간단한 방법을 소개합니다: 결정된 것을 지킨다. 문제에 대해서는 시간이나 돈으로 해결하지 말고, 단지 범위를 축소한다.

이런 전설이 있습니다. : 우리는 일정, 예산, 범위 내에 완료할 수 있다. 하지만 이것은 품질을 떨어뜨리지 않고는 불가능하다.

모든 것을 계획된 일정과 예산안에서 해결할 수 없다 하더라도, 절대로 일정과 예산을 늘리지 말고 범위를 축소시키세요. 향후 이러한 기능을 포함시킬 시간은 언제든지 있습니다. 나중은 끝없이 영원하고 지금은 쏜살 같이 지나갑니다.

비현실적인 마법 같은 시간, 예산, 범위로 헛점투성이의 싸구려 결과물을 만드는 것보다도 계획보다 범위가 축소되어 보다 작게 시작하는 것이 낳습니다. 그런 마법은 마술사 후디니(역주: 세계최고의 탈출 마술사, 1874-1926)에게나 맡기세요. 제대로 된 제품을 시장에 공급하는 것이 현실 세계의 비즈니스입니다.

시간과 예산을 고정시킴으로써 얻을 수 있는 효과에 대해서 알아보겠습니다.:

우리가 추천하고자 하는 것은: "범위를 축소시켜라"고 하는 것입니다. 그것이 비록 반쪽 기능의 제품이라도, 형편없는 전체 기능의 제품보다는 낫습니다. (뒷장에서 자세하게 설명하겠습니다.)

1, 2, 3 ...

어떻게 프로젝트가 예정보다 1년이나 지연될 수 있을까요? 하루에 하나씩 하는 겁니다.

—Fred Brooks, 소프트웨어 엔지니어 및 컴퓨터 공학가

라이벌을 만드십시오.

맞서 싸우세요.

당신의 어플리케이션이 어떤 모습일까 생각하는 최상의 방법은 반대로 생각하는 것-'어떤 모습이 되어서는 안되는가?'입니다. 라이벌의 어플리케이션을 분석하고, 당신이 어느 방향으로 가야 할 것인가에 대한 이정표를 수립하세요.

우리는 Microsoft Project가 너무나 고릴라 같이 거대 했기 때문에 프로젝트 관리 소프트웨어를 새롭게 개발하자고 의사 결정을 했습니다. 고릴라에 맞서는 두려움 대신 이것을 동기부여의 기회로 이용했습니다. 그 때문에 우리는 BaseCamp를 MS Project과 대비하여 무엇인가 색다른 것이 필요로 했습니다.

프로젝트 관리란 차트, 그래프, 리포트 및 통계치에 대한 것이 아닌, 바로 '커뮤니케이션' 이라는 것을 깨닫게 되었습니다. 그것은 PM이 단숨에 만들어 일방적으로 배포하는 것이 아니라, 프로젝트가 추진되기 위해 서로가 각자의 책임에 대해서 사람들이 서로 얘기하는 것이었습니다.

우리의 적은 프로젝트 관리 독재자와 그가 휘두르는 채찍입니다. 우리는 프로젝트 관리에 민주화 혁명을 일으키고 싶었습니다 - 고객을 포함하여 구성원 모두 동일하게 참가할 수 있는 프로젝트 툴로 말입니다. 프로젝트는 모두가 각 프로세스에 대해 오너십/책임감을 가질 때 보다 더 좋게 변화됩니다.

"WriteBoard" 때도 우리는 이미 경쟁사가 소위 많은 전문 특징에 노력을 기울이고 있던 것을 알고 있었습니다 그래서 오히려 우리는 반대로 요란하지 않는 점을 강조하기로 결정했습니다. 우리는 불필요한 기능은 버리고 사람들이 간단하게 아이디어에 대해 공유하고 협업할 수 있는 어플리케이션을 개발했습니다. 우리는 서비스 출시 3개월만에 10만개가 넘는 Writeboard가 만들어졌습니다.

"Backpack"을 개발할 때 우리의 우선순위는 작은 구조와 엄격한 규칙이었습니다. 사용자는 스스로의 정보를 스스로의 방식으로 자유롭게 정리할 수 있어야 하며, 사용자에게 정형화된 여러 화면이나 과다한 입력을 요구해서는 안됩니다.

라이벌을 가지고 있다는 것의 또 다른 이점 하나는 매우 분명한 마케팅 상의 메시지를 가질 수 있는 것입니다. 사람은 결전에 대해 열광합니다. 그리고 그들은 경쟁사와 비교를 통해 제품을 이해합니다. 다른 라이벌과 함께 그들에게 그들이 듣고 싶어하는 이야기를 할 수 있습니다. 당신의 제품을 보다 빠르게 많이 이해할 것이며, 그들은 선택할 것입니다. 이것이 그들의 관심과 열정을 더 높여줍니다.

반대로 경쟁을 너무 의식해도 오히려 좋은 결과가 나오지 않는다는 것 역시 중요합니다. 타사의 제품을 너무 분석하면 자신의 생각이 틀에 갇혀버리게 됩니다. 주위를 둘러 본 다음, 당신 자신의 시점과 자신의 비전과 자신의 아이디어를 가지고 진행하십시오.

선구자의 따르지 마라.

마케터(혹은 모든 사람은)는 선구자를 따라서 하라고 훈련 받습니다. 그러나 경쟁 상대의 강점을 알아내고, 이를 경쟁사보다 빠르고 싼 가격으로 승부하기 위해 노력하는 것은 인간의 본성입니다. 문제는 한 소비자가 다른 사람의 이야기를 듣고 거짓말을 믿고 산 경우, 그 소비자는 그것을 또 다른 소비자에게 같은 방식으로 전개합니다. 그리고 그들은 그들이 틀렸다는 사실을 싫어합니다.

중요한 것은 당신은 전혀 다른 이야기를 해야 하고, 이것이 그들이 지금 믿고 있는 사실보다 중요하다는 것을 설득시켜야 합니다. 경쟁 상대가 신속할수록, 당신은 싼 가격으로 승부해야 합니다. 경쟁 상대가 건강을 이야기하면, 당신은 편리함을 이야기 해야 합니다. x/y축 기반의 "우리가 더 저렴합니다."라고 외치지 말고, 이미 들어 알고 있는 사실들과 차별되는 실제 이야기를 해주세요.

—Seth Godin, from Be a Better Liar)의 작가/기업가

무엇이 근본의 문제인가

직면한 문제에 대한 가장 민첩한 해결 방법은 바로 경쟁사는 무엇을 하고 있는지 보는 것입니다. 이것은, 특히 우리의 서비스인 BlinkList로 몸소 체험했습니다. 우리가 서비스를 시작했을 때, 벌써 10여 개나 되는 소셜 북마크의 서비스가 있었습니다. 상세한 특징 비교를 온라인으로 내는 사람도 나오기 시작했습니다.

그러나, 이런 경쟁으로 머리가 가득한 상황에서는 자칫 길을 잘못 갈 수 있습니다. 우리는 큰 비전에 집중했고, 항상 스스로에게 물어 보았습니다. - "무엇이 우리가 해결해야 할 문제인가, 그 문제를 어떻게 해결해 나가야하는가?"라고.

—Michael Reining, 공동 창업자, MindValley & Blinklist

잡일을 만들지 마세요.

당신의 열정과 갈망이 길을 비추리라...

어플리케이션이 작을수록 해야하는 일이 작아집니다. 프로세스를 즐기기 위해서라도 그것을 작고 관리가 가능하게 작게 유지하세요.

만약 당신의 어플리케이션에 재미가 없다고 느끼면, 무엇인가 문제가 있는 것입니다. 만약 당신이 단지 돈을 위해서 일을 하고 있다면, 금방 표시납니다. 이와는 반대로 당신의 어플리케이션에 열정을 느낀다면, 그것은 최종 결과물에 묻어납니다. 사람들은 이 두 문맥을 이 차이를 바로 느낄 수 있습니다.

열정을 보여주세요.

디자인에서는 결과의 의미가 대단히 주관적이기 때문에 애매모호한 일도 종종 있으나, 정열의 차이도 극명합니다. 제품의 디자인은 흥미를 갖게 하거나 시시함을 안겨주거나 둘 중의 하나입니다. 두 경우 모두 그것을 제작할 때의 노력을 예측하는 것은 어렵지 않습니다.

열의는 물론 바로 즉시 표현되고, 냉담도 역시 잊혀지지 않습니다. 진짜 열정에 싸여 일을 추진하지 않으면, 아무리 정성들여 만들고 매력적으로 디자인되어 있다 할지라도 이것은 숨길 수 없는 공허함이 되어 버립니다.

—Khoi Vinh, Subtraction.com

빵집

지금의 미국의 비즈니스는 그야말로 아이디어를 개발하고, 그것을 유리하게 잘 만들어 판매하여, 이것이 수익을 내고, 확장하거나 다각화 하는 것입니다. 이것이 모든 초기 사업의 전부입니다. 내 아이디어는 이렇습니다. : 즐겁게 빵을 구워, 사람들에게 팔고, 사람들이 이것을 좋아하게 되면 더 많이 팔 수 있습니다. 그리면 빵집은 계속 유지하여 좋은 음식을 만들 수 있고, 이로 인해 사람들은 행복해지게 됩니다.

—Ian MacKaye, member of Fugazi and co-owner of Dischord Records
(from Salon.com People | Ian MacKaye)

Stay Lean chapter 3

"보다 작은"규모

가벼울 수록, 변화하기가 쉬워집니다.

T사물이 크면 큰 만큼, 그 방향을 바꾸는데 막대한 에너지가 필요하게 됩니다. 물리의 세계뿐만이 아니라, 이것은 비즈니스의 세계에도 적용되는 사실입니다.

그것이 웹 테크놀로지의 이야기가 되면, 변화는 보다 간단하게, 보다 저렴하게 실시할 수 있습니다. 만약 변화의 스피드를 따라갈 수 없어지면, 다른 누군가가 그것을 가로채갈 것 입니다. 이것이 작은 규모를 제안하는 이유입니다.

규모가 커지는 요소는......

반대로, 규모를 작게 하기 위해서는 ...

작은 규모는 방향 변경을 쉽고 신속하게 할 수 있습니다. 반응과 진화가 가능합니다. 좋은 아이디어에만 집중할 수 있고, 나쁜 것은 Drop 시킬 수 있습니다. 고객의 소리에 귀를 기울여 대답할 수 있습니다. 새로운 기술을 뒷전으로 하지 않고, 바로 도입할 수 있습니다. 항공모함이 아니고, 쾌속선으로 가세요. 이러한 사실을 즐기세요.

예를 들면, 적은 기능으로 보다 적은 소프트웨어를 만드는 군살 없는 소규모의 회사를 상상해 봅시다. 한편, 많은 기능으로 많은 소프트웨어를 판매하고 있는 대기업도 상상해 봅시다. Ajax 와 같이 새로운 기술, 새로운 컨셉의 것이 등장하게 되면, 어느 쪽이 보다 신속히 제품에 도입할까요? 후자와 같은 대규모 상품 전개와 1 년 넘는 로드맵으로 움직이는 대기업과 "지금, 우리가 주목 해야 할 것에 주목하자"라고 하는 소규모의 유기적인 조직 중 어느 쪽이라고 생각하십니까?

물론 소규모의 기업 쪽이 시장의 요구에 민감하게 반응할 수 있는 환경에 있는 것은 분명합니다. 작은 회사가 방향을 전환한 다음에도, 대규모의 회사는 방향을 바꿀지 계속 논의하거나 언제 돌아올지 모르는 상부로부터의 대응을 기다리는 것이 되겠지요. 대기업이 어떻게 추진할까를 계획하고 있는 동안, 소규모의 회사는 두발이나 세발 더 앞 설 수 있습니다.

재빠르고 민첩한 한 작은 규모의 비즈니스는, 비즈니스 모델, 제품, 특색, 마켓 메시지 등 모든 것을 재빠르게 바꿀 수 있습니다. 실수가 있어도 재빠르게 수정할 수 있습니다. 그 외, 우선 순위나 제품의 편성, focus등도 바꿀 수 있습니다. 그리고 가장 중요한 것은 스스로의 사고 방식도 바꿀 수 있다는 것입니다..


변화에 따른 비용을 적게 하세요.

변화의 장애를 줄여서 유연하게 대처하세요.

변화는 당신에게 있어서 최고의 친구입니다. 변화의 비용이 많이 들수록, 그만큼 그것을 완수하기 힘들어집니다. 그리고, 경쟁 상대가 보다 빠르게 변화한다면, 당신은 매우 불리한 입장에 놓여집니다. 변화가 너무 많은 이용을 요구하게 되면, 그것은 곧 죽음을 의미합니다.

이러한 것 때문에 군살을 빼는 것의 진가가 발휘됩니다. 만원으로 변화를 완수하는 능력은, 작은 팀에서는 기본적으로 가능한 것으로써, 큰 조직에서는 결코 불가능한 일입니다. 이런 이유로 큰 것이 작은 것을 시기 합니다. 거대한 조직에서의 거대한 팀이 몇 주 걸리는 것을 작은 조직에서는 불과 하루 만에 가능합니다. 이러한 장점은 가격을 매길 수 없습니다. 저비용으로 신속한 변화가 가능하다는 것은 숨은 병기와도 같습니다.

기억하세요: 작기 때문에 가능한 민첩성은 세상의 모든 돈이나 마케팅, 사람으로 얻을 수 없는 것입니다.

그리고 웹 기반 기술에서의 변화는 쉽고 저렴해야 합니다. 변혁은 간단하고 싸지 않으면 안됩니다. 만약 재빠르게 변화할 수 없다면, 다른 사람이 치고 올라옵니다. 이것이 작은 규모를 유지해야 하는 이유입니다.

Emergence

Emgergence 는 기민함의 기본 원리이며, 마법의 원리 중에 하나입니다. Emergence의 특징들은 미리 계획되거나 디자인되는 것이 아닙니다. 그것들은 전체 시스템의 다양한 결과에 의해서 자연스럽게 나타나게 됩니다. "Emergence"라는 말은 17세기의 라틴어로 "예측되지 않은 발생"이라는 뜻입니다. 우리는 그것을 예측허가나 계획할 수 없으며, 다만 그러한 발생이 가능한 환경을 만들 수 있을 뿐입니다.

Emergence의 전형적인 예는 떼를 지어 날아가는 새들에서 찾을 수 있습니다. 컴퓨터 시뮬레이션에서는 3개의 간단한 규칙만 사용해서 새들이 목적지로 날아가는 동안 장애물 피한 후에 따시 전열을 갖추는 등의 복잡한 행동들을 구현할 수 있습니다. 이러한 고도의 동작들은 그것에 대한 정해진 규칙이 있는 것이 아니며, 전체 시스템에 의해서 역학적으로 발생(emergence)하는 것입니다.

새들의 시뮬레이션에서와 같이 간단한 규칙들이 복잡한 행동을 이끌어 냅니다. 반면에 복잡한 규칙들은 어리석은 행동을 유발합니다. 많은 나라의 복잡한 세법들이 그러한 예입니다.

소프트웨어 개발에서의 많은 관례들은 불행하게도 Emergence가 발생할 가능성을 제거하는 부작용을 가지고 있습니다. 최적화를 위한 많은 노력들은 Emergence의 발생에 있어 가장 중요한 상호작용과 관계들의 범위를 줄여버립니다. 떼를 짓는 새들의 예에서도 흥미롭고 유용한 행동을 만들어 내는 것은 새들간의 관계와 상호작용입니다.

우리가 일들을 고정하고 단단히 묶어버릴 수록 창의나 Emergence가 발생할 여지는 줄어들게 됩니다. 잘 이해하지 못한 상태에서 요구사양을 확정지어버리거나 너무 이른 시점에 코드를 최적화하려고 하거나, 고객이 시스템을 사용해보기도 전에 복잡한 네비게이션이나 워크플로우를 만들고 고정해버리는 것들이 그러한 예입니다. 그 결과는 불필요하게 복잡하고 멍청한 시스템이 될 것이며, Emergence가 발생할 수 있는 깔끔하고 우아한 시스템은 결코 될 수 없습니다.

작게 유지하세요. 단순하게 유지하세요. 이루어지게 하세요.

—Andrew Hunt, The Pragmatic Programmers

삼총사

버전 1.0은 3명의 팀에서 개발 해라.

어플리케이션의 최초의 버전은 단지 3명만으로 시작하세요. 그것이 당신이 능률적이고 민첩하게 계속 되게 해주는 맨파워를 부릴 수 있는 마법의 숫자입니다. 개발자와 디자이너와 스위퍼 (Sweeper, 두 세상을 조율해 줄 수 있는 사람)로 시작하세요.

소수 인원수만으로 어플리케이션을 구축하는 것은 분명한 도전입니다. 그러나 올바른 팀을 가지고 있다면, 그것은 가치 있는 일입니다. 능력이 있는 사람에게는 끝없는 자원은 필요 없습니다. 그 사람들은 제한적인 환경에서도 도전적인 과제들을 성공시키며, 창조성으로 문제를 해결합니다. 일손이 부족하다고 하는 것은, 프로세스의 초기에 있어 무엇인가 거래를 해야 하는 의미를 내포하고 있지만 문제 될 것이 업습니다. 그것은 당신에게 나중보다는 먼저 해야 할 우선순위를 생각하게 합니다. 그리고 당신은 정기적으로 동료의 걱정을 없애기 위해 커뮤니케이션을 하게됩니다..

만약 당신이 첫 번째 버전을 세 사람이 구축할 수 없으면, 추가 인력이 필요한가 아니면 최초 버전의 규모를 축소해야 하는가를 생각하게 됩니다. 최초 버전은 작고, 타이트에서도 상관없다는 것을 기억하세요. 당신의 아이디어에 날개가 있을지 어떨지는 곧바로 압니다. 그렇게 함으로써, 명료하고 심플한 기반의 제품을 가질 수 있습니다.

메트칼프의 법칙(Metcalfe's Law)과 프로젝트 팀

팀은 가능한 한 작게 유지하세요. "커뮤니케이션 시스템의 가치는 그 시스템의 유저수의 제곱으로 증가한다"는 Metcalfe’s Law(매트칼프 법칙)도 프로젝트 팀에 대해서도 적용됩니다. 팀의 효율성은 팀 내의 멤버의 수의 제곱에 반비례 합니다. 1.0 의 제품의 출시에는 3명이 최적이라고 생각합니다. 당신은 팀에 가세하려고 한 사람들의 수를 줄이는 것부터 시작하세요. 그리고 한층 더 여러 명 줄이는 겁니다.

—Marc Hedlund, O'Reilly Media기업가

커뮤니케이션 흐름

커뮤니케이션은 큰 팀보다는 작은 팀에서 잘 통용됩니다. 만약 당신이 프로젝트에 있어서의 유일한 사람이라고 하면, 커뮤니케이션은 간단합니다. 유일한 커뮤니케이션 경로는 당신과 고객입니다. 프로젝트에 관련되는 사람의 수가 증가할 수록, 커뮤니케이션의 경로도 증가합니다. 그것은 사람의 수가 증가함에 따라서 가산되어 가는 것은 아닌, 사람의 수의 제곱에 비례해 배로 증가해서 갑니다.

—Steve McConnell, Chief Software Engineer at Construx Software Builders Inc.
(from Less is More: Jumpstarting Productivity with Small Teams)

제한을 수용한다.

제한을 창조적 해결책으로 승화하세요.

세상에 있는 것은 결코 충분하지는 않습니다. 시간도 돈도 사람도 충분하지 않습니다.

그것은 좋은 일입니다.

이러한 제약사항으로 흥분하지 말고, 받아 들이세요. 제약사항은 창조와 초점에 집중하도록 해줍니다. 제약 사항을 없애려 하지 말고, 그것을 당신에게 유리하게 이용하세요.

37signals의 경우도 "Basecamp" 개발시에 많은 제약이 있었습니다. 그것은：

우리는, "충분하지 않다"라고 투덜대고 있었습니다. 우리는 그릇을 작게만 하고 있었습니다. 작은 그릇은 담을 수 있는 양도 정해져 있습니다. 우리는 큰 태스크를 작은 단위로 쪼갠 후 한번에 한 개씩 실행 했습니다.. 사전 우선순위를 결정한 대로 단계별로 해결해 나갔습니다.

그것은 우리로 하여금 창의적인 제품을 개발할 수 있게 해주었습니다. 언제나 작은 규모로 소프트웨어를 개발하여 우리는 변경 비용을 낮췄습니다. 사람들에게 스스로의 문제를 스스로의 방법으로 해결하는데 충분한 특징을 도입해, 그들에게 맡겼습니다. 우리들 내부의 시차와 거리의 문제는 커뮤니케이션을 함에 있어 보다 효율적으로 할 수 있게 해주었습니다. 사람과의 미팅 대신에, 대부분 메신저와 전자메일로 커뮤니케이션 하였으며, 이것이 우리의 문제에 대해 빠르게 집중할 수 있었습니다.

제약사항은 가끔씩은 우리에게 장점이 됩니다. 벤처캐피털, 긴 제품 출시 일정, 고용은 잊어버리고, 가지고 있는 자원으로 일에 전념하세요.

해충과 싸우세요

"Creeping elegance"(프로그래머들이 지나치게 고상함에 집착하여 소프트웨어의 기능성이나 스케쥴, 사용성을 다소 무시하는 현상)는 "기능 해충"으로 표현하는 것이 더 적절할 지도 모릅니다. 이것은 식물의 진액을 빨아먹고식물 전체를 서서히 망가뜨리는 곰팡이와 같습니다. 소프트웨어에서 기능 해충을 방지하는 가장 쉬운 방법은 물론 데드라인을 압박하는 것입니다. 데드라인에 대한 압박은 구현이 오래 걸리는 기능들을 제외하게 만듭니다. 하지만 일반적으로는 가장 중요한 기능이 구현하는 데 시간도 가장 오래걸립니다. 따라서 기능 해충과 데드라인의 조합은 중요하지 않은 기능들로만 가득찬 소프트웨어라는 결과를 만들게 되므로 주의해야 합니다.

—Jef Raskin, 저자 ( "Why Software Is the Way It Is" 에서)

있는 그대로

대기업과는 다른 사람의 마음을 생각한 친밀감 있는 방법으로 접근하세요.

많은 작은 기업들이 스스로를 크게 보이게 하려고 행동하는 실수를 합니다. 스스로 작은 규모를 극복 해야할 약점으로서 생각하는 것 같습니다. 안타깝습니다. 작은 것은 큰 무기입니다-특히 커뮤니케이션의 부분에서는 더 그렇습니다.

작은 회사는 격식이 적고, 관료적인 것이 덜하고, 보다 자유롭습니다. 기본적으로 작은 회사는 고객과 가까운 위치에 있습니다. 그것은 고객과 직접 개개인에 접근 할 수 있는 방법으로 커뮤니케이션이 생기는 것입니다. 만약 작은 조직이라면, 까다로운 전문 용어를 사용하지 않고 더 친밀한 말로 이야기를 할 수 있습니다. 당신의 사이트나 제품은 기업의 선전문구가 아닌, 인간의 메시지를 전할 수 있습니다. 작은 규모라는 것은 고객을 깔보는 것이 아닌 고객과 대화할 수 있는 것입니다.

작은 회사에서는 조직 내부의 커뮤니케이션에도 장점이 있습니다. 무엇인가의 서류에 좌지우지되지 않고, 쓸데없이 복잡한 프로세스나 여기저기의 승인 도장도 필요 없게 됩니다. 어느 과정에서도 멤버 전원이 오픈 마인드로 정직하게 이야기할 수 있습니다. 아이디어에 속박이 없는 흐름은, 작은 규모의 큰 이점의 하나입니다.

당당히 정직하게

어쩌면 소비자는, 기업의 종업원수나 제품의 수, 즉 기업의 규모를 과장하면 속아 버릴 것이라고 생각할지도 모릅니다만, 영리한 사람(즉 당신이 정말로 타켓으로 하고 싶은 사람)은, 언제나 진실을 압니다. 창피한 이야기입니다만, 저도 과거에 이러한 자신을 크게 보이려고 했던 한 명입니다. 그러나, 그러한 일을 해도, 비즈니스가 의미 있는 것이 되어, 스스로의 서비스를 정말로 필요로 하고 있던 고객과의 관계가 계속 되어 신뢰 깊은 관계가 생긴 일은 없었습니다. 결국, 회사의 실제의 규모가 작아도 부끄러워하는 않고, 솔직하게 말하면 좋습니다.

—Khoi Vinh, Subtraction.com

언제라도

고객에게 있어서 좋은 고객 서비스는 어떤 비즈니스든지 최대의 기대사항입니다. 우리 조차도 그것을 바라는데, 고객은 어떻겠습니까? 초창기부터 우리에게 문의하는 모든 고객 및 모든 질문에 투명하게 대응했습니다. 웹 사이트에서는 무료 전화 번호를 기재하여, 우리 휴대폰으로 오게 했고, 명함에도 각자의 휴대폰 번호를 기재했습니다. 우리는 고객에게 무슨 일이 일어나든지 우리에게 연락할 수 있다고 강조했습니다. 고객들은 이러한 신뢰에 대해 고마워했고, 이 서비스에의 클레임은 없습니다.

—Edward Knittel, Director of Sales and Marketing, KennelSource

우선순위 chapter 4

커다란 아이디어

친근하고 인간적인 방식으로 대기업과 차별화하세요.

어플리케이션이 지향하는 바를 구체적으로 하나 정의하세요. 무엇을 위한 서비스인가요? 디자인이나 코딩을 하기전에 어플리케이션의 비전을 분명히 알아야 합니다. 크게 생각하세요. 왜 이 것이 필요합니까?, 다른 비슷한 서비스와의 차별성은 무엇인가요?

비전이 있으면 여러가지 결정들을 일관되게 할 수 있고 한 방향으로 나아갈 수 있습니다. 뭔가 혼란스러운 상황이 발생하면 스스로에게 물어보세요. "이 것이 우리의 비전과 일치하는가?"

비전은 간결해야 합니다. 핵심적인 생각을 전달할 수 있는 한 개의 문장이면 됩니다. 다음은 37Signals 각 서비스의 비전들입니다.

Basecamp의 비전은 "프로젝트 관리는 의사소통이다"입니다. 효과적인 의사소통은 프로젝트에 소속된 모든 이들의 참여의식과 주인의식을 높여줍니다. 또 모든 사람들이 공통의 목표를 향해 일할 수 있게 해줍니다. Basecamp가 이런 비전을 잘 만족시킬 수 있다면 다른 모든 것들은 상대가 안될 것입니다.

Basecamp의 비전은 더 개방적이고 더 투명한 구현결과를 이끌었습니다. 프로젝트를 하는 회사 내로만 의사소통을 제한하는 대신에 고객들도 접근 할 수 있도록 했으면, 접근 권한보다는 모든 관련자들이 적극적으로 참여할 수 있게 하는 데 더 주안 점을 두었습니다. 챠트나 테이블, 보고서, 통계자료 같은 기능을 제공하지 않고 메세지, 코멘트, to리스트, 파일 공유 등의 기능에 더 집중한 것도 그 때문입니다. 비전을 정하는 것은 큰 결정이지만 일단 비전을 정하고 나면 그 뒤의 세부적인 결정들은 훨씬 쉬워집니다.

화이트보드의 철학

앤디헌트와 나는 한 때 현금 카드 거래 시스템을 개발했습니다. 주요 요구사항은 사용자 계좌에서 동일한 건에 대해 출금이 두 번 발생하는 일을 방지하는 것이었습니다. 차라리 처리가 되지 않는 한이 있더라도 똑 같은 처리가 두번 발생하는 일은 절대 없어야 했습니다.

그래서 우리는 그것을 화이트보드에 큰 글자로 써두었습니다. "사용자에게 에러가 나는 것이 차라리 더 낫다."

그 외에도 대여섯개의 원칙들을 함께 정했고, 이렇게 정해진 원칙들은 다른 결정하기 까다로운 세부사항들을 쉽게 결정할 수 있게 해주었습니다. 또 이 원칙들은 내부적으로 응집력이 있고 외부적으로는 일관성이 있는 어플리케이션을 만들 수 있도록 도와주었습니다.

—Dave Thomas, The Pragmatic Programmers

슬로건을 만드세요.

조직에는 슬로건이 필요합니다. 구성원들이 매일 잠에서 깨어나서 일하러 갈 때 마음 속에 기억하고 있어야할 바로 그 것말입니다. 슬로건은 간결하고 분명해야 합니다. 슬로건은 서너 단어로 정도가 적당합니다. 우리의 존재 이유는 무엇인가? 우리의 동기는 무엇인가? 에 대한 답을 해줄 수 있는 것이 바로 슬로건입니다.

—Guy Kawasaki, 저자 (from Make Mantra)

초기에는 시시콜콜한 것들은 무시하세요.

큰 것에서부터 작은 것으로 진행하세요.

우리는 세부사항에 집착하는 경향이 있습니다.

성공과 만족은 세세한 것에 있습니다.

세세한 것에 성공의 요인이 있다고들 말합니다. 틀린말은 아닙니다. 하지만 그 것이 다가 아닙니다. 의견 불일치, 회의, 지연 이런 것들도 모두 세세하고 시시콜콜한 것들에 집착할 때 생기는 것들입니다. 이 런 것들은 팀의 분위기를 죽이며 성공의 가능성을 줄입니다.

단 하나의 코드 조각이나 한 부분의 디자인 때문에 하루 온 종일을 소비하는 경우가 얼마나 됩니까? 하루동안 열심히 일했지만 실제로 별로 진행된 것이 없다는 것을 깨닫는 경우가 얼마나 자주 있습니까? 이런일은 너무 이른 시점에 세부적인 내용에 집착할 때 생깁니다. 완벽주의자를 위해 준비된 시간은 충분히 있습니다. 그냥 나중에 하면 됩니다.

개발 첫 주에 헤더의 폰트 크기에 대해서 걱정하지 마세요. 둘 째 주에 맘에 딱 드는 녹색을 찾으려고 하지 마세요. 세 째 주에 'Submit'버튼을 3픽셀정도 오른쪽으로 옮기는 일 같은 것은 의미가 없습니다. 페이지에 있는 내용들을 그대로 두고 그냥 사용하면서 잘 동작하는 지만 확인하세요. 모든 것이 명확해지고 나서 조정하고 더 완벽햐?만드세요.

시시콜콜한 세부사항들은 그것을 사용해보고 상세한 개발을 진행해봐야 비로소 분명해집니다. 어떤 부분에 더 관심을 가져야할 지도 알 수 있습니다. 어떤 부분이 누락되었고, 어떤 부분을 보완해야할 지는 실제로 사용해봐야만 알 수 있습니다. 그런 순간이 왔을 때 작업하면 됩니다. 너무 빨리는 하지 마세요.

시시콜콜 악마

나는 일단 클래스들을 몇 개 그려보고 나면 "당장 세부사항들을 파보고 싶은" 마음에 사로잡힌다. 하지만 즉시 세부사항들을 그리기 시작한다면 곧 점점 망쳐지고 있다는 것을 알게될 것이다. 이런 방식을 완전히 잘못된 것이다.

그림을 그릴 때는 먼저 전체적인 구도의 비율을 맞추는 것부터 시작해야한다. 그리고 나서 큰 물체들부터 먼저 그리고, 다음에 더 작은 것들을 그려야 한다. 스케치는 너무 상세해서는 안된다. 사물의 생명감을 살리기 위해 그림자를 넣을 때도 처음에는 단 3개의 톤(밝음, 중간, 어두움)만으로 표현한다. 그리고 각 물체에 그려진 색체를 체적으로 평가하고 조정한다. 이 과정을 계속 반복한다.

Always. 항상 큰 것에서 작은 것으로

—Patrick Lafleur, Creation Objet Inc. (from Signal vs. Noise)

문제가 발생해야 문제

아직 발생하지도 않은 문제를 위해 시간을 낭비하지 마세요.

사용자 10만명을 처리할 수 있는 확장성에 대해서 오늘 고민할 필요가 있을까요? 사용자 10만이 될 때까지 족히 2년은 걸릴 텐데 말이죠.

지금 세 명이면 충분한데 굳이 여덟명의 프로그래머를 채용해야 할까요?

앞으로 일 년 동안 두 대만 있어도 충분한데 최신 서버를 당장 12대나 사야 할까요?

그냥 지금 나는데 필요한 날개를 달아주세요.

사람들은 자주 그들이 아직 당면하지도 않은 문제를 해결하는데 너무 많은 시간을 보냅니다. 37Signals는 Basecamp 서비스를 시작할 때 사용자에 대한 과금 기능을 만들지도 않았습니다. 왜냐하면 Basecamp는 매 월 요금을 받는 방식이므로 서비스 개시 후에도 30일의 추가 시간이 있었기 때문입니다. 서비스를 개시한 후에 그들은 과금 기닯?개발하기 시작했고 결국 아무 문제도 없었습니다. 이런 식으로 그들은 우선 가장 중요한 기능들을 개발하는데 전력을 투구할 수 있었습니다.

실제로 문제를 만나기도 전에 미리 땀빼지 마세요. 기능을 오버스펙으로 개발하지도 마세요. 필요가 생길 때 하드웨어든 소프트웨어를 추가하세요. 한 두 주 늦는다고 해서 세상이 끝나는 것도 아닙니다. 다만 솔직하면 됩니다. 고객들에게 기능 추가나 확장에 대해서 약간의 문제를 겪고 있다고 말하세요. 고객들이 그 것에 대해 기뻐할 리 없지만 여러분의 솔직함에 대해서는 고마워할 것입니다.

결정들을 제 때에 하는 것이 중요합니다. 제 때란 여러분이 결정을 내리기 위한 실질적인 정보를 가지고 있을 때를 말합니다. 그런 정보들이 생기기 전에는 단지 즉각적인 작업이 필요한 여러가지 다른 일들을 하고 있으면 됩니다.


맞춤 고객

어플리케이션에 딱 맞는 핵심 고객 층을 찾고 그들에게 집중하세요.

고객이 항상 옳은 것은 아닙니다. 여러분이 누가 옳고 누가 틀렸는 지를 결정해야 합니다. 좋은 소식은 인터넷에서는 딱 맞는 사람들을 찾기가 더 쉽다는 것입니다.

모두를 기쁘게 하려고 하면 아무도 만족하지 못하게됩니다.

Basecamp를 개발할 때, 37Signals는 주 고객을 디자인 회사로 정했습니다. 이런 식으로 슬쳄揚?한정함으로써 더 열정적인 고객들을 더 많이 찾을 수 있게 되었습니다. 어떤 고객들은 자발적인 전도사가 되기도 했습니다. 여러분이 만들려고 하는 어플리케이션이 정말 어떤 사람들을 위한 것인지를 알아야합니다.

지금까지 한 일 중 최고 잘했던 일

Campaign Monitor 에서 웹디자인 시장을 겨냥하기로 한 우리의 결정은 최고의 결정 중에 하나였습니다. 그 결정에 의해서 어떤 기능들이 정말 유용한 것인 지 쉽게 알 수 있게되었고, 그것보다 더 중요한 것은 필요하지 않은 기능들을 버릴 수 있었던 것이었습니다. 특정 분야로 고객을 한정함으로서 오히려 더 많은 고객을 모을 수 있었고고객들이 대부분 비슷한 요구사항들을 가지고 있었으므로 개발도 오히려 더 쉬워졌습니다. Campaign Monitor에는 웹디자이너가 아닌 사람들에게는 아마도 불필요할 수많은 기능들이 있습니다.

핵심 고객층에 집중하는 것은 또한 우리가 개발한 소프트웨어에 대한 소문을 퍼뜨리는 데도 더 도움이 됩니다. 우리는 좁게 정의된 고객층을 가지고 있기 때문에 그들이 더 자주 방문하는 온라인 사이트에 광고하고 글을 올릴 수도 있으며, 제품에 대한 커뮤니티를 형성하기도 더 쉽습니다.

—David Greiner, 창립자, Campaign Monitor

확장은 나중에

아직 확장에 대한 문제는 없습니다.

"우리 서비스에 100만명이 접속해도 확장성에 문제가 없을까?"

하지만 실제 문제가 발생할 때까지 기다리세요. 여러분의 시스템에 과부하를 줄 만큼 엄청난 사람들이 접속한다면 그것은 사실 '만세'를 부를 일입니다. 진실을 말하자면 정말 대부분의 웹 어플리케이션들은 결코 그 단계에 이르지 못합니다. 그리고 정말 과부하가 발생한다고 하더라도 그것이 당장 죽고사는 문제는 아닙니다. 여러분은 문제 파악하고 해결할 시간이 있습니다. 게다가 그 때즘 뙤면 여러분은 실제 데이터들에 대한 경험과 벤치마크 결과를 알고 있을 것이므로 이런 정보들을 이용해서 문제를 더 잘 해결할 수 있습니다.

예를 들어 Basecamp는 첫 일년동안은 한 대의 서버에서 동작했습니다. 매우 간단한 설정으로 시작했으므로 모든 것을 준비하는데 일주일이면 충분했습니다. 처음부터 15개의 클러스터 서벌 시작하거나 확장성을 위해서 몇달을 낭비하는 그런일은 하지 않았습니다.

과연 문제가 하나도 없었을까요? 몇 개는 있었습니다. 하지만 처음에 우려했던 대부분의 문제들은 실제로는 거의 문제가 되지 않는 다는 것을 알겠되었습니다. 발생한 상황에 대해서 솔직히 고객에게 말하고 계속해서 개선을 하는 한 고객들은 크게 문제삼지 않습니다. 되돌아보면 완벽한 준비를 위해서 서비스 시기를 늦추지 않은 것은 정말 잘한 결정이었습니다.

처음에는 핵심 기능을 튼튼하게 만드는 것을 첫번째 우선순위에 올리세요. 확장성이나 서버 군을 구성하는 사로잡히는 것은 좋지 않습니다. 먼저 멋진 서비스 어플리케이션을 만들고, 크게 성공했을 때의 문제들은 그 때가서 하세요. 그렇지 않으면 여러분의 에너지와 시간과 돈을 결코 일어나지 않을 일에 낭비하게 될 지 모릅니다.

여러분이 믿는 말든간에 진짜 중요한 문제는 확장성이 아닙니다. 더 중요한 문제는 확장성이 필요한 시점에 어떻게 도날하는가 하는 것입니다. 그 시점에 도달하지 못한다면 확장성이 문제가 될 리가 없습니다.

어차피 수정과 개선이 필요합니다.

사실 모두가 확장성의 문제를 가지고 있습니다. 그 어떤 서비스라도 몇 백만의 사용자 처리가 가능해지려면 처음의 모든 디자인과 구조들을 재검토하고 수정해야합니다.

—Dare Obasanjo, Microsoft (from Scaling Up and Startups)

방향성을 가진 소프트웨어

어플리케이션은 어느 한쪽 방향을 선택해야 합니다.

어떤 이들은 소프트웨어는 특정 의견에 편협하게 만들어서는 안된다고 합니다. 그들은 개발자들이 기능들을 제한하거나 어떤 기능 요구들을 무시하는 것은 거만한 자세라고 말합니다. 그들의 소프트웨어는 항상 최대한으로 유연하고 일반적으로 만들어야 한다고 주장합니다.

우리는 그런 의견은 정말 개떡 같다고 생각합니다. 최고의 소프트웨어는 비젼을 가지고 있습니다. 최고의 소프트웨어는 한 방향을 선택합니다. 누군가 소프트웨어를 사용할 때 그들은 기능들 보다는 접근 방식을 더 많이 봅니다. 비젼을 봅니다. 여러분의 비젼이 무엇인지 정하세요. 그리고 그것에 따라 진행하세요.

기억하세요. 어떤 사용자들이 여러분의 비전을 좋아하지 하더라도, 세상에는 정말 다양한 비전들이 있다는 것을요. 사람들을 무작정 쫓아간다면 결고 행복한 결과를 만들 수 없습니다.

이 점에 대한 최고의 사례는 최초의 위키 디자인에 대한 것입니다. 워드 커닝햄과 친구들은 예전에는 공동 문서작업을 위해 필요하다고 여겨지던 많은 기능들을 그들의 위키에서는 과감히 잘라 버렸습니다. 문서가 변경될 때마다 하나의 속성으로 변경을 한 사용자를 지정하면서, 대신 소유권과 관련된 가시적은 표시 기능들은 대부분 제거했니다. 그들은 콘텐트에 대해 개인의 존재감을 없애고, 콘텐트가 시간에 구애받지 않도록 만들었습니다. 그들은 누가 그 내용을 썼고 언제 그것이 변경되었는 지가 중요하지 안?]고 생각했습니다. 그리고 이런 결정들은 정말 커다란 차이를 만들었습니다. 커뮤니티에 공유의 마인드를 구축하였으며 그것이 바로 위키페디아 성공의 핵심 요소가 었습니다.

37Signals의 어플리케이션들도 이와 같은 방식을 따랐습니다. 모든 사람을 만족시키려고 하는 대신, 각 어플리케이션의 고유의 방식을 가지려고 했습니다. 그리고 어플리케이션의 동반자가 되어줄 고객 부류를 찾아서 그들과 비전을 공유하였습니다. 여러분도 우리와 같은 버스에 동승하는 것은 어떻습니까?


기능 고르기 chapter 5

제대로 된 절반

반은 엉망인 제품을 만들지 말고 반만 만들어도 제대로 만드세요.

"물빠지는 구멍이 없는 것만 빼고는 완벽한 부엌"과 같은 상황을 조심하세요. 좋은 아이디어라고 해서 모두다 추가하려다보면 결국 어느 하나 제대로 동작하는 것이 없는 상태가 되고 맙니다. 중요한 것은 일부분이라도 핵심적인 부분을 확실히 동작하도록 만드는 것입니다.

진짜 핵심인 부분에 집중하세요. 좋은 아이디어들을 종이에 나열해서 적으세요. 서비스에 필요하다고 생각되는 것들을 모두 적은 다음에 그 중 절반을 골라서 버리세요. 정말 핵심적이라고 생각되는 기능들만 남겨놓고 나머지를 버리세요. 이 과정을 반복하세요.

Basecamp에서 37Signals는 메세지 기능만으로 시작했습니다. 그 기능이 핵심이라는 것을 알았기 때문에 처음에는 마일스톤이나 todo리스트 같은 다른 기능들은 무시했습니다. 그리고 그 이후의 결정들은 실제 사람들이 사용하는 방식을 보고 정했습니다. 개발자들의 초기 직관과 추측에 의존해서 모든 것을 결정하는 것은 좋지않습니다.

가볍고 영리한 어플리케이션으로 시작해서 사용자들의 관심을 끄십시오. 그리고 나서 그 기반위에 기능들을 추가해나가면 됩니다.


중요한 문제가 아닙니다.

핵심적인 것만

"왜 이렇게 하지 않았죠?" 또는 "왜 이렇게 했죠?"와 같은 질문에 대해 우리가 가장 선호하는 답변은 "왜냐하면 그건 별로 중요하지 않기 때문입니다" 라고 말하는 것입니다. 이 문장은 제품을 위대하게 만들어주는 정신을 표현하고 있습니다. 정말 중요한 것을 찾아내고 나머지는 내버려두세요.

37Signals에서 Campfile 서비스를 개시했을 때 사람들로부터 다음과 같은 질문들을 받았습니다.

"왜 타임스탬프가 5분마다인가요? 왜 각 줄마다 타임스탬프를 찍지않나요?" 대답: 그것은 별로 중요하지 않습니다. 초단위나 분단위로 대화내용을 추적해야하는 경우가 얼마나 있습니까? 95%의 경우는 그렇지 않을 겁니다. 그러니 5분은 충분합니다.

"왜 볼드체나 이탤릭체 또는 문자에 색을 지정하는 것이 안됩니까?" 대답: 그 것은 중요한 문제가 아닙니다. 만약 강조하고 싶은 부분이 있으면 대문자를 사용하거나 *를 사용하면 됩니다. 이런 방법은 추가로 소프트웨어가 필요하지도 않고 기술지원도 필요없으며 따로 배우지 않아도 됩니다. 게다가 문자로 주고받는 간단한 대화에서 무거운 포맷팅 기능은 전혀 필>요없습니다.

"왜 현재 방안에 있는 사람의 수를 보여주지 않나요?" 대답: 중요하지 않습니다. 모든 사람의 이름의 리스트가 나오므로 누가 있는 지 쉽게 알 수 있습니다. 12명이든 16명이든 무슨 차이가 있습니다. 그것으로 인해서 사용자의 사용 동작에 차이가 없다면 전혀 중요하지 않습니다.

이런 기능들을 제공하면 좋을까요? 물론 좋을 겁니다. 하지만 그 것들이 핵심적인 기능들인가요? 정말 중요한가요? 절대 그렇지 않습니다. 그래서 37Signals는 이 기능들을 제공하지 않았습니다. 최고의 디자이너와 최고의 프로그래머는 최고의 기술을 가진 사람도 아니며 가장 재빠른 사람들도 아니고 포토샵이나 개발환경을 멋지게 다루는 사람들도 아닙니다. 정말 필요하지 않은 것이 무엇인지를 아는 사람들이야 말로 최고라고 할 수 있습니다. 차별성은 바로 이런 부분에서 나옵니다.

여러분은 대부분의 시간을 별로 중요하지 않은 일에 소모합니다. 만약 여러분이 중요하지 않을 일에 대해 생각하거나 작업하는 것을 줄일 수 있다면 상상도 못할 생산성을 얻게 될 것입니다.


일단 'NO'라고 말하세요.

기능들이 쉽게 구현되지 못하도록 하세요.

어느 것 하나도 제대로 동작하지 않는 엉터리를 만들지 않고 일부라도 제대로 동작하는 제품을 만드는 비결은 '아니오'라고 말하는 것입니다.

어떤 기능에 대해서 '예'라고 말할 때마다 마치 아이 하나를 입양하는 것과 같습니다. 이 아이는 그 모든 일련의 보살핌이 필요합니다.(디자인, 구현, 테스트 등) 그리고 일단 기능을 정하게되면 그것에 집착하게 됩니다. 고객이 멀리하는 기능을 하나 찾아서 왜 그렇게 되었는 지 알아보세요.

예스맨이 되지마세요.

매 기능의 구현 여부를 쉽게 결정하지 마세요. 기능이 정말 존재할 필요가 있는 지를 기능 스스로 증명하도록 하십시오. 마치 "Fighting Club"처럼 문간에서 들여보내줄 때까지 3일은 버티는 그런 기능들만을 고려해야합니다.

이것이 바로 우리가 "아니오"로 시작하는 이유입니다. 모든 새 기능에 대한 요청은 외부에서 온 것이든 내부에서 온 것이는 먼저 "아니오"를 만납니다. 우리는 요청에 경청하지만 즉시 행동하지는 않습니다. 첫번째 반응은 "지금은 아닙니다" 입니다. 만약 하나의 기능에 대한 요청이 다시 들어오면 우리는 좀 더 깊이 살펴볼 때라고 여기게 되며 실제로 고려하기 시작합니다.

그리고 자신의 기능 추가 요청을 받아들이지 않는다고 불평하는 사용자들에게 뭐라고 말하는 것이 좋을까요? 그들에게 그들이 왜 처음 그 서비스를 좋아하게 되었는 지를 상기시키세요. "당신이 우리 서비스를 좋아하는 이유는 우리가 '아니오'라고 말하기 때문입니다. 우리의 서비스가 100가지나 되는 기능들을 가지고 있지 않기 때문입니다. 우리의 서비스가 모든 사람을 항상 만족시키려고 하지 않기 때문입니다. "

"천 개의 기능은 필요하지 않습니다."

스티브잡스가 아아튠즈에 대해서 독립음반회사 사람들을 모아놓고 조그만 발표를 했습니다. 그 날 많은 사람들은 쉴 새없이 손을 들면서 어떤 기능이 제공되는 지, 혹은 어떤 기능을 추가할 계획이 있는 지 물었습니다. 마침내 쟙스가 말했습니다. "잠깐만요. 손을 잠시 내리고 제 말을 들어보시죠. 저는 여러분이 아이튠즈에 있으면 좋을 만한 아이디어를 수 천개 가지고 있다는 것을 잘압니다. 하지만 우리는 수 천개의 기능을 원하지 않습니다. 그렇게 하면 엉망이 될 겁니다. 혁신은 모든 것에 대해서 '예'라고 말하는 것이 아닙니다. 혁신은 정말 중요한 것을 제외한 나머지에 대해서는 '아니오'라고 말하는 것입니다."

—-Derek Sivers, 대표 및 프로그래머, CD Baby and HostBaby
(from Say NO by default)

숨은 비용

새 기능을 위한 비용을 밝히세요.

어떤 기능이 '아니오' 단계를 통과했다고 하더라도 여러분은 그 기능에 대한 숨은 비용을 찾아야 합니다.

예를 들어, 기능의 연쇄(어떠 기능을 위해서 다른 기능이 계속 추가로 필요해 지는 것)가 생기지 않을 지 살펴보십시오. 37Signals는 Basecamp에서 회의를 위한 탭을 추가해달라는 요청을 받았습니다. 그것은 자세히 살펴보기 전까지는 비교적 간단한 것으로 생각되었습니다. 그런데 회의 기능을 구현하기 위해서는 다음과 같은 개념들이 추가로 필요했습니다. 위치, 시간, 회의실, 참가자, 이메일 초대, 달력 연동, 회의록 작성 등. 물론 홍보 페이지를 변경하고 소개용 맛보기 페이지와 FAQ/도움말, 서비스 계약 등을 바꿔야 하는 것은 말할 필요도 없습니다. 이처럼 우리가 알지 못하는 사이에 아주 작은 아이디어 하나가 눈덩이처럼 커져서 두통거리가 되어버립니다.

new 모든 새로운 기능에 대해서 다음과 같이 하세요.


관리가 가능한가요?

관리할 수 있는 것을 개발하세요.

만약에 여러분이 어떤 가입형 서비스를 시작한다면 계정관리과 지불을 처리할 수 있는 시스템을 가지고 있어야 합니다. 여러분은 회원의 요금이 지불 수단으로 매달 직접 현금이나 수표를 송금하는 방식이 아니라 신용카드를 이용한 결제 수단이 필요할 겁니다.

여러분은 구글과 똑같이 무료로 1기가의 공간을 제공할 수 있습니까? 아마 여러분은 100메가정도부터 작게 시작해야 하거나 유료 계정에 대해서만 공간을 제공할 수 있을 지도 모릅니다.

여러분의 여건에 맞고 관리가 가능한 제품을 만들고 서비스를 제공하세요. 약속을 하는것은 쉽습니다. 하지만 그것을 지키는 것은 훨씬 더 어렵습니다. 어떤 일이든 시작하기 전에 그것이 조직적 전략적 기능적으로 잘 관리될 수 있는 일인 지를 미리 확인 하십시오.


사람의 해결책

소프트웨어를 범용적으로 만들어서 사람들이 그 들만의 방식으로 사용할 수 있도록 하세요.

사람들에게 규칙을 강요하지 마세요. 대신 소프트웨어를 범용적으로 만들어서 모든 사람들이 자신만의 방식으로 사용할 수 있도록 하세요. 사람들이 자신들의 문제를 자신만의 방식으로 해결 할 수 있는 방법을 창조적으로 찾아낼 수 있도록 하는 겁니다.

Ta-da List 를 개발할 때, 37Signals는 의도적으로 많은 기능을 빼고 개발했습니다. 할 일 항목에 대해서 사람을 지정하는 기능도 없었고 완료일을 지정하는 방법도 없었습니다. 아이템들을 분류하는 방법도 없었습니다.

이렇게 함으로써 사람들은 더 창조적이 되었고 소프트웨어는 깔끔하고 정돈된 상태를 유지할 수 있었습니다. 사람들은 스스로 문제를 해결하는 방법을 찾았습니다. 완료일을 지정하고 싶으며 내용 에 '기한: 2006년 4월 7일)' 이라고 추가했고, 분류를 지정하고 싶으면 단지 '[책]' 이라고 썼습니다. 이상적인 구현인가요? 물론 아닙니다. 욉瞿?構?유연한가요? 그렇습니다.

만약 37Signals가 이런 기능들을 위해서 특별한 방식으로 구현된 기능을 제공했다면 그것은 사람들이 원하는 다양한 경우를 모두 만족시킬 수 없었을 것입니다.

문제의 핵심 부분에 대해서는 최선을 다해서 최고의 기능을 제공하세요. 그리고는 한 발 벗어나세요. 사람들이 여러분이 제공한 틀 내에서 그들 자신의 해결책과 규칙을 만들어 사용할 수 있도록 하세요.


기능 추가 요구는 잊어버리세요.

중요한 것이라면 사용자들이 반복해서 상기시켜줍니다.

사용자들은 이 세상의 모든 것들을 원합니다. 사용자의 기능 추가 요청은 마치 눈사태처럼 쏟아져 들어올겁니다. 37Signals의 서비스 게시판을 보세요. 다른 게시판에 비해서 기능 요청 게시판의 글들이 월등히 더 많습니다.

아마도 이런 말들을 듣게 될 것입니다. "이 작은 추가 기능", "결코 어렵지 않은", "간단히 추가 가능한", "몇 초면 구현할 수 있는", "최소의 구현으로 최대의 효과를"

물론 기능을 요구하는 사용자들을 탓할 수는 없습니다. 오히려 그들이 더 많이 말하고 요구하도록 격려하는 것이 옳습니다. 우리가 추가하는 대부분의 기능들은 사용자의 요청에서부터 시작됩니다. 하지만 앞에서도 말했듯이 그러한 요청에 대한 우리의 첫번째 반은은 '아니오'이어야 합니다. 그렇다면 이렇게 쏟아지는 수많은 요청들을 어뜬뺐?처리해야 할까요? 어떻게 정리해야할까요? 정리하지 마세요. 그냥 한 번 읽어보고 잊어버리세요.

그렇습니다. 읽고, 던저버린 후 잊어버리세요. 좀 불경스럽게 들릴 수 도 있지만 중요한 내용이라면 결국 계속해서 나타날 것입니다. 그런 것들이 바로 우리가 기억하고 관심을 가져야할 중요한 것들입니다.

어째서 이런 결론에 도달했냐구요? 우리가 처음 Basecamp를 시작했을 때, 우리는 모든 주요한 기능 요구사항들을 Basecamp의 todo 리스트에 관리했습니다. 어떤 요청이 반복되면 우리는 별표를 하나 추가해서 표시했습니다. 그러다가 나중에 적당한 시점에 리스트에서 가장 요청이 많은 항목들을 구현할 생각이었습니다.

하지만 사실은 우리는 그 리스트를 한 번도 다시 보지 않았습니다. 우리는 다음에 해야할일을 그냥 알 수 있었습니다. 왜냐하면 사용자들이 그 기능을 계속해서 반복적으로 요청했기 때문입니다. 리스트 같은 것을 만들고 분석할 필요는 전혀 없었습니다. 누군가 매일 매일 같은 내용을 얘기해 주면 그것을 잊을 수 없는 것이 당연합니다.

또 한가지 사실은, 단 지 몇 명 이상의 사람들이 그 기능을 요청했다고 해서 반드시 그것을 추가해야한다는 것은 아닙니다. 가끔은 '아니오'라고 말하고 기존의 비젼과 방향성을 유지하는 것이 더 낫습니다.


Hold the Mayo

사용자들이 원하지 않는 것을 물어보세요.

대부분의 소프트웨어 설문이나 조사를 위한 질문들은 사람들이 무엇을 원하는 지에 대한 것입니디ㅏ. "추가되었으면 좋겠다고 생각하는 기능은 무엇입니까?", "만약 당신이 딱 하나의 기능을 추가할 수 있다면 그 것은 무엇입니까?", "이 제품을 더욱 유용하게 만들어줄 기능은 무엇일까요?"

하지만 동전의 뒷면을 보세요. 왜 사용자들이 원하지 않는 기능에 대해서는 묻지 않습니까? "만약 당신아 딱 하나의 기능을 제거할 수 있다면 무엇을 제거하겠습니까?" "어떤 기능을 전혀 사용하지 않습니까?" "도움이 되지 않고 귀챦기만 한 기능은 무엇인가요?"

"더 많이"는 절대 답이 아닙니다. 가끔은 어떤 기능을 빼버리는 것이 고객에게 큰 도움을 주는 일이 될 수 있습니다.

혁신은 '아니오' 에서 시작된다.

[혁신]은 1000가지 일에 대해서 '아니오'라고 말하므로써 잘못된 길을 가거나 불필요하게 너무 많은 일을 하지 않도록 하는 것에서 시작됩니다. 우리는 항상 새롭게 진입가능한 시장에 대해서 고민합니다. 하지만 그것은 과감히 '아니오'라고 말하므로써 실질적으로 중요한 일들에 대해서만 집중할 수 있을 때 가능합니다.

—Steve Jobs, CEO, Apple (from The Seed of Apple's Innovation)

프로세스6 장

실행가능한 소프트웨어를 향해서

실제로 실행이 가능한 것을 빨리 만드십시오.

동작하는 소프트웨어는 모멘텀을 만들 수 있는 최상의 방법이며, 팀의 활력을 불어넣고 나쁜 아이디어를 폐기할 수 있는 기회를 줍니다. 따라서 동작하는 소프트웨어를 만드는 것을 개발 첫째날부터의 최고 우선순위에 두어야 합니다.

동작하는 소프트웨어를 더 빨리 만들어내기 위해서라면, 일부 상세내용을 생략하거나 프로세스의 어떤 과정을 축소해도 됩니다. 동작하는 소프트웨어를 만들었을 때의 보답은 앞으로 어떻게 진행해야 할 지에 대해 훨씬 더 정확한 관점을 얻을 수 있다는 것입니다. 사용자 스토리, 와이어 프레임, 그리고 html로만 구현한 페이지들은 단지 추측에 불과합니다. 동작하는 소프트웨어만이 실제입니다.

실제 동작하는 소프트웨어가 있으면 모든 사람이 더욱 실제와 진실에 가까운 이해와 합의에 도달할 수 있습니다. 결국에는 소용없는 것으로 밝혀질 화면 스케치와 문서 내용에 대한 과열된 논쟁도 피할 수 있습니다. 원래 사소하다>고 생각했던 부분들이 실제로는 매우 중요하다는 사실을 깨달을 수도 있습니다.

실제 구현이 실제의 반응으로 이어지며 그것이 진실을 알 수 있는 방법입니다.

합의에 이르게 하는 실제 구현

사람들이 그들의 의견을 조화시키리면 실제가 어떨 지에 대해서 정확한 이해가 필요합니다. 만약 그들이 스케치와 의견 도출을 하고 있는 단계라면 합의에 이르기는 힘들 것입니다. 그러나 그들이 실제 구현을 하고 있다면 합의에 도달하기가 더 쉽게 됩니다.

—크리스토퍼 알렉산더, 아키텍쳐 교수
(Contrasting Concepts of Harmony in Architecture 아키텍쳐에서 조화의 상충하는 개념들에서)

최대한 빨리 동작가능하게 만드십시오.

나의 경험에 의하면 프로젝트의 규모가 크기에 상관없이, 실제 구현을 병행하지 않은 채 오랫동안 계획 기간을 가진 프로젝트가 스케쥴이나 비용, 기능의 측면에서 성공한 적이 없었습니다. 결국에는 불필요한 것으로 판명되거나 구현이 불가능할 기능을 고안하거나 개발하기 위해서 시간을 낭비하기가 매우 쉽습니다.

이것은 모든 수준의 개발에 해당하며, "실제로 동작하는 구현을 한다"는 진리입니다. 이것은 프로젝트의 전반에 걸쳐서만 적용되는 것이 아닙니다. 이 것은 더 작게 나누어진 컴포넌트들의 개발에도 적용됩니다.

주요 모듈의 동작하는 구현이 있다면, 개발자들은 자신들이 개발한 부분과 함께 잘 동작하는 지 알기 위해서 가능한 그 구현을 빨리 사용해보려고 할 것입니다. 나아가서 만약 그 구현 결과가 처음에 불완전 하다고 하더라도 이러한 빠른 개발자간 협업을 통해서 잘 정의된 인터페이스를 만들 수 있게 될 것이며 , 결국 그들이 원했던 대로 기능들을 구현할 수 있게 해줄 것입니다.

—매트 해머, 개발자 겸 프로덕트 매니저 Kinja

개선과 반복

반복 작업

한 번에 모든 것이 잘되기를 기대하는 것은 무리입니다. 어플리케이션이 점점 커지면서 개발자에게 직접 말하게 하세요. 스스로 변화하고 발전하게 하십시오. 웹 기반 소프트웨어에서는 완전한 상태로 출시할 필요는 없습니다. 화면을 디자인하고 사용하고 분석하십시오. 그리고 다시 반복하십시오.

미리 모든 것을 결정해버리는 것 대신, 반복개발 프로세스에서는 정보에 의한 결정을 하면서 진행해 나갈 수 있습니다. 또 실제 동작 가능한 어플케이션을 더 빨리 얻게 될 것이며, 그 결과로 실제 사용자들로부터의 피드백과 어디에 더 집중해야 할 지에 대한 가이드를 얻을 수 있습니다.

반복이 자유에 이르게 합니다.

어차피 계속 반복하게 될 것을 안다면, 한 번에 완전하게 하려고 하지 않을 것입니다. 어떤 문제를 나중에 다시 다루게 될 것을 안다는 것은 아이디어를 끄집어 내서 실제로 동작하는 지를 알게해주는 강한 동기로 작용합니다.

아마 여러분이 저 보다 더 똑똑할 것입니다.

아마 여러분이 저 보다 훨씬 더 똑똑할 것입니다.

그럴 가능성이 매우 높습니다. 하지만 여러분은 보거나 느끼거나 만질 수 없는 것을 잘 상상하지 못한 다는 점에서 다른 대부분의 사람과 같을 것이며 저 역시 그렇습니다.

사람은 주어진 환경에 대해서는 매우 잘 반응할 수 있습니다. 우리는 호랑이가 방으로 들어왔을 때 어떻게 공포에 질릴 지 알고 있습니다. 그리고 홍수가 쓸고간 뒤에 황페해진 공간을 깨끗이 치울 수도 있습니다. 하지만 불행히도 우리는 미리 계획을 세우는 능력은 매우 약합니다. 또 우리의 행동에 의한 결과를 예측하거나 정말로 중요한 일들의 우선순위를 가리는 것에도 그리 능하지 못합니다.

아마도 여러분은 이 모든 것을 다 잘할 수 있는 극소수 중의 한 명일 수도 있습니다. 하지만 그것은 그렇게 중요하지 않습니다.

웹 2.0은 (우리는 모든 사람이 웹을 사용하고 있다고 가정하고 있습니다.) 영리한 개발자이 사람들이 가진 것들을 사람들 자신을 위해서 다시 사용되도록 만든 것입니다. 그 방법은, 여러분의 사용자들이 여러분에게 뭔가 할 만한 일이 있는 것들에 대해서 그들이 생각하는 것을 말하게 하는 것이었습니다.

위의 마지막 문장은 여러분이 왜 우리가 제시하는 방식으로 개발해야하며, 어떻게 홍보하고 서비스를 시작해야할 지를 설명해줍니다.

여러분의 의도를 분명히 하고, 잘 작동하게 만드십시오. 그리고 나서 서비스를 개시하고 개선해 나가십시오. 다른 사람들이 여러분 보다 더 똑똑하다고 생각하지 마십시오

—세스 고딘, 저자/기업가

아이디어에서 구현까지

브레인스토밍에서 HTML으로 그리고 코딩으로

우리는 다음과 같은 순서로 'Getting Real'을 실천합니다.

브레인스토밍

아이디어를 가지고 어떤 제품을 만들 지를 정합니다. Basecamp의 예를 들면, 먼저 37Signal의 내부의 요구사항을 살펴보았습니다. 그 요구사항들은 다음과 같은 것들입니다. 프로젝트의 새로운 사항들에 대한 업데이트가 가능해야하며, 고객들이 직접 참여할 수 있어야 합니다. 또 프로젝트에는 마일스톤이 필요합니다. 참여자들이 지나간 것들에 대해서 쉽게 다시 살펴볼수 있는 하나의 저장소가 필요합니다. 높이 떠있는 새의 눈으로 보는 것 처럼 프로젝트 전반에 대한 큰 그림을 살필 수 있어야 합니다. 이러한 내용들을 모아서 밑그림을 그렸습니다.

이 단계는 시시콜콜한 세부사항들에 대한 단계가 아닙니다. 이것은 좀 더 큰 질문을 하는 단계입니다. 이 어플리케이션은 무엇을 하기 위한 것인가? 그것이 유용하다는 것을 어떻게 알 수 있는가? 우리가 만들고자 하는 것이 정확히 무엇인가? 이것은 비교적 높은 단계의 생각에 대한 것이며, 픽셀 수준의 토의를 위한 것이 아닙니다. 이 단계에서 아주 세부적인 사항들은 사실 의미가 없습니다.

종이 스케치

스케치는 빠르고 정확하지 않으며 비용이 거의 들지 않습니다. 여러분은 처음에 스케치로 시작해야합니다. 이것저것 아무렇게나 그려보세요. 박스와 원들과 선들을 그리세요. 머리속에 들어있는 생각들을 꺼내서 종이에 표현하세요. 이 단계의 목표는 머리속의 개념들을 대강의 인터페이스 디자인으로 바꾸는 것입니다. 이 것은 일종의 실험의 단계로 정확한 결과를 만들려는 것은 아닙니다.

HTML 페이지 만들기

기능들에 대해서 html 페이지들을 만드세요. 사람들이 화면에서 실제로 보고 느낄 수 있도록 하세요.

Basecamp의 경우에는 가장 중요한 기능인 "메시지 등록" 화면을 제일 먼저 만들었습니다. 그리고 "메시지 편집"기능을 만들었습니다.

하지만 아직 동작을 위한 코딩은 하지마세요. 단지 html과 css로 겉모양만 만드세요. 구현은 나중에 할 일입니다.

코드 작성

html로 만든 겉모양이 마음에 들고 필요한 기능들이 충분하다고 판단이 되면, 실제 동작을 위한 코딩을 시작하세요.

이러한 과정에서 항상 유연한 자세를 유지해야 하며, 여러번 반복이 될 수 있다는 것을 기억하세요. 어떤 단계에서라도 하고 있던 내용을 던져버리고 처음부터 다시 시작할 수 있습니다. 전체 단계를 여러번 반복하는 것은 자연스럽고 당연한 일입니다.


사용자 설정을 피하세요

중요하지 않은 세부사항의 동작 방식은 사용자가 직접 결정을 하지 않아도 되도록 한 가지로 정해야 합니다.

우리가 자주 만나는 어려운 문제는 "하나의 페이지에 얼마나 많은 메시지나 의미를 담을 것인가?" 이며, 처음 이런 문제를 만났을 때, 아마 이렇게 생각할겁니다. "사용자가 설정할 수 있도록 하자. 25 나 50 아니면 100으로 설정할 수 있도록." 이런 식의 접근이 더 쉬울 지 모르지만, 바람직한 것은 그 중 어느 한 가지로 정하는 것입니다.

사용자 설정을 추가하는 것은 어려운 결정을 회피하는 것입니다.

전문성을 사용해서 가장 좋은 방식을 정하는 대신, 우리는 고객에게 그것을 미루고 있습니다. 이런 방식이 사용자에게 친절을 베푸는 것으로 보일 수도 있습니다. 그러나 사실은 그들을 성가시게 만드는것입니다.(고객은 그렇지 않아도 충분히 바쁩니다.) 사용자 입장에서는, 끝 없는 선택 사항들로 가득찬 사용자 설정 화면은 두통거리이지 결코 축복이 아닙니다. 사용자는 모든 자잘한 사소한 것들에 대해서 생각할 필요가 없어야 합니다. 그러한 부담을 사용자들에게 떠 넘기지 마세요. 그것은 우리의 책임입니다.

사용자 설정은 더 많은 개발이 필요하게 된다는 점에서 더욱 나쁩니다. 더 많은 옵션은 더 많은 코드를 요구하게 됩니다. 또한 이에 따른 테스트와 디자인 또한 필요하게 됩니다. 하지만 이렇게 개발하게 될 여러가지 설정 조합에 따른 사용자 화면들은 결국 거의 사용되지 않을 것입니다. 이 것은 당신이 발견하지 못한 버그들, 깨어진 화면 레이아웃, 엉망인 테이블들, 이상한 페이징과 같은 이슈들이 존재한다는 것을 의미합니다.

결정하세요

사용자들을 대신해서 단순한 내용들을 결정하세요. Basecamp에서는 다음과 같은 결정들을 사용자 대신 했습니다. 페이지당 메시지 수는 25개. 전체 개요 페이지에서 보여지는 최근 항목수는 25개. 메시지들은 시간 역순으로 출력되도록 했습니다. 다섯 개의 최근 프로젝트가 대쉬보드에 보여집니다. 이런 기능들에서 어떤 옵션도 사용자들에게 제공되지 않으며, 그냥 있는 그대로 사용하게 됩니다.

물론, 당신의 결정이 틀릴 수도 있습니다. 하지만 상관없습니다. 만약 당신이 틀렸다면 사람들을 그 것에 대해서 불만을 제기할 것이고, 언제나 그렇듯이 고치면 그만입니다. Getting Real 은 바로 바로 수정할 수 있는 것에 대한 것입니다.

사용자 설정은 비용이 듭니다.

사용자 설정을 제공하기 위해서는 비용이 듭니다. 물론 어떤 사용자 설정은 무시할 수 없는 편의를 제공하거나 인터페이스 측면에서 핵심적인 부분이 될 수도 있습니다. 하지만 각각의 설정은 그 댓가를 지불해야 하므로 그 가치에 대해서 주의깊에 고려해야 합니다. 많은 사용자와 개발자들이 이 점을 이해하지 못하고, 많은 비용을 들여서 별 가치가 없는 설정기능들을 만들어냅니다. 만약 여러분이 단순히 사용자 설정을 추가하는 방식에 비해, 더 단순하면서도 훨씬 잘 동작하는 기본 설정을 가지는 방식에 대해 잘 훈련받았다면, 전체 사용자 인터페이스는 올바른 방향으로 개발될 수 있을 것입니다.

—Havoc Pennington, 기술 책임자, Red Hat ( Free software and good user interfaces)

일단 정하세요

결정이란 어차피 임시적인 것입니다. 그러니 일단 정하고 게속 진행하세요.

결정. 이 단어를 마법의 단어로 생각하세요. 어떤 것을 결정지었다는 것은 무언가를 성취했다는 것입니다. 하나를 결정 짓고 나면 그 다음을 진행할 수 있습니다. 그리고 이런 결정들이 이어질 때 추진력이 커집니다.

하지만 만약 우리가 뭔가 잘 못 결정해서 망쳐버린다면 어떻게 될까요? 사실 별 상관없습니다.우리는 뇌수술을 하는 게 아니라 그냥 웹페이지를 만들고 있을 뿐입니다. 계속 반복해서 말하고 있지만, 전체 개발 과정에서 우리는 모든 기능들과 개념들을 여러 번 반복해서 수정하고 개선하게 될 것입니다. 우리가 얼마나 오래 계획했는 지에 상관없이 항상 절반은 잘못된 방향으로 갈 것입니다. 따라서 일을 지나치게 분석하다가 마비상태가 되는 잘못을 범하지 마세요. 지나친 분석은 일의 진행을 늦추고 의욕을 떨어뜨릴 뿐입니다.

그 대신, 계속해서 점진적으로 진행해 나가는 것의 중요성을 인식하세요. 결정을 계속해 나가는 리듬을 만들세요. 우선 신속하고 심플한 결정을 내리고, 문제가 생긴다면 나중에 다시 고치세요..

결정들이란 임시적일 뿐이라는 사실을 받아들이세요. 실수란 일어나게 마련이며, 그 것을 빠르게 바로잡을 수 있는 한 별 문제가 되지 않는 다는 사실을 인식하세요. 실행하고 추친하여 계속 앞으로 나아가세요.

실행자가 되세요.

사람들이 아이디어의 노출에 대해서 지나치게 두려워하는 것을 보면 정말 재미있습니다. (그들은 너무나도 단순한 아이디어를 얘기하기 위해서 나에게 NDA를 맺자고 합니다.)

내게 있어 아이디어는 실행되지 않는 이상 아무 가치가 없습니다. 아이디어가 가치를 배가 시킬 수는 있습니다. 하지만 실행이야 말로 수백만 배의 가치가 있는 것입니다.

부가 설명:

  • 말도 안되는 아이디어 = -1
  • 낮은 수준의 아이디어 = 1
  • 그저 그런 아이디어 = 5
  • 좋은 아이디어 = 10
  • 뛰어난 아이디어 = 15
  • 정말로 멋진 아이디어 = 20
  • 실행 안됨 = $1
  • 낮은 수준으로 실행 = $1000
  • 그저 그런 수준의 실행= $10,000
  • 좋은 수준의 실행 = $100,000
  • 뛰어난 수준의 실행= $1,000,000
  • 정말로 멋진 실행 = $10,000,000

비지니스의 가치는 위의 두 요소를 곱한 결과가 됩니다.

가장 멋진 아이디가 실행되지 않는다면 가치는 20달러에 불과하지만, 뛰어난 수준으로 실행되는 경우에는 20,000,000달러의 가치를 가지게 됩니다.

이것이 바로 내가 사람들의 아이디어를 잘 듣지 않는 이유입니다. 나는 그 실행결과를 보기 전에는 아이디어 자체에 관심을 가지지 않습니다.

—Derek Sivers, 대표 겸 프로그래머, CD Baby 와 HostBaby

실전에서 테스트하세요

실제로 사용되는 방식을 통해서 어플리케이션을 테스트하세요

실제 사용자를 대신 할 수 있는 것은 없다. 실제 데이터를 모으세요. 실제 사용자들로부터 피드백을 받으세요. 그리고 이 정보들을 바탕으로 개선하세요.

공식적인 사용성 테스트는 너무 굳어 있습니다. 실험실에서의 환경은 실제를 그대로 반영할 수 없습니다. 만약 당신이 누군가의 어깨 너머로 (그 사람이 알지 못하는 상태에서) 살펴본다면, 실제 상황에서 어떤 일이 벌어지는 지 제대로 알 수 있을 것입니다. 하지만 사람들을 카메라 앞에서는 평소와 다르게 행동하는 경향이 있습니다. 그들은 실수를하지 않기 위해서 평소보다 더 주의를 기울이게 됩니다. 사실 실수야 말로 우리가 찾고 있는 것인데도 말입니다.

따라서, 일부 선택된 사람들을 대상으로 실제 어플리케이션의 베타 버전을 릴리스하세요. 그들은 실제 환경에서 실제의 사용절차와 데이터들을 가지고 그 기능들을 사용하게 될 것이며, 우리는 실제 결과를 얻을 수 있을 것입니다.

그리고, 정식 릴리스 버전과 베타 버전을 따로 유지해서는 안됩니다. 언제나 하나만 유지해야 합니다. 별도의 베타 버전은 결국 별도의 버전에 그치고 맙니다. 몇가지 베타 기능들이 추가된 실제 버전을 유지하는 것이 바람직합니다.

베타 북

개발자들이 코드를 정식으로 릴리스하는데 신경을 많이 쓰는 정도라면, 책을 만드는 이들은 책을 출간하는 것에 대해서 거의 무서워하는 수준입니다. 일단 책이 종이에 인쇄되는 단계를 지나면, 뭔가를 변경하는 것은 정말 힘든 일인 것으로 보여집니다.(사실을 말하자면 그렇지 않습니다. 이런 인식을 가지게 된 것은 과거의 인쇄 기술에서 기인한 우리의 기억과 경험이 아직도 현재 까지 널리 퍼져있기 때문입니다.) 그래서 책을 만드는 사람들은 책이 인쇄되기 전에 제대로된 책을 만들기 위해서 많은 노력과 고생을 합니다.

내가 'Agile Web Development With Rails'을 썼을 때, 수많은 개발자들로 부터 '레일스를 빨리 배울 수 있도록 당장 책을 볼 수 있게 해달라'는 요구가 있었습니다. 하지만 처음에 나는 책을 만드는 사람의 입장에 빠져서 아직 책이 준비되지 않았다고 말했습니다. 그러나 대중들로부터의 압력과 레일스를 만든 David Hainemeier Hansson(DHH) 의 권유는 내 마음을 바꾸었습니다. 우리는 책이 완성되기 두 달 전에 PDF형태로 책을 릴리스 했고 그 결과는 놀라웠습니다. 우리는 엄청난 양의 책을 팔았을 뿐 아니라 독자들로부터 많은 피드백을 받을 수 있었습니다. 나는 독자들의 코멘트를 자동으로 정리할 수 있는 자동화 시스템을 만들었고, 약 850개의 피드백과 오탈자, 기술적 오류 그리고 새로운 내용에 대한 제안을 받을 수 있었습니다. 그 대부분이 책의 완성판을 만드는데 도움이 되었습니다.

이것은 win-win 이었습니다. 나는 훨씬 더 개선된 책을 만들 수 있었고, 사람들은 더 빨리 그들이 원하는 것을 얻을 수 있었습니다. 만일 여러분이 경쟁적인 상태에 있다면 뭔가를 조금이라도 더 빨리 만드는 것은 여러분을 경쟁자보다 더 유리하게 해줄 것입니다.

—Dave Thomas, The Pragmatic Programmers

신속하게 하라

  • 1. 만약 그럴 가치가 있다면 결정지어라. 그리고 그랬다면
  • 2. 빨리 실행하라 완전하지 않더라도 실행하라.
  • 3. 저장하고 업로드하고 퍼블리시 하라.
  • 4. 사람들이 어떻게 받아들이는 지 확인보라.

      • 나는 새로운 기능을 추가하는 것을 항상 주저하는 편이지만, 일단 그것이 할 가치가 있다고 판단하는 순간이 되면, 몇 시간내로 그것은 웹사이트에 올려집니다. 비록 에러가 좀 있어도 사용자들의 피드백을 받으면서 점점 개선해 나갑니다.

      —Derek Sivers, 대표 겸 프로그래머, CD Baby , HostBaby

시간을 작게 나누어세요.

일을 쪼개세요.

여러 주 혹은 여러 달에 걸치는 일을 가늠하고 예측할 수 있다는 것은 환상에 불과합니다. 사실 당신은 그렇게 먼 앞날에 어떻게 될 지 미리 알 수 없습니다.

따라서 시간을 줄여야 합니다. 전체 시간을 더 작은 조각들로 계속 나누어야 합니다. 12주가 걸리는 하나의 프로젝트 대신 12 개의 1주짜리 프로젝트들로 나누어야 합니다. 30시간 이상이 소요되는 일들을 예측하고 계획하는 대신, 6시간에서 10시간이 걸리는 일의 조작들로 나누어야 합니다. 그리고 한 번에 하나씩 진행해 나가세요.

동일한 원리는 다른 문제들에도 똑같이 적용됩니다. 당신이 해결하기 힘든 큰 문제에 직면하고 있다면, 그 문제를 쪼개세요. 더 작게 더 작게 당신이 잘 소화할 수 있는 조각들이 될 때까지 나누세요.

더 작은 일의 조각들, 더 작은 시간표

소프트웨어 개발자들은 특별한 낙관론을 가지고 있습니다. 어떤 개발 업무를 만나게되면 그들은 "흠 쉬워보이는군. 그렇게 오래 걸리지 않을거야" 라고 생각합니다.

그래서 만약 3주의 시간이 있다면, 개발자는 2주와 절반을 이리 저리 헤메면서 보내고 그 나머지 기간에 개발을 할 것입니다. 잘못 정의된 요구사항은 처음에 보이는 것보다 훨씬 복잡한 것으로 판명되기 마련이므로 결과물>은 스케쥴을 지나서 완료될 것입니다. 또 결과가 나온다고 해도 3주나 전에 팀이 합의한 사항에 대해서는 아무도 정확히 기억하지 못할 것입니다.

프로그래머에게 오후에 코딩할 수 있는 작은 분량을 할당하세요. 특정한 모듈을 명확히 지정해서 개발자 그것을 정확히 돌아가게 만든 후에 다음단계를 준비할 수 있도록 해야합니다.

더 작은 업무 단위와 더 짧은 시간 계획들이 더 관리하기 좋습니다. 또 요구사항에 대한 오해를 줄일 수 있고, 마음이 바뀌어서 변경이 필요할 때 변경 비용을 줄여줍니다. 더 짧은 시간계획은 개발자가 더 자주 성취감을 느끼게 해주고, "음 남은 시간이 많으니까 지금은 iTunes에서 음악 라이브러리나 좀 정리하자"와 같은 생각을 할 기회를 줄여줍니다.

—Gina Trapani 웹개발자겸 편집자, Lifehacker 'the productivity and software guide'에서

진정한 요소들

다음 번에 어떤 사람이 정확한 답을 하기 어려운 — 프로젝트 완료일이나 최종 개발 비용 또는 그랜드 캐넌을 모두 채울 수 있는 우유의 양과 같은 — 질문들을 해서 당신을 괴롭히려 한다면 일단 다음과 같이 말해서 분위기를 바꾸는 것이 필요합니다. "모릅니다."

이 답변은 사실 당신의 신뢰성을 떨어뜨리는 대신 당신이 결정을 내리는데 얼마나 주의를 기울이는 지를 보여주게 됩니다. 똑똑하고 다아는 체하는 말들을 하지 마세요. 이렇게 함으로써 질문 답변에 대한 역할을 당신 혼자에서 전체의 대화로 바꿀 수 있게 됩니다. 당신의 예측이 얼마나 정확해야하는지 또 왜 그래야하는 지를 알게됨으로써 당신은 수치들 뒤에 숨어 있는 진정한 요소들에 대한 전체의 이해를 높일수 있게됩니다.

—Merlin Mann, 43folders.com의 편집자 겸 개발자

Solve The One Problem Staring You in the Face 당장 직면하고 있는 첫번째 문제를 해결하세요.

최근에 웹에서 일어난 일 중에 가장 좋았던 일은 'nofollow' 속성의 채택입니다. 그 전 아무도 그것에대 해 얘기한 사람들이 없었습니다. 컨퍼런스나 협의체도 없었고, 따라서 그 의미나 문법적 속성에 대해서 수많은 논쟁을 하지도 않았습니다. RFC도 없었습니다. 사실 RFC로 정의되면 정말 단순한 아이디어도 20줄이 넘는 XML로 정의될 것이며, 버전 3을 보는지 3.3b를 보는지를 확신할 수 없기 때문에 결국 사용하지 못하게 될 것입니다.

'nofollow'의 구현은 단순하고 효과적이며, 그 옵션을 원하는 사람들만이 사용할 수 있도록 해줍니다. — 이것은 스펙의 준수같은 것은 신경쓰지 않는 대다수의 웹 관련자들을 고려할 때 훨씬 더 좋은 방식입니다.

어떨 때는 20개의 문제를 해결하는 것보다 당장 직면한 하나의 문제를 해결하는 것이 더 유용합니다. 그것은 단지 스팸에 대한 작은 승리가 아니었으며(스팸에 대한 모든 승리는 작은 것입니다.) 사실 단순함과 재빠른 결과를 선호하는 우리 모두의 승리였습니다.

—Andre Torrez, Federated Media Publishing프로그래머 겸 엔지니어링 담당이사

조직제 7 장

통합

여러 부