Getting Real이란?
성공적인 웹어플리케이션을 만들고 싶으세요? 그럼 이 "Getting Real"을 적용하세요. Getting Real은 보다 작고, 빠르고, 좋은 소프트웨어 구축을 위한 방법입니다.
Getting Real은 실제를 대신하는 도구들(차트나 그래프, 박스, 화살표, 도식, 와이어 프레임. 등) 대신, 실제의 업무를 구축합니다. Getting Real은 날씬합니다. 복잡하지 않고, 소프트웨어를 줄이며, 특징 기능은 보다 줄이고, 사무 작업도 줄이고 기본적이지 않은 모든 것들을 줄여줍니다. (당신이 필수불가결하다라고 생각하는 것의 대부분은 실제로 그렇지 않습니다). Getting Real은 작게 지속되며, 신속 기민하게 유지됩니다. Getting Real은 사람들이 사용할 때 보는 실제의 화면인 인터페이스로부터 시작합니다. 사람들의 체험에서 시작하여 차츰 시스템을 구축해 나갑니다. 그러면 소프트웨어는 잘못된 방향으로 가지 않게 하고, 올바른 인터페이스를 얻을 수 있습니다. 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에 의해 줄일 수 있는 것들... 몇 개월 혹은 몇 년이나 걸리는 긴 스케줄 믿을 수 없는 기능 스펙 확대되는 논쟁 끝없는 스탭 미팅 '필요'라는 이름으로 고용된 많은 인원 무의미한 버젼 넘버들 완벽한 장면을 그린 초기의 로드맵 끝없는 환경 설정 옵션 아웃소싱 기반의 고객 지원 비현실적인 유저 테스트 쓸데 없는 사무 작업 Top-down 방식 구조 훌륭한 소프트웨어를 개발하기 위해서, 큰 돈이나 거대한 팀, 또는 긴 개발 사이클은 필요 없습니다. 그런 것들은 대체로 스피드가 늦고, 애매하고, 수정할 수 없는 어플리케이션이 태어나는 것입니다. 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
적은 구현(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)
가벼울 수록, 변화하기가 쉬워집니다. 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" 개발시에 많은 제약이 있었습니다. 그것은：
운영 디자인 회사 결정 기존의 고객과의 일 7시간의 시차(프로그래머 David은 덴마크에서 개발하고 있었고, 나머지는 미국에서 있었습니다.) 작은 팀 외부 조달 투자가 없는 상태 우리는, "충분하지 않다"라고 투덜대고 있었습니다. 우리는 그릇을 작게만 하고 있었습니다. 작은 그릇은 담을 수 있는 양도 정해져 있습니다. 우리는 큰 태스크를 작은 단위로 쪼갠 후 한번에 한 개씩 실행 했습니다.. 사전 우선순위를 결정한 대로 단계별로 해결해 나갔습니다.
그것은 우리로 하여금 창의적인 제품을 개발할 수 있게 해주었습니다. 언제나 작은 규모로 소프트웨어를 개발하여 우리는 변경 비용을 낮췄습니다. 사람들에게 스스로의 문제를 스스로의 방법으로 해결하는데 충분한 특징을 도입해, 그들에게 맡겼습니다. 우리들 내부의 시차와 거리의 문제는 커뮤니케이션을 함에 있어 보다 효율적으로 할 수 있게 해주었습니다. 사람과의 미팅 대신에, 대부분 메신저와 전자메일로 커뮤니케이션 하였으며, 이것이 우리의 문제에 대해 빠르게 집중할 수 있었습니다.
제약사항은 가끔씩은 우리에게 장점이 됩니다. 벤처캐피털, 긴 제품 출시 일정, 고용은 잊어버리고, 가지고 있는 자원으로 일에 전념하세요.
해충과 싸우세요
"Creeping elegance"(프로그래머들이 지나치게 고상함에 집착하여 소프트웨어의 기능성이나 스케쥴, 사용성을 다소 무시하는 현상)는 "기능 해충"으로 표현하는 것이 더 적절할 지도 모릅니다. 이것은 식물의 진액을 빨아먹고식물 전체를 서서히 망가뜨리는 곰팡이와 같습니다. 소프트웨어에서 기능 해충을 방지하는 가장 쉬운 방법은 물론 데드라인을 압박하는 것입니다. 데드라인에 대한 압박은 구현이 오래 걸리는 기능들을 제외하게 만듭니다. 하지만 일반적으로는 가장 중요한 기능이 구현하는 데 시간도 가장 오래걸립니다. 따라서 기능 해충과 데드라인의 조합은 중요하지 않은 기능들로만 가득찬 소프트웨어라는 결과를 만들게 되므로 주의해야 합니다.
—Jef Raskin, 저자 ( "Why Software Is the Way It Is" 에서) 있는 그대로
대기업과는 다른 사람의 마음을 생각한 친밀감 있는 방법으로 접근하세요. 많은 작은 기업들이 스스로를 크게 보이게 하려고 행동하는 실수를 합니다. 스스로 작은 규모를 극복 해야할 약점으로서 생각하는 것 같습니다. 안타깝습니다. 작은 것은 큰 무기입니다-특히 커뮤니케이션의 부분에서는 더 그렇습니다.
작은 회사는 격식이 적고, 관료적인 것이 덜하고, 보다 자유롭습니다. 기본적으로 작은 회사는 고객과 가까운 위치에 있습니다. 그것은 고객과 직접 개개인에 접근 할 수 있는 방법으로 커뮤니케이션이 생기는 것입니다. 만약 작은 조직이라면, 까다로운 전문 용어를 사용하지 않고 더 친밀한 말로 이야기를 할 수 있습니다. 당신의 사이트나 제품은 기업의 선전문구가 아닌, 인간의 메시지를 전할 수 있습니다. 작은 규모라는 것은 고객을 깔보는 것이 아닌 고객과 대화할 수 있는 것입니다.
작은 회사에서는 조직 내부의 커뮤니케이션에도 장점이 있습니다. 무엇인가의 서류에 좌지우지되지 않고, 쓸데없이 복잡한 프로세스나 여기저기의 승인 도장도 필요 없게 됩니다. 어느 과정에서도 멤버 전원이 오픈 마인드로 정직하게 이야기할 수 있습니다. 아이디어에 속박이 없는 흐름은, 작은 규모의 큰 이점의 하나입니다.
당당히 정직하게
어쩌면 소비자는, 기업의 종업원수나 제품의 수, 즉 기업의 규모를 과장하면 속아 버릴 것이라고 생각할지도 모릅니다만, 영리한 사람(즉 당신이 정말로 타켓으로 하고 싶은 사람)은, 언제나 진실을 압니다. 창피한 이야기입니다만, 저도 과거에 이러한 자신을 크게 보이려고 했던 한 명입니다. 그러나, 그러한 일을 해도, 비즈니스가 의미 있는 것이 되어, 스스로의 서비스를 정말로 필요로 하고 있던 고객과의 관계가 계속 되어 신뢰 깊은 관계가 생긴 일은 없었습니다. 결국, 회사의 실제의 규모가 작아도 부끄러워하는 않고, 솔직하게 말하면 좋습니다.
—Khoi Vinh, Subtraction.com 언제라도
고객에게 있어서 좋은 고객 서비스는 어떤 비즈니스든지 최대의 기대사항입니다. 우리 조차도 그것을 바라는데, 고객은 어떻겠습니까? 초창기부터 우리에게 문의하는 모든 고객 및 모든 질문에 투명하게 대응했습니다. 웹 사이트에서는 무료 전화 번호를 기재하여, 우리 휴대폰으로 오게 했고, 명함에도 각자의 휴대폰 번호를 기재했습니다. 우리는 고객에게 무슨 일이 일어나든지 우리에게 연락할 수 있다고 강조했습니다. 고객들은 이러한 신뢰에 대해 고마워했고, 이 서비스에의 클레임은 없습니다.
—Edward Knittel, Director of Sales and Marketing, KennelSource
커다란 아이디어
친근하고 인간적인 방식으로 대기업과 차별화하세요. 어플리케이션이 지향하는 바를 구체적으로 하나 정의하세요. 무엇을 위한 서비스인가요? 디자인이나 코딩을 하기전에 어플리케이션의 비전을 분명히 알아야 합니다. 크게 생각하세요. 왜 이 것이 필요합니까?, 다른 비슷한 서비스와의 차별성은 무엇인가요?
비전이 있으면 여러가지 결정들을 일관되게 할 수 있고 한 방향으로 나아갈 수 있습니다. 뭔가 혼란스러운 상황이 발생하면 스스로에게 물어보세요. "이 것이 우리의 비전과 일치하는가?"
비전은 간결해야 합니다. 핵심적인 생각을 전달할 수 있는 한 개의 문장이면 됩니다. 다음은 37Signals 각 서비스의 비전들입니다.
Basecamp: 프로젝트 관리는 의사소통이다. Backpack: 생활의 앞뒤를 맞추자. Bring life's loose ends together Campfire: 글러먹은 메신저 대신 할 그룹 채팅 Ta-da List: 포스트잇과 경쟁하자 Writeboard: MS워드는 너무 복잡해 Basecamp의 비전은 "프로젝트 관리는 의사소통이다"입니다. 효과적인 의사소통은 프로젝트에 소속된 모든 이들의 참여의식과 주인의식을 높여줍니다. 또 모든 사람들이 공통의 목표를 향해 일할 수 있게 해줍니다. Basecamp가 이런 비전을 잘 만족시킬 수 있다면 다른 모든 것들은 상대가 안될 것입니다.
Basecamp의 비전은 더 개방적이고 더 투명한 구현결과를 이끌었습니다. 프로젝트를 하는 회사 내로만 의사소통을 제한하는 대신에 고객들도 접근 할 수 있도록 했으면, 접근 권한보다는 모든 관련자들이 적극적으로 참여할 수 있게 하는 데 더 주안 점을 두었습니다. 챠트나 테이블, 보고서, 통계자료 같은 기능을 제공하지 않고 메세지, 코멘트, to리스트, 파일 공유 등의 기능에 더 집중한 것도 그 때문입니다. 비전을 정하는 것은 큰 결정이지만 일단 비전을 정하고 나면 그 뒤의 세부적인 결정들은 훨씬 쉬워집니다.
화이트보드의 철학
앤디헌트와 나는 한 때 현금 카드 거래 시스템을 개발했습니다. 주요 요구사항은 사용자 계좌에서 동일한 건에 대해 출금이 두 번 발생하는 일을 방지하는 것이었습니다. 차라리 처리가 되지 않는 한이 있더라도 똑 같은 처리가 두번 발생하는 일은 절대 없어야 했습니다.
그래서 우리는 그것을 화이트보드에 큰 글자로 써두었습니다. "사용자에게 에러가 나는 것이 차라리 더 낫다."
그 외에도 대여섯개의 원칙들을 함께 정했고, 이렇게 정해진 원칙들은 다른 결정하기 까다로운 세부사항들을 쉽게 결정할 수 있게 해주었습니다. 또 이 원칙들은 내부적으로 응집력이 있고 외부적으로는 일관성이 있는 어플리케이션을 만들 수 있도록 도와주었습니다.
—Dave Thomas, The Pragmatic Programmers 슬로건을 만드세요.
조직에는 슬로건이 필요합니다. 구성원들이 매일 잠에서 깨어나서 일하러 갈 때 마음 속에 기억하고 있어야할 바로 그 것말입니다. 슬로건은 간결하고 분명해야 합니다. 슬로건은 서너 단어로 정도가 적당합니다. 우리의 존재 이유는 무엇인가? 우리의 동기는 무엇인가? 에 대한 답을 해줄 수 있는 것이 바로 슬로건입니다.
—Guy Kawasaki, 저자 (from Make Mantra) 초기에는 시시콜콜한 것들은 무시하세요.
큰 것에서부터 작은 것으로 진행하세요. 우리는 세부사항에 집착하는 경향이 있습니다.
화면 요소간의 공간 The perfect type leading 완벽한 색이 사용 완벽한 문구 7줄 대신 4줄로 구현하기 89% 대 90% 750픽셀 대 760픽셀 한달에 39달러와 49달러 성공과 만족은 세세한 것에 있습니다.
세세한 것에 성공의 요인이 있다고들 말합니다. 틀린말은 아닙니다. 하지만 그 것이 다가 아닙니다. 의견 불일치, 회의, 지연 이런 것들도 모두 세세하고 시시콜콜한 것들에 집착할 때 생기는 것들입니다. 이 런 것들은 팀의 분위기를 죽이며 성공의 가능성을 줄입니다.
단 하나의 코드 조각이나 한 부분의 디자인 때문에 하루 온 종일을 소비하는 경우가 얼마나 됩니까? 하루동안 열심히 일했지만 실제로 별로 진행된 것이 없다는 것을 깨닫는 경우가 얼마나 자주 있습니까? 이런일은 너무 이른 시점에 세부적인 내용에 집착할 때 생깁니다. 완벽주의자를 위해 준비된 시간은 충분히 있습니다. 그냥 나중에 하면 됩니다.
개발 첫 주에 헤더의 폰트 크기에 대해서 걱정하지 마세요. 둘 째 주에 맘에 딱 드는 녹색을 찾으려고 하지 마세요. 세 째 주에 '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의 어플리케이션들도 이와 같은 방식을 따랐습니다. 모든 사람을 만족시키려고 하는 대신, 각 어플리케이션의 고유의 방식을 가지려고 했습니다. 그리고 어플리케이션의 동반자가 되어줄 고객 부류를 찾아서 그들과 비전을 공유하였습니다. 여러분도 우리와 같은 버스에 동승하는 것은 어떻습니까?
제대로 된 절반
반은 엉망인 제품을 만들지 말고 반만 만들어도 제대로 만드세요. "물빠지는 구멍이 없는 것만 빼고는 완벽한 부엌"과 같은 상황을 조심하세요. 좋은 아이디어라고 해서 모두다 추가하려다보면 결국 어느 하나 제대로 동작하는 것이 없는 상태가 되고 맙니다. 중요한 것은 일부분이라도 핵심적인 부분을 확실히 동작하도록 만드는 것입니다.
진짜 핵심인 부분에 집중하세요. 좋은 아이디어들을 종이에 나열해서 적으세요. 서비스에 필요하다고 생각되는 것들을 모두 적은 다음에 그 중 절반을 골라서 버리세요. 정말 핵심적이라고 생각되는 기능들만 남겨놓고 나머지를 버리세요. 이 과정을 반복하세요.
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 모든 새로운 기능에 대해서 다음과 같이 하세요.
- '아니오'라고 말합니다.
- 그 기능이 스스로의 가치를 증명하도록 합니다.
- 만약 다시 '아니오'이면 끝, 만약 '예'이면 계속
- 화면을 스케치합니다.
- 화면을 디자인합니다.
- 코드를 짭니다. 7-15. 테스트하고 고치고, 테스트하고 고치고, 테스트하고 고치고...
- 도움말의 내용이 수정되어야 한다면 그렇게 합니다.
- 필요하면, 서비스 둘러보기를 업데이트합니다.
- 필요하면, 홍보 문구를 업데이트 합니다.
- 필요하면, 서비스 계약 문구를 업데이트합니다.
- 기존에 계약 조건에 대한 위반이 없는 지 살핍니다.
- 가격 정책에 영향이 없는 지 살핍니다.
- 실제 서비스에 적용합니다.
- 이제 한 숨 돌립니다.
관리가 가능한가요?
관리할 수 있는 것을 개발하세요. 만약에 여러분이 어떤 가입형 서비스를 시작한다면 계정관리과 지불을 처리할 수 있는 시스템을 가지고 있어야 합니다. 여러분은 회원의 요금이 지불 수단으로 매달 직접 현금이나 수표를 송금하는 방식이 아니라 신용카드를 이용한 결제 수단이 필요할 겁니다.
여러분은 구글과 똑같이 무료로 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)
실행가능한 소프트웨어를 향해서
실제로 실행이 가능한 것을 빨리 만드십시오. 동작하는 소프트웨어는 모멘텀을 만들 수 있는 최상의 방법이며, 팀의 활력을 불어넣고 나쁜 아이디어를 폐기할 수 있는 기회를 줍니다. 따라서 동작하는 소프트웨어를 만드는 것을 개발 첫째날부터의 최고 우선순위에 두어야 합니다.
동작하는 소프트웨어를 더 빨리 만들어내기 위해서라면, 일부 상세내용을 생략하거나 프로세스의 어떤 과정을 축소해도 됩니다. 동작하는 소프트웨어를 만들었을 때의 보답은 앞으로 어떻게 진행해야 할 지에 대해 훨씬 더 정확한 관점을 얻을 수 있다는 것입니다. 사용자 스토리, 와이어 프레임, 그리고 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 신속하게 하라
- 만약 그럴 가치가 있다면 결정지어라. 그리고 그랬다면
- 빨리 실행하라 완전하지 않더라도 실행하라.
- 저장하고 업로드하고 퍼블리시 하라.
- 사람들이 어떻게 받아들이는 지 확인보라.
나는 새로운 기능을 추가하는 것을 항상 주저하는 편이지만, 일단 그것이 할 가치가 있다고 판단하는 순간이 되면, 몇 시간내로 그것은 웹사이트에 올려집니다. 비록 에러가 좀 있어도 사용자들의 피드백을 받으면서 점점 개선해 나갑니다.
—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 장 통합
여러 부서로 나누지 마세요. 대부분의 회사들은 디자인, 개발, 카피라이팅, 지원, 마케팅 부서들을 별도의 조직으로 나눕니다. 물론 전문화는 그 장점이 있습니다, 하지만 이런 방식에서는 각 팀원들은 자신의 좁은 영역만을 보게 되며 웹어플리케이션 전체에 대한 문맥을 보기 어렵>게 됩니다.
가능한 전체 팀을 통합하여 상하 좌우간의 활발하고 건강한 논의가 개발 과정에서 일어나도록 하는 것이 좋습니다. 이렇게 하면 점검과 균형을 위한 시스템이 만들어집니다. 부서간의 의사 전달과정에서 중요한 내용이 사라지는 일이 없도록 해야 합니다. 카피라이터는 디자이너와 함께 일해야 합니다. 지원 게시판의 내용들은 개발자들이 바로 볼 수 있어야 합니다.
더 나은 방법은 개발 과정에서 여러가지 역할을 할 수 있는 멀티플레이어를 채용하는 것입니다. 그렇게 하면 더 조화로운 결과물을 얻게 될 것입니다.
혼자 있는 시간
사람이 일을 해내기 위해서는 방해받지 않는 시간이 필요합니다. 37signals는 4개 도시의 8개 타임존에 걸쳐서 일하고 있습니다. 유타의 프로보에서 덴마크의 코펜하게까지 우리 5명은 8개의 시간대에 떨어져 있습니다. 이런 상황의 한가지 좋은 점은 혼자 있는 시간이 보장된다는 것입니다.
우리 모두가 동시에 함께 일할 수 있는 시간은 하루에 4-5시간에 불과합니다. 다른 시간에는 덴마크에 있는 데이비드가 일하는 동안 미국팀이 잠을 자며, 데이비드가 자는 동안에는 우리가 일합니다. 그래서 하루의 절반은 함께 일하고 절반은 혼자 일하>게 됩니다.
우리가 대부분의 일을 실제로 해내는 시간은 어느 쪽일까요? 물론 혼자 있는 시간입니다. 별로 놀라운 일도 아닙니다. 많은 사람들이 아침 일찍 또는 밤 늦게 일하는 것을 선호하는데 그것은 그 때 그들이 방해받지 않고 일할 수 있기 때문입니다.
오랜 동안 방해받지 않고 일을 계속하면 어떤 '상태'에 도달하게 됩니다. 그 '상태'는 여러분이 가장 생산적으로 일할 수 있는 상태입니다. 또 여러가지 일들에 대해서 신경을 쓰지 않아도 되는 상태입니다. 이메일을 보고 답장을 쓰거나 전화를 받거나 >메신저로 얘기를 하지 않아도 되는 시간입니다. '혼자의 상태'는 실제로 일의 진도가 나가는 시간입니다.
그 '상태'에 도달하기 위해서는 일정한 시간이 좀 필요합니다. 이것이 바로 방해나 인터럽트가 나쁜 이유입니다. 그것은 마치 렘 수면과 같습니다. 우리가 잠을 잘 때 즉시 렘 상태에 도달하지 못합니다. 처음에 잠이 들면 일정 시간이 지나야 렘 상태에 도달 할 수 있으며 중간에 어떤 방해를 받으면 처음부터 다시 시작해야 합니다. 렘 상태는 실제로 잠의 마법이 펼쳐지는 상태입니다. '혼자의 상태' 도 역시 이와 유사하며 실제 개발의 마법이 펼쳐지는 상태입니다.
일할 때, 절반은 혼자서 일할 수 있도록 업무 규칙을 만둘어야 합니다. 오전 10시에서 오후 2시까지는 식사시간을 제외하고는 아무도 서로에게 말을 걸지 않도록 하세요. 꼭 그 시간이 아니라도 오전 또는 오후를 '혼자의 시간'으로 정해도 됩니다. 유의>할 것은 이 시간대를 연속적인 긴 구간으로 정해야 한다는 것입니다.
성공적인 '혼자의 시간대'란 대화 중독에서 해방되는 것을 의미합니다. 혼자의 시간동안에는 메시징이나 전화 또는 다른 회의를 해서는 안됩니다. 아주 긴급한 답변이 필요한 경우를 제외하고는 이메일에 답하는 것도 해야합니다. 입을 꾹 다물고 일에만 집중하십시오.
흠뻑 빠져보세요.
지식근로자는 앞서 '상태'라고 했던 플로우(flow)의 상태에 도달했을 때 가장 일을 잘한다는 것은 이미 알려진 사실입니다. 그 상태에서 일에 대한 집중도가 가장 높아집니다. 시간이 어떻게 지나는 지도 모르게 완전한 집중을 통해 많은 것을을 이루어냅 니다. 그런데 문제는 이 상태가 아주 쉽게 깨어질 수 있다는 것입니다. 특히 동료의 방해에 의한 경우가 많습니다. 만약 1분동안 동료가 어떤 질문을 한다면, 그 상태는 완전시 깨어질 것이면 다시 진입하기 위해서 최소한 30분은 필요하게 됩니다. 전체의 생산성이 엄청나게 나빠집니다.
—조엘 스폴스키, 소프트웨어 개발자, Fog Creek Software (from 이 사람들은 어디에서 그들의 (독창적이 아닌) 아이디어를 얻는가?) 회의는 독입니다.
회의를 하지 마세요. 정말로 회의가 필요합니까? 회의는 보통 어떤 개념이 충분히 분명하지 않을 때 하게됩니다. 회의에 의존하기 보다는 개념을 단순화한 후에 이메일이나 메신저등을 이용해서 재빨리 내용을 논의 하는 것이 좋습니다. 회의를 피하는 것이 목표입니다. 회의를 피하여 얻게된 시간을 실제의 일을 하는데 사용할 수 있게 됩니다.
생산성의 측면에서 회의보다 더 독이 되는 것은 없습니다. 그 이유는 다음과 같습니다.
회의는 하루 일과를 여러 개의 작고 집중도가 떨어지는 조각들로 나누어버립니다. 그래서 당신의 자연스러운 워크플로우를 망쳐버립니다. 회의는 보통 말이나 추상적인 개념에 대한 것이지 코드나 인터페이스 디자인 같은 실질적은 것에 대한 것이 아닙니다. 회의에서 매 분당 전달되는 정보의 양은 지독히도 적습니다. 회의에는 최소한 한 명의 바보가 있기 마련이며, 그 사람의 발표 시간은 다른 모든 사람들에게는 아무 의미없이 낭비의 시간이 됩니다. 회의는 폭설이 내린 시카고 도로위의 택시처럼 어디로 미끄러져갈 지 알 수 없습니다. 회의의 토의 주제가 너무 모호하여 아무도 그것이 무엇인 지 알 수 없는 경우가 많습니다. 회의에는 철저한 준비가 꼭 필요하지만 사람들은 대부분 준비를 하지 않습니다. 여러분이 정말로 어쩔 수 없이 회의를 해야만 한다면 (정말로 드문 일이어야 합니다.) 다음의 간단한 규칙들을 꼭 지켜야 합니다.
30분의 타이머를 설정하고, 벨이 울리면 회의를 끝내세요. 참석자의 수를 가능한 최소로 해야 합니다. 아주 분명한 주제가 없다면 결코 회의를 해서는 안됩니다. 회의의 수를 줄이세요.
회의의 수가 너무나 많습니다. 생산적이지 않거나 말이 안되는 회의에는 등을 돌리십시오. 사업상 중요한 이슈가 있고, 타인의 의견이나 동의 또는 찬성이 필요한 경우에만 회의를 하세요. 또 그런 경우라고 하더라도 모든 사람, 심지어는 그들의 형제들까지, 회의에 참석시키고 싶은 욕구를 자제해야 합니다. 불필요하게 사람들의 시간을 낭비하시 마십시오.
—리사 헤인버그, (회의가 지배하도록 내버려 두지 마라!) 조각으로 나누세요.
프로젝트가 점점 커지면, 사람들을 추가하더라도 그 효과가 점점 적어집니다. 이에 대한 가장 흥미로운 이유는 참여자들간의 의사소통 채녈의 수가 많아지기 때문이라는 것입니다. 두 사람이 있다면 서로에게만 얘기하면 되므로 단지 한 개의 의사소통 채널이 존재합니다. 세 사람이 있다면 세 개의 채널이 있게 되고, 4명은 6개가 됩니다. 사실 이 채널의 증가는 기하급수적으로 증가합니다. 따라서 금방 메모와 미팅이 전체 작업 시간의 대부분을 차지하게 되어버립니다.
해결책은 명확합니다. 팀을 더 작게 나누세요. 자율적이고 독립적인 단위들로 나누어서 그들의 의사소통 채녈의 수를 줄여야 합니다.
비슷한 얘기지만, 프로그램도 작은 조각들로 나누어야 합니다. 문제의 대부분은 의존성(전역변수, 함수 전달 데이터, 공유되는 하드웨어 등)에서 비롯됩니다. 이러한 의존성을 최소화 할 수 있도록 프로그램을 쪼갤 수 있는 방법을 찾아야 합니다.
—제네시스 그룹 (작게 유지하라) 작은 성취를 찾고 축하하세요.
오늘 당장 무엇이든 릴리스하세요. 소프트웨어 개발에서 가장 중요한 것은 동기부여입니다. 만약 당신이 지금 현재 하고 있는 일에서 동기부여를 받지 못한다면 전체적인 동기부여는 낮아집니다. 더 솔직히 말하면 엉망이 될 것입니다.
기다란 릴리스 사이클은 동기부여를 죽입니다. 축하의 간격이 너무가 길어지기 때문입니다. 반대로 축하할 수 있는 간격을 짧게 하는 것은 최고의 동기부여 방법입니다. 기다란 릴리스 간격으로 잦은 성취를 막아버린다면 동기부여를 죽이는 것 뿐 제품도 죽이는 결과가 됩니다.
따라서 만약 여러분이 여러달이 걸리는 릴리스 사이클의 중간에 있다면, 일주일에 하루는 작은 성취를 축하할 수 있도록 계획을 세우는것이 좋습니다. 스스로에게 "우리가 4시간이내에 릴리스 할 수 있는 것이 뭐지?"라고 물어보세요. 그리고 그것을 실행 하십시오. 그런 일들에는 다음과 같은 것들이 있습니다.
새로운 간단한 기능 추가 기존 기능의 간단한 개선 지원업무의 부담을 줄여 줄수 있도록 도움말 다시 쓰기 꼭 필요하지 않은 입력 필드 제거하기 이런 4시간짜리 성취 거리들을 많이 찾아서 실행한다면, 사기가 높아지고 동기가 부여될 것이며, 팀이 올바른 방향으로 나아가고 있다는 것을 반복해서 확인할 수 있게 될 것입니다.
더 적게 그리고 더 나중에 채용하세요.
속도를 내려면 투입의 속도를 늦추세요. 일찍부터 큰 조직을 갖출 필요는 없습니다. 사실 나중에도 그렇습니다. 심지어 지금 당장 아주 좋은 사람들 100명을 얻을 수 있다고 해도, 그들 모두를 당장 채용하는 것은 좋은 생각이 아닙니다. 그렇게 많은 사람들을 곧바로 하나의 조직으로 융화시키는 방법은 없습니다. 교육의 부담감, 성격의 부조화, 의사소통의 어려움을 겪게 될것이며 사람들은 여러개의 방향으로 나뉘게 될 수 있으며 더 나쁜 일들도 일어날 것입니다.
그러므로 채용하지 마십시오. 정말입니다. 채용하지 마십시오. 다른 방법을 찾아보세요. 지금 하려는 그 일이 정말로 꼭 필요한 일인가요? 그렇다면 당신을 직접 그 못할 이유는 무엇입니까? 그 문제를 해결할 수 있는 소프트웨어를 찾아보거나 혹은 일의 방식을 바꾸는 것은 어떻습니까?
GE의 전 CEO였던 잭웰치는 사람을 해고할 때마다, 그 빈자리를 채우기 위한 채용을 즉시 하지 않았습니다. 대신 그 자리를 비워두고 얼마나 오래 버틸 수 있는 지 알고 싶어했습니다. 우리는 이 이론을 실험하기 위해서 사람들을 해고하라고 권하는 것은 아닙니다. 하지만 우리는 잭의 생각에 일리가 있다고 생각합니다. 사실 여러분이 생각하는 것 만큼 사람이 많이 필요하지 않습니다.
만약 다른 방법이 정말 없다면 채용에 대해서 고려하십시오. 하지만 여러분은 누구를 채용해야 하는 지 분명히 알고 있어야 합니다. 그들에게 어떻게 그 일을 소개할 지를 알아야 하며, 그 들이 해결해 주기를 바라는 부분이 정확히 무엇인지 알아야 합니다.
브룩스의 법칙
프로젝트 후반에 사람들을 추가하면 그 과제는 더 늦어진다.
—프레드 브룩스 프로그래밍과 모짜르트의 레퀴엠
딱 한 사람의 우수한 프로그래머가 한 가지의 일을 하고 있으면 거기에는 의사소통이나 서로 조화를 이루기 위한 부담이 없습니다. 다섯 명의 프로그래머가 하나의 일을 하고 있다면 서로의 방식에 맞추고 의사소통하기 위해서 많은 노력을 해야합니다. 이것은 많은 시간이 필요합니다. 우수한 소수의 프로그래머 대신 자질이 낮은 다수의 프로그래머가 있을 때의 진짜 문제는 그들이 아무리 오래동안 작업하더라도 우수한 프로그래머들이 만들 수 있는 결과를 만들 수 없다는 것입니다. 안토니오 살리에르가 5명이 모여도 모짜르트의 레퀴엠을 만들 수 없듯이 말입니다. 절대 불가능합니다. 그들이 100년 동안 노력하더라도 말입니다.
—조엘 스폴스키, 개발자, Fog Creek Software (from Hitting the High Notes) 타이어 발로 차기
먼저 지원자가 함께 일하는 시험기간을 가지세요. 채용을 위한 조건으로 포트폴리오, 실제 작성한 코드, 예전에 개발한 결과물은 중요합니다. 하지만 이것들 못지 않게 중요한 것은 다른 사람과 함께 잘 일할 수 있는 능력입니다. 가능하다면 채용희망자를 잠시 테스트 기간동안 팀에 합류시켜서 함께 일해보는 것이 좋습니다.
우리는 채용을 하기전에 먼저 작은 프로젝트에 투입해봅니다. 그래서 그가 어떻게 일을 처리하는 지를 살펴보고, 다른 사람과의 의사소통은 어떤 지등을 살펴봅니다. 그가 다른 사람들과 함께 코드를 작성하거나 디자인을 하는 것을 직접 보면 그 사람에 대해서 정말 많은 것을 알게 되며 그 사람을 정말 채용해야할 지를 곧 바로 알 수 있게 됩니다.
이런 테스트 기간을 위해 서로의 스케쥴을 조절하는 것은, 그것이 단 20시간이든 40시간이든 쉽지 않을 지 모릅니다. 하지만 이것은 정말 도움이 됩니다. 좋은 채용이 될 지 아닐 지를 미리 명확히 알 수 있음으로서, 혹시 그 채용이 적당한 것이 아닌 경우, 서로가 겪게될 많은 문제와 위험을 미리 피할 수 있게 해줍니다.
작게 시작하기
작은 테스트 과제부터 시작하세요. 시작부터 여러분의 모든 업무에 함께 뛰어들지 않게 하세요. 채용 예정자에게 한 두개의 시험과제를 주고 어떻게 되는 지 살펴보십시오. 몇가지 문제를 적당히 숨겨 두는 것도 괜챦습니다. 그것이 시험을 위한 과제라는 것을 분명히 해 두십시오.
—수잔 팔터 반즈, 저자/생산성 전문가 (from 어떻게 하면 가상의 조력자를 찾고 또 계속 함께 일할 수 있을까?) 말보다 행동
오픈소스에 기여한 내용을 보고 대상자를 판단하세요. 기술직을 채용하는 전형적인 방식은 학위나 이력서등을 보는 것입니다. 하지만 이것은 여러 면에서 어리석은 방식입니다. 학위나 그의 학업 성적이 정말로 중요할까요? 이력서의 내용이나 추천서의 내용을 정말 믿을 수 있습니까?
오픈소스는 기술직을 채용하려는 이들에게는 선물과 같습니다. 오픈소스를 보면 여러분은 대상자들의 얼마동안 어떤 일을 했는지 얼마나 기여했는 지를 알 수 있습니다.
이것은 여러분이 그들의 말 대신 그들이 실제로 행동한 결과를 가지고 판단할 수 있다는 것을 의미합니다. 여러분은 다음의 정말 중요한 것들을 판단의 기준으로 삼을 수 있습니다.
작업의 품질 많은 프로그래머들은 언변에 능합니다. 하지만 오픈소스를 보면 그 사람의 개발 기술을 실제로 확인 할 수 있습니다. 문화적 관점 프로그래밍은 사실 모두가 결정을 내리는 것에 대한 것이라고 할 수 있습니다. 정말로 많고도 많은 결정들이 필요합니다. 결정은 그 사람의 문화적인 소양이나 관점에 의해 내려집니다. 코딩이나 테스트 또는 집단 토론에서 후보자가 내리는 결정들을 관찰하면 여러분이 그 후보자와 문화적으로 일치하는 지를 알 수 있습니다. 이런 부분이 잘 맞지 않으면 매번 결정을 내려야 할 때마다 문제가 생길 것입니다. 열정 오픈소스에 관려하는 것은 최소한 어느정도의 열정을 필요로 합니다. 열정이 없다면 왜 그들이 개인의 소중한 시간을 모니터 앞에서 보내겠습니다. 오픈소스에 기여한 양을 보면 그가 얼마나 열정을 가지고 있는 지을 알 수 있게 됩니다. 완성도 아무리 똑똑하고 문화적인 소양이 일치하며, 열정이 있다고 해도 만약 그가 일을 끝까지 해내지 못한다면 소용이 없을 것입니다. 불행히도 많은 프로그래머들이 그런 경우에 해당합니다. 그러므로 여러분은 주어진 일을 끝까지 해낼 수 있는 에너지를 가진 사람을 찾아야 합니다. 이것을 위해서라면 다른 요건들을 조금 포기할 수도 있습니다. 사회적 일치 어떤 사람과 오랫동안 함께 일하는 것은 기쁠 때나 슬플 때, 편안할 때나 위급할 때를 모두 함께 지내는 것이며, 이것은 그의 진짜 인간성을 모두 드러내 보여줄 것입니다. 따라서 매너나 사회적인 소양이 부족한 사람을 피해야 합니다. 우리는 프로그래머의 경우, 오픈소스를 통해서 알게된 사람만을 채용합니다. 사실 우리는 다른 모든 방식은 필요없다고생각합니다. 우리는 Jamis를 채용했을 때 그가 Ruby커뮤니티에 참여하고 릴리스한 내용들을 보고 결정했습니다. 그는 위에서 언급한 모든 항목들에서 뛰어났습니다. 우리는, 정말로 중요한 요소인, 그의 실제 작업 수준을 기준으로 채용했으므로 다른 요소들을 확인할 필요가 없었습니다.
오픈 소스 활동과 같은 외부 활동을 하는 것이 그 사람의 실제 업무 시간을 좀먹을 수 있다는 걱정은 할 필요가 없습니다. 옛말에도 있듯이 당신이 뭔가를 이루고 싶다면 당신이 아는 가장 바쁜 사람에게 도움을 요청해야 합니다. Jamis와 David는 Rails에서 가장 많은 기여를 하는 두 사람이며 동시에 37Signals를 기술적으로 유지해가고 있습니다. 정말로 프로그래밍을 사랑하고 일들을 해내는 사람이야말로 여러분의 팀에 가장 필요한 사람일 것입니다.
오픈 소스 열정
여러분이 새로운 채용자에게 가장 기대하는 것은 그가 하는 일에 대한 열정입니다. 그리고 이것을 확인할 수 있는 가장 좋은 방법은 오픈소스 프로젝트에 대한 기여입니다.
—자르키오 라이네, 개발자 (from 위험을 줄이려면 오픈소스에서 채용하라 ) 여러가지를 두루 잘할 수 있는 사람
딱 한 가지만 잘하는 사람보다는 빨리 배우며 여러가지를 잘 할 수 있는 사람을 선택하세요. 우리는 소위 '정보 아키텍트'와 같은 타이틀을 가진 사람은 채용하지 않을 것입니다. 그것은 너무나 한정적입니다. 우리와 같이 작은 팀에서는 그렇게 좁은 기술 영역에 제한된 사람을 뽑는 것은 말이 안됩니다.
작은 팀에는 여러가지 모자를 쓸 수 있는 사람들이 필요합니다. 글도 잘 쓰는 디자이너가 필요하며, 디자인을 이해하는 프로그래머가 필요합니다. 모든 사람인 정보 구조(그것이 무엇을 의마하든 간에)에 대해서 아이디어를 가지고 있어야 합니다. 모든 사람이 잘 정리된 견해를 가지고 있어야 합니다. 모든 사람이 고객과 의사소통이 가능해야합니다.
그리고 모든 사람이 굳은 일도 마다하지 않아아야 합니다. 또 작은 팀들은 자주 방향이 바뀔 수 있고 빨리 바꿀 수 있어야 한다는 것을 명심하세요. 진흙에 깊이 박힌 막대기 처럼 오직 한 가지 일만 할 수 있는 사람이 아닌, 변화하고 새로 배우며, 유연한 사람이 필요합니다.
열정을 가장할 수는 없습니다.
Go for happy and average over frustrated and great 열정은 절대 가장 할 수 없는 것들 중에 하나입니다. 사람을 채용할 때는 구루나 최고 기술을 가진 사람이 반드시 좋은 것은 아닙니다. 종종 그런 사람들은 뭐든지 자기 마음대로인 경우가 많습니다. 평균정도의 능력을 가졌지만 함께 일하기에 즐거운 사람이, 불만이 가능하고 짜증투성이인 사람보다 낫습니다.
열정적인 사람을 찾으십시오. 혼자 내벼려두더라도 일은 믿고 맡길 수 있는 사람, 더 크고 더 느린 조직을 경험한적이 있으며 새로운 환경을 희망하는 사람, 여러분이 만들고자 하는 것에 대해서 매우 흥미를 가지는 사람, 여러분이 미워하는 것들을 똑같이 미워하는 사람, 여러분의 기차에 동승하는 것에 대해서 진정으로 기뻐하고 기대하는 사람, 이런 사람이 바로 여러분이 찾아야 할 사람입니다.
질문을 위한 추가 참고 사항
지원자가 여러분의 프로젝트에 대해서 많은 질문을 하는 지 관찰하십시오. 열정을 가진 개발자라면 가능한 빨리 자신이 해결해야 할 문제에 대해서 이해하고 싶어하며, 재빨리 자신의 해결책이나 개선안을 제시하려 할 것이며, 이를 위해 여러가지 추가 질문을 해댈 것입니다. 자세한 질문들을 묻고 답하는 동안 지원자가 여러분과 문화적으로 잘 맞을 지도 알수 있을 것입니다.
—에릭 스페판스, BuildV1.com 언변가
글 잘쓰는 사람을 채용하세요. 하나의 자리를 놓고 몇 명의 후보 중에 한 명을 고르고 있다면 항상 글을 더 잘쓰는 사람을 선택하십시오. 그 사람이 디자이너든, 프로그래머이든 마케터이든 무엇이든 글을 잘 쓰는 능력은 도움이 될 것입니다. 효과적이고 간결한 글 쓰기는 효과적이고 간결한 코드와 디자인, 이메일, 인스턴트 메시징과 그 이상을 의미합니다.
글을 잘쓰는 것은 단지 글과 말에 대한 것이 아닙니다. 글을 잘 쓰는 사람은 의사소통을 어떻게 해야할 지를 알고 있습니다. 그들은 이해하기 쉽게 설명할 줄 압니다. 다른 사람들에게 자신을 잘 이해시킵니다. 어떤 것을 생략해야 하는 지 알며, 명료한 사고를 합니다. 이런 것들이 바로 여러분이 필요한 것입니다.
잘 정리된 생각
좋은 글 쓰기 능력은 생각이 잘 정리되었다는 것을 보여주는 지표이며, 정보들을 잘 정리하여 체계적인 방식으로 활용하며 다른 사람들이 잘 이해할 수 있도록 도울 수 있게 해줍니다. 이러한 능력은 코드를 작성할 때, 사람간의 의소통에, 메신저로 대화할 때 발휘됩니다. 또 모호하고 이해할 수 있는 어려운 개념들을 전문적이고 신뢰할 수 있도록 정리해 줍니다.
—Dustin J. Mitchell,개발자 (Signal vs. Noise) 명확한 글쓰기가 명확한 사고로 이어집니다.
명확한 글 쓰기는 명확한 사고로 이어집니다. 여러분이 무엇을 표현해보기 전에는 그 것을 제대로 알고 있는 지 알 수 없습니다. 좋은 글 쓰기는 어떤 면에서는 성격의 문제입니다. 자기 자신이 편한방식이 아니라 글을 읽는 사람에게 쉽도록 해야 합니다.
—Michael A. Covington, 조지아 대학 컴퓨터 공대 교수 (더 명확한 글쓰기와 더 명확한 사고, 그리고 복잡한 개념의 더 쉬운 이해 )
인터페이스 디자인
프로그래밍을 시작하기 전에 인터페이스부터 디자인하세요. 수많은 어플리케이션들이 디자인과 프로그래밍 중에 프로그래밍부터 시작하는데 이것은 정말 나쁜 아이디어입니다. 어플리케이션 개발에 있어서, 디자인보다 프로그래밍이 보다 많은 비용이 들고 수정도 어렵기 때문에, 디자인부터 시작해야 합니다.
상대적으로 디자인은 비용이 적게 듭니다. 종이 스케치는 저렴하며 수정이 쉽습니다. HTML디자인도 비교적 수정이 쉽다. (또는 그냥 내버려도 된다.) 하지만 프로그래밍은 그렇지 않습니다. '디자인 우선'은 유연하지만, '프로그래밍 우선'은 추가적인 비용이 발생하며 여러가지 제약이 발생합니다.
또한 디자인은 어플리케이션의 얼굴이기 때문에, 사용자에게 보다 직접적입니다. 만약 마지막 단계에서 디자인이 비난받는다면, 그 차이가 명확해집니다.
우리가 인터페이스부터 시작하는 것은 처음부터 어플리케이션이 어떻게 보이고 동작하는지 알고 싶어서입니다. 전체 개발 과정을 통해서 인터페이스는 지속적으로 개선됩니다. 이게 말이 될까? 사용하기는 쉬울까? 이런 방식이 문제를 바로 해결해주는 걸까? 이런 질문들의 답은 오직 실제 화면을 보아야만 얻을 수 있습니다. '디자인 우선'은 전체 개발 과정에서 이런 문제들의 답을 더 빨리 얻을 수 있도록 해줍니다.
오렌지색 펜으로 시작한 Blinksale
나는 재고 송장 소프트웨어로 인한 좌절을 겪고나서, 그 송장 솔루션이 어떻게 동작하는 지를 그려보기로 했다. 그 날 저녁에 손에 잡히는 펜이 오렌지색 펜 하나였기 때문에 나는 그 펜으로 작업했다. 몇시간 후에 나는 전체의 75% 정도를 그릴 수 있었고, 다림질을 하고 있던 아내 레이첼에게 보여주었다. "어떻게 생각해?" 아내는 웃으면서 대답했다. "그 거 꼭 만들어 보세요."
다음 두 주일동안 나는 디자인을 수정하고 보완하여 단순 html로 완전히 만들었는데, 이것인 Blinksale의 첫번째 버전이었다. 나는 오렌지색 펜으로 할 수 없는 어떤 기능이나 로직도 추가하지 않고 단순히 html 디자인에만 집중하여 우리가 개발할 제품의 '실제 모습'이 어떻게 될 지를 파악하는데 집중했다. 사실 그 때 우리는 그것들을 어떻게 구현할 지도 몰랐다.
html 모형이 모두 완성된 후에, 개발자인 스캇에게 연락했다. 대부분의 UI가 먼저 완성되어 있는 것은 여러 면에서 정말 도움이 되었다. 우선, 스캇은 무엇을 할 지를 금방 알 수 있었고, 즉각 우리와 같은 의욕을 가지게 되었다.두 번째로 그것은 스캇이 해야 할 일의 분량을 미리 측정할 수 있게 해주었다. 당신이 어떤 프로젝트를 시작할 때, 금전적으로, 전체 예산을 일찍 예측할 수 있을 수록 유리하다. UI디자인은 우리의 첫번째 단계의 프로젝트 범위를 알 수 있는 벤치마크 역할을 해주었다. 또 UI디자인은 우리가 개발을 계속 진행함에 있어서 우리가 하려고 하는 것이 무엇있었는 지를 계속 상기시켜주었다. 우리가 새로운 기능을 추가하고싶은 유혹에 빠졌을 때, 우리는 그냥 "좋아 한 번 추가해보자" 라고 말하고는 디자인으로 돌아가서 그 새로운 기능을 추가했을 때 어떻게 되는 지 살펴보았다. 만약 새 기능을 추가할 적당한 위치를 찾지 못하면 그것은 추가 되지 못했다.
—조쉬 윌리엄스, 창업자, 블링크세일 핵심 디자인
페이지의 가장 중요한 부분부터 시작하세요. 핵심 디자인(epicenter design)은 페이지에서 정말 필수적인 부분에 집중합니다. 그리고 나서 나머지 부분을 만듭니다. 이것은 처음에는 부가적인 요소들(네비게이션, 탭, 하단 footer, 색, 사이드바, 로고)에 대해서는 무시한다는 것을 의미합니다. 대신 가장 중요한 핵심 부분에서 시작합니다.
핵심부분이 빠진 페이지는 존재할 수 없습니다. 예를들어 블로그를 디자인하고 있다면, 각 블로그 글 그 자체가 핵심입니다. 사이드바의 분류나, 상단의 헤더 또는 하단의 코멘트는 핵심이 아닙니다. 블로그 글이 없다면 그 페이지는 블로그가 아니기 때문입다.
핵심 부분을 끝낸 후에, 다음 순위의 항목에 대해서 생각해야 합니다. 그리고는 또 그 다음으로 중요한 부분의 식으로 진행해나가야 합니다. 이것이 핵심 디자인의 방식입니다.
핵심 디자인은 '전체 프레임워크를 만드고 나서 내용을 만든다'는 기존의 전통을 따르지 않습니다. 기존 방식에서는 먼저 페이지 전체 모양이 만들어지고나서 네비게이션이 추가됩니다. 그리고 마케팅 요소가 삽입되고 마지막으로 남은 영역에 그 페이지에서 가장 중요한 내용인 콘텐츠가 추가됩니다. 이는 최고 우선순위를 뒤로 미루는 방식입니다.
핵심 디자인은 이 과정을 뒤집어, 중요한 내용부터 시작합니다. 필수적인 것을 먼저하고 부가적인것은 나중에 합니다.이렇게 하면, 사용자에게 보다 친근하고, 핵심이 드러나는, 유용한 화면을 꾸밀 수 있습니다.더군다나 페이지의 모든 기능들을 정의하기 전에, 디자이너와 개발자간의 논의를 시작할 수 있습니다.
고려해야할 세 가지 상황
채워진 데이터를 보는 상황, 데이터가 비어있는 상황, 오류 상황에서의 디자인 각 화면마다, 발생 가능한 상황에 대해서 고려해야 합니다.
채워진 데이터를 보는 상황 모든 것이 정상적으로 동작하고, 데이터가 출력된 화면을 사용자가 보고 있는 상황. 데이터가 비어있는 상황 어플리케이션 사용초기에, 데이터가 입력되기 전의 화면을 사용자가 보고 있는 상황. 오류 상황 오류발생 화면을 사용자가 보고 있는 상황. "채워진 데이터를 보는 상황"은 머리 아플 일이 없습니다. 가장 많이 시간을 투자할 상황이지만, 다른 상황에 대한 투자를 간과해서는 안됩니다. 뒤에서 보다 자세히 다루겠습니다.
데이터가 비어있는 상황
사용자는 한 번의 경험만으로 어플리케이션의 가치를 가늠합니다. "데이터가 비어있는 상황"을 경시하시는 것은 크나큰 실수입니다. "데이터가 비어있는 상황"에서 어플리케이션의 첫인상이 결정되며, 두 번의 기회는 없습니다. 대개 문제는 데이터를 넣어두고 UI를 디자인할 때 발생합니다. 디자이너들은 항상 템플릿에 데이터를 채워둡니다. 모든 리스트와 게시물, 입력 필드들 같은 모든 것들이 그 속에 값을 가지고 있습니다. 사실 그렇게 하면 화면이 멋지게 동작하는 것처럼 보입니다. 그러나 원래 어플리케이션의 초기 상태에는 데이터가 없습니다. 누군가 처음 가입하게되면 "데이터가 비어있는 상황"에서 시작하게 됩니다. 마치 블로그처럼, 데이터를 채워가는 것은 사용자들의 몫입니다. — 전체적인 화면은 사용자가 게시물, 코멘트, 사이드바, 기타 정보와 같은 데이터를 넣을 때까지 자리잡지 못합니다. 불행하게도, 사용자는 "데이터가 비어있는 상황" — 어플리케이션 전체를 가치를 판단함에 있어, 너무나도 작은 최소한의 정보, 디자인, 내용 — 으로만 어플리케이션의 가치를 판단합니다. 따라서 "데이터가 비어있는 상황"에 대한 적절한 디자인이 나와주지 않을 경우, 사용자들은 어플리케이션 사용이 아직은 시기상조라고 생각할 것입니다. 그러나 대부분의 디자이너와 개발자들은 여전히 이러한 상황를 당연시하며, "데이터가 비어있는 상황"의 디자인에서는 짧은 시간만을 할애할 뿐입니다. 개발을 진행하면서 테스트용의 직접 입력한 수많은 데이터를 경험하지만, "데이터가 비어있는 상황"은 인식하지 못할 수도 있습니다. 분명히 처음에는 신규 사용자로 로그인할 때가 있겠지만 대부분의 개발시간에는 데이터가 충분히 많은 상황에서 작업하게 됩니다. "데이터가 비어있는 상황"를 유용하게 쓸려면?
짧은 사용법이나 간단한 도움말을 보여줄 수 있는 기회로 이용할 수 있습니다. 데이터가 채워진 상태의 샘플 스크린샷을 제공해서 사용자들이 앞으로 사용하게 될 화면이 어떨 지를 미리 보여줍니다. 이것은 사용자에게 이 어플리케이션을 계속 사용하고 싶은 마음이 생기도록 합니다. 어떻게 시작해야 하는 지를 설명하고 화면이 어떻게 보이게 될 지 등을 설명합니다. 처음 사용자들이 하게 될 주요 질문에 대한 답변을 합니다. 예를 들어 "이 페이지는 무슨 용도인가요? 여기서 무엇을 하는 건가요? 데이터를 입력하게되면 화면은 어떻게 되나요?"와 같은 질문들입니다. 요구사항들을 정리해서 사용자들의 어플리케이션의 사용 과정에서 겪을 수 있는 혼란이나 좌절을 최소화합니다. 첫인상은 매우 중요합니다. 만약 '데이터가 비어있는 상황'에 대한 적절한 디자인이 나와주지 않으면, 사용자들에게 어플리케이션과 서비스에 대한 나쁜 인상을 심어주게 될 것입니다.
결코 두번의 기회는 찾아오지 않습니다.
스티브잡스로부터 많은 영향을 받은 것으로 생각되는, Mac OS X의 UI의 두드러진 특징은 설정과 초기실행에서의 경험입니다. 저는 잡스가 첫 인상의 중요성을 예리하고 정확하게 파악하고 있다고 생각합니다. 게다가 초기 실행의 경험을 관찰하고 깊이 고민했을 것으로 생각합니다. 초기실행의 경험은 하나의 장치를 사용하면서 겪는 경험에 비하면 1/1000에 불과할 수도 있지만, 가장 핵심이 되는 1/1000입니다. 왜나하면 초기실행의 경험은 수많은 경험 중의 첫번째 경험이며, 첫인상이 되고, 사용자가 제품에 대한 가치를 결정하는 척도가 되기 때문입니다.
—John Gruber, 저자 겸 웹 개발자 (John Gruber 인터뷰 중에서 ) 방어적인 자세
비정상적인 경우를 고려한 디자인 일이란 잘못될 수 있습니다. 아무리 주의를 기울여서 어플리케이션을 디자인하더라도, 아무리 많은 테스트를 수행하더라도 고객들은 여전히 문제를 발견하게 될 것입니다. 이러?? 피할 수 없는 오류와 잘못들을 어떻게 처리해야 할까요? 바로 방어적인 디자인이 해답입니다.
방어적 디자인은 방어 운전과 유사합니다. 운전자들이 항상 도로를 잘 살피고 난폭한 다른 운전자 또는 다른 위험한 상황들에 대비해야하는 것과 같이 사이트를 개발하는 사람들은 고객들에게 실망과 좌절을 안겨주는 문제를 발생시키는 부분들을 항상 찾아야 합니다. 사이트에서 좋은 방어는 고객의 경험을 만들거나 중단시킬 수 있습니다.
우리는 방어적 디자인 한가지에 대해서만도 책한권을 쓸 수도 있습니다. 사실 벌써 그렇게 했습니다. "Defensive Design for the Web"이 그 책의 제목입니다. 이 책은 오류화면이나 다른 위험한 요소들을 피하는 방법들을 위한 최고의 자료입니다.
기억하세요: 당신의 어플리케이션은 90%의 시간동안에는 휼륭히 동작하겠지만, 만약 당신의 그들이 필요로 하는 시점에 고객들을 방치한다면 그들은 결코 잊지않을 것입니다.
일관성보다는 문맥
한 곳에서 괜챦은 것이, 다른 곳에서는 적당하지 않을 수 있습니다. 액션들은 버튼이어야 할까요 아니면 링크이어야 할까요? 그것은 각 액션에 따라 달라집니다. 달력의 모양은 리스트 형태이어야 할까요 아니면 격자 형태이어야 할까요? 그것은 달력이 보여지는 위치나 달력에서 표현하고자하>는 시간의 범위에 따라 다릅니다. 모든 전역 네비게이션 링크들은 모든 페이지에 있어야 할까요? 전역 검색은 모든 곳에서 필요할까요? 각 페이지에 항상 똑같은 footer 가 있어야 될까요? 정답은 '그 때 그 때 다르다'입니다 .
이것이 바로 문맥이 일관성보다 중요한 이유입니다. 만약 디자인이 더 좋아진다면 일관되지 않아도 좋습니다. 사용자에게 중요한 것을 제공하세요. 그들이 필요한 것을 필요한 시점에 제공하고 필요하지 않을 때는 제거하세요 . 그것이 일관적인 것보다 더 좋습니다.
지능적인 비일관성
일관성은 꼭 필요하지 않습니다. 수년 동안 UI와 UX를 공부하는 학생들은 인터페이스에서 일관성이 가장 중요한 규칙의 하나라고 배워왔습니다. 그것은 소프트웨어에서 맞을 지도 모릅니다. 하지만 웹에서라면 그렇지 않습니다. 웹에서 중요한 것은 각각의 페이지에서 사용자가 빠르고 쉽게 다음단계로 진행할 수 있게 하는 것입니다.
'Creative Good'에서 우리는 이것을 "지능적인 비일관성"이라고 부릅니다. 전체 프로세스에서 각 페이지가 사용자에게 정확히 그들이 필요로 하는 것을 제공하도록 하는 것입니다. 단순히 다른 페이지들과의 일관성을 위해서 불필요한 네비게이션 요소들을 더하는 것은 어리석은 일입니다.
—Mark Hurst, Creative Good 창립자 이며 Goovite.com 개발자 ('The Page Paradigm' 중에서) 카피라이팅도 인터페이스 디자인
모든 글자는 중요합니다. 카피라이팅은 인터페이스 디자인입니다. 위대한 인터페이스는 쓰여집니다. 만약 모든 픽셀과 아이콘과 모든 타입페이스가 중요하다고 생각한다면, 모든 글자들 역시 중요하다는 사실을 믿어야 합니다. 인터페이스에서 글을 작 성할 때느, 항상 그 글을 읽을 사용자의 관점에서 작성해야합니다. 그들이 알아야하는 것이 무엇인지 어떻게 그것을 간단하고 명확하게 전달할 것인가에 대해서 생각해야합니다.
버튼에 'Submit', 'Save', 'Update', 'New', 'Create' 같은 레이블을 붙입니까? 그것이 바로 카피라이팅입니다. 세 문장으로 작성하나요? 혹은 다섯 개 문장으로 작성하나요? 일반적인 예를 들어 설명합니까? 아니면 상세한 >세부사항을 설명합니까? 컨텐츠에 '신규', '수정' 또는 '최근 수정', '고침' 와 같은 레이블을 붙입니까? '5개의 새로운 메시지가 있습니다'입니까? 아니면 '새로운 메시지: 5개' 입니까? '5'입니까? '다섯'입니까? 이런 모든 것들이 중요합니다.
고객과 같은 언어를 사용해야합니다. 웹을 개발할 때도 기술 용어들을 조심해야 합니다. 고객에 대해서 생각하고 그 버튼들과 단어들이 그들에게 의미하는 바를 생각하세요. 약어나 대부분 사람들이 이해하기 힘든 단어를 조심해야합니다. 내부적으로 쓰는 말을 사용하면 안됩니다. 엔지니어가 다른 엔지니어에게 말할 때 쓰는 말을 쓰면 안됩니다. 간결하고 부드럽게 해야합니다. 필요한 말만해야하면 더 이상은 안됩니다.
좋은 글쓰기는 좋은 디자인입니다. 글이 디자인과 별개인 경우는 매우 드문 경우입니다. 아이콘은 이름이 있고, 폼의 필드들은 예문을 가집니다. 버튼에는 레이블이 있고, 프로세스에는 각 단계별로 안내문이 있습니다. 환불 에 대한 명확한 설명이 있어야 합니다. 이런 것들이 모둔 인터페이스 디자인입니다.
하나의 인터페이스
관리 기능들을 일반 인터페이스와 조화시키세요 관리 화면— 설정이나 사용자등을 관리하기 위한 화면 —은 엉망인 경향이 있습니다. 그것은 개발에서 대부분의 시간이 일반 화면에만 집중되기 때문입니다.
엉망진창 관리 화면을 피하려면, 관리 기능을 별도로 개발하지 말아야 합니다. 대신 일반 인터페이스 내에서 관리 기능들을 개발하세요.
만약 사용자용과 관리자용의 두 가지 인터페이스를 별도로 유지해야한다면, 두 가지 모두가 좋지 못할 것입니다. 이것은 결국 세금을 두번 내는 것과 같습니다. 중복을 하게되고 점점 지저분하고 이상하게 될 것입니다. 신경써야 할 화면이 적을 수록 결과는 좋게 됩니다.
별도 인터페이스 금지
어플리케이션은 그 자체로 모든 것을 포함해야 합니다. 변경이나 추가, 조정등은 그 어플리케이션 내에 있는 관리 영역을 통해서 즉시 적용 가능한 것이 좋습니다. 이렇게 하면 사용자들이 보게될 정확한 화면 동일하게 볼 수 있기 때문에, 사용자들이 갖게될 수도 있는 의문이나 문제점들을 더 빨리 도울 수 있게 해줍니다. 또 사용자들은 별도의 인터페이스에 로그인하는 일을 피할 수 있게됩니다. 사용자들은 자신들의 고객과의 약속을 정하는 업무를 하다고 곧 새로운 직원을 채용하는 업무를 할 수도 있습니다. 이러한 일들을 하기 위해서 서로다른 여러개의 어플리케이션들을 옮겨다니는 것은 좋지 않습니다. 일관되게 하나의 인터페이스를 유지해주면 사용자들은 어플리케이션에 더 빨리 적응하게 됩니다.
—Edward Knittel, KennelSource의 세일즈 및 마케팅 담당자
작은 소프트웨어
최대한 코드를 심플하게 유지하세요. 코드의 크기가 2배가 되면 복잡도도 2배가 된다고 생각할 지 모르겠습니다. 하시만 코드의 크기가 증가될 때마다, 소프트웨어는 기하급수적으로 더 복잡해집니다. 조그만 기능 추가, 약간의 변경, 상호 의존성, 선택사항 등은 모두연쇄적인 결과를 초래합니다. 부주의하게 코드를 계속 추가해가면 결국에는 거대한 진흙덩어리를 만들게 될 것입니다.
이러한 복잡성과 싸우는 방법은 더 작은 소프트웨어입니다. 작은 소프트웨어는 더 적은 기능들, 더 적은 코드 그리고 더 적은 낭비를 의미합니다.
요령은 큰 소프트웨어를 요구하는 어려운 문제를 더 작은 소프트웨어를 요구하는 단순한 문제로 다시 정의하는 것입니다.
작은 소프트웨어는 여러분이 운명의 수정 구슬 멀리한다는 것을 의미합니다. 미래의 문제를 예언하려고 하는 대신 오직 오늘의 문제들만 다루는 것입니다. 왜냐하면 오늘 여러분이 걱정하는 문제들은 대부분 결코 발생하지 않을 것이기 때문입니다. 그런 허상의 문제들을 해결하기 위해서 여러분 자신을 괴롭히지 마십시오.
처음부터 우리는 더 작은 소프트웨러의 개념에 입각해서 디자인을 합니다. 가능한 어려운 문제들을 더 쉬운 문제들로 쪼갭니다. 우리는 쉬운 문제들에 대한 해결책이 구현하기에 더 쉬울 뿐 아니라 이해하고 사용하기에도 더 쉽다는 것을 알게되었습니다. 이런 점이 우리가 경쟁자들과 차별성을 가지는 부분입니다. 더 많이 제공햐는 제품을 만들려고 노력하는 대신 우리는 더 적게 제공하는 제품을 만듭니다.
작은 소프트웨어는 더 관리하기 쉽습니다. 작은 소프트웨어는 전체 코드를 줄여주며, 다음과 같은효과가 있습니다. 더 적은 관리 업무와 더 기뻐하는 스탭들 더 적은 소프트웨어는 변경의 비용을 낮추어 주므로, 더 빨리 변화에 적응할 수 있으, 많은량의 코드 수정에 대한 걱정없이 기존의 결정을 바꿀 수도 있습니다. 작은 소프트웨어는 더 적은 버그를 의미합니다. 작은 소프트웨어는 더 적은 지원이 필요함을 의미합니다. 추가하거나 삭제할 기능으로 어떤 것을 선택하는 지도 작은 소프트웨어와 많은 관련이 있습니다. 구현이 힘든 기능 요구에 대해서 안된다고 말하는 것을 두려워하지 마세요. 만약 그 기능이 정말로 필수적인 것이 아니라면, 구현을 하지 않음으로써 시간과 노력을 아끼고 혼란을 방지 할 수 있습니다.
또 속도를 늦추세요. 일주일만에 당장 행동을 하지마세요. 대신 처음의 흥분이 가라앉은 후에도 여전히 그것이 멋진 아이디어로 보이는 지 지켜보십시오. 가끔은 이렇게 생각을 숙성시키는 시간에 더 쉬운 해결책이 떠오르기도 합니다.
프로그래머들이 반대의견을 낼 수 있도록 격려하십시오. 여러분은 "당신의 제안은 12시간이 필요한 것입니다 하지만 저는 한 시간만에 할 수 있습니다. 단지 저는 x는 하지 않고 y를 할 것입니다." 와 같은 의견들을 듣기 원할 것입니다. 프로그래머들에게 자신들이 최선이라고 생각하는 것을 위해서 싸우라고 말하십시오.
그리고 개발을 더 많이 요구하지 않는 다른 방법을 찾아보세요. 화면에 문구를 변경하여 사용자들에게 그것이 필요하지 않도록 할 수는 없습니까? 예를 들어 사용자들이 이미지를 업로드할 때 서버측에 이미지 툴 기능을 제공하는 대신 사용자들에게 지정된 크기의 이미지를 올리도록 안내할 수 있습니다.
어플리케이션에 포함되는 모든 기능들에 대해서 스스로에게 물어보세요. "더 큰 소프트웨어를 만들지 않고도 이 기능을 추가하는 방법이 없을까?" 꼭 필요한 코드만을 추가하세요. 그렇게 하면 어플리케이션은 더 가볍고 건강해질 것입니다.
아직 작성하지 않은 코드보다 더 유연한 코드는 없습니다.
좋은 소프트웨어 디자인의 비밀은 코드에 무엇을 추가할 지를 아는 것에 있지 않고 무엇을 뺄 지를 아는 것에 있습니다. 또 중요한 부분과 그렇지 않은 부분이 어디인 지를 파악하는 데에 있으며, 어떤 부분을, 빽빽하게 만드는 대신, 여유롭게 만들지를 아는 것에 있습니다.
—Brad Appleton, 소프트웨어 엔지니어 (from There is No CODE that is more flexible than NO Code!) 복잡도는 크기에 단순 비례하는 것이 아닙니다.
잘 알려지지 않은 소프트웨어 엔지니어링의 주요 원칙 중의 하나는 복잡도가 크기에 선형 비례하는 것이 아니라는 것입니다. 2000라인의 프로그램이 그 절반 크기를 개발하는 것에 비해서 2배 보다 많은 개발 시간이 필요합니다.
—The Ganssle Group (from Keep It Small) 행복을 최적화하세요.
여러분의 팀에 흥미와 자극을 줄 수 있는 개발 환경을 선택하세요. 행복한 프로그래머는 생산적인 프로그래머입니다. 그것이 바로 우리가 행복을 위해서 최적화를 하는 이유이며 여러분 또한 그렇게 해야 합니다.
특히 프로그래밍 언어를 선택하는 것은 매우 중요합니다. 일반적인 대중의 인식과는 반대로 언어들은 다 비슷한 것이 아닙니다. 사실 어떤 언어로도 무엇이든 못만드는 것은 아니지만, 적절히 선택된 언어는 개발을 단순히 가능하는데 그치지 않고 즐겁고 기운나게 합니다. 이것은 매일매일의 업무를 즐거울 지를 결정하는 중요한 요소입니다.
행복은 연쇄 효과를 가지고 있습니다. 행복한 프로그래머는 옳은 일을 합니다. 그들은 간단하고 읽기 좋은 코드를 작성합니다. 또 간결하고 분명하며 품위있는 방식을 사용합니다. 그리고 그들은 재미있습니다.
우리는 Ruby로 개발하는 즐거움을 발견했으며 Rails를 통해서 그것을 다른 개발자들에게 전파했습니다. Ruby와 Rails는 모두 사람과 사람의 행복을 최적화 한다는 미션을 지향합니다. 여러분도 그 조합을 한 번 사용해보시기 바랍니다.
요약해보면 여러분의 팀은 그들이 사랑하는 툴들을 사용할 수 있어야 합니다. 우리는 여기서 프로그래밍 언어를 주로 얘기했습니다. 하지만 같은 내용이 어플리케이션들과 플랫폼 그리고 그 밖에 모든 것들에 적용됩니다. 그들을 흥분 시킬 수 있는 도화선과 같은 툴들을 선택하세요. 흥미와 동기를 높여주고 결과적으로 더 나은 제품을 얻게 될 것입니다.
여러분이 필요한 엔지니어
우리가 어플리케이션을 Ruby on Rails로 개발하는 첫번째 이유는 그것이 정말 품위있고 생산적이며 아름답게 디자인되었기 때문입니다. 또한 이런 요소들을 중요시하는 엔지니어들의 관심을 모을 수 있으며, 그런 엔지니어들이 바로 여러분이 원하는 사람들입니다. 왜냐하면 그들은 품위있고 생산적이며 아름>다운 소프트웨어를 만들 것이며 그것이 바로 시장에서 이기는 길이기 때문입니다.
—Charles Jolley, Managing Director at Nisus Software (from Signal vs. Noise) 코드는 말을 합니다.
코드가 하는 말을 들으세요. 코드에 귀를 기울이세요. 코드는 여러가지를 제시합니다. 코드는 어디에 문제가 있는 지 말해주며, 문제를 해결하기 위한 새로운 방법을 제시하기도 합니다. 또 더 작은 소프트웨어 모델에 집중할 수 있도록 도와줍니다.
어떤 새로운 기능의 개발을 위해서 여러 주가 필요하고 수 천라인의 코드가 요구됩니까? 그것은 바로 코드가 더 좋은 다른 방법이 있다는 것을 말해주는 것입니다. 10시간이 걸릴 복잡한 방법대신 단 한 시간이면 코딩이 끝날 간단한 방방법이 있습니까? 이 또한 코드가 여러분을 안내해주는 것입니다. 코드에 귀 기울이세요.
코드는 더 비용이 적게들고 가벼운 수정이 가능하도록 안내해 줍니다. 쉬운 경로들이 나타날 때는 주의를 기울이세요. 분명히 구현하기 쉬운 기능은 여러분이 원래 마음 속에 떠올렸던 그 기능이 아닐 수도 있스니다. 하지만 무슨 상관입니까? 그 기능이 충분히 잘 동작하고 남는 시간에 여러분이 뭔가 또 다른 일을 게속할 수 있다면 말입니다.
잘 들으세요.
디자인에 대해서 걱정하지 마세요. 코드에 귀를 기울이다면 저절로 좋은 디자인이 나타날 것입니다. 기술자들의 말에 귀를 기울이세요. 만약 그들이 어떤 변경을 하는 것이 어렵다고 불만을 제기한다면 그 불만을 진지하게 받아들이고 그것들을 고치는 데 충분한 시간을 주십시오.
—Martin Fowler, Chief Scientist, ThoughtWorks (from Is Design Dead?) 만약 프로그래머가 코드를 지우는 댓가로 월급을 받는다면
만약 프로그래머들이 소프트웨어에 새로운 코드를 추가하는 대신 코드를 지우는 것에 대해서 돈을 받는다면 소프트웨어는 훨씬 더 좋아졌을 것입니다.
—Nicholas Negroponte, MIT 미디어랩 교수 (from And, the rest of the (AIGA Conference) story) 부채를 관리하세요.
코드 부채를 줄이고, 청구서에 대비하세요. 우리는 보통 부채는 돈에 대한 것이라고 생각하지만, 사실 그것은 여러가지 형태로 존재합니다.여러분은 아주 쉽게 코드를 만들 수 있을 겁니다 그리고 그것은 디자인의 부채가 될 수 있습니다.
기능은 동작하지만 난해한 나쁜 코드를 만드는 것은 빚을 지는 것과 같습니다. 적당하지만 정말 좋은 것은 아닌 디자인을 사용하는 것 역시 마찬가지입니다.
가끔은 그렇게 할 수도 있습니다. 사실은 어떤 일을 빨리 처리해야 할 때는 이런 방식이 필요할 수도 있습니다. 그러나 여러분은 이것이 빚이기 때문에 어떤 시점에 도달하면 난해한 코드를 정리하고, 그저 그런 페이지를 다시 디자인하는 식으로 그 빚을 청산해야 한다는 사실을 분명이 기억해야합니다.
우리가 정기적으로 수입 중의 일부를 세금의 몫으로 남겨두듯이 정기적으로 일정 시간을 코드와 디자인의 빚을 청산하는데 사용해야합니다. 그렇게 하지 않으면 원금을 청산하여 계속 앞으로 진행하지 못하고, 이자를 물면서 잘못들을 수정하는 데 더 많은 노력을 들여야 할 것입니다.
문을 여세요.
RSS, API 등을 통해서 데이터를 세상으로 보내세요. 고객들을 가두어 두려고 하지 마십시오. 그들이 원할 때는 언제든 지 원하는 방식으로 자신들의 정보를 가져갈 수 있도록 하십시오. 그렇게 하려면 데이터를 은밀하게 감싸두려는 생각을 포기해야합니다. 대신 데이터를 자연스럽게 노출하세요. 사람들이 그들의 정보를 rss를 통해 접근할 수 있도록 하세요. 다른 개발자들이 여러분의 데이터를 가지고 개발할 수 있도록 api를 제공하세요. 그렇게 하면 사용자들의 삶을 더 편리하게 만들게 되며, 여러분 어플리케이션의 가능성 또한 더 커지게 됩니다.
사람들은 RSS를 단순히 블로그나 뉴스사이트의 새로운 글을 확인 할 수 있는 수단으로 생각했습니다. 하지만 RSS는 그것보다 더 많은 것을 할 수 있습니다. RSS는 고객들이 어플리케이션에 직접 접속하지 않고도, 어플리케이션에 있는 자신들의 Content에 대해서 발생한 새로운 변화들을 쉽게 알 수 있게 해줍니다. Basecamp의 RSS 피드는 고객들이 자신들이 참여한 프로젝트에서 새로운 메시지나 할당된 업무 리스트, 변경된 마일스톤의 내용들을 확인 할 수 있게 해줍니다.
API는 개발자들이 여러분의 어플리케이션에 대한 추가 기능들을 만들 수 있게 해줍니다. 그리고 그런 추가 기능들 중에서 어떤 것은 여러분의 어플리케이션의 가치를 엄청나게 높여줄 수 있습니다. Backpack 에서 제공한 API를 사용해서 Chipt Production에서는 Mac OS X용 대쉬보드 위젯을 만들었습니다. 그 위젯으로 사람들은 데스크탑 화면에서 직접 기억해야할 내용들을 쉽게 추가하고 편집할 수 있었습니다. 사람들은 이 위젯에 대해서 환호했고, 이떤 사람들은 이 위젯이야 말로 Backpack을 사용하는 가장 중요한 이유라고도 말합니다.
부메랑 효과를 얻기 위해서 기업들이 데이터를 무료로 제공하는 좋은 예들은 다음과 같습니다.
구글의 지도 API는 사람들이 다른 곳의 데이터들(아파트 리스트 같은)을 가져와서 지도 위에 표시하는 것과 같은 재미있는 매쉬업들들 많이 양산했습니다. Linkrolls는 사람들이 최신의 del.icio.us 북마크를 자신들의 사이트에 표시할 수 있는 방법을 제공했습니다. Flickr는 다른 업체들이 상업용 API를 이용하여 고객들이 사진집이나 포스터, 우표 등을 구매할 수 있도록 했습니다. Flickr의 Stewart Butterfield는 말합니다. "목표는 완전히 개방해서 사람들이 사진으로 할 수 있는 모든 다양한 일들을 할 수 있도록 하는 것입니다." 위젯은 차이를 만듭니다.
37signals이 얼마전에 Backpack를 서비스하기 시작했을 때, 나의 첫 인상은...으.
위젯을 처음 제공했을 때 그것은 너무나 멋졌기 때문이 다운받아서 사용하지 않을 수 없었고, 그 때문에 나는 Backpack을 다시 한 번 살펴보게 되었습니다. 그리고 그 느낌은 처음과는 많이 달랐습니다.
이제 나는 어떤 아이디어가 떠오르면 팝업을 띄워서 입력하고 전송합니다. 확인해야할 메일이 도착하나요? 위젯을 띄우고 입력하고 전송하면 끝입니다. 위젯은 내가 사용하는 모든 맥에서 내가 사용하는 순간 두뇌 'dump'와 같습니다. 그리고 모든 것이 웹 기반이므로 어떤 버전 콘트롤이나 동기화도 필요없습니다. 데이터 어디로 가는지 나중에 어떻게 접근할 수 있는 지는 걱정할 필요가 없으며 그냥 내용을 입력만 하면 됩니다.
—Todd Dominey, 창립자, Dominey Design (from Trying on Backpack)
기능명세서는 어떤 기능도 하지 못합니다.
기능 정의서를 작성하지 마십시오. 기능 정의서는 환상입니다. 기능정의서는 실제를 반영하지 못합니다. 어플리케이션은 개발자가 구현하고 디자이너가 디자인하고 사용자들이 사용하기 전에는 '진짜'가 아닙니다.
기능정의서는 일종의 타협입니다. 그것은 사람들을 기분좋게 만드는 따뜻하고 모호한 말들로 만들어지지만 전혀 도움이 되지 않습니다. 어플리케이션을 잘 만들기 위해 알아야할 어려운 결정사항이나 비용에 대해서 알려주지 못합니다.
기능 정의서는 '합의'라는 환상만을 이끌어 낼 뿐입니다. 많은 사람들이 진짜 합의가 아닌 문장에 동의합니다. 모든 사람들은 같은 내용을 읽으면서도 다른 것을 생각합니다. 그리고 나중에 꼭 문제가 생깁니다. "잠깐 이것은 내가 생각했던 것이 아닌데", "어? 이것은 우리가 적었던 방식이 아닙니다", "그렇지 않습니다. 이것은 우리가 합의했고 사인까지 한 바로 그대로입니다." 이런 식이 됩니다.
기능 정의서는 가장 중요한 결정을, 가장 정보가 부족한 시점에 하도록 강요합니다. 개발을 시작하는 시점은 여러분이 가장 적게 알고 있을 때입니다. 개발을 진행 할 수록 점점 더 많이 알게되며, 바로 그 때가 정말로 결정을 해야하는 시점입니다. 정보를 더 많이 가지고 있을 때 말입니다.
기능정의서는 오버스펙을 야기합니다. 스펙을 작성는 하는 동안에는 일정 지연이라는 것이 없습니다. 글을 쓰거나 항목을 하나 더 추가한다고 해서 비용이 더 드는 것도 아닙니다. 어떤 사람을 만족시키기 위해서 개인 취향의 기능을 하나 추가할 수도 있습니다. 이러다 보면 어느새 화면 상단에 30개의 탭이 필요하게 됩니다.
기능정의서에 대해서는 개선이나 변경, 재평가가 잘 이루어지지 않습니다. 하나의 기능이 합의되고 서명되고 나면, 개발을 진행하면서 어떤 경우에는 그것이 나쁜 생각이었다는 것을 알게되더라도 어쩔 수가 없습니다. 스펙은 여러분이 실제 개발을 진행하면서 다루게 되는 실제가 아닙니다. 모든 것은 변하기 때문입니다.
그렇다면 스펙에서 해야 할 것은 무엇일까요? 실제 구현을 위해서 할 수 있는 간단한 방법들을 적으세요 . 어플리케이션에 요구되는 사용자 스토리를 간단히 한페이지 정도로 작성하십시오. 일반적인 용어를 사용해서 신속하게 작성하십시오. 만약 한 페이지 이상이 필요하다면 지나치게 복잡한 것입니다. 또 이 과정은 하루 이상 진행되어서는 안됩니다.
그리고 나서는 인터페이스를 만드세요. 인터페이스는 기능 정의서에 대한 하나의 대안이 될 수 있습니다. 종이 위에 간단하게 그리세요. 그리고 나서 html로 코딩을 시작하세요. 글로 적은 것은 여러 가지로 해석될 수 있지만 인터페이스 디자인은 모든 사람이 제대로 동의할 수 있는 공동의 기반을 제공합니다.
모든 사람이 똑같은 화면을 사용하면 혼란은 사라집니다. 모든 사람들이 보고 사용하고 클릭도 해볼 수 있는 인터페이스를 '백엔드' 코드를 개발하기 전에 만드세요. 최대한 여러분 자신을 사용자들이 경험하는 입장에 두십시오.
고정불변의 스펙같은 것은 잊어버리세요. 그것은 여러분이 크고 중요한 결정들을 개발과정 중에 너무 일찍 하도록 합니다. 스펙 작성 단계는 스킵하세요. 그리고 항상 유연하고 쉽게 변경할 수 있는 자세를 유지하세요.
불필요한 스펙
스펙은 거의 소용이 없습니다. 나는 충분히 크고 상세하면서 동시에 유용하고 정확한 스펙을 한 번도 본적이 없습니다.
그리고 나는 스펙에 기반한 많은 작업들이 엉망이 되는 것을 봐왔습니다. 스펙 작성은 소프트웨어를 만드는 정말 나쁜 방법의 하나입니다. 왜냐하면 그것은 말 그대로 소프트웨어가 이론에 일치해야 한다는 것을 의미하게 때문입니다. 실제가 아니라 말이죠.
—Linus Torvalds, Linux창시자 (from: Linux: Linus On Specifications) 방해꾼들에 맞서세요.
저는 광범위한 요구사양서를 강하게 요구하는 사람들이 사실 개발 단계의 진행을 늦추려 하는 방해자들이라는 것을 알게되었습니다. 이런 사람들은 보통 디자인이나 창조적인 사고에는 전혀 기여하지 못하는 부류입니다.
우리가 자랑하는 최고의 결과들은 모두 머리속에 있는 몇 개의 개념을 가지고 만들어졌습니다. html로 간단한 프로토타입을 만들고 화면 디자인을 조금 바꾸어보고, 진짜 데이터를 포함한 동작하는 프로토타입을 만들어보면서 말입니다. 이러한 프로토타입을 여기저기 만지고 두드려본 후에 우리는 진짜 프로젝트를 시작하며 좋은 결과를 얻 게 됩니다.
—Mark Gallagher, 기업 인트라넷 개발자 (from Signal vs. Noise) 사문서를 만들지 마세요.
불필요한 문서작업을 줄이세요. 기능정의서를 작성하지 않은 것은 좋은 출발이지만 거기서 멈추지 마십시오. 모든 곳에서 지나친 문서작업을 막으세요. 문서가 실제 결과에 녹아들어갈 것이 아니라면 만들지 마십시오.
글을 쓰는 대신 개발을 하세요. 뭔가 설명할 필요가 있다면 모양을 만들고 프로토타입을 만드는 것이 긴 문서를 작성하는 것보다 낫습니다. 인터페이스나 프로토타입은 실제 제품으로 가는 과정입니다. 하지만 문서는 결국 쓰레기통으로 가게될 뿐입니다.
구체적인 예를 들겠습니다. 만약에 디자인가이드 문서가 작성이 끝난 후에 실제 디자인이 되지 않을 것이라면 작성하지 마십시오. 그 문서가 실제 디자인으로 녹아들 것이 맞는 다면 작성해도 좋습니다.
여러분의 어플리케이션과 따로 노는 문서는 아무런 가치가 없습니다. 여러분이 하는 모든 행동은 실제 결과물로 이르는 것이어야 합니다. 만약 문서가 그 자체로서만 존재한다면 그것은 죽은 문서입니다.
아무도 읽지 않습니다.
저는 지금까지 결국 읽히지도 않을 개발 요구 사양과 비지니스 요구 기술서들을 얼마나 많이 작성했는지 모릅니다. 우리가 코딩하고 문제들을 토론하고 질문을 주고받으면서 사용자 테스트를 하는 동안, 개발팀 옆의 책상위에 있던 그 문서들에는 먼지만 쌓이고 있었습니다. 또 길고 상세하게 몇 시간을 들여서 이메일을 작성하거나 코딩 규칙 문서를 작성하는 개발자들과 함께 일한 적도 있지만 이런 것들 역시 아무도 읽지 않습니다.
웹 어플리케이션은 여러 문서들을 가지고 진행되는 것이 아닙니다 소프트웨어 개발은 계속적으로 변하며, 상호작용에 대한 반복적인 프로세스이고 신속한 결정과 계속해서 나타나는 예측불가의 이슈들에 대한 것입니다. 이 들중 어떤 것들도 문서로 미리 쓰여질 수 없고 그러한 시도를 해서도 안됩니다.
방대하고 보기좋은 문서를 만들기 위해서 여러분의 시간을 낭비하지 마십시오. 아무도 읽지 않을 겁니다. 문서를 작성하지 않는 것은 오히려 여러분의 제품이 성장하고 변화될 수 있는 기회를 제공합니다. 문서들은 결국 최종의 제품과는 전혀 비슷하지 않을 것이라는 것을 기억하십시오.
—Gina Trapani, 웹 개발자 및 편집자 Lifehacker, the productivity and software guide 짧은 스토리를 쓰세요.
스토리를 작성하세요. 단 상세하지 않아야 합니다. 만약 여러분이 어떤 기능이나 개념을 설명할 필요가 있다면 간단한 스토리를 쓰세요. 기술이나 디자인의 상세한 부분에 대해서 적지 마세요. 단지 간단한 스토리만을 쓰세요. 대화를 하듯이 사람의 관점에서 쓰십시오.
에세이처럼 적지는 마십시오. 다만 어떤 일들이 일어날 지에 대한 흐름을 기술하세요. 그리고 거기에 여러분이 만들고 있는 몇 개의 화면들을 추가한다면 더 좋습니다.
세부적인 내용들보다는 사용자 경험에 집중하세요. 세부 전술보다는 전략을 생각하세요. 세부 전술들은 개발을 하다보면 여러 곳에서 실패할 수 있습니다. 처음에 여러분에게 필요한 것은 대화를 시작할 수 있게 해주고 올바른 방향으로 유도해 줄 스토리입니다.
현실의 단어들을 사용하세요.
"Lorem Ipsum"대신 실제 내용을 넣으세요. "Lorem ipsum dolor"("어쩌구 저쩌구")는 디자이너의 친구입니다. 아무 의미가 없는 문장들은 처음에는 신선해보일 수 있습니다. 하지만 무의미한 텍스트는 위험합니다.
"Lorem ipsum"은 화면이 보여지는 방식을 바꿉니다. 그것은 텍스트 기반의 콘텐트를 비쥬얼한 디자인으로 바꿉니다. 사용자가 입력하거나 읽어야 하는 의미있는 정보를 단지 텍스트의 '모양'으로 바꾸어 버립니다. 무의미한 텍스트는 실제 정보들이 입력되었을 때 피할 수 없게될 여러가지 변화들을 보지 못하게 합니다. 그것은 실제 입력 양식에 입력될 내용들이 결국 어떻게 보이게 될지 알지 못하게 하며 결국 여러분과 실제의 사이를 가리는 장막이 됩니다.
어떤 필드에 실제로 얼마정도의 길이의 내용이 들어갈지 알려면 실제 데이터가 필요합니다. 테이블이 얼마나 늘어나고 줄어들지를 알기 위해서 실제 데이터가 필요합니다. 또 진짜 어플리케이션이 어떻게 보일 지 알기 위해서도 실제 데이터가 필요합니다.
최대한 빨리 실제로 사용될 텍스트를 사용하십시오. 만약 여러분의 사이트가 데이터 입력이 필요한 것이라면 실제 데이터를 입력하세요. 이 때 복사와 붙여넣기를 사용하지 말고 실제로 입력을 하십시오. 만약 이름이라면 진짜 이름을 넣고 도시라면 정말 존재하는 도시의 이름을 넣으세요. 그리고 패스워드가 두 번 입력을 요구한다면 실제로 그렇게 하세요.
물론 입력 양식에 'abc', '123', 'dkfsj' 같은 아무 내용이나 넣는 것이 더 쉽고 빠릅니다. 하지만 이것들은 진짜가 아니며, 사용자들이 실제로 할 행동들이 아닙니다. 사용자들은 실제로 더 많은 시간이 필요한데 그것을 경험하지 않고 더 쉬운 방법은 택하는 것이 정말 잘하는 행동일까요? 여러분이 가짜 데이터를 빠른 방식으로 입력한다 면 여러분은 그 입력 양식을 사용할 때 사용자가 정말 어떻게 느끼게 될 지 결코 알 수 없습니다.
사용자가 하는 것과 똑같이 해보세요. 그러면 그들을 더 잘 이해하게 됩니다. 사용자들 더 잘 이해하고 그들이 느끼는 것을 똑같이 느낄 수록 더 좋은 인터페이스를 만들 수 있습니다.
'Lorem Ipsum' 쓰레기
실제 내용이 어떤 것일 지에 대해 생각하지 않는 것은 디자인에서 충분하 고려를 하지 못하는 것입니다. "Lorem Ipsum"을 사용하면 그것이 단지 "문자들"일 뿐이므로 의미가 사라지며, 누구도 그 내용이 어떤 것을 의미하는 지 알 수 없게되므로 전체적인 이해가 힘들게 됩니다. "Lorem Ipsum"은 어떤 내용도 전달하지 못하므로 실제 데이터를 사용했을 때 얻었을 수도 있는 개선의 기회를 놓치게 됩니다. 텍스트의 의미는 모두 축소되고 단지 예쁘게 배열된 공간들만을 가지게 됩니다.
—Tom Smith, 디자이너 및 개발자, (from I hate Lorem Ipsum and Lorem Ipsum Users) 제품에 인성을 담으세요.
여러분의 제품을 사람에 비유하면 어떤 사람인가요? 여러분의 제품을 사람으로 생각해보십시오. 여러분의 제품이 어떤 사람이기를 원합니까? 친절한 사람? 엄격한 사람? 관대한 사람? 재미있는 사람? 무덤덤한 사람? 진지한 사람? 자유로운 사람? 대단히 꼼꼼한 사람? 아니면 믿을 수 있는 사람?
일단 결정을 하면, 개발을 하는 동안 마음 속에 그 인성의 특성을 계속 기억하십시오. 그리고 카피라이팅이나 인터페이스, 기능들을 결정할 때 적용하십시오. 어떤 변경을 하는 경우에도 그 변화가 여러분이 결정한 제품의 인성에 부합되는 지를 확인하십시오.
제품은 목소리를 가지고 있습니다. 그리고 하루 24시간 계속 고객들에게 그 목소리로 얘기하게 됩니다.
무료 샘플
무료로 뭔가를 제공하십시오 정말 시끄럽고 정신없는 세상입니다. 이런 환경에서 사람들의 관심을 끌기 위해서는 뭔가 공짜같은 것이 필요합니다.
영리한 회사들은 공짜를 제공하는 것이 고객을 유인하는 정말 좋은 방법이라는 것을 알고 있습니다. 애플을 예로들면, 아이튠즈를 무료로 제공하여 아이팟과 아이튠즈 뮤직스토어에 대한 수요를 만들어냈습니다. 오프라인 세상에서도 소매점들은 똑같은 방식을 사용합니다. 스타벅스에 따르면 다섯번의 샘플 제공당 한 번의 새로운 고객이 생긴다고 합니다. 공짜 제공에 대해서 부끄러워 하지마십시오.
우리는 Writeboard와 Ta-da 리스트 서비스를 완전히 무료로 제공합니다. 그리고 이것을 통해서 고객들은 우리의 다른 서비스들을 사용하게 됩니다. 또 모든 우리의 서비스에는 어떤 형태로든 무료 버전의 샘플 서비스가 포함됩니다.
우리는 사람들이 우리가 만든 제품의 인터페이스와 유용성을 직접 경험해 보기를 기대합니다. 일단 고객들이 우리의 제품을 좋아하게 되면, 유로 서비스로의 전환을 하게 될 것입니다. (유료서비스에서는 동시에 여러 개의 프로젝트를 관리할 수 있거나, 더 많은 수의 페이지를 만들 수 있거나 파일 업로드나 SSL 암호화 같은 추가 기능들이 제공됩니다.)
한 입 크기
한 입 크기로 나누어 만드세요. 고객이 기꺼이 한 입 베어 물기에 적합하게 전문화되고 더 작은 크기의 서비스 조각들을 생각해내십시오. 저렴하고 쉽고 재미있는 한 입 크기의 서비스나 제품의 부분을 최소 하나 이상 만드십시오.
—벤 맥코넬과 재키 후바,Church of the Customer Blog의 저자 (from What is customer evangelism?) 여러 분의 히트작을 나누어 주세요.
여러분의 앨범에서 홍보를 위해서 한 곡을 무료로 다운로드 할 수 있게 해준다고 생각해봅시다. 영화의 예고편이나 라디오에 가수들이 제공하는 앨범 타이틀곡을 생각해보면 알겠지만, 그 무료로 제공되는 노래는 고객이 여러분의 전체 앨범을 기꺼이 살 수 있도록 해야합니다.
그 노래의 불법 유포같은 것은 걱정할 필요가 없습니다. 사람들이 그 노래를 마음껏 연주하고 복사하고 공유하고 선물하도록 하십시오. 세상이 모두 그 노래를 듣는다면 결국 여러분에게 보답이 있을 것이라는 믿으십시오.
—드렉 시버스, CD Baby와 HostBaby의 대표 겸 프로그래머 (from Free Promo Track) 쉽게 시작하고 쉽게 끝내기
가입과 해지 과정을 고통없이 만드십시오. 여러분의 어플리케이션을 처음 사용하는 절차와 사용 중지 절차를 최대한 쉽게 만드십시오.
여러분의 어플리케이션을 사용하려는 고객의 입장에서는, 가입절차는 어려움이 없고 머리를 쓸 필요가 없을 수록 좋습니다. 큼직하고 깔끔한 가입 버튼을 만들어서 여러분의 각 홍보 페이지의 잘보이는 곳에 넣으세요. 사람들에게 가입이 얼마나 쉬운 지 말하세요. "가입에서 로그인까지 1분이된 됩니다"
고객들이 자신들의 신용카드번호를 입력하기 전에 미리 경험용으로 사용할 수 있는 무료 옵션을 제공하십시오. 어떤 경쟁자들은 무료 옵션을 사용하기 위해서 특별한 암호나 어떤 약속이나 콜백같은 것을 요청합니다. 도대체 그런 것들이 무슨 의미가 있나요? 우리는 고객들이 언제라도 무료로 사용할 수 있도록 합니다.
가입양식을 최대한 간단하게 하십시오. 실제로는 전혀 필요하지도 않은 내용들을 꼬치꼬치 묻기 위한 긴 양식을 만들지 마십시오.
동일한 원칙이 가입 해지 절차에도 적용됩니다. 여러분의 고객들을 서비스내에 꼭꼭 가두어 두려고 하지 마십시오. 사람들이 우리의 Basecamp계정을 해지하려고 하면 우리 역시 서운합니다. 하지만 우리는 해지 절차를 복잡하거나 어렵게 만들지 않습니다. "가입 해지" 링크는 고객의 계정 페이지에 명확히 표시됩니다. 가입해지를 위해서 이메일을 보내거나 특별한 양식을 입력하거나 질문에 답하는 일 같은 것은 절대 요구하지 않습니다.
또한, 사람들이 원한다면 그들이 해지할 때 자신들의 데이터를 가져갈 수 있도록 보장하십시오. 우리는 고객들이 쉽게 모든 메시지와 코멘트들을 xml 형태로 언제라도 가져갈 수 있는 기능을 제공합니다. 그것을 그들 소유의 데이터이므로 그들이 원하는 대로 할 수 있어야 합니다.
이 것은 정말 필수적인 요소입니다. 왜냐하면 사람들이 자신들의 정보를 마음대로 제어할 수 있게 하는 것은 '신뢰'를 구축하기 때문입니다. 고객의 데이터라는 섬에 다리를 제공하고 그들이 아무런 피해없이 떠나 갈 수 있도록 하십시오. 그것이 옳은 일이며 또한 좋은 일입니다.
쉬운 해지
사용자들을 그들의 의지에 반하여 붙잡아 두지 마십시오. 그들이 떠나기를 원한다면 어떤 추가 비용없이 그들이 만든 모든 데이터를 가지고 떠날 수 있도록 하십시오. 그들이 어쩔 수 없이 붙잡혀 있는 것이 아니라 스스로 돌아오고 싶어지도록 만드십시오.
—챨리 오도넬, Union Square Ventures의 분석가 (from 엄청 성공적인 웹2.0기업을 위한 10단계) Silly Rabbit, Tricks are for Kids
장기 약정이나 서비스 요금제 같은 것을 만들지 마십시오. 장기 계약을 좋아하는 사람이나 조기 해지시의 추가 요금이나 최초 설정비 같은 것 역시 그렇습니다. 그러므로 이러한 것들을 만들지 마십시오. 우리의 서비스는 매월 요금이 청구됩니다. 특별히 체결하거나 해지하는 계약 같은 것은 없습니다. 그리고 절대 설정비 같은 것도 없습니다.
돈을 더 벌기 위해서 치사한 방법을 찾으려 말고, 정당하게 돈을 버세요.
부드러운 총알
나쁜 소식은 미리 공지하여 충격을 완하시키세요. 요금 인상과 같은 나쁜 소식을 전해야만 한다면, 가능한 미리 사전 공지를 하여 사용자들이 느끼는 충격을 최소화하십시오. 또 기존의 고객들에게는 일정한 기간동안 인상을 면제해주는 기간을 두십시오. 기존의 고객들은 여러분을 먹여 살리는 사람들이므로, 바가지를 썼다고 느끼는 대신 자신들이 대접받고 있다고 느끼도록 하십시오.
헐리우드 론칭
티저 광고에서 미리보기 그리고 론칭 만얀 어떤 서비스가 깊은 숲 속에서 개시되어서 아무도 사용하는 사람이 없다면 그 서비스에 대한 소문들이 생겨날까요? 여기에서 우리가 강조하고 싶은 것은 여러분의 서비스가 사전에 어떤 기대감도 형성하지 못한채로 개시된다면 사람들은 그 서비스에 대해서 전혀 알지 못하게 될 것이라는 사실입니다.
흥분과 기대감을 만들기 위해서는 헐리우드식의 론칭이 필요합니다. 그것은 다음과 같은 순서로 진행됩니다. 1) 티저, 2) 미리보기, 3) 서비스 시작
티저광고(Teaser) 몇 달 전에 힌트를 흘리기 시작하세요. 여러분이 무엇인가 하고 있다는 사실을 사람들에게 알리세요. 로고를 만들어서 공개하세요. 블로그에 개발에 대해서 적으세요. 다소 모호하게 씨앗을 뿌리세요. 그리고 관심있는 사람들의 메일 주소를 수집할 수 있는 사이트를 만드세요.
이 단계에서는 전문가들과 커뮤니티 그룹에 속한 사람들의 관심을 끌기 위해 노력해야 합니다. 이러한 사람들은 항상 최신 기술을 지향하며, 유행을 만들어냅니다. 남들에게 보여주기를 좋아하는 그들의 특징과 변화 선도자로서의 속성을 이끌어 내십시오. 그들에게 남들은 경험할 수 없는 비밀스런 프리뷰가 있을 거라고 말하십시오. 보잉보잉, 슬래쉬닷, Digg 같은 사이트가 여러분의 어플리케이션을 링크한다면, 많은 트래픽과 관심을 받게 될 것입니다. 또 구글의 페이지 랭크도 올라갈 것입니다.
프리뷰 서비스 개시 몇 주 전에는 프리뷰 기능들을 시작하세요. 사람들에게 제한된 접근을 허락하세요. 서비스의 테마를 설명해주세요. Basecamp에서는 스크린샷들을 올려서 리마인더, 마일스톤 등의 기능들을 강조했습니다.
그리고 어플리케이션 서비스에 녹아있는 원칙과 아이디어들에 대해서 말하십시오. Backpack 서비스에서 우리는 서비스 개시 전에 우리의 이념을 공개했습니다. 이 것으로 인해 많은 사람들이 우리의 어플리케이션에 대해서 생각하고 얘기를 나누게 되었습니다.
또 여러분은 어떤 종류의 특별 티켓을 몇 명에게만 제공하여 그들이 서비스를 먼저 시작할 수 있게 할 수도 있습니다. 그들은 자신들이 얼리아답터가 되는 것에 대한 특별한 즐거움을 얻게 되고 동시에 여러분은 베타테스터를 얻게 됩니다.
그리고 서비스가 개시되었을 때 사용할 이메일 주소들을 확보 할 수 있도록 사람들의 사전가입을 계속 유도하세요. 우리의 경우 서비스를 시작할 때 쯤이 되면, 가입의사를 밝힌 수 천개의 메일을 확보하게 되며 이것은 서비스가 잘 굴러갈 힘을 얻는 데에 큰 도움이 됩니다.
Launch 이제 서비스를 릴리즈할 때입니다. 사람들이 서비스를 보러 극장으로 몰려옵니다. 서비스 가입을 예약했던 사람들에게 메일을 보내세요. 마케팅 전용 사이트를 여세요. 최대한 많이 좋은 소문들을 퍼뜨리세요. 블로그들이 링크를 올리도록 노력하세요. 진행상황에 대해서 계속 글을 올리세요. 얼마나 많은 사람들이 가입했습니가? 어떤 업데이트 가 있었고 어떤 수정을 추가했는 지를 공개하세요. 모멘텀들을 미리 알려주고 지켜나가세요.
서비스 개시까지의 과정
Blinksale이 정말로 만들게 될 것이라는 것을 알자마자 우리는 메일링 리스트를 통해서 숨겨진 광고를 흘리기 시작했다. 그들은 우리의 프로젝트에 대해서 정보를 받겠다고 신청한 사람들이었다. 그들은 우리의 팬이었다. 만약 어떤 정보를 정보를 전달하도록 허가 받은 사람들을 있다면 그들이 바로 첫번째 시작할 대상이다.
두번째로 우리가 한 것은 우리의 제품에 대해서 얘기를 할 수 있는 더 많은 사람들로 부터 허락을 받아내는 것이었다. 서비스를 시작으로부터 약 6주전에 우리는 웹사이트에 티저광고를 위한 페이지를 만들었다. 그것은 더 쉽게 송장(invoice)를 보낼 수 있는 더 쉬운 방법이 생길 것이라는 것을 알려주는 것이었다. 그 페이는 단지 호기심과 약간의 긴장감을 일으킬 정도로만 정보를 제공하였으며 너무 세부적인 정보들은 여전히 숨기고 있었다. 그 페이지에서 선명하게 표시된 한 가지는 메일 주소를 입력받기 위한 양식이었다. 다른 정보는 모두 필요없고 단지 이메일만을 요구하였으며, 관심이 있는 사람들이 나중에 서비스가 개시되었을 때 통보를 받을 수 있게 하는 것이었다.
우리는 약 10여명의 친구와 동료들에게 우리가 만들 제품에서 느끼고 생각하는 점들을 전달했고 그들은 자신들의 블로그를 통해서 앞에서 말한 티저광고 페이지와 우리의 얘기를 전파했다. 몇 일이 지나지 않아서 우리는 수 천개의 메일 주소를 갖게 되었다. 그들은 우리에게는 중요한 사람들이었다. 그들은 바로 우리의 서비스에 대해서 더 알고 싶어하는 사람들이었으며 우리가 서비스를 개시할 때 통보받기를 원하는 사람들이었다.
마침내 서비스 개시 약 2주전에 우리는 몇명의 친구들과 동료들 그리고 업계에서 유명한 사람들을 초대하여 Blinksale의 베타 테스트를 부탁했다. 그 사람들은 우리의 서비스에서 유용함을 얻을 수 있으면 동시에 우리 서비스에 대한 얘기를 널리 퍼트려 줄 수 있는 사람들이었다. 우리가 그 누구에게도 우리 서비스에 대한 글을 쓰도록 부탁하거나 강요하지 않았다는 점은 중요한 사실이다. 우리는 단지 우리의 제품이 보여주기를 원했고 서비스가 개시될 때 사람들이 그것에 대해서 얘기를 나누기를 원했다. 만약 이런 식으로 많은 사람들의 관심을 이끌어 낼 수 있다면 여러분의 서비스 성공할 것이라고 여겨도 좋을 것이다. 그렇지 못하면 그 서비스는 바람앞에 등불과도 같다.
서비스 개시일이 되었을 때, 우리는 메일링 리스트에 메일을 보내고, 우리의 블로그 친구들에게 알렸다. 그리고 베타 서비스를 사용하고 있던 사람들이 그들이 느낀 점을 얘기하도록 권유했다. 그리고 정말 기쁘게도 그 노력은 큰 결실을 맺었다. 서비스 개시가 되자마자 수만명이 우리 사이트를 방문하고 수천명이 가입을 한 것이다.
—Josh Williams, 창업자, Blinksale 강력한 홍보 사이트
티저광고에서 프리비 그리고 서비스 개시 홍보를 위한 최고의 수단은 휼륭한 제품입니다. 만약 사람들이 정말로 유용하다고 생각하는 어플리케이션을 만들어 낸다면 저절로 소문이 퍼져 나갈 것입니다.
하지만 홍보 사이트 역시 필요합니다. 홍보사이트에는 어떤 내용을 담아야 할까요? 다음과 같은 것들입니다.
개요: 서비스에 대해서 설명하고 어떤 좋은 점들이 있는 지 설명하세요. 둘러보기: 사람들이 다양한 기능들을 경험할 수 있도록 하세요. 화면 캡쳐와 비디오: 어플리케이션의 실제 모습과 동작 방식을 보여주세요. 정신: 어플리케이션의 담긴 정신과 아이디어들을 설명하세요. 케이스 스터디: 실제 사용 예제를 제공하고 구체적으로 어떤 것들이 가능한지를 보여주세요. 인기: 사용자들의 증언과 리뷰, 언론의 기사 등을 실으세요. 포럼: 커뮤니티의 멤버들이 서로를 도울 수 있는 공간을 제공하세요. 가격과 가입: 사람들이 최대한 빨리 서비스에 가입할 수 있도록 하세요. 블로그: 블로그는 여러분의 사이트를 새로운 소식, 사용팁 등을 다루면서 여러분의 사이트를 신선하게 유지해줍니다.
블로그에 올라타기
블로깅은 광고보다 더 효과적입니다. (더구나 훨씬 저렴합니다.) 광고는 비용이 많이 듭니다. 그리고 여러가지 광고의 효과를 정확히 파악하는 것에는 더 많은 비용이 들어갑니다. 전통적인 방식의 광고를 할 만한 시간과 돈이 없다면 블로그를 통한 광고를 고려하십시오.
서비스에 가입하기를 권유하면서 동시에 유용한 정보들과 팁, 도움이 되는 링크들을 제공하는 블로그를 만드세요. Signal vs. Noise 블로그는 매일 여러가지의 흥미로운 내용들과 도움이 될 수 있는 정보들을 올리고 있기 때문에 일주일에 수천명의 사람들이 방문하고 있습니다.
37Signals의 첫번째 서비스인 Basecamp의 경우에도 블로그에서 홍보가 시작되었습니다. SvN에 먼저 서비스에 대한 글이 올라왔고 그 내용이 널리 펴졌습니다. Kottke, BoingBoing의 블로거들, Jim Coudal 같은 많은 유명 블로거들이 이 서비스를 널리 알렸으며 이것이 서비스의 성공적인 출발에 큰 도움이 되었습니다.
Ta-da List는 블로그를 이용한 마케팅의 또 다른 좋은 예입니다. Ta-da 는 SvN의 하나의 글에서 시작되었습니다. 몇 주가 지난 후에 200여개의 블로그에서 Ta-da가 언급되었고, 12000명의 사람들이 Ta-da에 계정을 만들기 위해서 가입했습니다. Backpack의 경우에는 소문이 더 빨리 퍼졌습니다. 24시간만에 10000명이 가입했습니다.
미리 홍보하기
미리 붐을 조성하고 서비스 가입을 받으세요. 이미 다룬 내용이지만, 중요하기 때문에 다시 한 번 다음 내용을 강조할 필요가 있습니다. 먼저 사이트를 하나 만들고 이메일 수집을 최대한 빨리 시작하세요. 도메인명을 선택하고 로고도 만드세요. 한 두개의 문장으로 서비스를 설명하세요. 또 어떤 서비스가 나올 지 힌트를 주세요. 이런 방식으로 서비스가 개시되었을 때 그 서비스를 기 다리고 즉시 가입할 사용자 층을 형성할 수 있습니다.
지식공유를 통한 홍보
지식을 세상과 공유하세요. Jeopardy에 선생님이 출연하면 Alex Trebek은 자주 '고상한 직업'이라고 말하곤 합니다. 그 말이 맞습니다. 지식을 타인과 공유하는 것은 정말 멋지고 가치있는 일입니다. 더구나 공유되는 내용이 서비스될 어플리케이션에 대한 거라면 일석이조의 효과가 있는데 대중에게 뭔가 가치있는 것을 제공하는 것과 홍보를 위한 효율적인 노출이 그것입니다.
홍보의 기술로서 지식공유는 서비스 또는 서비스 개발 주체의 명성을 높이는 자연스러운 방법입니다. '이 서비스에 가입하세요' 와 같은 직접적인 홍보대신 가치있는 뭔가를 제공하면서 사람들의 관심을 얻을 수 있습니다. 그것은 긍정적인 반응을 일으키게 되며, 이런 반응은 전통적인 홍보 방식으로는 얻기 힘든 것입니다. 지식을 제공받은 사람들은 자연스럽게 여러분이 만들 서비스에 대한 전도사가 됩니다.
지식공유는 여러가지 방식으로 가능합니다. 팁이나 요령을 올리면 사람들은 그것을 공유하려고 할 것입니다. 컨퍼런스에서 발표를 하고 참석자들과 만나서 인사하는 것도 가능합니다. 워크샵을 직접 주최해서 관심이 있는 사람들이 더 많이 배우고 서로 얘기할 수 있도록 할 수 도 있습니다. 대중언론과 인터뷰를 하거나 유용한 정보를 제공 하는 글을 써서 기고할 수 도 있고 지금 이 글처럼 책을 쓸 수도 있습니다. ;)
37Signals는 Yellow Fade Technique(YFT)라는 기술을 만들어 낸적이 있습니다. 이 것은 웹 페이지에서 최근에 변경된 부분을 부드럽게 강조하는 방식입니다. 이 방식을 소개하고 설명하는 글이 SvN에 올려졌고, 그 글은 계속해서 수천건의 페이지 뷰를 기록하고 있습니다. (지금까지도 엄청난 트래픽이 있습니다.)
그 글은 지식공유와 홍보라는 두 가지 측면에서 모두 유용했습니다. 하나의 새로운 기법이 널리 공유되었으며, 원래는 전혀 모르고 지나 갈 뻔 했던 많은 사람들이 37Signals의 서비스에 대해서 알게되었습니다. 또 다른 예는 37Signals에서 Ruby on Rails를 개발하면서 이것을 오픈소스화 한 것입니다. 그것은 정말 현명한 결정이었습니다. 37Signals는 대중에게 뭔가 좋은 일을 할 수 있었으며, 많은 피드백과 함께 세계 곳곳의 개발자들의 기여도 활발히 이루어졌습니다.
지식의 공유는 정말 좋은 일입니다. 그것은 남을 도우면서 건강한 홍보를 할 수 있게됩니다. 그리고 명성도 얻을 수 있게 됩니다. 자 여러분이 알고 있는 내용 중에서 남들이 알고 싶어할 만한 것에는 무엇이 있습니까?
Pay It Forward
37Signals의 사이트에서 블로그의 글과 팁 섹션이 가장 인기있는 부분입니다. 이메일 마케팅에 대한 지식을 공유하면 고객들은 더 서비스를 더 잘 이용할 수 있게됩니다. 그리고 이로 인해 사업이 더 잘될 것이므로 모두에게 이익이 됩니다.
자유롭게 지식을 공유하는 것은 전문분야에서 명성을 얻게 해 줄뿐 아니라 기존의 고객들과의 관계를 더욱 강화해줍니다. 왜냐하면 고객들은 좋은 지식을 공유하는 사람들이 서비스의 품질을 중요시 한다는 것을 쉽게 알 수 있기 때문입니다. 또 검색엔진이나 다른 블로그들을 통해서 높은 방문 트래픽을 갖게됨으로써 서비스에 더 많은 사람들이 노출되는 홍보효과가 있습니다.
—David Greiner, founder, Campaign Monitor 기능 음식
사용자들은 새로운 기능에 굶주려있습니다. 새롭고 흥미로운 기능은 어플리케이션을 널리 알릴 수 있는 좋은 방법입니다. 관심을 가진 사람들은 기능을 곱씹어본 후에 대중들에게 뱉어내기를 좋아합니다. 좀 불쾌한 비유지만 무슨 의미인 지 이해하시겠죠?
예를 들어 새로운 웹개발 플랫폼인 Ruby On Rails를 사용하면서 우리는 Basecamp에 대해서 개발자 커뮤니티로부터 엄청난 관심을 받게 되었습니다.
우리가 사용했던 Ajax 요소들은 상당히 유명해져서 Business 2.0이라는 잡지에서 37Signals가 구글, 야후, MS, 아마존과 함께 Ajax을 선도하고 있다고 언급하기도 했습니다.
또 많은 블로거들이 Basecamp의 RSS 기능에 관심을 가진 이유는 그것이 상용서비스에 RSS가 적용된 첫번째 사례 중에 하나였기 때문이었습니다.
iCal과 연동하는 기능은 분명히 작은 기능이었지만, 37Signals를 Mac과 관련된 여러 사이트들에서 유명하게 만들어 주었습니다. 그 사이들은 아마 iCal연동기능이 아니었다면 서비스자체에 대해서 전혀 언급하지 않았을 것입니다.
작은 팀은 새아이디어를 소프트웨어로 구현하는 데 있어 재빠릅니다. 큰 회사들이 관료적인 결정들 때문에 병목현상으로 빨리 움직이지 못할 때, 재빨리 새로운 아이디어를 구현해서 사용자들의 관심을 얻도록 하십시오.
최신의 인기있는 기술을 사용하면 비용을 적게 들이면서도 효과적으로 서비스에 대한 소문들을 이끌어 낼수 있습니다.
로그 추적
로그를 분석해서 동향을 파악하세요. 누가 서비스에 대해서 얘기하고 있는 지 알아야 합니다. 로그를 분석해서 Buzz가 어디에서 오는지 파악하세요. 누가 헐뜯고 있습니까? 테크노라티, 블로그덱스, 피드스터, 딜리셔스, 데이팝에 등록된 어떤 블로그들이 여러분에 대해서 말하고 있습니까?
그들이 누구인지 알아내세요. 그리고 여러분의 존재를 드러내세요. 그 블로그들에 댓글을 남기세요. 서비스에 대한 링크를 올려준 것에 대해서 감사하세요. 그리고 앞으로 새로운 릴리즈나 업데이트가 있을 때 가장 먼저 그 소식을 전달 받을 수 있는 특별 그룹의 일원이 되고 싶은지 물어보세요. 긍정적인 칭찬의 글들을 모아서 Buzz 페이지를 따로 하나 만드세요. 제 3자의 말이 더 믿음이 가는 법이므로 이러한 페이지는 서비스를 홍보하는데 큰 도움이 될 것입니다.
부정적인 댓글에 대해서도 관심을 가시세요. 귀기울여 듣고 있다는 것을 보여주어야 합니다. 비판에 대해 사려깊게 대응해야 합니다. "사실 저희가 그와 같은 방식으로 개발한 이유는 ...", "좋은 지적입니다. 그 부분에 대해서 작업을 시작했습니다." 와 같이 대응하세요. 이렇게 하면 비판의 강도를 낮출 수 있으며 서비스에 인간적인 정감을 실을 수 있게 됩니다. 블로그에 올린 사려깊은 댓글 하나가 불평들을 누그러뜨리고 나아가서 불만을 가진 사람들을 전도사로 바꿀 수 도 있습니다.
요금제 업그레이드
서비스의 요금제의 업그레이드를 권유하세요. 누구라도 마케팅 사이트를 만들 수 있습니다. 하지만 그것이 끝이 아닙니다. 만약 여러단계의 요금제가 있다면 높은 요금제로의 전환을 유도하세요.
요금제를 업그레이드하면 여러가지 제약사항들이 사라진다고 말하세요. 예를들어 Basecamp에서는 무료계정으로는 파일 업로드가 안됩니다. 하지만 누군가 업로드를 하려고 하면 단순히 에러 페이지나 메시지를 보이는 대신에 왜 파일 업로드가 안되고 있으며 유료버전으로 전환하면 어떤 다른 좋은 점들이 있는 지를 설명하면서 요금제 전환 을 권유합니다. 비슷한 방식으로 사용자들이 현재의 요금제의 범위를 벗어날 때 업그레이드를 권유하세요.
기존 고객은 매출 확대를 위한 최고의 대상입니다. 여러분의 서비스에 이미 잘알고 있고 실제로 사용하고 있는 그들에게 지속적으로 홍보를 하는 것을 꺼릴 필요가 없습니다.
이름
기억하기 쉬운 이름을 정하세요 많은 사람들이 저지르는 큰 실수 중의 하나는 서비스의 이름이 그 서비스를 엄청 잘 설명하는 것이어야 한다고 믿는 것입니다. 서비스의 목적을 생생하게 잘 전달하는 이름을 정하기 위해서 뻘뻘 땀흘릴 필요까지는 없습니다. 사실 그런 이름들은 너무나 일반적이어서 오히려 잊기 쉽습니다. Basecamp는 'Project Management Center', 'ProjectExpress' 같은 이름보다 훨씬 나은 이름입니다. 'WriteBoard'도 'CollabEdit'보다 낫습니다.
그리고 이름을 짓기 위해서 그룹이나 위원회를 만들지 마십시오. 그냥 짧고 기억하기 쉬우며 느낌이 오는 이름을 하나 정해서 사용하세요.
그리고 원하는 도메인이름을 얻으려고 그렇게 노력할 필요도 없습니다. 조금만 창의력을 발휘하면 한 두 글자를 더하는 것으로 비슷한 도메인을 얻을 수 있습니다.(예: backpackit.com, campfirenow.com )
쉬워야 합니다.
기술업계는 기억하기 쉽고 스스로를 잘 표현하는 이름이 결국 득이된다는사실을 모르는 걸까요? 그것이 무엇이든 간에 쉬운 이름은 유리합니다. 왜냐하면 그런 이름은 거만한 엔지니어들이 논하는 최신 기술들과는 거리가멀다 고 스스로 생각하는 고객들을 겁줘서 멀리 쫓아내지 않으니까요. 새 기술은 더 빨리 이해될수 있고, 새로운 제품은 더 설명하거나 사용하기 쉬어지고 결국 더 많이 팔리게됩니다.
—David Pogue, 컬럼니스트, New York Times (from What's in a Product Name?)
불편을 직접 느껴보세요.
지원부서와 개발부서 사이의 벽을 허무세요. 음식점에서는 흔히 주방에서 일하는 것과 홀에서 일하는 것에는 많은 차이점들이 존재하기 때문에 양측에서 서로를 잘 이해하는 일이 매우 중요하다. 그래서 요리학교나 식당들에서는 가끔 요리사가 직접 손님의 주문을 받고 서빙하도록 하여 주방에서 일하는 사람이 홀에서 일하는 사람들이 느끼는 것을 알 수 있게 한다.
많은 소프트웨어 개발자들도 유사한 단절을 격고 있다. 디자이너와 프로그래머는 주방에서 일하고 있으며, 지원부서는 홀에서 고객의 요청을 처리한다. 불행하게도 이것은 소프트웨어 개발자가 결코 사용자들의 목소리를 직접 듣지 못한다는 것을 의미한다. 이것은 꽤 심각한 문제인데 왜냐하면 사용자들의 목소리에 귀기울이는 것이 서비스의 장단점을 파악하고 개선하는 데 있어 가장 유용한 방법이기 때문이다.
해결방법은? 사용자와 개발자 또는 디자이너 팀사이에 장벽이 생기지 않도록 하는 것이다. 고객지원부서를 외부의 콜센터등에 아웃소싱하지마세요. 고객 지원을 직접하세요. 개발에 참여한 인원 모두가 고객이 말하는 것을 알아야 합니다. 고객이 짜증이 났다면 그것을 금방 알아야 합니다. 그들의 불만을 들어야 하며 여러분도 똑같이 짜증을 느껴야 합니다.
37Signals에서는 모두가 지원을 요청하는 메일을 직접 처리하고 있습니다. 이렇게 하는 첫번째 이유는 그렇게 함으로써 고객 지원을 더 잘할 수 있기 때문입니다. 고객들은 실제로 그 기능을 개발한 사람들로부터 응답을 받게됩니다. 또 이런 지원 체계는 개발자들이 서비스를 사용하는 사람들과 항상 연결되어 있도록 해줍니다. 사용자들이 뭔가 어려움을 느낀다면 개발자들도 역시 어려움을 느낄 것입니다. 개발자들은 진심으로 "여러분의 불편을 이해합니다"라고 말하게 됩니다.
통계적 분석에 의존해서 문제가 되는 지점을 찾고 싶을 때가 많을 겁니다. 하지만 통계는 사용자들의 목소리와는 다른 경우가 많습니다. 고객의 목소리와 여러분 사이에 있는 단계들을 최대한 제거하십시오.
사용자가 있는 바로 그 곳에서 모든 일이 일어납니다. 그곳으로 가세요. 요리사들이 웨이터의 역할을 하도록 하십시오. 사용자의 이메일을 읽고 그들의 불편과 실패 사례를 듣고 그들의 제안을 직접 확인하십시오. 그리고 그들로부터 배우십시오.
중계역할을 하는 사람은 필요없습니다.
37Signals 에서 대부분의 Campaign Monitor 개발과 지원 그리고 마케팅은 단 두 명으로 이루어집니다. 앞으로 팀을 크게 키워야 하더라도 지원팀을 개발팀과 분리하지 않을 것입니다. 직접 모든 요청에 응대하면서 각각이 고객의 입장이 되어 고객의 관점에서 바라볼 수 있게 됩니다.
사용자가 필요로하는 것이 무엇인지를 단순히 아는 것보다 그것이 왜 필요한 지 아는 것이 더 중요합니다. 그 배경을 아는 것이 어떤 것을 디자인할 때 큰 영향을 미칠 수 있습니다. 중계 역할 자는 없애도록 하십시오. 여러분이 직접 들을 수록 고객이 원하는 바로 그것을 줄 수 있을 확률이 높습니다.
이런 얘기를 하면 많은 사람들이 처음에 "지원을 위해서는 경력이 좀 적은 사람들을 고용해야 하지 않나요?"라는 반응을 보입니다. 고객의 입장에 직접 서보세요. 만약 여러분의 스테이크가 여러분이 원하는 대로 요리되기 원한다면 그 얘기를 버스 기사에게 하시겠습니까? 아니면 요리사에게 하시겠습니까?
—David Greiner, 창립자, Campaign Monitor 불필요한 매뉴얼
별도로 매뉴얼이나 교육이 필요없도록 문맥내에서 도움말과 FAQ를 제공하세요. 야후나 구글 아마존을 사용하기 위해서 매뉴얼은 필요없습니다. 매뉴얼이 필요없도록 개발할 수 없을까요? 사용법을 교육하지 않아도 되는 어플리케이션을 만들기 위해서 노력하십시오.
이것을 어떻게 할 수 있을 까요? 앞에서도 언급했지만 모든 것을 단순하게 유지하세요. 어플리케이션이 복잡하지 않을 수록 고객들의 실수를 도와야할 필요성이 줄어듭니다. 또한 추가 지원을 없앨 수 있는 최고의 방법은 문맥에 따라 나타나는 인라인 도움말과 혼란이 있을 수 있는 지점에서 FAQ를 제공하는 것입니다.
예를들어, 우리는 사용자가 자신의 로고를 업로드하는 화면에서 미리 지원 메시지를 제공합니다. 어떤 사람들은 브라우저의 캐쉬때문에 기존의 로고가 업데이트 되지 않는 문제를 겪을 수 있습니다. 그래서 "로고 제출"이라는 버튼 옆에 FAQ로의 링크를 제공하여 사용자들이 브라우저의 캐쉬기능을 끄도록 유도합니다. 사실 이 링크를 제공하기 전에 우리는 하루에만 5개이상의 질문 메시지를 받았지만, 지금은 전혀 받지 않고 있습니다.
빠른 응답
지원 요청에서는 빠른 응답 시간이 매우 중요합니다. 사용자들은 자신들의 질문에 빠른 답변을 받으면 기뻐합니다. 그들은 답변을 받는데 여러날 이상이 걸리는 경우를 많이 보아 왔기 때문에 만약 여러분이 빠른 응답을 제공한다면 경쟁자들과 차별성을 쉽게 만들 수 있습니다. 업무시간내에 우리는 90%의 이메일 요청을 90분 내에 처리합니다. 30분내에 처리하는 경우도 많습니다. 당연히 사람들은 굉장히 좋아합니다.
비록 완벽한 답을 당장 모르는 경우라도 무엇이든 답변을 하십시오. 그러한 답변을 통해서 개방적이고 정직한 방식으로 호의를 살 수 있게 됩니다. 만약 누군가 즉시 고치기 힘든 문제에 대해서 불평한다면 "지적하신 내용에 대해서 잘 알겠습니다. 앞으로 이 부분에 대해서 보완을 하겠습니다." 와 같이 답변하세요. 이것은 혹시 있을 지도 모를 불행한 상황을 방지해 줄것입니다.
사용자들은 솔직한 것을 좋아해서 정직하고 빠른 답변을 받으면 화가 났다가도 누그러져서 예의바른 태도를 갖출 것입니다.
대중의 힘
어떻게 3명의 개발자만으로 구성된 작은 팀이 혁신적인 서비스를 만들며 큰 회사들과 성공적으로 경쟁할 수 있을까요? 정답은 대중의 힘을 빌리는 것입니다.
서비스를 처음 시작할 때, 고객이 가장 중요한 자산이었던 때를 기억하세요. 그리고 그들이 서비스의 장기적인 성공을 위한 가장 중요한 부분으로 여기던 때를 기억하세요. 거대 기업과 싸우는 방법은 작게 시작하고 고객 한사람 한사람에게 관심을 기울이는 것입니다.
버그를 발견해서 알려주는 것은 바로 고객이며, 부족한 부분을 일깨워주는 것도 고객입니다. 서비스를 널리 알려주는 것도 바로 고객입니다.
그렇다고 해서 서비스를 시작할 때 모든 것이 완벽해야한다는 뜻은 아닙니다. 오히려 반대로 더 빨리 더 자주 릴리즈하십시오. 그러나 사용자가 버그를 알려오는 경우에는 재빨리 그들의 피드백에 대해서 감사를 표하는 것을 잊지 마세요.
사용자들은 서비스가 완전하기를 기대하지도 않으며, 모든 기능들이 한 번에 다 구현되어 있기를 기대하지도 않습니다. 하지만 사용자들은 여러분이 사용자의 말에 귀기울이고 사용자의 관심에 감사해 주기를 기대합니다. 그러므로 여러분이 사용자에게 관심을 가지고 있음을 보여주세요. 이 부분은 거대 회사들의 상당히 취약한 부분이므로 여러분 은 대중에게 빠르게 어필할 수 있을 것 입니다.
Blinklist에서는 모든 사용자들의 이메일에 응답을 일일이 합니다. 우리가 잠들어 있지 않는 한 한 시간내에 답변을 합니다. 우리는 또 온라인 포럼을 운영하고 있는데 모든 게시글에 대해서 댓글을 달고 있습니다.
또한 우리의 모든 개발자는 고객의 피드백을 직접 받으며, 그들은 온라인 토론 포럼에서 활발하게 활동합니다. 이런 식으로 우리는 천천히 그렇지만 확실하게 적극적이고 충성도가 높은 Blinklist 의 커뮤니티를 만들고 있습니다.
—Michael Reining, 공동 창업자, MindValley & Blinklist 거친 사랑
사용자에게 기꺼이 'No'라고 말할 수 있어야 합니다. 추가 기능에 대해서는 고객이 항상 옳은 것은 아닙니다. 만약 우리가 고객이 요구하는 모든 것을 추가했더라면 아무도 우리 서비스를 사용하지 않을 것입니다.
만약 우리가 사용자들의 모든 변경에 그대로 따랐다면 Basecamp는 아마도 완전한 시간 관리 기능과 완전한 과금 기능과 완전한 회의 스케쥴 기능, 완전한 달력 기능, 완전한 업무간 의존성 관리 기능, 완전한 메신저 기능, 완전한 위키 기능, 그리고 완전한 그 모든 기능들을 가져야 했을 것입니다.
하지만 사용자들을 대상으로한 조사에서 우리가 확인한 일순위 요구사항은 Basecamp를 심플하게 유지하는 것입니다.
다른 예를 하나 들어보겠습니다. 어느 정도의 불만들에도 불구하고 우리는 ie5를 지원하지 않기로 결정했습니다. 그 결정으로는 우리는 약 7%에 해당하는 마켓을 잃었습니다. 하지만 우리는 다른 93%에 대해서 집중하는 것이 더 중요하다고 결정했습니다. ie5를 위한 버그를 수정하고 테스트를 하는 것은 거기에 필요한 시간만큼의 가치가 없습 니다. 우리는 차라리 다른 모든 사람들을 위한 더 좋은 제품을 만들기로 했습니다.
소프트웨어 개발 회사로서 우리는 모두 마치 필터처럼 행동해야 합니다. 모든 사람들이 요구하는 모든 기능이 언제나 옳은 것은 아닙니다. 우리는 모든 요청들을 검토하지만 사용자들이 항상 옳은 것은 아닙니다. 어떤 사용자들의 요청은 무시해야 하는 경우가 있습니다. 그게 인생입니다.
개발 회사로서 여러분은 여러분의 제품과 서비스를 사랑해야만 합니다. 만약 여러분의 서비스가 여러분이 동의하지 못하는 기능들을 가득 가지고 있다면 어떻게 사랑할 수 있겠습니까. 이것은 여러분이 옳다고 생각하지 않는 고객의 요구를 거슬러야 하는 또 하나의 이유입니다.
휼륭한 포럼
포럼이나 채팅을 사용해서 사용자들이 서로를 도울 수 있도록 하세요. 포럼과 웹기반 그룹 채팅은 사용자들이 서로 질문하고 서로를 도울 수 있는 휼륭한 방법입니다. 중계자를 없앰으로써 여러분은 개방된 대화의 장을 제공할 수 있으며 동시에 여러분의 시간을 절약할 수도 있습니다.
우리가 제공하는 포럼의 경우, 사용자들은 여러가지 사용법과 사용팁, 기능 요청 등 여러가지 내용을 올립니다. 우리들도 가끔 포럼의 이 곳 저 곳에서 지원을 하기는 하지만 포럼은 주로 사용자 커뮤니티가 직접 서로 돕고 경험을 공유하는 공간입니다
사람들이 서로를 도우고 싶어하는 정도는 놀라울 정도로 큰 편입니다.
잘못한 것들을 공개하세요.
나쁜 소식은 빨리 알리세요. Get bad news out there and out of the way 만약 뭔가 잘못되었다면 사용자들에게 말하십시오. 비록 그들이 아직 알지 못하는 상태라고 하더라도 말하십시오.
예를들어, Basecamp가 밤에 몇시간동안 다운 되었던 적이 있었습니다. 99%의 사용자들은 알지 못했을 것입니다. 하지만 우리는 이 예상지 못했던 다운에 대한 공지를 'Everyghing Basecamp' 블로그에 올렸습니다. 우리는 사용자들이 알 권리가 있다고 생각했습니다.
뭔가 잘못되었을 때 우리가 작성하는 글을 다음과 같습니다. "오늘 아침에 있었던 시스템 다운에 대해서 사과드립니다. 우리의 데이터베이스에 뭔가 문제가 있었고 일부 사용자들이 서비스를 제공하지 받지 못하거나 심각한 속도 저하를 겪으셨습니다. 우리는 즉시 이 문제를 수정했고 앞으로 같은 문제가 재발하지 않도록 조치를 밟고 있습니다 . 이 문제에 대해서 다시 한 번 사과드리면, 불편함을 참아주신 것에 대해 감사드립니다. "
최대한 개방적이고 정직하고 투명하게 하십시오. 뭔가 내부에 비밀을 숨기지 마세요. 정확한 정보를 알게된 고객은 최고의 고객이 됩니다. 또한 대부분의 실수들은 우리가 생각하는 만큼 고객에게는 심각하게 느껴지지 않는 다는 것을 알 수 있을 것입니다. 사용자들은 우리가 그들에게 솔직하다는 것을 안다면 우리에게 약간의 여유와 용서를 해줄 수 있다는 것에 대해 행복해 할 것입니다.
좋거나 나쁜 뉴스를 전달하는 것에 대한 추가 사항. 나쁜 소식의 경우에는 즉시 공개하세요. 반대로 좋은 소식은 천천히 내용을 조금씩 공개하세요. 만약 좋은 분위기를 계속 연장할 수 있다면 최대한 그렇게 하세요.
빠르고 정직하고 솔직해지세요.
이상하게 들릴 지 모르지만, 이것이 나쁜 소식을 전할 때의 가장 좋은 방식입니다. 이것은 여러분의 회사가 약해지고 방어적인 위치에 몰리는 것을 미연에 방지해줍니다.
—Greg Sherwin, 응용기술 부사장 , CNET, and Emily Avila, Principal, Calypso Communications (from A Primer for Crisis PR)
한 달 튠업
서비스 개시 한 달 후에 주요 업데이트를 하세요. 빠른 업데이트는 좋은 분위기를 계속 유지할 수 있게 해줍니다. 여러분이 고객의 의견을 듣고 있다는 것을 보여줍니다. 고객들이 앞으로도 계속 새로운 것들이 제공될 것이라고 느끼게 해줍니다. 처음의 좋은 느낌을 다시 경험하게 해줍니다. 그리고 여러분이 블로그 등을 통해 다른 사람들에게 얘기하고 홍보할 수 있는 꺼리를 제공해 줍니다.
빠른 후속 업그레이든가 있을 것이라는 것을 알기 때문에 여러 분은 서비스 개시 이전에는 정말 중요한 부분들에 더 집중할 수 있습니다. 몇 가지 기능들을 추가로 더 짜내는 대신에 핵심 기능들을 더 완전하게하고 서비스를 개시할 수 있습니다. 일단 서비스를 세상에 내 놓은 후에 사용자들의 피드백을 받게되면, 여러분이 추가로 집중해야 할 부분이 어디인지 알 수 있게 됩니다.
이러한 아기걸음마 방식은 Backpack에서 꽤 유효했습니다. 우리는 기본 기능들을 먼저 제공했고 몇 주 후에 사용자들이 가장 필요하다고 요구한 이동형 장치를 위한 Backpack Mobile 이나 태깅과 같은 기능들을 추가했습니다.
계속 글을 올리세요.
서비스 개시 후에 지속적인 블로깅을 통해 서비스 개발이 진행 중임을 보여주세요. 서비스 개시 후에 블로깅을 계속하십시오. 여러분의 서비스가 활발하게 살아 움직이고 있다는 것을 전용 블로그를 계속 업데이트 함으로써 보여주십시오.(최소한 일주일에 한 번 가능하다면 그 이상이 좋습니다.)
포함할 내용들:
FAQ 여러가지 사용 법 Tip과 Trick 새로운 기능, 업데이트, 수정 사항 홍보/언론보도 블로그는 여러분의 어플리케이션이 살아있음을 보여주며 또한 여러분의 회사를 더 인간적으로 보이게 해줍니다. 블로그의 어조를 친근하고 인간적으로 유지하세요. 작은 팀은 가끔 그들이 더 크며 매우 전문적으로 보여지기를 원합니다. 하지만 이것은 나폴레옹 컴플렉스의 기업 버전이라고 할 수 있습니다. 작게 느껴지는 것을 싫어하지 마 세요. 고객에게 친구처럼 말할 수 있다는 것에 집중하십시오.
살아있는 서비스
자주 업데이트 되는 서비스 전용 블로그는 웹 어플리케이션이 활발하게 개발되고 있으며, 사랑받고 있고 활발하게 돌아가고 있다는 것을 보여줍니다. 더 이상 관리되지 않는 제품의 블로그는 그 서비스 역시 더 이상 관리되지 않고 있으며 관리자들이 전혀 관심이 없다는 것을 말해줍니다.
제품의 블로그에서 사용자들과 지속적인 대화를 유지하십시오. 그리고 솔직하고 넓은 마음으로 정보를 공유하십시오. 여러분 회사의 철학이 블로그를 통해서 빛날 수 있도록 하십시오. 경쟁자들에 대해서도 개방적으로 토론하고 링크를 거세요. 예정된 기능들을 알려주고 코멘트를 통해 피드백을 얻으세요.
살아있는 서비스는 사용자들에게 말하고 사용자들의 말을 경청합니다. 자주 업데이트 되는 블로그는 투명성을 높여주며, 브랜드에 대한 충성도와 커뮤니티 소속감을 높여줍니다. 또한 공짜로 널리 알려질 기회를 제공합니다.
Lifehacker의 편집자로서, 나는 웹어플리케이션들의 홍보용 블로그를 검색합니다. 나는 구글이나 플리커, 야후, 딜리셔스, 37signals의 블로그들을 계속 좋아해왔습니다. 나는 언론에 좋은 쪽만을 강조한 기사들을 내보내면서 블로그등을 통해 고객들과 공개된 대화는 하지 않는 웹 서비스들은 거의 다루지 않게 됩니다.
—Gina Trapani, 웹 개발자 및 편집자, Lifehacker, 생상성과 소프트웨어 가이드 Better, Not Beta
'베타'를 희생양으로 사용하지 마세요. 요즘에는 모든 것들이 영원히 베타로 계속 되는 것 같습니다. 이것은 책임 회피입니다. 끝날 줄 모르는 베타 상태는 사용자에게 여러분이 끝내 완성된 서비스를 제공하지 않을 것이라고 말하는 것과 같습니다. 마치 "이 서비스를 사용해주세요. 하지만 이것은 완전하지 않으며, 그것이 우리의 잘못은 아닙니다"라고 말하는 것 같습니다.
만약 여러분 스스로 서비스에 대해 확신하지 못한다면, 어떻게 고객이 만족할 수 있겠습니까? 비공개 베타라면 괜챦지만 공개 베타라면 문제가 있습니다. 고객이 사용하기에 충분히 좋지 못하다면 고객에게 제공해서는 안됩니다.
서비스가 완전해질 때까지 기다리지는 마십시오. 절대 일어날 수 없는 일이니까요. 하지만 여러분이 릴리스하는 서비스에 대해서 책임지십시오.
베타는 무의미합니다.
이 문제에 대해서는 구글이 책임이 있습니다. 그 개발자들 때문에 사용자들은 이제 "베타"가 실제로 아무것도 의미하지 않는다고 여기게 되었습니다.
—Mary Hodder, 정보 아키텍트 및 인터렉션 디자이너 (베타의 정의) 언제나
언제나 베타인 것은 나 뿐인가요? 아니면 모두 다 그런가요?
—Jim Coudal, 창립자, Coudal Partners 버그들은 동등하지 않습니다.
버그들의 우선순위를 정하세요. (어떤 것들은 무시하세요.) 서비스에서 버그를 발견했다고 해서 항상 당황할 필요는 없습니다. 모든 소프트웨어는 버그를 가지고 있으며 그것은 우리 인생의 진리입니다.
모든 버그를 즉시 고칠 필요는 없으며 그렇게 할 수도 없습니다. 대부분의 버그들이 성가시긴 하지만 모두가 파괴적이지는 않습니다. "이렇게 하는 것은 뭔가 이상한것 같은데"라는 식의 오류들이나 다른 사소한 잘못들은 잠시 옆으로 제쳐두어도 괜챦습니다. 하지만 만약 버그가 데이터베이스에 문제를 일으킨다면 즉시 수정해야 합니다.
버그들을 우선순위화하십시오. 얼마나 많은 사용자들이 영향을 받는 문제입니까? 문제의 심각성이 어느 정도입니까? 즉시 수정해야 할 문제인가요? 아니면 잠시 내버려둬도 괜챦은 것인가요? 가장 많은 사람들이 혜택을 받을 수 있도록 하려면 즉시 해야할 것이 무엇인가요? 종종 새로운 기능을 새로 추가하는 것이 버그하나를 수정하는 것보다 더 중요한 일이 될 수도 있습니다.
그리고 버그에 대해서 겁먹는 문화를 만들지 마세요. 버그는 생기기 마련입니다. 계속해서 누군가를 비난하려고 하지 마십시오. 가장 일어나서는 안되는 일은 버그들이 공개적으로 논의되지 못하고, 서로에게 숨겨진 상태에서 마구잡이로 처리되는 상황입니다.
그리고 우리가 앞에서 솔직함의 중요성에 대해서 얘기한 것을 잊지마십시오. 고객이 버그에 대해서 이야기하면 그들에게 솔직해지십시오. 여러분이 그 문제에 대해서 인지했으면 그것을 처리할 것이라고 말하십시오. 만약 즉시 고쳐질 것이 나리면 왜 그런 지 설명하고 지금 여러분이 더 집중하고 있는 부분이 무엇인지를 알려주십시오. 정직은 최선의 정책입니다.
Ride Out the Storm
변화에 대한 자동 반사의 반응들이 가라 않을 때까지 기다리세요. 배를 흔들면 파도가 생기듯이, 새로운 기능을 추가하거나 정책을 바꾸거나 어떤 기능을 없애고 나면, 자동적인 반응들이, 물론 가끔은 부정적인 것들이, 쏟아집니다.
이런 반응들에 당황해서 급하게 또 다른 변경을 하자 마세요. 열정은 처음에는 불타오르게 마련입니다. 하지만 처음 하루나 이틀의 시간이 지나면 점차 안정될 것입니다. 대부분의 사람들은 여러분이 추가하거나 변경한 것을 실제로 충분히 경험하기도 전에 반응합니다. 그러니 느긋한 마음을 가지고 기다리세요. 어느 정도의 시간이 흐를 때까지는 대응하지 마십시오. 그러면 좀 더 나은 대응을 할 수 있게 됩니다.
그리고 부정적인 목소리가 긍정적인 목소로보다 더 크고 열정적이라는 것을 기억하세요. 사실 대부분의 고객들이 만족하고 있는 상황에서도 여러분은 부정적인 소리를 들을 수 도 있습니다. 필요할 지도 모르지만 확실하지 않은 결정을 내려서 변화를 철회하거나 되돌리는 일이 없도록 하십시오.
Keep Up With Joneses(이웃에 지지 않기)
경쟁자들의 RSS 를 구독하세요. 여러분의 제품뿐 아니라 경재자들의 제품에 대한 뉴스를 읽으세요. 적에 대해서 파악하는 것은 언제나 현명한 행동입니다. PubSub, Technorati, Feedster같은 서비스들을 통해서 최신동향을 파악하세요.(회사 이름이나 제품이름으로 검색하세요.) RSS는 여러분이 항상 뒤쳐지지 않도록 계속해서 새로운 정보를 전달해 줍니다.
비대증 괴물을 조심하세요.
더 완전해지는 것이 반드시 더 복잡해지는 것을 의미하지는 않습니다. 점차 일들이 진행되어 나갈 때, 기능 부풀림에 주의해야 합니다. 그 유혹은 점점 커질 것이지만 그렇게 되어서는 안됩니다. 어떤 것이 오래되고 점점 완전해진다는 것이 꼭 더 복잡해지는 것을 의미하지는 않습니다.
마치 외계에서 온 듯한 최신형 펜이 꼭 필요한 것은 아닙니다.그냥 연필만으로 충분할 수 있습니다. 스위스 만능 칼이 아니라, 그냥 스크류드라이버로 충분할 수도 있습니다. 수중 5000미터에서 방수가 되는 잠수용 시계가 아니더라도, 여러분의 고객이 주로 땅에 있는 사람들이라면 단지 시간만 정확히 알려줄 수 시계라면 충분합니다.
확장을 위한 확장을 해서는 안됩니다. 그것이 바로 어플케이션이 비대해지는 방식입니다.
새로운 것이 항상 개선을 의미하지는 않습니다. 어떤 때는 여러분의 제품을 그냥 있는 그대로 유지해야하는 경우가 있습니다.
이 점이 바로 웹기반 소프트웨어 개발이 전통적인 데스크탑 기반 어플리케이션보다 더 좋은 장점 중에 하나입니다. Adobe, Intuit, Microsoft 와 같은 데스크탑 소프트웨어 개발 회사는 매년 새로운 버전을 여러분에게 판매해야 합니다. 그런데 매년 똑같은 버전을 판매할 수는 없는 노릇이므로 그들은 매번 새로운 기능들을 추가함으로써 추가 비용지불에 대한 근거를 만들어내고 있는 것입니다. 그래서 비대증이 생기고 있습니다.
정기적으로 사용료를 받는 모델을 사용하는 웹 소프트웨어의 경우에는 고객이 매달 서비스를 이용하는 댓가로 돈을 지불합니다. 여러분은 고객에게 계속해서 무언가를 판매할 필요가 없으며, 현재의 서비스를 계속해서 제공하면 됩니다.
흐름을 유지하세요.
방향 변화에 개방적인 자세를 가지세요. 웹 어플리케이션의 장점 중 하나는 유동성입니다. 웹어플리케이션은 박스에 포장되어 판매되거나 다음 버전이 나오려면 1년이상 걸리는 방식이 아니며, 지속적으로 내용이 고쳐지고 개선될 수 있습니다. 여러분의 처음 생각이 틀렸거나 최선의 아이디어가 아닐 수 있다는 마음가짐이 필요합니다.
플리커의 경우 처음에는 'The Game Neverending'라는 온라인 멀티플레이어 게임으로 시작했습니다. 하지만 개발자들은 그 게임에서 사진을 공유하는 기능이 게임 그 자체보다 훨씬 더 각광받고 있다는 것을 인식했으며, 자신들의 실수를 인정하고 방향을 바꾸었습니다.
여러분은 바다위의 서퍼와 같습니다. 커다란 파도가 어디에서 생기고 부서지는 지를 재빨리 알아내십시오.
이제 시동을 거세요.
끝! 좋습니다. 끝까지 읽으셨군요. 이제 여러분은 'Getting Real'을 여러분의 어플리케이션에 적용하고 싶어졌을 것으로 믿습니다. 최소한의 자원만으로 휼륭한 소프트웨어를 만들 수 있는 가장 좋은 때가 왔습니다. 좋은 아이디어, 열정, 시간, 기술 그리고 무한한 가능성을 펼치십시오.
누구나 책을 읽을 수 있습니다. 누구나 좋은 아이디어를 떠올릴 수 있습니다. 누구에게나 웹디자이너 사촌 한 명쯤은 있습니다. 누구나 블로그를 개발할 수도 있습니다. 누구나 함께 코드를 보고 고심할 동료를 고용할 수 있습니다.
여러분과 '누구나'의 차이는 얼마나 잘 '실행'하는가에 있습니다. 성공은 모두 위대한 실행에서 비롯됩니다.
소프트웨어에서의 실행은 여러가지 일들을 '올바로' 하는 것을 의미합니다. 원래 표현하고자 하는 내용을 잘 전달하지 못한다면 좋은 글쓰기라고 할 수 없습니다. 코드가 여기저기 핵들로 가득하다면, 깔끔한 인터페이스를 만들 수 없습니다. 위대한 어플리케이션이라 해도, 형편없는 홍보 때문에 아무도 알지 못한다면 결국 아무 소용도 없게됩니다. 성공하려면 이 모든 것들을 모두 합해야합니다.
중요한 점은 균형입니다. 만약 어느 한 쪽으로 너무 치우친다면, 실패를 경험하게 될 것입니다. 계속해서 부족한 부분들을 찾아내고 그 것들을 개선해야합니다.
성공적인 웹어플리케이션을 만들기 위해서 가장 중요한 요소에 대해서 다시 한 번 강조하겠습니다. 바로 사람입니다. 구호나 슬로건, 핵심 디자인, 더 작은 개발 그리고 그 외의 모든 놀라운 개념들도 만약 적당한 사람들을 찾지 못한다면 무용지물입니다.
자신이 하는 일에 열정적인 사람이 필요합니다. 자신의 기술에 대해서 신경쓰는 사람. 그리고 실제로 장인의 마인드를 가진 사람이 필요합니다. 금전적 보상에 상관없이 자신의 작업에 대해서 자부심을 가지는 사람이 필요합니다. 95%의 사람들은 그 차이를 알 지도 못할 미세한 부분을 위해서 땀을 흘릴 줄 아는 사람이 필요합니다. 사람을 필요로 하는 사람이 필요합니다. 이런 사람을 발견하면 그 사람을 꼭 붙드세요. 결국 여러분의 팀에서 이런 사람들이 프로젝트와 회사의 성공을 결정할 것입니다.
'Getting Real'의 개념들이 단지 소프트웨어에만 적용되는 것이 아니라는 것을 말하고 싶습니다. 일단 이러한 개념들을 숙지하게 되면, 아마도 모든 곳에서 만나게 될 것입니다. 예를 들면,
네이비실이나 그린베레 같은 특수 작전 부대들은 '작은 팀'과 '쾌속 개발' 개념을 이용해서 임무를 달성하며, 그러한 임무들은 너무 크거나 너무 느린 조직들은 해낼 수 없는 것들입니다. 'The White Stripes'는 간단한 공식에 집중하여, 단 두 명의 멤버, 유선형의 음악, 아이같은 드럼, 스튜디오 시간의 최소유지 등의 제한된 요소들을 극복합니다. 애플의 iPod는 내장 라디오 기능이나 음성 기능 등 경쟁사가 제공하는 기능을 제공하지 않음으로써 차별화에 성공하였습니다. Hurry up offenses in football pick up big chunks of yards by eliminating the "bureaucracy" of huddles and play-calling. 레이첼 레이의 성공적인 요리책과 TV쇼는 그녀의 '30분만에 진짜 요리 해내기' 방식에 기반을 두고 있다. 어네스트 헤밍웨이과 레이몬드 카버는 간단하고 명료한 언어를 사용해지만, 최대의 느낌을 전달 했다. Shakespeare reveled in the limitations of sonnets, fourteen-line lyric poems in iambic pentameter.
분명히 'Getting Real'은 휼륭한 소프트웨어를 만드는 방법에 대한 것입니다. 하지만, 꼭 거기에 한정할 필요는 없습니다. 여기에 제시된 개념들을 여러분의 생활의 다양한 부분들에 적용해보세요. 아마도 멋진 결과를 얻을 수 있을 겁니다.
'Getting Real'이 여러분에게 정말 도움이 되었는지 알고 싶습니다. gettingreal [at] 37 signals [dot] com 으로 이메일을 보내주세요.
그리고, 37signals 의 Signal vs. Noise사이트와 'Getting Real'을 포함하여 사용성, 디자인 등의 여러가지 내용을 다루고 있는 저희의 블로그를 방문하면 최신의 내용들을 볼 수 있습니다.
읽어주셔서 감사합니다. 행운을 빕니다!
- 37signals site
- Signal vs. Noise weblog
- Basecamp — Web-based project collaboration
- Campfire — Web-based group chat for business
- Backpack — Web-based information organizer
- Writeboard — Web-based collaborative writing
- Ta-da List — Web-based dead-simple to-do lists
- Ruby on Rails — Open-source web application framework
- 번역 에 참여한 사람들: 김정현(ikspres), Peter Kim, Jungmin Seo(오타 수정)
Getting Real Overview(영어)
Buy your own copy of Getting Real
You've browsed the site and read some chapters, now get your own copy of the book in paperback or PDF.
"Every once in a while, a book comes out of left field that changes just about everything. This is one of those books. Ignore it at your peril."
—Seth Godin, Author
$29 in paperback Available from Lulu.com
$19 in PDF Instant download
Note: The text on this web site and the text in the book is identical. Buying the PDF or paperback version allow you to take the content with you and show your support for the Getting Real movement. Thanks for your business.
All content copyright ©1999-2014 37signals, LLC. All rights reserved. No part of this book or site may be reproduced or redistributed in any form or by any electronic or mechanical means, including information storage and retrieval systems, without permission in writing from 37signals, except by a reviewer who may quote brief passages in a review.
https://archive.is/Xj3BO