-
Notifications
You must be signed in to change notification settings - Fork 1
/
index.html
1526 lines (1525 loc) · 213 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xml:lang="en" xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
<title>Getting Real by 37signals</title>
<link rel="Stylesheet" href="screen.css" type="text/css" media="screen"/>
<link rel="SHORTCUT ICON" href="http://www.37signals.com/images/37.ico"/>
</head>
<body class="essay">
<div class="header">
<a href="http://www.37signals.com/" class="image"><img src="37s-mark-black.gif" alt="37signals logo" style="float: right;" height="22" width="22"/></a>
<a href="http://gettingreal.37signals.com/toc.php"></a><a href="http://gettingreal.37signals.com/index.php">Getting Real Overview</a>
</div>
<div class="fixed_side side">
<img src="logo-small-grbook.gif" style="margin: 0pt 5px 0pt 0pt;" align="left" height="51" width="39" alt="" />
<h2>購買本書</h2>
<p><a href="#footer">購買 Getting Real (英文版)</a> PDF電子版或印刷版本。<br/><br/></p>
<h2 style="margin-top: 14px;">翻譯修訂中</h2>
<p>基於簡體中文版翻譯修訂而成。持續修訂中。</p>
</div>
<div id="Container">
<div class="content">
<h1 style="margin-bottom: 20px;">Getting Real</h1>
<p class="nogap">中文版最後修訂： 2012年2月27日， <a href="https://plus.google.com/u/0/117007853526866642045">VampireNeo</a></p><br />
<a name="chapters"></a>
<ul class="chapters">
<li><span>第一章</span> <a href="#ch01">引言</a></li>
<li><span>第二章</span> <a href="#ch02">起跑線</a></li>
<li><span>第三章</span> <a href="#ch03">保持精益</a></li>
<li><span>第四章</span> <a href="#ch04">首要任務</a></li>
<li><span>第五章</span> <a href="#ch05">挑選功能</a></li>
<li><span>第六章</span> <a href="#ch06">操作</a></li>
<li><span>第七章</span> <a href="#ch07">組織</a></li>
<li><span>第八章</span> <a href="#ch08">人員配備</a></li>
<li><span>第九章</span> <a href="#ch09">界面設計</a></li>
<li><span>第十章</span> <a href="#ch10">代碼</a></li>
<li><span>第十一章</span> <a href="#ch11">文字</a></li>
<li><span>第十二章</span> <a href="#ch12">定價和註冊</a></li>
<li><span>第十三章</span> <a href="#ch13">推廣</a></li>
<li><span>第十四章</span> <a href="#ch14">技術支援</a></li>
<li><span>第十五章</span> <a href="#ch15">上線之後</a></li>
<li><span>第十六章</span> <a href="#ch16">總結</a></li>
</ul>
<br/><hr/>
<h2 class="chapter_title"><a name="ch01"></a>引言 <span>第一章</span></h2>
<h1>什麼是 Getting Real?</h1>
<p>想構建一個成功的Web應用麼? 那麼正是時候Getting Real. Getting Real 是一種更小規模，更快速，更高質量的軟件構建方法。</p>
<ul>
<li>Getting Real是關於省略所有表達現實（圖表，曲線，矩形，箭頭，統計圖），而構建現實。</li>
<li>Getting real 是追求精煉。更少的代碼量，更少的軟件，更少的功能，更少的文檔工作，更少無所謂的東西（而且大部分你認為必要的，其實不是）。</li>
<li>Getting Real 是保持精益，變得敏捷。</li>
<li>Getting Real從界面開始，也就是用戶使用的屏幕。它從實際的用戶體驗開始，並且構建似曾相識的體驗。這讓你在軟件誤入歧途之前得到正確的用戶界面。</li>
<li>Getting Real 是關於迭代和降低變化成本的方法。Getting Real聚焦於上線、調整、持續改進，使得其成為開發Web軟件的最佳途徑。</li>
<li>Getting Real只交付客戶所需的，摒棄任何客戶不需要的。</li>
</ul>
<h2>Getting Real的優點</h2>
<p class="nogap">Getting Real能夠交付更好的結果，是因為它強迫你處理真正要解決的問題，而不是關於那些問題的空想。它迫使你面對當下。</p>
<p>Getting Real更注重實際的用戶界面，而不是功能規格說明書和其他曇花一現的文檔。只有當一個真實的網頁呈現出來，相關的功能規格才是可信的，被證明是可接受的。那才是是我們的客戶將要看到和使用的。那才是需要關心的。Getting Real幫助你更快達到這個目的。並且那意味著你正在基於真實需求，而不是異想天開來構建軟件。 </p>
<p>最後，Getting Real是適合於Web軟件的理想途徑。那種把軟件包裝在盒子裡，再等一年到兩年才發佈一個更新的學院派方法已經過時了。不像需要安裝的軟件，Web應用能夠以天為單位持續改進。Getting Real利用了這種優勢來提升Web應用的價值。</p>
<div class="quote">
<h3>如何編寫健壯的軟件 How To Write Vigorous Software</h3>
<p>健壯的著作是簡明的。句子無廢詞，段落無廢句子。同樣的原因，畫應無多餘的線條，機器應無多餘的零件。這不是要作者刻意縮句來逃避細節，從而提綱挈領，而是要作者字字珠璣。</p>
<cite>—來自 <a href="http://www.bartleby.com/141/strunk5.html">"The Elements of Style"</a> by William Strunk Jr.</cite>
</div>
<br/>
<br/>
<h2>不再發胖</h2>
<p class="nogap">舊方式：冗長，官僚主義的，「我們正在這麼做來控制這些蠢驢」 的流程。典型後果是：臃腫，過目即忘，平庸得掉渣的軟件。Blech。</p>
<h2>Getting Real 除掉...</h2>
<ul>
<li>花費數月，甚至數年的進度表</li>
<li>不切實際的功能規格文檔</li>
<li>可伸縮性的爭論</li>
<li>又臭又長的員工大會 </li>
<li>大量招人的需求</li>
<li>毫無意義的版本號</li>
<li>憧憬完美未來的幼稚「路線圖」 </li>
<li>無窮盡的偏好設置選項</li>
<li>外包支持</li>
<li>不切實際的用戶測試 </li>
<li>寫無用文檔</li>
<li>自頂向下的管理結構</li>
</ul>
<p>你不需要成噸的鈔票或者龐大的團隊或者漫長的開發週期來構建偉大的軟件。那些正是緩慢，晦澀，變化成本高昂的應用程序的幫兇。Getting real反其道而行之。</p>
<h2>這本書將帶給你...</h2>
<ul>
<li>信仰之重要</li>
<li>為什麼小是好事情</li>
<li>怎樣構建更少</li>
<li>怎樣從現實世界中快速找到創意</li>
<li>怎樣培養團隊</li>
<li>為何要由內到外的設計</li>
<li>為什麼寫作至關重要 </li>
<li>為什麼要比對手少做</li>
<li>如何升級你的應用和散播文字</li>
<li>成功維護的秘訣</li>
<li>發佈後能夠持續保持後勁的秘訣。</li>
<li>其他... </li>
</ul>
<p>本書關注於理論高度。我們不會使你陷入代碼片段細節，或者是CSS竅門。我們會堅守在驅動Getting Real過程的主要思想和價值觀上。</p>
<h2>本書適合你麼？</h2>
<p class="nogap">你是管理者，設計師，程序員，或者市場人員。</p>
<p>你意識到舊規則不再管用了。每年通過光碟分發你的軟件？2002這個版本號怎麼樣？</p>
<p>或者你對敏捷開發和企業組織結構略懂皮毛，但是熱切的想多瞭解一些。 </p>
<p><strong>如果聽起來你是其中之一，那麼這本書就是為你準備的。</strong></p>
<p>注意：雖然這本書著重在構建Web應用上，很多理念也可以應用到非軟件活動。關於小型團隊，快速原型，期望迭代，和許多提到的其他經驗能夠為你引路。無論你正在開始一項業務，寫一本書，設計一個網站,記錄簽名冊，還是其他各種各樣的活動。一旦你在你生活中的某一領域開始Getting Real，你就或發現這些概念能適用的非常廣泛。</p>
<br/><hr/>
<h1>關於 37signals</h1>
<h2>我們做什麼</h2>
<p>37signals是一個創造簡單的，專一的軟件的小團隊。我們的產品幫助你協同工作，組織團隊。超過35000個人和企業使用我們的Web應用來搞定他們的業務。來自華爾街雜誌的Jeremy Wagstaff寫到 「37signals 的產品是超簡單，精緻，直接了當的工具，這些工具讓微軟的Outlook軟件使用起來像受刑 。」我們的軟件不會把你推到這種境地。</p>
<h2>我們的習慣做法</h2>
<p class="nogap">我們相信軟件太複雜了。太多的功能，太多的按鈕，需要學習太多東西。 我們的產品比對手做的少 — 故意地. 我們構建的產品運行靈巧，感覺舒適，允許你以自己的方式做事，並且容易使用。</p>
<h2>我們的產品</h2>
<p class="nogap"> 當這本書出版之即，我們有5個商業產品和一個開源框架。</p>
<p><a href="http://basecamphq.com/">Basecamp</a>把項目管理作為首要問題。Basecamp提供了消息板，待辦事宜，簡單調度，協同寫作，文件共享。而不是甘特圖，炫麗的曲線圖，和繁重的電子錶格。目前，成千上萬的人同意這是一種更好的方式。來自Salon.com的Farhad anjoo說：「Basecamp代表了Web軟件的未來。」</p>
<p><a href="http://campfirenow.com/">Campfire</a> 提供了業務模式下的簡單群聊方式。實時持久的群聊對於業務來說非常重要。傳統的實時聊天對於快速的一對一模式很有效。但是對於3個或者更多的人同時聊天來說異常痛苦。Campfire解決了此問題和其他相關問題。</p>
<p><a href="http://backpackit.com/">Backpack</a> 是一種替代那些玄乎，複雜，「通過25個步驟管理人生」之類的個人信息管理系統的產品。Backpack在頁面，筆記，待辦事宜，電話和電子郵件通知上的簡單嘗試，在受「statis-quo-itie」折磨的一類產品中，是一個獨具匠心的創意。Wall Street Journal的Thomas Weber說它是同類產品中最出眾的。 New York Times 的 David Pogue說它是一個「非常酷」的組織工具。</p>
<p><a href="http://www.writeboard.com/">Writeboard</a> 使你能夠撰寫，分享，修訂，和比較自己或者他人的文章。臃腫的文本處理工具，對於你95%的文字是功能過剩的，而Writeboard是一個全新的替代品。Web-guru Jeffrey Zeldman說：「37signals 的天才思想王者歸來。」</p>
<p><a href="http://tadalist.com/">Ta-da List</a> 維護聚合你的所有待辦清單，並且以在線方式組織。為你自己維護待辦清單，或者通過和其他人分享來協作。沒有更好的方式來搞定這些了。迄今為止，其創建了超過100，000個清單和1，000，000項行動。 </p>
<p><a href="http://www.rubyonrails.org/">Ruby on Rails</a>, 對於開發者來說，是一個用Ruby編寫的全棧式的開源Web框架。其使得開發真是應用快速而簡單。你可以關注在你的思想上面，而由Rails操心雜事。O'Reilly的Nathan Torkington說：「Ruby on Rails太令人震撼了。使用它像是觀賞一個功夫片，片中一堆流氓框架準備痛扁這個小新人，沒想到卻被各種充滿想像力的方式揪住了屁股。」Gotta喜歡這段話。</p>
<p>你可以從<a href="http://www.37signals.com/">www.37signals.com</a>找到更多關於我們產品和我們的公司的信息.</p>
<br/><hr/>
<h1>告誡，免責，和其他醜話說在前頭</h1>
<p>為了掃清障礙，下面是我們對於一些不時聽到的抱怨的答覆。: </p>
<h2>"這些技術不適合我"</h2>
<p class="nogap">Getting real 是一套對我們來說效果非凡的系統。但是本書的思想並不是放之四海皆准。如果你正在構建一套武器系統，一個導彈控制設備，一個為數以百萬用戶服務的銀行系統，或者其他對生命、財產至關重要的系統，你將會迴避一些我們的放縱主義態度。請繼續前行並且採取一些其他的防範措施。 </p>
<p>而且不必全部採納或者全盤否定我們的主張。即使你沒能力完全Getting Real，一定有少許觀點你能夠偷偷摸摸避開當權者而實行。</p>
<h2>"這些思想不是你們發明的"</h2>
<p class="nogap">我們沒有聲明我們發明了這些技術。許多概念已經以各種形式伴隨我們很久了。當你讀到一些我們的建議，並且它提醒你讀到的一些東西已經在一些人的日記或者一些已經出版了20年的書裡面了。這是完全可能的。這些技術並不是37signals的獨創。我們只是告訴你我們怎樣工作和是什麼帶給我們成功的。</p>
<h2>"你們的觀點過於絕對" </h2>
<p class="nogap">如果我們的口吻看起來好像無所不知，目中無人，請寬容我們。我們認為果敢地提出觀點要比唯唯諾諾，模稜兩可要好得多。如果這是驕傲自大的形象，它就是。我們寧願具有煽動性，也不願意用「那要看…」這樣的話來和稀泥。當然這些規則需要時間來完善或者打破。而且一些策略可能不適合你的場合。請運用你的判斷力和想像力。</p>
<h2>"我們公司內部不適用."</h2>
<p class="nogap">覺得你的公司太大以至於難以Get Real？連微軟也Getting Real（而且我懷疑你的公司更大）。</p>
<p>即使你的公司典型地執行長期，大型團隊的調度計劃，仍有方式Get real。第一步是分解成更小的團隊。當太多的人牽扯進來，什麼事都搞不定。你越輕裝上陣，事情就做的越快越好。</p>
<p>沒錯，這需要一些推銷潛質。讓你們的公司投身於Getting Real過程中。給他們出示這本書。向他們炫耀你用更少時間和更小團隊所得到的真實成就。</p>
<p>解釋Getting Real是一種嘗試新概念的低風險，低投入的方式。</p>
<p>如果你有勇氣的話，秘密行動。在雷達下面飛行來證明真實結果。這正是Start.com團隊在微軟運用Getting Real的方式。「我觀察過Start.com團隊的工作方式，而他們沒有經過許可」，微軟的技術傳播者Robert Scoble說。「他們有一個老闆作為空中掩護。他們每次只接受一點功能，實現他們，並且響應反饋。」</p>
<div class="quote">
<h3>推進微軟的 Start.com</h3>
<p>在大公司中，流程和會議是非常平常的。數月的時間被浪費在規劃功能，爭論細節，力求達到每個人在什麼是對於客戶來說是「正確」的東西上達成一致。</p>
<p>這可能是塑料包裝軟件的正確途徑，但是基於Web的軟件有難以置信的優勢。立刻發佈！讓用戶告訴你這是不是正確的東西。如果你願意，你可以當天修正它然後發佈最新版。沒有什麼話比客戶的意見更有用 — 拒絕舉行囉嗦的會議和爭論。僅僅發佈產品，並且證明這個觀點。</p>
<p>知易行難 — 這說明：</p>
<p><em>數月的規劃沒有必要。</em><br/> 花費數月來寫規格說明根本沒必要 — 規格說明應該在開發過程中理清框架，描述並且精化細節。不要試圖在開發開始之前解決所有選而懸而未決的問題，並且敲定所有細節。</p>
<p><em>發佈更少，但高質量的功能.</em><br/>你不需要一道電閃雷鳴伴隨著全新的發佈和一捆新功能。一小塊一小塊地喂用戶，讓他們能夠消化。</p>
<p>如果發現了細微的bug，先發佈敲定的核心功能，然後發佈補丁。動作越快用戶反饋越好。紙上談兵聽起來不錯，但是實踐中往往不理想。你越快發現觀點的關鍵錯誤越好。</p>
<p>一旦你快速迭代，並且響應用戶反饋，你就和用戶建立了一種關係。記住目標是通過構建用戶所想來贏得客戶。</p>
<cite>—Sanaz Ahari, <a href="http://www.start.com/">Start.com</a>, <a href="http://www.microsoft.com/">Microsoft</a> 的程序經理</cite>
</div>
<br/><hr/>
<h2 class="chapter_title"><a name="ch02"></a>起跑線 <span>第二章</span></h2>
<h1>建構從簡</h1>
<h2>做得比竟爭對手少</h2>
<p>常規的思維方式告訴我們，不管競爭對手做什麼你總是要比他們加多一些。如果他們有4個特色功能，你就需要做出5個（或15個，或25個）。如果他們花了x，你就該花xx。如果他們有20，你就得有30。</p>
<p>這種強調更多一層的冷戰競爭思維是行不通的死胡同。如此創造產品的方式是昂貴的，過分防禦的，並且有點偏執不正常的。防禦性的偏執的公司是做不到前瞻性思維的，他們只能做事後思維。他們不可能領導，只能跟從。</p>
<p><em>如果你只想創建一個隨大流的公司，那麼你現在就可以放下這本書，無需繼續讀下去了。</em></p>
<p>那怎樣才是有效的方法呢？答案是：做少。靠做得比對方少來打敗他。解決簡單的問題，把繁複困難棘手的問題留給大眾。不做更多，相反的我們做的更少。不趕超，相反的我們試著退一步，守後。</p>
<p>我們將會將貫穿全書論述「少做」的概念，現在先簡要介紹「少做」的含義作為熱身：</p>
<ul>
<li>更少的功能</li>
<li>更少的選擇項和首選項</li>
<li>更少的配備人員和企業架構</li>
<li>更少的會議和抽像討論</li>
<li>更少的承諾</li>
</ul>
<br/><hr/>
<h1>是什麼問題一直困擾你？</h1>
<h2>為自己而做這個軟件</h2>
<p>一個很好的做軟件的方式就是一開始用它來解決你自己的問題。由於你自己變成了軟件的目標受眾因此你會知道什麼是重要的什麼不是。這樣做下去將會是推出一個突破性產品的偉大起始點。</p>
<p>關鍵是你要瞭解你並不孤單。如果你有一個困擾你的問題那麼非常有可能成百上千的其他人業有同樣的煩惱。這，就是你產品的市場。看，不難找到吧？</p>
<p>Basecamp這個產品來自於一個困擾我們的難題：做為一個設計公司，我們需要有一個很簡單的方式來和客戶做項目溝通。一開始，我們建了一個外部網，通過不斷更新其內容來連線客戶。但每次一個項目需要更新我們就得手動更改HTML，這實在不是一個解決方案。這些項目網站總是看起來不錯但最終總是被放棄了。這是很令人惱火的，因為它使我們變得很沒有組織性，也讓客戶感到無所適從。</p>
<p>於是我們開始尋找其他解決方案。但每樣我們找到的工具都是 1)並不能做我們想做的 或 2)充斥著我們所不需要的功能 — 比如象賬單，登錄權限控件，圖表，等等。我們覺得一定會有更好的方案，最終我們選擇了自己來做這個軟件</p>
<p>當你在做軟件解決你自己問題的時候，你創造的工具是你對之有激情的。那激情就是關鍵所在。激情意味著你真正去用這個軟件，去關心這個軟件。這是能感動他人並一起為之所動的最好的方式。</p>
<div class="quote">
<h3>自助（自撓其背而止癢）</h3>
<p>這是很長一段時間以來被開源領域奉為箴言的 — 他們叫它做「自撓其背而止癢」。對開源軟件開發者來說，這意味著他們將自己去組織必需的工具，用自己的方式來推出產品。不僅於此，這樣做的有著更深遠的裨益。</p>
<p>作為一個新軟件的網頁設計師和程序開發者，每天你要面對上百個細小的決策：是要藍色的還是綠色的？用一個表格還是兩個？靜態的或是動態的頁面？放棄重新來過還是修復？一般我們是怎樣來做這些決定的呢？如果那是我們認為很重要的我們也許會提出來討論。其餘的我們就靠猜想。最終所有那些猜想的部分將積累成軟件的一種債務 — 一堆互相交織著的錯綜複雜的充滿不確定因素的網。</p>
<p>作為一個開發者，我厭惡這種現象。想到有那麼多的小型定時炸彈分佈在這個軟件中，給我帶來了很大的壓力。自己幫助自己的開源軟件開發者不會有這樣的困擾。因為他們就是用戶本身，90％的情況下他們瞭解他們應該做什麼決定。我想這是為什麼這些人能夠在一天辛苦的工作回家後還能繼續編寫開源程序的眾多原因之一，因為它反而是一種放鬆。</p>
<cite>—Dave Thomas, <a href="http://www.pragmaticprogrammer.com/">《程序員修煉之道》</a></cite>
</div>
<div class="quote">
<h3>一切源於必要性</h3>
<p> Campaign Monitor公司的成立事實上是來源於必要性。多年來各種email市場營銷工具的低劣品質一直困擾著我們。一個工具可以做到x和y卻總也做不到z，另一個能搞定y和z卻總也做不好x。老是這麼下去我們將無法成就贏家。</p>
<p> 我們於是決定整頓我們的時間表，著手開發我們理想中的email市場營銷工具。我們很清醒地決定不看其他人在做什麼而是專心做一個能讓我們自己和客戶都活得自在一些的產品出來。</p>
<p> 事實證明，我們並不是惟一對現狀感到不滿的人。我們對軟件成品做了一些改動，這麼一來所有的設計公司（不僅我們自己）都能使用它並且開始幫我們推廣。不到6個月，數以千計的設計師開始用Campaign Monitor來發佈他們自己和客戶的email推廣信了。</p>
<cite>—David Greiner, 創始人, <a href="http://www.campaignmonitor.com/">Campaign Monitor</a></cite>
</div>
<div class="quote">
<h3>你必須在乎這個東西</h3>
<p>當你在寫一本書，你必須要有一個以上的有趣故事可講。你必須有強烈地要講敘這個故事的慾望。你必須要以某種方式把自己投入到故事中去。如果你要和一件事業共存兩年，三年或你地一生，你必須要真正在乎它</p>
<cite>—Malcolm Gladwell, 作者 (from <a href="http://www.powells.com/authors/gladwell.html">雜看Malcolm Gladwell</a>) </cite>
</div>
<br/><hr/>
<h1>找自己募資</h1>
<h2>外部資金只是第二條路(plan B)</h2>
<p>很多創業者的首要任務就是找投資者募集資金。但必須記住，當你尋求外部資金的時候就意味著你不得不向別人匯報。於是別人對你的期望值將提升。投資者無不希望他們能夠收回資金 — 並且是以最快的速度收回。導致一個不幸的事實就是往往搶錢優先過做一個優質的產品。</p>
<p>現時創業並不需要太多的啟動資金。硬件便宜了，大量的優秀框架軟件也都開源免費了。而且創業的激情是不需要標價的。</p>
<p>因此手頭有多少錢就先動起來做多少事。用心想想決定什麼是你最基本需要的，什麼是可以先捨棄不做的。什麼事是你可以三個人就搞定而不必用到十個人？什麼是兩萬塊而不用十萬塊就能辦到的？什麼樣的軟件你可以一邊白天打工用業餘時間做出來的？</p>
<h2>資源拮据往往能激發想像力</h2>
<p>當在有限的資源平台上運作，你往往會被迫更早的更緊迫的認識到這種壓力。那是一件好事。有壓力才會促使創新。</p>
<p>拮据也能迫你更早地將你的點子推出來—這是另一件好事。這麼跨出去一兩個月後你就會比較清楚的瞭解這個點子是否有戲。這樣一來，你就會在短時間內樹立起自信心，不再那麼急切尋求外部資金了。如果你的點子行不通，是虛的（酸檸檬），那麼就是重新來過的時候了。壞消息至少你現在知道比幾個月後或幾年後知道好。至少你比較容易退出。當有投資者涉入的時候退出方案要複雜的多了。</p>
<p>如果你做軟件只是想搞一度快錢，那麼事實是瞞不住的。想很快的回本實踐中是不大可能的。所以，專心做一個優質的軟件，做出一個你和你的客戶都能長久依賴的工具才是正道。</p>
<div class="quote">
<h3>兩條路 </h3>
<p>[Jake Walker擁有的一家公司是用投資者的錢創立的 (<a href="http://www.disclive.com/">Disclive</a>) 另有一家不是 (<a href="http://www.theshowlive.com/">The Show</a>)。 在這裡他探討了這兩條路的不同風景。] </p>
<p>所有問題的根本並不是籌募資金本身，而是隨之而來的一系列事情。基本上就是更高的期望值。人們於是開始領工資，然後動力就成了做一個軟件然後把它賣了，或想辦法把種子基金給還了。就我前面的第一家公司（Disclive)，出於必要性我們起步得比我們原先設想的高很多 — </p>
<p>[關於第二家公司The Show] 我們發現我們可以推出一個花更少的錢卻可以做得更好得產品，只不過要多花些時間。我們把很多自己的錢賭到一個人們願意犧牲一點時間來換取品質的產品上面。但公司一直保持著小規模（也預計會一直這麼走下去）。從那以後，我們就全部是內部募資。通過採取一些靈活的交易方式和我們的供應商合作，我們從不需要投入自己很多的資金。並且我們並不是做大後賣了，而是隨需要而發展，走持續的可盈利道路。</p>
<cite>—評論來自於 <a href="http://www.37signals.com/svn/archives2/entrepreneurs_angels_and_the_cost_of_launch.php">Signal vs. Noise</a></cite>
</div>
<br/><hr/>
<h1>固定時間和預算，但靈活控制產品外延</h1>
<h2>準時地在預算內推出</h2>
<p>一個簡單方法讓你能準時地在預算範圍內推出產品：定額定量。絕對不要在一個難題上多投時間和金錢。要麼縮小規模，要麼縮小範圍。</p>
<p>總會有一個這樣誤區：我們能做到準時地，在預算內發佈一個規模完整的產品。這可以說完全不可能的，如果真是這樣的話一定是以質量做為代價的。 </p>
<p>如果你不能在預定的時間和預算內完成所有的東西的話，就不要拉長時間和增加預算。相反的，把產品的外延縮小些。下一步總是有時間可以加東西進去 — 過後有的是時間，當下卻是稍縱即逝的。</p>
<p>做一個比預計要小巧些的好東西比做一個龐大平庸而又漏洞百出的東西要現實的多，因為你要象魔術師一樣巧妙的照顧到時間，預算和產品內容的方方面面。變魔術就交給Houdini（魔術大師）。你所做的可是在運作一個真正的事業，在推出一個真實的產品。 </p>
<p>以下是一些固定時間和預算，靈活控制產品外延的好處: </p>
<ul>
<li><h4>要有優先級</h4> 你一定要搞明白什麼才是最重要的。什麼是首發的產品中必須要具備的特性功能？這個限制思維逼迫你下一些痛苦但必要的決定，而不是挑挑揀揀的拿不定主意。</li>
<li><h4>要現實些</h4> 設定期望值是關鍵。如果你同時要固定死時間，預算和產品的外延，你將不能推出高層次的產品。當然你可能推出個東西，但那個「東西」會是你真正想做的嗎？</li>
<li><h4>要有靈活性</h4> 及時應變的能力很重要。如果什麼都固定死就很難應變。給產品的外延注入機動性，當真正做起來就有比較多的選擇空間。機動靈活是你的良師益友。</li>
</ul>
<p>我們建議：範圍縮小些。做半個產品比做半拉子的產品好（後面將進一步論述這點）。</p>
<div class="quote">
<h3>一天，兩天，三天...</h3>
<p>知道一個項目是怎樣拖到最後比預計遲一整年的嗎？就是這麼一天一天拖出來的。</p>
<cite>—Fred Brooks, <a href="http://en.wikipedia.org/wiki/The_Mythical_Man-Month">軟件工程師，電腦科學者</a></cite>
</div>
<br/><hr/>
<h1>找個敵人</h1>
<h2>挑選一場戰鬥</h2>
<p>有時瞭解你的應用程序應該做成什麼樣子的最佳方式就是，認識到它不應該成為什麼。搞清楚你的軟件的對手是誰，就像點一盞燈，能照亮你前行的道路。</p>
<p>當我們決定開發項目管理軟件的時候，我們清楚的知道微軟項目軟件（Microsoft Project)是這個小舞台上的一個龐然大物，大猩猩。我們不是去害怕這個大傢伙，相反的我們把它做為一個刺激我們前進的引擎。我們決定Basecamp將做成一個完全不同的項目管理軟件，就是反Microsoft Project而行。</p>
<p>我們意識到項目管理並非就是有關圖表，報告和統計數據 — 它更重要的是溝通。它並不是要一個項目經理坐得高高在上去傳達一個項目計劃。它應該是每個人都參與的，一起擔起責任來使項目付諸實現。</p>
<p>我們的敵人就是項目的獨裁者和他們用來指手畫腳的工具。我們要把項目管理民主化 — 讓每個人都能成為它的一份子（包括客戶）。只有每個人都承擔負責流程的一部分，這樣整合起來項目才能做得更好。</p>
<p>說說Writeboard這個協同文字編輯軟件，我們知道有很多的競爭對手的產品內建了許多複雜玄妙的功能。正因為如此，我們決定著重從「不花哨」入手。我們開發了這個程序僅僅來讓人們共享和協作，而不用一些非必要的功能來使他們舉步維艱。只要是不必要的我們就不做。推出後僅3個月的時間，已經超過10萬個用戶在使用Writeboards。</p>
<p>當我們開始著手Backpack這個資訊管理軟件的時候，我們的敵人就是嚴格的組織框架和規章制度。人們應該要能夠用他們自己的方式來管理他們的信息 — 而不是在一堆預先規定好的格式和眾多的表格中填空。</p>
<p>你能從敵人那裡得到的一個好處就是：一個非常清晰的營銷理念。人們很容易被衝突對立挑動。並且通過把一個產品和另一個作比較能更多地瞭解這個產品。選中了這麼一個敵人，你給人們灌輸了他們想要知道的對立的信息。這樣一來，他們不僅能更好更快地認識你的產品，也會站到你的這邊。這是一個吸引注意力和引發產品傾向性的一個萬無一失的方法。</p>
<p>說了這麼多，必須指出的是，也不要太過著迷於競爭。過分地去分析其他產品會慢慢限制你的思維想像力。很快地看一下他們在做什麼，然後就要回到你自己地理念和理想上來。</p>
<div class="quote">
<h3>別老跟著領頭羊</h3>
<p>營銷人員 (和幾乎所有人) 都被培訓要跟從領導者。自然的本能都是在思考競爭對手做對了什麼，然後你在那個基礎上做得更超過。 — 如果你的對手在競價你就一定要比他更便宜，如果他在競速你就要比他做得更快。這麼一來出現的問題是萬一消費者聽信了別人的故事（或謊言），你再要把他說轉回來就會像要說服他承認他是錯的一樣。沒人喜歡承認他是錯的。</p>
<p>於是你應該創造一個不同的故事來說服聽眾，告訴他們你的故事要比他們在其他地方聽到的更重要。如果你的競爭對手是在競速，那麼你就必須轉到競價上來。如果他們強調的是健康，那麼你就必須推銷方便性。並不是簡單地在x/y軸圖表上標出「我們比較便宜」的聲明，而是實實在在地用真實的完全不同於他人正在推銷的故事。</p>
<cite>—<a href="http://sethgodin.typepad.com/">Seth Godin</a>, 作家/企業家(from <a href="http://www.moveahead1.com/articles/article_details.asp?id=33">做個更好的騙子</a>)</cite>
</div>
<div class="quote">
<h3>問題的關鍵是什麼?</h3>
<p>老是看你的競爭對手在做什麼是你給自己找麻煩的最快的方式之一。對於我們建造BlinkList這個平台來說尤其確實。從我們推出以來已經有其他10個類似的社交關係網軟件相繼出現。有些人已經開始在網上用並排圖表來做不同軟件之間功能特色的詳細比較。</p>
<p>這是很容易誤導的。我們不隨大流，相反的，我們只看大方向，時時提醒自己什麼是我們想要解決的問題關鍵，怎樣去解決它。</p>
<cite>—Michael Reining, 共同創立人, <a href="http://www.mindvalley.com/">MindValley</a> 和 <a href="http://www.blinklist.com/">Blinklist</a></cite>
</div>
<br/><hr/>
<h1>它不該成為一種交易</h1>
<h2>你的激情 — 或者冷漠 — 會起作用的</h2>
<p>如果你越不把軟件當作一種交易去做，你就越能做得好。把它控制在一個你能把握的小範圍內，你就有可能真正地享受過程。 </p>
<p>如果你做這個軟件一點不興奮，那就是什麼地方出了問題了。如果你只為了趕緊搶點錢做掉它，那這種影響會出現在最終產品上。同樣地，如果你滿懷熱情地去做它，結果也會反映在產品上。人們是能夠分辨出箇中的區別的。</p>
<div class="quote">
<h3>激情的體現 </h3>
<p>在設計這個高度主觀，具爭議性且難以界定的領域裡，沒有什麼是能做到比表達激情更直接清晰的了。一個產品會使你歡欣或讓你無動於衷是很顯而易見的; 不管是前者或後者，要人們不發現軟件背後那些創造者的感情投入是很困難的。</p>
<p>熱情是很容易凸顯出來的，漠然也是同樣難以掩飾的。如果你並非帶著一種誠摯的心去對待手頭上的產品，那麼它留下的漠然與空白是幾乎不可能掩飾的，不管一個設計作品表面看來多麼精細吸引人。</p>
<cite>—Khoi Vinh, <a href="http://www.subtraction.com/">Subtraction.com</a></cite>
</div>
<div class="quote">
<h3>烘培師 </h3>
<p>在美國，在這個時代生意經往往是提出一個構想，讓它能盈利，在還能盈利的時候把它賣了，然後改行或不幹了。這往往是一個能否挺下去的問題。對我而言: 去熱愛烘培，賣你自己做的麵包，人們如果喜歡它我就賣多些。我就這麼把烘培事業做下去，因為我知道我在做好吃的人們愛吃的東西。</p>
<cite>—Ian MacKaye, Fugazi的會員， Dischord Records的合夥人<br/>(from <a href="http://archive.salon.com/people/conv/2001/01/08/mackaye/print.html">Salon.com People | Ian MacKaye</a>) </cite>
</div>
<br/><hr/>
<h2 class="chapter_title"><a name="ch03"></a>保持精益 <span>第三章</span></h2>
<h1>更小的質量</h1>
<h2>你越做到精益，改變越容易</h2>
<p>一個物體的質量越大，改變方向需要的能量越多。物理世界的這個真理同樣適用於商業世界。</p>
<p>當真理應用到Web技術的時候，改變必須是簡易和低廉的。如果你不能如飛一樣的改變，你就會敗給能夠做到的競爭者。這就是你需要追求更小質量的原因。</p>
<h2>質量會由於以下因素增加</h2>
<ul>
<li>長期合同</li>
<li>多餘的職員</li>
<li>固執的決策</li>
<li>關於會議的會議</li>
<li>厚重的流程</li>
<li>存貨（物理的或者頭腦的）</li>
<li>硬件，軟件和技術的鎖定</li>
<li>專有數據格式</li>
<li>未來被過去支配</li>
<li>長期的路線圖</li>
<li>辦公室政治 </li>
</ul>
<h2>質量會由於以下因素減少</h2>
<ul>
<li>必要而及時的思考</li>
<li>多面手的團隊成員</li>
<li>擁抱限制，而不是試著移除他們</li>
<li>更少的軟件，更少的代碼</li>
<li>更少的特徵</li>
<li>小規模團隊</li>
<li>簡單</li>
<li>被拆分為正交的接口</li>
<li>開源產品</li>
<li>開放的文件格式</li>
<li>開放的文化，使承認錯誤更容易</li>
</ul>
<p>更小的質量使你快速的改變方向。你可以隨機應變和演進。你可以集中於好的主意，擯棄壞的。你可以傾聽並尊重你的客戶。你可以集成新技術現在而不是以後。你駕駛的是蒸汽船而不是飛機貨艙。為這個事實驕傲吧。</p>
<p>舉例來說，想像一個精益，小質量的公司，用更少的軟件，更少的特徵製造了一個產品。另一方面是一個更大質量的公司擁有一個帶有明顯更多軟件和特徵的產品。那麼試想一下，隨著新技術，比如Ajax，或者新概念，比如標籤的出現，誰會更快的調整他的產品？擁有更多軟件更多特徵還帶著12個月路線圖的團隊，還是另一個團隊，擁有更少軟件更少特徵和一個更有機的流程——「讓我們集中於我們當下應該集中精力的地方吧」。</p>
<p>很明顯，更小質量的公司在適應市場真實需要的方面處於更有利的位置。當小質量公司已經完成轉換很久以後，更大質量的公司有可能仍然在爭論變化或者將他們推入官僚主義的流程中。小質量公司會領先兩步於仍然在爭論如何走的大質量公司。</p>
<p>反應快，敏捷，小質量的公司可以快速的改變他們整個業務模型，產品，特徵集和營銷信息。他們可以犯錯並快速的修復。他們可以改變他們的優先級，產品組合和重點。還有最重要的，<strong>他們可以改變他們的想法 </strong>。</p>
<br/><hr/>
<h1>減少改變的成本</h1>
<h2>通過減少改變的阻礙保持靈活</h2>
<p>改變是你最好的朋友，改變的代價越大，你越不可能做出改變。如果你的競爭對手可以比你更快的改變，你會處於一個很大的劣勢。如果改變變得過於昂貴，你已經死了。</p>
<p>這就是保持精益真正幫助你的地方。很短時間內改變的能力是小團隊與生俱來而大團隊永遠不會有的。這是大傢伙嫉妒小傢伙的地方。讓巨大組織裡的大團隊花費數周才能改變的，對於小團隊可能只需要1天。這個優勢是無價的。低廉和迅速的改變是小團隊的秘密武器。 </p>
<p>請記住：所有的現金，所有的營銷策略，所有的世界上的優秀人物，都買不到小帶來的敏捷。</p>
<div class="quote">
<h3>順其自然</h3>
<p>順其自然是敏捷的根本原則之一，也是最接近純正魔術的一個。順其自然的特性不是設計的或內建的，它自然的發生，就如系統其餘部分的動態結果。「順其自然」來自於17世紀中期的拉丁文，意思是「無法預見的出現」。你不可能為它做計劃，或者做時間表，但是你可以為它營造一個環境，讓它發生並受益於它。</p>
<p>順其自然一個經典的例子是鳥群的遷徙行為。計算機模擬只需要少至三個原則（按照「不要撞到一起」），你會一下子得到非常複雜的行為來描述鳥群在天空中優雅的飛行和滑翔，重組隊形繞開障礙，等等。沒有一個高級行為（比如躲開障礙重組形成的相同形狀）是被規則規定的；都是由系統動態衍生的。</p>
<p>簡單的規則，就像鳥群的模擬一樣，導致複雜的行為。複雜的規則，就像許多國家的稅法一樣，導致愚蠢的行為。</p>
<p>許多常見的軟件開發實踐帶來了令人遺憾的邊際效應，他們消除了順其自然行為的發生機會。大多數優化的嘗試——直率的敲下一些代碼——減少了互動和關聯的寬度和範圍，而這些正是順其自然的來源。在鳥群遷徙的例子中，正如一個設計良好的系統，正是互動和關聯創造了有趣的行為。 </p>
<p>我們把事物綁的越緊，留給創新的、順其自然的解決方式的空間就越少。不管是在需求被完全理解前就鎖定了需求，還是不成熟地優化代碼，讓終端用戶使用系統前引進了複雜的導航和工作流場景，結果都是一樣的，一個過分複雜、愚蠢的系統，而不是順其自然帶來的清潔和優雅的系統。</p>
<p>保持小，保持簡單，順其自然。</p>
<cite>—安德魯·亨特(Andrew Hunt)， <a href="http://www.pragmaticprogrammer.com/">實效程序員網站(The Pragmatic Programmers )</a></cite>
</div>
<br/><hr/>
<h1>三個火槍手</h1>
<h2>用三人小組構建1.0版本</h2>
<p>對於產品的1.0版本，請從只有三個人開始。三是一個魔力數字，提供足夠人力的同時允許你保持流暢和敏捷。從一個開發者，一個設計者，和一個清道夫（一個可以在開發和設計中隨意切換的人）開始。 </p>
<p>現在顯而易見的是用很少的人建造一項應用是一個挑戰。但是如果你有一個正確的團隊，挑戰是值得的。有才能的人不會需要無盡的資源。他們會在約束限制下的工作和利用創造力解決問題的挑戰中成功。缺少人力意味著你會被迫更早的應對權衡——那是沒問題的。這種情況會讓你更早而不是更晚的指出你的重點。你也能夠與人交流，不用經常地擔心他們不瞭解前因後果。 </p>
<p>如果你不能夠用三個人建造第一個版本，那麼你或者需要更改人數或者需要縮減初始的版本。記住，保持你的第一個版本小而緊湊是沒有問題的。你會快速的發現你的想法是否快速的進展，如果是，你會擁有一個清潔的簡單的基礎可以繼續建造。 </p>
<div class="quote">
<h3>梅特卡夫定律(Metcalfe's Law)和項目團隊</h3>
<p>保持團隊盡可能的小。梅特卡夫定律(Metcalfe's Law)，「網路的價值，為使用者的平方」，應用到項目團隊的時候得到一個推論：團隊的效率和團隊人數的平方成反比。我開始覺得三個人對於1.0產品發佈是最優的...從減少你計劃添加到團隊的人數開始，接著減少更多。</p>
<cite>—Marc Hedlund, <a href="http://www.oreilly.com/">奧萊利媒體（O'Reilly Media）</a>入住企業家(entrepreneur-in-residence)</cite>
</div>
<div class="quote">
<h3>通信流</h3>
<p>通信在小團隊比在大團隊中更容易流動。如果你是項目中唯一的一人，通信是簡單的。唯一的通信通路是你和客戶之間。但是，隨著項目人員數目的增長，通信通路的數量也隨之增長。它並不是加法形式的增長，隨著人員數目的增長，它是乘法形式的增長，正比於人員數目的平方。 </p>
<cite>—史蒂夫·麥克科耐爾(Steve McConnell）, Construx軟件公司（Construx Software Builders Inc.）首席軟件工程師。<br/> (摘自 <a href="http://www.stevemcconnell.com/articles/art06.htm">《少即是多——小團隊的第一生產力》，Less is More: Jumpstarting Productivity with Small Teams</a>)</cite>
</div>
<br/><hr/>
<h1> 擁抱約束</h1>
<h2>讓限制帶領你到創新的解決方法</h2>
<p>總是有不充足無法滿足所有需要。不充足的實踐。不充足的金錢。不充足的人。</p>
<p><em>這是一件好事情</em></p>
<p>不要被這些約束逼得發瘋，擁抱他們。讓他們指導你。約束驅動創新並強迫集中精力。不要試著移除它們，使用它們帶來你的優勢。</p>
<p>當37signals構建Basecamp的時候，我們有非常多的限制。我們有：</p>
<ul>
<li>一個需要運營的設計公司</li>
<li>已有的客戶工作</li>
<li>一個七小時的時差（David在丹麥編程序，我們其餘的人在美國）</li>
<li>一個小團隊</li>
<li>沒有外部的資金</li>
</ul>
<p>我們感受到了「不充足「的憂傷。所以我們讓我們的盤子保持小。那時我們只能夠往上方這麼多。我們選取大任務，把它們分解成我們一時間能夠處理的小任務。我們一步一步的行動並在前進的過程中分清主次。</p>
<p>」不充足「強迫我們使用創新的方法解決。我們通過始終構建更少的軟件減少改變的成本。我們給人們僅僅足夠的特色讓它們以自己的方式來解決自己獨特的問題 — 於是我們便不再是障礙。時差和空間上的距離讓我們在交流中更加有效。不是人參加會議，我們的交流幾乎毫無例外通過及時通訊軟件和電子郵件，它們強迫我們快速的到達重點。</p>
<p>約束經常是偽裝的優勢。忘掉風險投資，長發佈週期和快速招聘。代替的是，和你目前擁有的合作。</p>
<div class="quote">
<h3>與枯萎作鬥爭</h3>
<p>曾經被稱作「緩慢增長的優雅」可以被更恰當的叫做「特徵枯萎病」，就像植物上的真菌一樣，它節外生枝，模糊了產品的輪廓並吸乾了它的汁液。特徵枯萎病的解藥是，當然是，「限死的最後期限」。這導致特徵被按照實現所需時間的比例被拋棄。經常出現的情況是最有用的特徵需要最長的時間。於是枯萎和最後期限的結合產生了許多我們知道和喜愛的軟件，包含了充足的沒有用的特徵。</p>
<cite>—Jef Raskin, 作者 (摘自 <a href="http://jef.raskincenter.org/unpublished/widgets_of_the_week.html#anchor1152335">"為什麼軟件是它的方式"</a>)</cite>
</div>
<br/><hr/>
<h1>做你自己</h1>
<h2>通過親切友善和人性化來把自己和大公司區分開來</h2>
<p>大量的小公司犯了試著裝作大公司的錯誤。就好像他們意識到他們的規模是一個缺點，需要隱藏。太糟糕了。小型實際上可以是一個巨大的優勢，尤其是在通訊方面。</p>
<p>小公司享受著更少的形式主義，更少的官僚主義，和更多的自由。<strong>小公司天生和顧客更親近。</strong> 那意味著他們可以以一種更加直接和人性化的方式和顧客溝通。如果你是小公司，你可以用熟悉的語言而不是晦澀的行話。你的網站和產品可以用一種人類的聲音，而不是操著公司的腔調。小型意味著你可以和你的顧客在一起談話，而不是居高臨下的方式。</p>
<p>小公司在內部的交流生同樣有優勢。你可以擯棄形式主義。所有事情都不再需要繁雜的流程和多重的簽字確認。參與流程的人都可以開放和誠實的發言。這個沒有被束縛的思想流是保持小型的巨大優勢。</p>
<div class="quote">
<h3>驕傲地、無所畏懼地做到真實</h3>
<p>雖然你可能認為，顧客可以被誇大員工數字或者你的支付能力欺騙，但是精明的，你真正希望的顧客，永遠會知道真相 — 無論通過直覺還是推理。尷尬的是，我曾經參與過這樣的善意謊言，所有謊言都沒有帶來對商業最重要的東西：和真正需要你的服務的顧客建立的有意義的、持久的和互利互惠的關係。更好的應對應該是驕傲地、無所畏懼地對公司的實際規模和寬度做到真實。</p>
<cite>—Khoi Vinh, <a href="http://www.subtraction.com/">Subtraction.com</a></cite>
</div>
<div class="quote">
<h3>不論何時</h3>
<p>不管你在哪個行業，良好的顧客服務應該是所有客戶最大的要求。我們自已對於服務是這樣要求的，我們的客戶又怎麼會有區別？從一開始，我們就做到讓客戶和我們的接觸容易和明晰，不管他們有多少、甚至沒有問題。在我們的網站上，我們列出了一個免費號碼會轉接到我們的手機；在我們的名片上，每個人都列出了手機號碼。我們向顧客強調，不管他們有什麼問題，他們隨時可以聯繫到我們。我們的顧客感謝我們這樣的信任，沒有人濫用過我們的服務。</p>
<cite>—Edward Knittel, 銷售和市場總監, <a href="http://www.kennelsource.com/">KennelSource</a></cite>
</div>
<div class="next">
<a href="#chapters">返回目錄</a> |
</div>
<br/><hr/>
<h2 class="chapter_title"><a name="ch04"></a>首要任務 <span>第四章</span></h2>
<h1>什麼理念才是偉大的</h1>
<h2>明確定義產品的閃光點</h2>
<p>竭盡全力將你的軟件定位在一個點上。你的軟件代表的是什麼？它到底是有關什麼的？在你開始設計或寫任何代碼之前你必須清楚地知道你做這個產品的目的 — 它的前景。把理想放大些。為什麼要有它？它和其他類似產品不同的地方在哪裡？ </p>
<p>這個理念會引導你的每個決定，指引你不偏離航線。任何時候有比較出格的舉動時，問自己，「我們是不是還在堅守著自己的理念做事？」</p>
<p>你的理念必須是簡潔的。應該一句話就能把想法傳達到。以下是我們每個產品的理念：</p>
<ul class="tight">
<li><strong>Basecamp</strong>: 項目管理即是溝通</li>
<li><strong>Backpack</strong>: 把生活中的凌亂歸整</li>
<li><strong>Campfire</strong>: 用及時通訊軟件來開展團體交流太遜了</li>
<li><strong>Ta-da List</strong>: 和及時貼便條做鬥爭</li>
<li><strong>Writeboard</strong>: 用不著麻煩微軟的WORD</li>
</ul>
<p>舉個例，我們Basecamp軟件的理念是，「項目管理即是溝通」。我們強烈的感覺到對一個項目的有效溝通是引導一系列責任，參與，投資和能量的關鍵。它把大家統到同一個目標上來增強共識。我們清楚地知道如果Basecamp能做到這點，那麼其他事情也就會一一水到渠成。</p>
<p>這個理念引導著我們盡可能地保持Basecamp的透明性和開發性。我們不把溝通局限在公司內部，相反我們向客戶敞開。我們不考慮太多權限地問題，相反我們更鼓勵各方的參與。就是這個理念使我們放棄了圖表，表單，報告，狀態分析和電子錶格的功能，相反的我們專注在優先問題的溝通上，如果每日新信息，評論，該日備忘項目和文件的共享。把有關你理念的重大決定做在前面，將來其他小的決定就會變得容易多了。</p>
<div class="quote">
<h3>白板上的哲理</h3>
<p>有一次Andy Hunt和我編寫一個借記卡的交易開關。有一個要點就是同一個交易不許向用戶的借記卡二次收費。也就是說，不管操作過程中怎樣出錯，錯誤都只能發生在交易最終產生前，不能允許出現重複的交易。</p>
<p>因此，我們在共享信息的白板上用大字寫下：要從客戶角度出發，容許客戶犯錯誤的可能。</p>
<p>還有其他大約半打多類似這樣的信條，在我們創建一些複雜的產品，需要下有技巧性的決定時，這些信條給我們指引了方向。它們使我們的軟件有強大的內部凝聚力和外部的統一性。 </p>
<cite>—Dave Thomas, <a href="http://www.pragmaticprogrammer.com/">一個實用編程者</a></cite>
</div>
<div class="quote">
<h3>編寫座右銘</h3>
<p>組織需要指導原則。需要有一個綱要; 員工每天醒來時應該要知道他們為什麼而工作。這個綱要最好言簡意賅，富有激情：為什麼你會在這裡？是什麼激勵了你？我把這看做是座右銘 — 一段三或四個字的描述你存在的意義。</p>
<cite>—<a href="http://www.guykawasaki.com/">Guy Kawasaki</a>, 作者 (摘自 <a href="http://www.alwayson-network.com/comments.php?id=11963_0_1_0_C">編寫座右銘</a>)</cite>
</div>
<br/><hr/>
<h1>在初期時忽略細節</h1>
<h2>先粗後細</h2>
<p>我們太過癡迷於細節。</p>
<ul class="tight">
<li>兩個原素之間的留白空間</li>
<li>完美的首個字母大寫字形</li>
<li>完美的顏色</li>
<li>完美的用詞</li>
<li>代碼只能四行長，不能七行</li>
<li>90%與89%之差</li>
<li>760px與750px之差</li>
<li>$39/月與$49/月之差</li>
</ul>
<p><em>成功和滿意來自於細節</em></p>
<p>然而，細節中並不只有成功。細節中你還會遇到停滯不前，意見不合，無數的會議和延遲。這些東西會掩煞你的信念，降低你成功的幾率。</p>
<p>你可有常常一整天被困死在一個設計原素或一個程序代碼上？可有不時覺得你今天的進展實在算不上什麼真正進展？過早專注於細節就會導致這些結果。要做完美主義者有的是時間。但不是現在。</p>
<p>別在第一周就擔心標題字體的大小。不需要在第二周就搞定什麼是最佳的綠色的色調。更不用在第三周就要把「提交」按鈕向右移動三個像素。先把該放的東西放上去。然後去用它。保證它是可用的。最後才去把它調整到完美。</p>
<p>細節是在你使用的過程中才會顯露出來的。只有在使用中你才能看到什麼需要進一步關注。在使用中你才會感到缺了些什麼。常常走路絆倒腳你才會清楚地上什麼坑窪是需要填補的。那些是當你被迫要留意的時候才需要的細節，不是一想到細節就去搞定它。</p>
<div class="quote">
<h3>魔鬼隱藏在細節中</h3>
<p>在選修了幾堂繪畫課後，我徹底擺脫了「馬上投入到細節中」的態度...如果你一開始就畫細節十有八九出來的畫作會不怎麼樣。事實上，從你一開始那麼做就完全錯了。</p>
<p>你必須一開始把全局的比例分配搞對。你要從最大的一塊著手，慢慢過渡到最小的。草稿必須體現模糊的主題。然後你著手潤色，使整體畫作具有生命力。著色先從淺，中，深三個色調下手。這麼一來你的草稿就會有明暗了。接下來，在你畫作的其他部分都要秉持三個色調的應用原則。如此反覆直到整體成型...</p>
<p>永遠，都要從大到小去做。</p>
<cite>—Patrick Lafleur, Creation Objet Inc. (摘自 <a href="http://www.37signals.com/svn/archives2/getting_real_ignore_details_early_on.php">Signal vs. Noise</a>)</cite>
</div>
<br/><hr/>
<h1>當問題成為問題的時候才去擔心</h1>
<h2>不要把時間浪費在還未成為問題的問題</h2>
<p>你真的的需要考慮當用戶到達10萬以上的時候會出現的問題嗎？它可能已經是兩年以後的事了。</p>
<p>如果你現在只需要三個程序員你真的有必要雇八個嗎？</p>
<p>你難道真的馬上需要12台高端服務器即使兩台就足以讓你頂一年？ </p>
<h2>就先掠過吧</h2>
<p>人們總是預先花很多時間在還不知道會不會發生的問題上。靠，我們推出Basecamp的時候還不知道如何向客戶收費！因為產品是月付費的，我們知道還有30天的時間來搞定付費方式。我們把預先省下的時間用在解決更緊急的問題，直到產品推出後，我們才著手付費問題。結果很順利（它迫使我們用最簡單的解決方案，沒什麼花哨的東西）。</p>
<p>別整天操心還沒成型的麻煩。別過度開發一個產品。到適當的時候再添加硬件和系統軟件。如果進度推遲了一兩個星期，別擔心，還沒到世界末日。只要誠實: 解釋給你的客戶聽，說你們正經歷著成長的煩惱。他們也許不會因此無比感動，但他們起碼會贊同你的坦誠。</p>
<p>關鍵是: 如果你已經掌握了你需要的信息就及時做決定。這樣你就能把注意力集中到需要馬上解決的問題上來。 </p>
<br/><hr/>
<h1>去網羅對味的顧客</h1>
<h2>找到你產品的核心市場然後就專注進去</h2>
<p>顧客並不總是對的。現實中你要能分辨出誰是你該針對的顧客，誰是你該放棄的。慶幸的是，互聯網使得發掘有共識的顧客的過程變得無比容易。</p>
<h2>如果你想討好每個人那麼你什麼人也討好不了。</h2>
<p>當我們做Basecamp的時候，我們把市場營銷集中在設計公司這塊上。如此縮小市場範圍，我們就更有可能吸引一些有心的顧客來成為產品的追隨者。要清楚地知道你的產品是為誰推出的，集中精力去討好這部分人。</p>
<div class="quote">
<h3>我們最成功的一步棋</h3>
<p>把Campaign Monitor（市場策略觀察）這個產品嚴格地定位在網頁設計這塊市場是我們走得最好得一步棋。它使我們能很容易地分辨出什麼產品特色才是真正有用，更重要地是，什麼特色是該捨棄地。這樣一來，我們不僅能靠瞄準一個比較小地目標市場來爭取更多地客人，也因這些客人都有相近的需求使得我們的開發工作更容易些。在Campaign Monitor中有大量的功能對其他人是毫無用處的完全針對網頁設計者做的。</p>
<p>關注在一個核心市場也便於產品的宣傳。我們有了這麼一個定位精準的用戶群，就能知道要在他們網上經常出沒的地方做廣告，發佈他們可能會感興趣的文章，然後逐步建立一個產品的用戶社區。</p>
<cite>—David Greiner, 創始人, <a href="http://www.campaignmonitor.com/">Campaign Monitor</a></cite>
</div>
<br/><hr/>
<h1>過後才去做規模調適</h1>
<h2>你還沒有必要現在就做調整</h2>
<p><em>"我的應用程序能否適應萬人的使用規模?"</em></p>
<p>等那真發生了再說，明白嗎？如果用戶的數量大大超過你的系統負荷那麼恭喜！太喜歡這種麻煩事了。但在現實世界中，超大多數的網絡應用程序從來都沒有到達那一步。即使你真的開始超負荷了，也不會到馬上就掛了的地步。你將會有時間反應和調適。還有一點就是，只有推出產品後你才有機會採集真實的數據指標，然後你才能用它們來推斷哪些領域需要改進。</p>
<p>舉例說明，推出的第一年我們的Basecamp只是在一台服務器上運作。因為這樣的一個簡易設置，整個實施只花了我們一周。我們並沒有一開始就搞個15台服務器的集群或是花好幾個月的時間擔心規模調適的問題。</p>
<p>我們這麼做有碰到什麼問題嗎? 有一些。但我們也發現大多數我們害怕的問題，比如短暫的系統滯緩，對用戶來說並不是什麼不得了的事。只要你及時和用戶溝通，誠實地面對問題，他們是會諒解的。回頭看，我們真的非常高興當時並沒有為了」完美的呈現「而把產品的發佈推後數月。</p>
<p>開始階段，要把建造強有力的核心產品做為首要任務，不要過分執迷於需不需要服務器組和是否有能力調整規模應變。 <strong>先把一個偉大的產品推出，然後才去擔心它無比成功了以後該怎麼辦的問題。</strong> 否則你可能只是把精力，時間和金錢花在一個永遠不會發生的預期上。</p>
<p>信不信由你，最大的問題不是規模調適，而是怎樣達到你不得不需要去調適的那一刻。沒有第一個麻煩哪來下一個麻煩。</p>
<div class="quote">
<h3>反正你怎麼也得回頭重新審視</h3>
<p>事實上，每個人都會有規模調整的問題，當服務人群從零到幾百萬的時候，所有人都必須回過頭去重新審視產品設計架構的方方面面。</p>
<cite>—Dare Obasanjo, <a href="http://gettingreal.37signals.com/Scaling%20Up%20and%20Startups">微軟</a> (摘自 <a href="http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=067a2eb8-85c0-4886-b35f-f32b1a46eab9">規模調適和創業公司</a>)</cite>
</div>
<br/><hr/>
<h1>軟件要有自己的主張</h1>
<h2>你的軟件應該要有傾向</h2>
<p>一些人在論證軟件應該保持中立的問題。他們說開發者限制或忽視大眾訴求的軟件功能是一種傲慢的表現。他們說軟件應該總是能隨機應變的。</p>
<p>我們認為那都是扯淡。偉大的軟件必須要有自己的理想。偉大的軟件必定是有傾向的。當人們使用軟件的時候他們不只是在看功能，同時他們也在尋找一個解決方案，一種理想。決定你的理想而後追求不懈。</p>
<p>同時謹記，如果他們不認同你的理念的話還有無數的其他理念可供選擇。沒有必要總追逐你永遠無法討好的人。</p>
<p>一個著名的例子就是wiki的最初設計過程。Ward Cunningham和他的朋友們有意把傳統上認為協作文章不可或缺的許多功能都捨棄不用。他們不把每次文章的修改歸功於特定哪個人，而把所有權標識都去除了。這麼一來，內容就不再自我，而成為永恆。因為他們相信重要的不是誰或什麼時候寫的文章。這個理念改變了一切。這個決定孕育了一個以共享己任的社區，成為Wikipedia（維基百科）日後的主旋律。</p>
<p>我們的軟件走的是一條類似的路。我們的軟件並不追求成為所有人的寵兒。我們的軟件是有自己的性格的。他們找尋的是志同道合的用戶夥伴。他們是在和有著同樣理想的用戶對話。你要麼上來一起，要麼下車。</p>
<br/><hr/>
<h2 class="chapter_title"><a name="ch05"></a>挑選功能 <span>第五章</span></h2>
<h1>部分，而不是殘缺不全</h1>
<h2>構建一半產品，而非產品有一半缺陷</h2>
<p>小心「所有東西除了廚房水池」的Web應用開發途徑。投身於出現的每一個合適的點子上，你將會終結在產品的一個半傻不隉的版本上。你真正想要做的是構建一個把愚蠢一腳踢開的產品。</p>
<p>專注於真正必須的。好點子可以盡量坦白。<strong>擺出產品應該成為什麼樣的任何點子，然後砍掉一半。</strong>減少功能直到只剩下最必要的功能。週而復始。</p>
<p>對於Basecamp，我們從Message開始。我們知道它是這個應用的靈魂，所以我們暫時忽略了Milestone，Todo-list，以及其他功能。這讓我們基於真實的使用情況來決定下一步怎麼走，而不是憑空猜測。</p>
<p>從一個精簡，聰明的應用開始，然後讓它得到關注。就能開始在你構建的堅實基礎上添磚加瓦。 </p>
<br/><hr/>
<h1>無所謂</h1>
<h2>只留精髓</h2>
<p>對於「為什麼你們做這個而不做那個？」這種問題，我們青睞的回答總是「因為無所謂。」這個陳述表達了是什麼讓產品變得偉大。找出緊要的，略去其他。</p>
<p>當我們發佈Campfire時，我們從第一次嘗試此產品的人中聽到下面一些問題：</p>
<p><em>「為什麼只有每五分鐘才有時間戳？為什麼不是每一行聊天都有？</em> 回答：無所謂。有多少次你需要每秒或者每分鐘記錄談話內容？當然不是95%的情況下，5分鐘時間戳足夠了，因為任何更多的細節都不重要。</p>
<p><em>「為什麼你不允許粗體，斜體或者有色字體格式在聊天中出現？」</em>回答：無所謂。如果你希望強調某事，使用可信賴的caps lock鍵，或者在詞語或者段落周圍投放幾個 * 字符。那些方法不需要額外的軟件，技術支援，處理能量，或者學習曲線。除此之外，在簡單的基於文本的聊天中重量級的格式無關緊要。</p>
<p><em>「為什麼你不顯示當前時間房間裡的總人數？」</em>回答：無所謂。每個人的名字被列出來，所以你知道誰在那兒，但是12個還是16個人有什麼區別？如果它不改變你的行為，那麼無所謂。</p>
<p>這些功能如果有就更好麼？當然。但是他們是不可或缺的麼？他們真的重要麼？不是。這就是為什麼我們把他們刨除在外。最好的設計師和最好的程序員不是技能最好的，或者手指最敏捷的，或者用Photoshop用的神乎其神的人。他們是能夠決定什麼不重要的人。真正的收穫源自於此。</p>
<p>你的大部分時間浪費在無關緊要的東西上。如果你能拋棄不重要的工作和思考，你將會獲得不可思議的生產力。</p>
<br/><hr/>
<h1>從說「不」開始</h1>
<h2>不輕易實現功能</h2>
<p>構建部分而不是殘缺不全的秘訣是說不</p>
<p>每一次你對一個功能說yes時，你正在收養一個小孩。你必須帶著你的孩子通過一連串事件（例如設計，實現，測試等）。一旦這個功能出現了，你就被拖住了後腿。盡量為客戶少發佈一個功能，再看客戶是否憤怒地離開。</p>
<h2>不要成為 yes-man</h2>
<p> 不要輕易實現每個功能。而要讓每個功能證明自己，並且表明自己是倖存者。這就像加入搏擊會一樣（參考電影 <i>Fight Club</i>）。你應該只考慮那些好像為了能加入進來而站在走廊苦候了三天的功能。</p>
<p>這就是為什麼你從說「不」開始。每一個向我們提出的 — 或者我們自己提出的 — 新功能需求都遇到一個 NO。我們傾聽但是不採取行動。最初的回應是「不是現在」，如果一個需求或者功能不停的過來，我們知道這才是時候對它進一步觀察。然後，只在那時，我們才開始考慮實現這個功能。</p>
<p>當你不採納他們的功能建議時，你如何回復他們的抱怨呢？首當其衝的是，你要提醒他們為什麼他們喜歡這個應用。「你喜歡它因為我們說NO。你喜歡它因為它沒有做其他100件無關緊要的事情。你喜歡它因為它不試圖始終討好所有人。」 </p>
<div class="quote">
<h3>「我們不想要一千個功能」</h3>
<p>關於iTunes音樂商店，Steve Jobs 私下為獨立唱片製作人做了一個小型的演講。我喜歡的瞬間是，當觀眾不停地舉手說：「可以做[x]麼？」，「你計劃添加[y]麼？」。最終Ｊｏｂｓ回答：「等等 — 放下你們的手。聽著：我知道關於iTunes應該具有很酷的特性你有一千個主意。我們也是。但是我們不想要一千個功能。那樣做很噁心。創新不是關於對每件事說yes。而是對每一件事說NO，除了至關重要的特性。」</p>
<cite>—-Derek Sivers, president and programmer, <a href="http://www.cdbaby.com/">CD Baby</a> and <a href="http://www.hostbaby.com/">HostBaby</a><br/>(from <a href="http://www.oreillynet.com/onlamp/blog/2004/08/say_no_by_default.html">Say NO by default</a>)</cite>
</div>
<br/><hr/>
<h1>隱藏的成本</h1>
<h2>看清功能的成本</h2>
<p>即使一個新功能通過了對其說不的階段，你還需要去發現它隱藏的成本。</p>
<p>比如，我們應該注意到功能循環（帶來更多功能的功能）這種現象。我們曾經有一個需求是在Basecamp裡加上一個「會議標籤」。如果不仔細權衡這看上去好像很簡單。但是想想「會議標籤」需要的不同元素：地點、時間、房間號、人員、郵件邀請、日曆的整合、支持文檔等等。這還不包括修改推廣活動中的截圖、用戶預覽頁、常見問題及幫助頁、服務條款以及更多。在你還沒搞清楚它是怎麼回事之前，一個簡單的想法就像滾雪球一樣弄得你大傷腦筋。</p>
<p><strong>對於每一個新功能你需要……</strong></p>
<ul class="tight">
<li>1. 對它說不</li>
<li>2. 強迫它證明自己的價值</li>
<li>3. 如果得到否定的答案，就此打住。如果是yes，繼續往下……</li>
<li>4. 為界面繪製草圖</li>
<li>5. 設計界面</li>
<li>6. 編寫代碼</li>
<li>7-15. 測試，改進，測試，改進，測試，改進，測試，改進……</li>
<li>16. 檢查幫助文字是否需要修改</li>
<li>17. 更新產品預覽流程（如果有必要的話）</li>
<li>18. 更新用於銷售的拷貝（如果有必要的話）</li>
<li>19. 更新服務條款（如果有必要的話）</li>
<li>20. 檢查是否違背之前的任何許諾</li>
<li>21. 檢查價格體系是否受影響</li>
<li>22. 上線</li>
<li>23. 深吸一口氣</li>
</ul>
<br/><hr/>
<h1>你能把握住它麼?</h1>
<h2>構建你有把握的</h2>
<p>如果你發佈一個會員程序，你的系統能夠處理帳戶和支付問題麼？可能你應該只讓用戶根據會員身份通過信用卡支付，而不是讓他每個月撰寫，簽名，並且郵寄一張支票。</p>
<p>你能承受得起1G的免費空間麼？還是僅僅因為Google這麼作了？可能你應該從100M開始，或者只給付費用戶提供空間。</p>
<p>底線：構建你能夠掌握的產品和服務。許諾容易遵守難。確保你所作所為是在承擔範圍內 — 從組織，戰略和財政上</p>
<br/><hr/>
<h1>人本主義</h1>
<h2>為一般概念構建軟件，並且鼓勵人們創建自己的解決方案。</h2>
<p>不要約束人的習慣。而是令軟件寬容的接納每個人自己的解決方案。給人們足以通過自己的方式解決他們自己的問題的能力。然後解決之。</p>
<p>當我們構建 Ta-da List的時候我們故意忽略掉了一堆東西。不能分配某人一個to-do，不能標記時間範圍，條目不能分類，等等。.</p>
<p> 我們保持工具乾淨整潔,讓人們富有創造性。人們自己琢磨出了如何解決問題。 如果想要添加一個日期到代辦事宜項目,他們可以在該項目前添加 (至: 2006年4月7日) 。 如果想要添加分類,也可以在該項目前添加[圖書]。 理想嗎? 不 。 無限彈性? 是的。 </p>
<p>如果我們試圖寫軟件專門處理這些情景, 我們就會使它在這些擔憂並不適用時的所有情況下，變得不怎麼有用。</p>
<p>把問題的根盡力處理好，然後走開。人們將會在你的總框架內找到自己的解決方案和約定。</p>
<br/><hr/>
<h1>忘掉功能需求</h1>
<h2>讓你的顧客提醒你什麼是最重要的</h2>
<p>顧客想要一切在陽光下。 他們會用雪崩似的功能和特性要求淹沒你。看看我們的產品論壇，功能類別的要求總是蓋過其它要求一大截。</p>
<p>我們會聽到："這一點點額外的特徵" ，或 "這不難辦到"或"加入這個不是很簡單麼？"或"僅用短短幾秒鐘就可以把這個加進去" ,或 "如果你加上這個，我付兩倍的錢" ,等等。</p>
<p>當然,我們並沒責怪人們提出要求。我們鼓勵這樣,並想聽聽他們怎麼說。我們加入產品的幾乎一切,起初都是作為客戶的一個要求提出來的。但是,正如我們前面提到的,你的第一反應應該是一個No 。 所以,你究竟應該怎樣對待這些紛至沓來的要求呢? 你怎樣儲存它們?<strong>你如何管理它們? 你不需要，看完之後，把它們扔掉。</strong></p>
<p>是啊,看完之後，扔掉,並且忘記它們。 聽起來像褻瀆了用戶,但其中真正重要的會不時冒泡，提醒你。 這些都是你唯一要記住的。 這些才是根本必要的。 不必為跟蹤和保留進來的每一請求而操心,讓你的客戶成為你的記憶倉庫. 如果它真的值得一記,他們就會提醒你,直到你不能忘記。</p>
<p>我們是如何得出這個結論的? 當我們第一次啟動 Basecamp 時，我們在Basecamp 的一個代辦事宜列表中跟蹤每一個主要功能的要求 。 當一個需求被某人重複提出後,我們就用一個額外的記號更新名單上的項目(II或III或IIII等) 。 我們計劃有一天我們要檢閱這份名單，並從被請求最多的功能開始依次實現之。 </p>
<p>但事實是,我們從來沒有再去看它一遍。 我們已經知道下一步需要做什麼,因為我們的客戶在通過重複同樣的需求不斷提醒我們。 沒有必要留一份名單或進行太多分析,因為這一切都在實時發生。 當每天都被不停地提醒時， 你不可能忘記什麼是最重要的。</p>
<p>另外一件事要注意:不能因為有 X 人提出需要什麼,就把它列入你的產品功能。 有時不如只說不,並維持你心目中的產品。</p>
<br/><hr/>
<h1>抓住核心 </h1>
<h2>問人們<em>不想</em>要什麼</h2>
<p>大多數的軟件調查和研究都是圍繞人們想要的產品 。"你認為有還缺失什麼特徵？" ， "如果你可以加入一個功能,那會是多少?" ， "如何使這個產品對你更有用" ?</p>
<p>硬幣的另一面會是怎麼樣呢? 為什麼不問人們，不想要什麼? "如果你可以去掉其中一個功能,那會是哪個呢? " ，"你為啥不用? " ， "什麼讓你覺得最礙事？" 。</p>
<p>答案並不是「更多」。有時你對用戶最大的優惠就是把一些東西去掉，拿出來。</p>
<div class="quote">
<h3>創新來自說不</h3>
<p> [創新]來自說不,否定一千件事情,以確保我們不步入歧途或是試圖做得太多。我們總是在考慮進入新的市場,但是通過說不，可以讓我們集中精力做那些真正很重要的事情。</p>
<cite>—史蒂夫.喬布斯, CEO, <a href="http://www.apple.com/">Apple</a> (摘自： <a href="http://www.businessweek.com/bwdaily/dnflash/oct2004/nf20041012_4018_db083.htm">蘋果創新的種子</a>)</cite>
</div>
<br/><hr/>
<h2 class="chapter_title"><a name="ch06"></a>操作 <span>第六章</span></h2>
<h1>一場把軟件運作起來的比賽</h1>
<h2>盡快地推出一個真實的產品</h2>
<p>一個可運作的軟件是積蓄動力，整合團隊，去除行不通的點子的最佳方式。你必須從第一天開始就將它擺在首要位置。</p>
<p>做少一些功能，跳過一些細節，如果一些捷徑能加快軟件進度就大膽用，這些都是OK的。當你做下去的時候，你會對下一步的方向有更準確的把握。太多的故事，建模，甚至HTML演示都是比較虛的構想。一個運作著的軟件是真實的。</p>
<p>只有一個真實的，可操作的軟件才能拉近每個人對現實的理解和認同。避免了為一些草圖和段落爭得面紅耳赤，最終發現這些都是無謂的。同時，你也會發現有些你想像中無關痛癢的事情事實上是很重要的。</p>
<p>真實的產品導致真實的行動。這才是你走向真理之路。</p>
<div class="quote">
<h3>辦實事能導致共識</h3>
<p>當一群不一樣的人開始嘗試尋找和諧共鳴的時候...如果他們是一建立一個全方位的真實的產品那麼他們的意見總會趨於一致。當然，如果他們只是打打草稿或是生出一些點子的話是很難達成共識的。因此，當你真正開始做一個實在的產品時，共識就比較容易達成。 </p>
<cite>—Christopher Alexander, Professor of Architecture<br/>(摘自 <a href="http://www.katarxis3.com/Alexander_Eisenman_Debate.htm">Contrasting Concepts of Harmony in Architecture（對比和諧建築中的概念）</a>)</cite>
</div>
<div class="quote">
<h3>盡快地運作起來</h3>
<p>我不認為我有參加過任何軟件項目，不管大的或小的，是從一段漫長的規劃討論起步，不求同步發展，而又能在進度，成本或功能上成功的。把寶貴的時間浪費在發明一些不必要的或難以實施的性能上是容易的，有趣的，僅此而已，別無益處。</p>
<p>這個道理適用於軟件開發的所有層面，「把一個產品搞起來」是一個靈活的思想。它不僅適用於一個整體的項目，微觀上也適用於小規模的組件開發。</p>
<p>當一個可操作的組件做成後，開發者就希望知道它是否能和應用程序配合，因此他們就會盡可能快的去用它。即使一開始組件的實施並不完全，這種初期的開發協作通常會產生一個比較規範的界面和一些物盡其用的功能。 </p>
<cite>—Matt Hamer, 開發者和產品經理, <a href="http://www.kinja.com/">Kinja公司</a></cite>
</div>
<br/><hr/>
<h1>沖洗一下再來過</h1>
<h2>在不斷反覆中工作著</h2>
<p>別期望一開始就做得好。讓軟件自然成長，和軟件對話。讓它自然蛻變而進化。做為一個在線的軟件是不需要在完成後才推出的。設計一些界面，使用它們，分析它們，反覆地做。 </p>
<p>與其停止在把一切都事先做好做對的思路上，不如在經反覆求證得出的分析判讀中前行。同時，你可以更快的推出一個積極的產品，因為你並不是一味追求一出門就完美的產品。結論是是由真實世界裡的反饋，真實的目標來引導你的注意重心。 </p>
<h2>反覆能解脫你</h2>
<p>如果你知道過後總是要重來一遍，你就不需追求一開始就達完美。這種明瞭不管如何你總是得過後重新審視一些問題的理念，能引發你先把產品想法推出去看看是否可行的激情。 </p>
<div class="quote">
<h3>可能你比我聰明</h3>
<p>可能你比我聰明的多。</p>
<p>這是完全有可能的。事實上，是非常有可能。但是，如果你像大多數人的話，那麼你就會像我一樣，在對看不見摸不著的東西的想像方面有困難。</p>
<p>人類極度善於對環境週遭的事物作出反應。一隻老虎走到房間裡時我們會驚慌失措，災難性的洪水過後我們懂得去清理。遺憾的是，我們在事先計劃方面，在理解我們行為帶來的後果方面，在重要事情的優先排序方面，卻很糟糕。</p>
<p>或許你是少數人中能把所有事情都把握在你的腦子裡的，但這也並不重要。</p>
<p>Web 2.0, 在這個時代我們預定每個人都已經開始使用網絡，這就為一些聰明的開發者運用人類行為的不確定性創造機會。怎麼說呢？就是在允許你的用戶告訴你他們想法的同時，留有空間去做改進。</p>
<p>最後那句同時也解釋了為什麼你應該以這種方式開發在線軟件，以怎樣的方式去推廣推出產品。</p>
<p>把你想做到的說清楚。確保各個環節無誤。然後就推出和進行改進。沒有哪個人自己一個能比大夥兒加起來更聰明。 </p>
<cite>—<a href="http://sethgodin.typepad.com/">Seth Godin</a>, 作家/企業家</cite>
</div>
<br/><hr/>
<h1>從概念到實施</h1>
<h2>從靈感，到草稿，到HTML，到代碼</h2>
<p>以下是我們Get Real（求實）的過程:</p>
<h2>腦力激盪</h2>
<p>先要有個點子。這產品要給我們帶來什麼？以Basecamp來說, 我們是要滿足自己的需要。我們想要用它來發佈項目的一些更新信息。我們希望能讓用戶一起參與。我們知道項目都有里程碑。我們希望能有個集中歸檔的地方讓大家能回過頭去溫習一些舊的東西。我們想要有個全局觀，從一定的高度來鳥瞰所有項目的進度。歸結起來，這些假想和一些其他設想打下了我們日後著手的基礎。</p>
<p>這個階段並不是有關一些實施的具體細節。這是一個大方向。軟件需要為我們做什麼？什麼時候才能知道它有用？確切的說我們要做出個什麼東西來？這是高階的理念，不是像素階段（細節）的推敲。在這個階段，那些細節是沒有意義的。</p>
<h2>紙上草稿</h2>
<p>草稿是迅速的，實用的和便宜的，這就恰恰是你想要開始的方式。塗些東西，畫些東西，方塊，圓圈，線條，什麼都行。把你腦子裡的想法搬到紙上。這階段的目標是把概念轉成一個界面設計的粗稿。這個階段完全是試驗性的。不存在什麼答案是錯誤的。</p>
<h2>創建HTML頁面</h2>
<p>做一個HTML版本的功能界面（或一個區間界面或流程界面，如果這麼做更合適的話）。發佈一個實在的東西，這樣一來大家就都可以看到它出現在屏幕上的樣子。</p>
<p>以Basecamp而言，我們先做「發佈一條信息」的界面，然後是「編輯信息」的界面，然後一步步下去。</p>
<p>先別寫任何程序代碼。只把HTML和CSS的框架搞出來。有關細節實施是後面的事。</p>
<h2>上代碼編程</h2>
<p>當模型框架看起來過得去又兼具一些足夠必要的功能時，就是開始上代碼編程的時候了。</p>
<p>在這整個過程中要記住保持機動彈性，要有多次反覆的思想準備。應該隨時有這個意識：捨棄某些已完成的步驟重新來過，如果成品看起來醜陋不堪。數次重複這個過程是很自然的。</p>
<br/><hr/>
<h1>遠離設置首選項</h1>
<h2>要幫你的客戶決定一些小處細節</h2>
<p>假設你將面臨一個困難抉擇：在一個頁面上可以發佈多少條信息？你的第一反應可能是，「不如做個設置首選項，在那裡人們可以選擇25，50，或100條每頁」。這麼做可是一個方便自己之門。你必須要自己做一個決定。</p>
<h2>設置首選項是一種逃避困難抉擇的方式</h2>
<p>你不是運用你的專業去決定最佳的選擇，相反地把問題留給了客戶。表面看起來好像是你在幫客戶的忙，事實上你只是會使他們更忙（客戶自己已經是夠忙的了）。對客戶而言，面對無窮無盡的設置選項是一個很令人頭痛的問題，不是一件好事。客戶不應該去煩惱細枝末節 —當是你的責任的時候就不要讓別人去擔待。</p>
<p>設置選項也是邪惡的因為他們使軟件變得冗余。更多的選項就需要更多的編程代碼。而且你還要花額外的時間在測試和設計上。還有很多選項排序和顯示界面等你可能從來沒見過的東西。這意味著隱藏的軟件瑕疵：破碎的佈局，凌亂的表格，奇奇怪怪的頁面排序問題等等。</p>
<h2>你要拿主意</h2>
<p>替你的客戶下簡單的決定。這也是我們在Basecamp上用到的訣竅。每頁可發佈信息數是25條。項目總覽頁顯示最近的25條信息。信息反時序排（最新的在上面）。最新近的5個項目會顯示在控制面板上。不需要任何設置選項。它本來就該這樣。</p>
<p>是的，你有可能下了一個不太好的決斷。沒什麼大不了。如果事情發生了，人們會抱怨，會讓你知道。照樣，你可以做調整。Getting Real（求真求實）說的就都是有關能夠一路做靈活修改的道理。</p>
<div class="quote">
<h3>做設置首選項是要付出代價的</h3>
<p>事實證明，加設置首選項是有代價的。當然，有些首選項也有重要的作用 — 並且可能是關鍵的頁面職能。但每提供一個選項都有不菲的代價，你應當仔細考量其價值。很多的用戶和開發者都沒能理解這個道理，最終付出很大成本，寶貴的資本只帶來一點點的價值...我發現，如果你是信奉要靠設計優秀默認功能而不是懶惰地去添加設置首選項的人，那麼自然而然地你的總體UI（用戶界面）會走上正確的道路。</p>
<cite>—Havoc Pennington, 首席技術指導, <a href="http://www.redhat.com/">Red Hat</a> (from <a href="http://www106.pair.com/rhp/free-software-ui.html">Free software and good user interfaces （自由軟件和優秀用戶界面）</a>)</cite>
</div>
<br/><hr/>
<h1>"搞定!"</h1>
<h2>決定都是暫時的，那麼拿定主意就繼續到下一步 </h2>
<p>搞定。現在就開始把它看成一個有魔力的詞。當你到達「搞定」的階段就表明你已完成某事。一個決定已經下了，走下一步。「搞定」也表明你已經聚集了能量。</p>
<p>慢著，如果你搞砸了，下了一個錯誤的決定怎麼辦？沒問題。 <strong>這並不是什麼開顱手術，它是一個在線應用程序。</strong> 我們一再強調，在開發過程中你總是需要不時回過頭去調整軟件的功能及想法。不管你計劃得多周密總有可能一半左右的東西沒做好。所以，不要做「到死都要調查分析」的傻事。那樣做只會慢了進度和磨去意志。</p>
<p>相反地，要知道以「朝前看向前走」為重。要跟上拿主意的節拍。做一個迅速簡單的決斷，如果它行不通那就再回頭修改。</p>
<p>要接受多數決斷都是暫時的有時效性的現實。要接受錯誤必將發生的現實，同時也要認識到這並不是什麼大不了的，只要你能迅速改正之。執行，積蓄能量，而後前行。 </p>
<div class="quote">
<h3>做一個執行者</h3>
<p>當我聽說有人對自己的點子很具保護性時覺得很可笑。（那些在告訴我一些簡單的概念之前希望我簽定保密協定的人。）</p>
<p>對我而言，如果不去執行的話點子是一無用處的。它們只是倍數。執行才是價值萬金的。</p>
<p>理由:</p>
<ul class="tight">
<li>糟糕的點子 = -1</li>
<li>脆弱的點子 = 1</li>
<li>普通的點子 = 5</li>
<li>好點子 = 10</li>
<li>偉大的點子 = 15</li>
<li>超閃亮的點子 = 20</li>
<li>沒有執行 = $1</li>
<li>柔弱的執行 = $1000</li>
<li>普通的執行 = $10,000</li>
<li>好的執行 = $100,000</li>
<li>偉大的執行 = $1,000,000</li>
<li>超強的執行 = $10,000,000</li>
</ul>
<p>如果要成就一番事業，你必須將二者相乘。</p>
<p>最閃亮的點子，如果沒有執行，最多值$20。如果它乘以優秀的執行，那麼就值$20,000,000。</p>
<p>那就是為什麼我不愛聽他人的點子。只有當看到它被確實執行下去了我才有興趣。</p>
<cite>—Derek Sivers， 總裁，程序員， <a href="http://www.cdbaby.com/">CD Baby公司</a> and <a href="http://www.hostbaby.com/">HostBaby公司</a></cite>
</div>
<br/><hr/>
<h1>放飛去讓大眾測試</h1>
<h2>在現實使用中測試你的軟件</h2>
<p>讓真人在真實的環境中使用你的軟件，這是無可代替的。取得真實的數據。取得真實的反饋。然後在那些信息的基礎上進行改進。</p>
<p>常規的可行性測試太死板了。實驗室的設置並不能反應現實。如果你站在別人的背後觀察監視，你可能多少瞭解一個方案是否行得通，但人們普遍在攝像機面前無法自然表現。當被別人這麼看時，大家都會很小心地不去犯錯 — 但錯誤卻正是你所要獲知的信息。</p>
<p>相反，在正式軟件中發放beta功能給一些有選擇的用戶。讓他們能同時使用beta功能和已發佈的功能。這樣這些測試的功能就能曝露在真實的數據和流程中。從這你就能取得真實的數據。</p>
<p>另外，不要搞正式版和beta版的遊戲。兩者不應該有區別。另外做一個beta版本只會得到一個輕描淡寫的試用。正式版本，注入一些beta的功能，才能得到全方位的體驗。 </p>
<div class="quote">
<h3>Beta書的發佈</h3>
<p>如果開發者在發佈代碼的時候都很緊張，那麼書的發行商和作者在推出一本書時豈不得嚇死。當一部書付諸印刷時，要做修改是一件無比麻煩的事。（事實上並非如此，但這些和舊技術聯繫在一起的感覺和記憶還瀰漫在行業中。）因此，發行商總是花很大的功夫（和成本）要在書發行前爭取把書做到「對」為止。 </p>
<p>當我寫Agile Web Development With Rails（使用Rail的敏捷 Web 開發）這本書時，很多的開發者有相當明確的需求：我們現在就需要這書 — 我們想要知道更多有關Rails。我也可能從出版商的角度出發。「它還沒完成」，我會這麼說。但來自社區壓力和David Heinemeier Hansson的督促使我改變了想法。我們在書最後完成前兩個月以pdf的格式預先發佈了這書。結果是令人難以置信的。我們不僅賣了很多書，而且得到了反饋 — 許多的反饋意見。我開發了一個自動化系統來攫取讀者發佈的看法，最終得到差不多850個有關錯字和技術錯誤的報告，另有添加新內容的建議。所有這些的解決方案都濃入到最後的書面出版中。</p>
<p>這是一個雙贏的局面：我能提交一個完善了的紙面出版書籍，社區也能及早地得到他們需要的內容。如果你是在一場賽跑競爭中，早些把作品交出去可以爭取更多的追隨者而不是過後引來更多的競爭對手。 </p>
<cite>—Dave Thomas, <a href="http://www.pragmaticprogrammer.com/">The Pragmatic Programmers（《程序員修煉之道》）</a></cite>
</div>
<div class="quote">
<h3>要快</h3>
<ul class="tight">
<li>1. 決定它是否值得做，如果是的話:</li>
<li>2. 盡快去做 — 不需完美，只需做下去</li>
<li>3. 保存。上傳。發佈。</li>
<li>4. 看人們的反應</li>
</ul>
<p>雖然我並不總愛給產品加新功能，但一旦那個值得去做的"yeah!"時刻到來，新的功能一般幾個小時後就能上到網頁上去，有瑕疵但就這麼發佈了，讓用戶反饋來引導下一步的修補工作。 </p>
<cite>—Derek Sivers, 總裁，程序員，<a href="http://www.cdbaby.com/">CD Baby公司</a>和<a href="http://www.hostbaby.com/">HostBaby公司</a></cite>
</div>
<br/><hr/>
<h1>縮短你的時間</h1>
<h2>把它分塊來做</h2>
<p>做幾周甚至幾個月的預期是不現實的。事實上你無法預見那麼遠的將來會發生什麼狀況。</p>
<p>所以，縮短你的時間範圍。把一個時間段分成一個個小塊。把一個12周項目看成是12個周項目。與其去推演一個要花30個工作小時的任務，不如把它們分成更現實的6-10個小時的小任務。然後一塊一塊地去執行。</p>
<p>這個理論同樣適用與其它問題。你是否有碰到一個很大的問題想都想不過來？把它劃分開來想。就這麼一直把問題分成小塊及更小塊直到你能消化它為止。 </p>
<div class="quote">
<h3>小一些的任務和時間表</h3>
<p>軟件開發者是一群特殊的樂觀主義物種：面對放在他們面前的編程任務時，他們總會想，「那不難！花不了多少時間。」</p>
<p>所以，如果給一個程序員3周去完成一個大型任務，她會花兩周半拖拉，然後用一周的時間在編程上。這種不按期執行結果就會造成和預期任務要求脫節，因為每個任務總是會比表面看起來更複雜。還有，誰還記得三周前整個團隊達成的詳細共識是什麼？</p>
<p>給程序員一個下午去編一個小的特定的模塊，她就會有辦法把它趕出來，然後準備進入到下一個任務。</p>
<p>小一些的任務和時間表比較好管理，可以省去一些可能由於繁多產生的誤解，同時你改變主意或重新做的成本也會較小。小一些的時間表可以督促開發者，讓他們更有機會去享受某種成就感，同時不讓他們有更多的理由去想，「哦，我還有很多時間去做那個項目。現在讓我給我iTunes寶庫裡的歌曲評評級先。」</p>
<cite>—Gina Trapani, 網頁開發者，編輯 <a href="http://www.lifehacker.com/">Lifehacker</a>, the productivity and software guide（效率和軟件指南）</cite>
</div>
<div class="quote">
<h3>事實的真相</h3>
<p>下次如果有人硬要你回答一個答案尚未可知的問題 — 不管它是有關一個截止日，一個項目的最終成本，或填滿Grand Canyon（大峽谷）需要多少牛奶 —這類不發生無法知道的問題，你儘管可以從避免空談的角度出發：說「我不知道」。</p>
<p>這不僅遠不會毀壞你的信用，同時能顯示你對下決定的慎重和用心。不要只說些聽起來精明的話。你還需平衡遊戲規則，將問題重整成有利協同合作的對話。通過對你的預期所能達到的效果的逐步明確化的討論，你就能和其他人一起打造一個共識的平台，揭開數字背後的真相。 </p>
<cite>—Merlin Mann, 創造者和編輯， <a href="http://www.43folders.com/">43folders.com</a></cite>
</div>
<div class="quote">
<h3>解決衝著你來的那個問題</h3>
<p>近來我的網絡記憶中最自豪的一件事就是發佈和引進"nofollow（譯者注，一個HTML屬性值）"的態度。沒人事先討論過它。沒有一大堆的會議座談可以讓一些無聊人用來進行其含義和編程本質的爭論。沒有徵求意見的過程，於是不需要把一個簡單的理念做成得花上20行xml的小程序（還得花時間解讀如何用這個程序，最終結果就是不用它，因為我不清楚是否設定在版本0.3或3.3b）。</p>
<p>它簡單，有效，只提供選項給需要的人 — 這對於網絡中不在乎技術規格的框框條條或覺得遵禮節太費時的一群，無疑是非常重要的。</p>
<p>有時，解決後來的20個難題往往不如搞定直衝你來的那一個問題來得有用和審慎。它不僅僅是一個戰勝濫碼的一個小勝利（所有和冗余代碼的鬥爭勝利都不會是大的），而且是對那些熱愛簡潔和迅速的結果並以之為己任的網頁開發者的一個大勝仗。 </p>
<cite>—Andre Torrez, 程序員和副總工程師， <a href="http://fmpub.net/">Federated Media Publishing</a></cite>
</div>
<br/><hr/>
<h2 class="chapter_title"><a name="ch07"></a>組織 <span>第七章</span></h2>
<h1>一致性</h1>
<h2>拒絕分隔</h2>
<p>很多公司將設計，開發，廣告撰寫，支持和營銷分隔成不同的戰鬥單位。雖然專業化有它的好處，但是它創作的環境卻讓員工只看到自己的小世界而不是web應用的整個背景。</p>
<p>盡你所能的，整合你的團隊，這樣才能有一個健康的，反覆的討論貫穿整個流程。建立一個制約平衡的系統。不要讓事情在翻譯中迷失。讓廣告撰寫者和設計者一起工作。支持的疑問一定要讓開發者看到。</p>
<p>更好的情況是，僱用擁有多項天賦的人，他們可以在開發過程中擔任不同的角色。最終的結果是一個更加協調的產品。</p>
<br/><hr/>
<h1>獨處的時間</h1>
<h2>為了讓事情做好，人們需要不被打擾的時間</h2>
<p>37signals跨越4個城市和8個時區。從猶他州的普羅沃到代碼的哥本哈根。我們五個人分隔了8個小時。這8個小時的距離的一個積極的副作用是獨處的時間。</p>
<p>一天中只有四到五個小時我們都醒著並在一起工作。其他的時間，美國團隊在睡覺而David，人在丹麥，在工作。剩下的時間，我們在工作而David在睡覺。這讓我們一天中一半在一起而另一半獨處。</p>
<p>猜猜在一天中哪一部分完成我們完成的工作最多？獨處的那部分。這沒有什麼驚奇的。很多人喜歡的工作時間是清晨或者午夜 — 他們不會被打擾的時間。</p>
<p>如果你有很長時間沒有被打擾，你就能漸入佳境。這個情境是你最有生產力的時間；這個時間內你不必在各種各樣的任務中切換思維；這個時間你不會受到干擾，比如回答問題或者是查找東西，發送郵件或者應答即時通訊。獨處的時區是產生真正進展的地方。</p>
<p>漸入佳境需要時間。這就是為什麼干擾是你的敵人。這就像深度睡眠 — 你並不直接進入深度睡眠，你先進入淺睡眠，然後你會逐漸進入深度睡眠。任何干擾都會讓你從頭開始。<strong>深度睡眠是真正的睡眠魔法發生的地方；獨處的時間是真正的開發魔法發生的地方。</strong></p>
<p>在工作中建立一條規定：一天中一半的時間作為獨處時間。從上午10點到下午兩點，任何人都不可以和別人談話（除了午餐時間）。或者讓一天的前一半或者後一半作為獨處時間。只要保證這個範圍是連續的，為了避免破壞生產力的干擾。</p>
<p>成功的獨處時間意味著趕走交流癡迷。在獨處時間中，放棄即時通訊，電話呼叫和會議。不要打開隨時更新的email程序。只需閉上嘴去幹活。（Just shut up and get to work.）</p>
<div class="quote">
<h3>進入最佳狀態</h3>
<p>我們都知道知識工作者在穩定狀態工作最出色，這種狀態也被稱作「漸入佳境」，他們全神貫注於工作，開足馬力，忘了周圍的環境。他們忘了時間的流逝，在絕對的集中精力下產生了巨大的成果...那番在於這種情境太容易被破壞。噪聲，電話呼叫，吃午餐，需要開車5分鐘去星巴克喝咖啡還有合作者的打擾 — 特別是合作者的打擾 — 都破壞了這個情境。如果你需要花一份鍾處理合作者問問題的干擾，這足以破壞你的集中經歷，那麼你需要花費一個小時重新達到有效率，你的總生產力變得很糟糕。</p>
<cite>—Joel Spolsky, 軟件開發者, <a href="http://www.fogcreek.com/">Fog Creek Software</a><br/>(摘自 <a href="http://www.joelonsoftware.com/articles/fog0000000068.html">這些人從哪裡得到他們(非原創的) 思想?</a>)</cite>
</div>
<br/><hr/>
<h1>會議有毒</h1>
<h2>不要會議</h2>
<p>你真的需要會議嗎？會議經常出現在概念不夠清楚的時候。不要求助於會議，試著簡化概念，於是你可以快速的討論它，通過電子郵件，即時通訊或者Campfire。目標就是避免會議。你避免花費在會議上的每一分鐘是你真正做事情的每一分鐘。</p>
<p>對於生產力的毒性沒有比會議更厲害的了。以下是幾點原因：</p>
<ul>
<li>他們將工作日分解成小的，不連續的片段從而打亂了你的日常工作流程</li>
<li>他們經常是關於詞語或者抽像概念，並非真實的事物（比如代碼片段或者一些接口設計）</li>
<li>他們經常每分鐘傳達非常小的信息量</li>
<li>他們通常包含至少一個笨蛋，輪到他時不可避免的通過無意義的話浪費大家的時間</li>
<li>他們偏離主題比大雪中的芝加哥出租車還容易</li>
<li>他們的議程經常非常模糊以致於沒有人真正的明確他們的目的T</li>
<li>他們經常需要精心的準備但是人們無論怎樣罕能做到</li>
</ul>
<p>在你<em>確實地必須</em> 開會（這必須是一個少見的事情）的時候 , 堅持這些簡單的原則：</p>
<ul>
<li>設定一個30分鐘的計時器。當它響的時候，會議結束。句號。 </li>
<li>邀請盡可能少的人。 </li>
<li>沒有明確議程的時候不要開會。 </li>
</ul>
<div class="quote">
<h3>少開會</h3>
<p>有太多的會議了。放棄那些沒有意義的和沒有效果的會議。只有當需要討論重要的商務議題的時候或者你需要建議，贊同或者一致意見的時候才召開會議。即便如此，不要不加選擇的邀請人 — 不要不必要的浪費人們的時間。</p>
<cite>—Lisa Haneberg, 作者 (摘自 <a href="http://managementcraft.typepad.com/management_craft/2004/09/dont_let_meetin.html">不要讓會議統治你！</a>)</cite>
</div>
<div class="quote">
<h3>分解它</h3>
<p>當子昂目增長的時候，增加人員帶來了減少的回報。最有趣的原因之一就是增加的交流通道的數量。兩個人只需要相互溝通；只有一條簡單的交流途徑。三個人有三條交流途徑；4個人有6條。事實上，交流途徑的增長是指數級的……很快，備忘錄和會議匯佔據整個工作時間。</p>
<p>解決方法是明顯的：把團隊分解成小的，自治的和獨立的小單位以減少這些交流途徑。</p>
<p>詳細的，把程序也分解成更小的單位。既然問題的一大部分起源於相互的依賴（全局變量，函數間傳送的數據，共享的硬件等等），找一個方法分割程序以消滅— 或者減少— 個體間的相互依賴。</p>
<cite>—<a href="http://www.ganssle.com/">The Ganssle Group</a> (from <a href="http://www.ganssle.com/articles/keepsmall.htm">Keep It Small</a>)</cite>
</div>
<br/><hr/>
<h1>尋找和慶祝小的勝利</h1>
<h2>每天發行點什麼</h2>
<p>軟件開發中最重要的就是激勵。激勵是局部的 -- 如果你沒有被你正在做的事所激勵， 機會就沒有應有的那麼好。 實際上，很有可能變得更糟糕。</p>
<p>冗長，滯後的發佈週期是激勵的殺手。 這使得慶祝活動之間間隔太長的時間。 另一方面， 可以慶祝的迅速勝利是極大的激勵動因。 如果你讓冗長的發佈週期壓碎迅速的勝利，就殺死了激勵。 並且這樣也會殺死你的產品。</p>
<p> 所以， 如果你的發佈週期是在一個月以內， 拿出每週一天（或者沒2周拿出一天）對取得的小勝利進行慶祝。 並捫心自問： 「我們可以在4個小時內發佈些什麼？」 ， 然後去實現它。 這可以是</p>
<ul>
<li>一個新的簡單特性 </li>
<li>一個對現有特性的小改進 </li>
<li>為了減低支持負擔，重寫一下幫助信息 </li>
<li>去除那些並不需要的表格項</li>
</ul>
<p>當你發現這些 4小時的迅速勝利時， 你將發現慶祝的理由。 這樣鼓舞了士氣， 增強了激勵 並且 再次肯定了團隊正在向著正確的方向前進。</p>
<br/><hr/>
<h2 class="chapter_title"><a name="ch08"></a>人員配備 <span>第八章</span></h2>
<h1>不需過早招聘太多員工</h1>
<h2>慢慢加人迅速發展</h2>
<p>初期後期都並不一定要壯大隊伍。即使你接觸過100個頂級人才，一口氣把他們全招來也並不是什麼好主意。沒有辦法能讓這麼多人迅速的融入到統一的企業文化中去。你將遭遇令人頭痛的人員培訓、性格不和、溝通不暢、發展方向不同等諸多麻煩。</p>
<p>所以不要隨便招人。真的。不要招人，另想辦法。讓你陷入煩惱的這件事是真正必要的嗎？你不做又會如何呢？能不能用某種軟件或者改變做事方法來解決呢？</p>
<p>ge前執行總裁Jack Welch每次裁掉一個人之後並不會馬上招人來頂替他的位置。他想看看在那個職位和人員空缺的情況下能支撐多久。我們當然不主張用裁人來驗證這個理論，但是我們的確認為Jack的做法有一定道理：你並不需要你考慮中的那麼多人手。</p>
<p>如果沒別的辦法再考慮招人。但是你應該清楚知道你需要什麼樣的人，怎麼向他介紹工作任務，以及具體要他負責解決什麼樣的棘手問題。</p>
<div class="quote">
<h3>Brooks的原則</h3>
<p>給延期的軟件開發項目添加人手只會更加拖延進度。</p>
<cite>—Fred Brooks</cite>
</div>
<div class="quote">
<h3>編程與莫扎特的安魂曲</h3>
<p>一個優秀的程序員在完成單個工作任務時不存在因溝通和分工而產生的額外開銷。而五個程序員坐到一起完成同一個任務的時候必須分工合作，那將花費很多時間……用很多一般的程序員而不是幾個足夠好的程序員將產生的真正問題在於：無論讓他們幹上多久，也絕對沒有優秀程序員幹得出色。五個Antonio Salieris也永遠寫不出莫扎特的安魂曲，哪怕給他們100年的時間。</p>
<cite>—Joel Spolsky, <a href="http://www.fogcreek.com/">Fog Creek Software</a>的軟件開發人員 (摘自<a href="http://www.joelonsoftware.com/articles/HighNotes.html">Hitting the High Notes</a>)</cite>
</div>
<br/><hr/>
<h1>摸底</h1>
<h2>先和候選員工在測試項目中協作</h2>
<p>看作品、簡歷、例程、工作經歷是一碼事，和他在一起工作是另外一碼事。只要有條件，應該和准團隊成員一起去「試試車」。</p>
<p>在聘用人之前，我們會給他們一個小項目琢磨琢磨。我們能從中看出他們怎麼管理這個項目，他們怎樣進行溝通，他們具體怎麼做等等。和他們一起設計或者編寫幾屏代碼能看出很多東西。你能迅速摸清和他們是否心有靈犀。</p>
<p>這種事規劃起來比較難，但即使只能拿出20或者40小時來做也比沒有強。適合不適合都能看得很清楚。如果不適合，先摸清情況能給雙方避免很多麻煩和風險。</p>
<div class="quote">
<h3>小處著手</h3>
<p>從分派一個小的測試任務開始。不要一股腦把你的工作任務都拿出來。給你的新虛擬助理一兩個測試項目來做，看看化學作用如何發生。開始的時候，大家很容易在和和氣氣的氛圍中忽略掉潛在的問題。記住這只是在試車。</p>
<cite>—Suzanne Falter-Barns, 作家和創意專家<br/>(摘自<a href="http://www.promotionworld.com/promotion/articles/findperfectva.html">How To Find And Keep The Perfect VA</a>) </cite>
</div>
<br/><hr/>
<h1>行勝於言</h1>
<h2>根據對開源社區的貢獻選擇潛在的技術人才</h2>
<p>典型的通過學歷、簡歷等方式來招聘技術人員在很多方面都是很愚蠢的。應聘者畢業於什麼學校、學習成績如何真的那麼重要嗎？一份簡歷或介紹信真能信得過嗎？</p>
<p>開源社區是為那些需要招聘技術人員的人準備的禮物。通過開源社區，你可以在很長的時間跨度裡跟蹤某人的成果和貢獻，無論好壞。</p>
<p>這意味著你能以他做過什麼而不是說過什麼來判斷他是否合適。你可以通過考察真正重要的方面來做決定： </p>
<ul>
<li><strong>工作質量</strong><br/>
很多程序員說的時候口若懸河，實際去做的時候卻錯漏百出。通過開源社區，你可以直觀的瞭解這個人的編程技巧和素養。</li>
<li><strong>文化視角</strong><br/>
編程就是做判斷。很多很多的判斷。判斷力遵循於這個人的文化水平、價值觀和觀念。考察候選人在編碼、測試和社區討論（爭吵）中作出的具體決定，看看他在文化上是否和你有共同點。如果沒有共同點，每個決定都將引發一場爭論。</li>
<li><strong>熱情程度</strong><br/>
根據定義，參與到開源項目至少是需要一些熱情的。不然為什麼他要在屏幕前浪費業餘時間？對開源項目的投入程度就能看出候選人對編程的熱衷程度。</li>
<li><strong>執行力</strong><br/>
如果完不成任務，再聰明的頭腦、再合適的文化傾向和再高的熱情也帶不來有價值的軟件。不幸的是，很多程序員都做不到這點。應該去找那些熱忱工作的人。要做比買賣的時候，需要有這樣的人——這個人要把貨帶出門，而且他也願意去做。</li>
<li><strong>社會經驗</strong><br/>
和人一起共事很長時間，一起經歷過緊張和悠閒，一起經歷過起起落落，才能看出他們的真實性格。如果他缺乏教養，沒有社交技巧，把他排除掉。</li>
</ul>
<p>說到程序員，我們只聘用通過開源社區認識的人。我們認為其他任何方式都是不負責任的。我們聘用Jamis是因為我們關注過他在Ruby社區的參與程度和發佈成果。他在前文所述的各個方面都做得很好。不需要次要原因，我們只評判真正重要的——他的工作質量。</p>
<p>不用擔心團隊成員「課外活動」的活躍度帶走他們的注意力和工作熱情。有句老話是這麼講的：如果你想做好一件事，去找你所認識的最忙的人。Jamis 和David兩個都是對Rails 社區有重大貢獻的人，同時，他倆還駕馭著37signals的技術部門。熱愛編程並且能幹活的人就是你真正需要的團隊成員。</p>
<div class="quote">
<h3>對開源社區的熱情</h3>
<p>你最希望從新員工身上看到的就是他對自己工作任務的熱情，而最能看出這點的辦法就是在開源項目中去追溯他的提交記錄。</p>
<cite>—Jarkko Laine, 軟件開發人員<br/>(from <a href="http://www.loudthinking.com/arc/000505.html">Reduce the risk, hire from open source</a>) </cite>
</div>
<br/><hr/>
<h1>尋找全面發展的人</h1>
<h2>選擇能快速學習的多面手，而不是專攻一面的專家。</h2>
<p>我們從來不會用一個信息架構師。那實在太狹隘了。對於我們這樣的小團隊，招技術層面那麼窄的人沒用。</p>
<p>小團隊需要能扮演不同角色的人。你需要會編程的設計師。你需要懂設計的程序員。每個人都應該對怎麼構建信息（無論它指的是什麼）有自己的想法。每個人都應該思路清晰。每個人都需要能和客戶打交道。</p>
<p>而且每個人都需要能」在路上換檔「。要記住小團隊經常需要迅速改變前進方向。你需要有人能持續的調整和學習，而不是故步自封，只會幹一件事。</p>
<br/><hr/>
<h1>熱情是裝不出來的</h1>
<h2>選擇快樂的和技術水平中等的，而不是令人不滿的專家</h2>
<p>熱情，是無法偽裝的。招人的時候，不要認為你需要一個技術大師或者技術名流。他們往往自以為是。一個水平說得過去的快樂員工勝過於愁眉苦臉的專家。</p>
<p>尋找充滿熱情的人；尋找你信任他可以獨立完成任務的人；尋找在發展緩慢的大公司受過折磨，並且渴望新環境的人；尋找為一起去建造你正在建造的東西而感到激動的人；尋找對你所厭惡的事物同樣感到厭惡的人；尋找為入你的伙而感到興奮不已的人。</p>
<div class="quote">
<h3>為提問加分</h3>
<p>留意候選人是否對你的項目提出很多疑問。熱心的程序員總是想盡量去理解存在很多疑點的問題並快速提出可能的解決辦法和改進方案。闡明問題能產生一種認識：項目的做法很多，但基本上取決於你對你的Web應用如何運作的想像。當你深入到細節，你能感覺到這個人是否在文化水平上符合。</p>
<cite>—Eric Stephens, <a href="http://blog.buildv1.com/">BuildV1.com</a></cite>
</div>
<br/><hr/>
<h1>煉字師</h1>
<h2>招文字功底好的人</h2>
<p>如果你在琢磨從幾個人選中挑出哪一個來填補空缺，選文字功底好的那位。無論他是設計師、程序員、市場人員、銷售人員還是其他，寫作技巧都很有用。簡潔高效的寫作和文字編輯能力可以帶來簡潔高效的代碼、設計、郵件、即時信息以及更多。</p>
<p>這是因為要當好寫手並不只是堆砌詞藻。好寫手懂得溝通的技巧，他們讓事情易於理解，他們能站在別人的立場考慮問題，他們知道什麼是可以忽略的，他們思路清晰。而這正是你需要的才能。</p>
<div class="quote">
<h3>條理清晰的頭腦</h3>
<p>好的寫作風格是頭腦清晰的指示器，清晰的頭腦能有條絮地梳理信息和論點，還能幫助（而不是逼著）其他人去理解。這種技巧能滲透到代碼的編寫、口頭表達、即時通信（對於那些遠程協作的人來說），甚至更深層次的職業素養和可靠性等領域。</p>
<cite>—Dustin J. Mitchell, 開發人員 (摘自<a href="http://www.37signals.com/svn/archives2/hiring_tip.php">Signal vs. Noise</a>)</cite>
</div>
<div class="quote">
<h3>有清晰的文字才有清晰的思路</h3>
<p>清晰的文字能帶來清晰的思路。表達它的時候你才知道你對它瞭解些什麼。好的寫作風格也從一定程度上反映出人的性格。讓讀者省事，而不是給自己省事。</p>
<cite>—Michael A. Covington, 佐治亞州立大學計算機科學教授<br/> (摘自<a href="http://www.ai.uga.edu/mc/WriteThinkLearn_files/frame.htm">How to Write More Clearly, Think More Clearly, and Learn Complex Material More Easily</a>)</cite>
</div>
<br/><hr/>
<h2 class="chapter_title"><a name="ch09"></a>界面設計 <span>第九章</span></h2>
<h1>界面先行</h1>
<h2>開始編程之前先設計界面</h2>
<p>很多應用人們在開始做的時候都抱著先編程的心態——那是個壞主意。編程是構建應用的過程中最笨重的部分，也就是說，它改動起來最複雜，成本也最高。做應用應該始於界面設計。</p>
<p>界面設計相對來說是比較輕量級的。一紙草圖修改起來簡單，成本也低。html頁面的設計修改起來或是推翻也比較簡單。修改程序就不是這麼回事了。界面先行可以讓你保持靈活；先行編程則會讓你陷入花費額外開銷的圈套。</p>
<p>界面設計先行的另一個原因是——界面就是你的產品。你向人們銷售的產品正是他們能看到的。如果你最後才推出界面，就會出現缺口。</p>
<p>我們先從界面開始，所以從一開始我們就知道這個應用看上去如何，給人感覺怎樣。在開發過程中，界面將會不斷的改進。合理嗎？易用嗎？是不是解決了手裡的問題？這些問題只有你和真實的界面打交道的時候才能回答。設計優先讓你保持靈活而且讓你能更早地回答那些問題。</p>
<div class="quote">
<h3>開創Blinksale的橙色鋼筆</h3>
<p>當我意識到現有的帳單管理軟件都無法讓我滿意的時候，我決心把我想要的帳單管理解決方案畫出來。我拿出一支橙色鋼筆，因為它是那晚上唯一好用的東西，然後我用了幾小時畫出了75％的用戶界面。我把它拿給我妻子Rachel看，當時她正在燙衣服，我問她：「你覺得怎麼樣？」她微笑著回答：「你真該把它實實在在的做出來。」</p>
<p>接下來的兩個星期裡我重新斟酌了設計，並且做好了當時可能成為Blinksale第一版的大部分靜態頁面。除了那些用橙色鋼筆畫的草圖，我們從來沒有做過其它網格之類的東西。而且直接進入html頁面的設計讓我們一直為項目變得現實起來而感到激動，即使在當時我們並不知道我們正在陷入什麼當中。</p>
<p>html頁面一完成，我們就和開發員Scott一起商量關於Blinksale的想法。已經設計好的用戶界面在好些層面都發揮了非常好的作用。首先，它讓Scott能親眼看到，使他為我們的目標感到激動。它遠遠不止是一個創意，它是真實的。其次，它幫助我們可以精確衡量Scott需要花多長時間和精力才能把設計變成能跑的應用。當你在對一個項目的孵化提供資金上的支持，越早能做出預算越好。界面設計成為了我們在項目初期的評估基準。最後，用戶界面的設計就像一個嚮導，能在我們進一步開發的時候提醒我們這個應用程序的核心目標。當我們臨時決定添加新功能的時候，我們不能簡單地說：「好的，那就加吧！」我們必須回到設計上來，問自己新功能應該放在哪，如果沒有它的位置，它就不該加。</p>
<cite>—Josh Williams, <a href="http://www.blinksale.com/">Blinksale</a>創始人</cite>
</div>
<br/><hr/>
<h1>震中設計</h1>
<h2>始於頁面的核心然後向外延展</h2>
<p>震中設計就是關注於頁面的本質——震中，然後再向外拓展。這意味著，一開始要忽略細枝末節的東西：導航條或者導航標籤、頁腳、用色、邊欄、標識等，從震中著手，先設計頁面中最重要的內容。</p>
<p>頁面賴以生存的是其核心。舉例來說，如果你正在設計顯示博客文章的頁面，那麼核心就是博客文章本身。不是在邊欄裡的文章分類，不是頂部的頁頭，不是底部的評論提交表單，而是實際的博客文章單元。沒有博客文章單元，這就不是一個博客文章頁。</p>
<p>只有當這個單元完成之後你才能開始考慮頁面中次重要的元素。次重要的元素完成之後，你再轉戰第三重要的元素，以此類推。這就是震中設計。</p>
<p>震中設計規避了傳統中 「先搭建框架，再填充內容」的方式。在那種方式裡，人們先建立好頁面佈局，然後把導航條包含進去，然後插入有關銷售推廣方面的東西，到最後才把核心功能——頁面的實際意義所在用來填充剩下的空間。這是本末倒置的做法。</p>
<p>震中設計讓你從一開始就關注於真正重要的部分。先做必需要的，再做其他的。結果是給用戶一個更友好、重點清晰的界面。並且，這樣可以讓你馬上和設計、開發人員展開對話而不是等到頁面所有部分都各就各位之後。</p>
<br/><hr/>
<h1>考慮三種情況下的解決方案</h1>
<h2>常規、初始、錯誤三種情況下的設計</h2>
<p>對於每一個界面，你需要考慮可能出現的三種情況：</p>
<ul>
<li><strong>常規</strong><br/>
一切運行正常的話，人們看到的是一個充滿內容的界面。</li>
<li><strong>初始</strong><br/>
人們第一次使用這個應用，在加入內容前的界面。</li>
<li><strong>錯誤</strong><br/>
有錯誤發生時，人們看到的界面。</li>
</ul>
<p>常規的情況眾人皆知，它將花去你最多的時間。但別忘了也要為初始和錯誤兩種情況花些時間（接下來的文章作更詳細地說明）。 </p>
<br/><hr/>
<h1>初始界面</h1>
<h2>期待一個周到的初次運行體驗</h2>
<p>忽略初始界面的階段是你會犯的最大錯誤之一。初始界面是應用留給人們的第一印象，永遠不會有第二次這樣的機會……這個麼，你應該知道。</p>
<p>問題是，設計界面時，通常是事先用數據填充起來。設計者總是用臨時數據填滿頁面模板，每一個列表、文章、輸入框、邊邊角角里都填上內容。這時候界面看上去很棒。</p>
<p>然而，產品在初始狀態下是沒有內容的。當新人註冊，他們將從初始界面開始。就像是一個博客，用戶需要自己去充實它。而在用戶輸入文章內容、鏈接、評論、日期、邊欄的信息或其它數據前，整體外觀無法成形。</p>
<p>不幸的是，用戶會在初始界面時決定產品是否值得一用——在這個內容和信息最少的階段來判斷產品的適用性。如果你設計的初始界面有缺陷，人們就不知道缺少些什麼，因為他們感覺什麼都沒有。</p>
<p>然而大多數設計者和開發人員仍然認為這種狀況理所當然。他們沒有很多時間為初始界面做設計，因為當他們開發和使用產品的時候，裡面填滿了他們用來測試的數據。他們甚至沒遭遇過初始界面。當然，他們可能也以新用戶的身份登錄過幾次，不過他們主要的時間是沉浸在一個充滿數據的產品裡。</p>
<p>一個有用的初始界面應該包含些什麼？</p>
<ul>
<li>利用它作為添加新手指南和熱門推薦的機會。</li>
<li>給出一個填滿內容的頁面截圖，這樣能讓人們有所期待。</li>
<li>講解如何上手，頁面最終會像什麼樣子等。</li>
<li>回答第一次來的訪客會問到的關鍵問題：這是什麼頁面？我在幹什麼？頁面有內容的時候是什麼樣子？</li>
<li>做好預期準備，幫助減少挫折感、恐懼感和大的迷惑。</li>
</ul>
<p>第一印象太關鍵了。如果沒有設計出周到的初始界面，會為你的產品或服務留下反面的（錯誤的）印象。</p>
<div class="quote">
<h3>沒有第二次機會……</h3>
<p>我覺得蘋果OS x操作系統的界面中另一個深受Steven Jobs影響的是安裝和初次運行的體驗。我想Jobs一定深深理解到第一印象的重要性……也許Jobs在考慮初次運行的體驗時會想，它可能是一個用戶對電腦上千次用戶體驗中的一次，但是它將是最重要的千分之一，因為它是一千次中的第一次，人們對它寄予了期望並形成初步印象。</p>
<cite>—<a href="http://daringfireball.net/">John Gruber</a>, 撰稿人和開發人員 (摘自 <a href="http://www.guidebookgallery.org/articles/interviewwithjohngruber">Interview with John Gruber</a>)</cite>
</div>
<br/><hr/>
<h1>做好防禦</h1>
<h2>出錯時的設計</h2>
<p>我們得承認：在線上的程序總有出錯的情況。無論應用設計得多麼用心，無論做了多少測試，用戶仍然會遇到問題。那麼如何處理這些不可避免的故障呢？做好保護性設計。</p>
<p>保護性設計就像是在小心駕駛。和司機在行車時必須留意道路是否打滑、魯莽的司機以及其它危險情況一樣，網站建設者們必須不斷尋找會造成訪問者困惑和不滿的故障點。好的保護性設計能決定用戶體驗的好壞。</p>
<p>關於保護性設計的內容我們可以單獨寫成一本書。實際上，我們已經寫了。這本叫《網站的保護性設計》的書對於想學習如何改進出錯界面和其他故障點的人來說是非常好的資源。</p>
<p>記住：你的應用可能90％的時間都運行良好。但是如果在用戶需要幫助時置之不理，他們是不會忘記這一點的。</p>
<br/><hr/>
<h1>應用環境勝過一致性</h1>
<h2>這裡有意義的那裡不一定有意義</h2>
<p>動作是使用 按鈕 還是用 鏈接 來實現 ？ 這取決於那個動作。 一個日曆視圖是應該使用列表方式還是表格方式實現？這取決於 它要用在哪裡 並且 要顯示多長的時間。 全局的導航鏈接是否需要出現在每個頁面上 ？ 是否每個地方都需要一個全局的搜索條 ？ 否在每一頁上需要一個完全相同的頁腳？ 答案是「這取決於應用環境」 。</p>
<p>這就是應用環境比一致性重要的原因。 如果你的設計在那種狀況下有意義， 不一致也沒有什麼大不了的。 只給人們重要的。 給他們所需要的，並且去掉其不需要的。 比保持一致性更好的是保持正確。 </p>
<div class="quote">
<h3>聰明的不一致</h3>
<p>一致性不是必不可少的。 很多年來， 學習用戶界面和用戶交互的學生都這樣被教導，界面中的一致性是界面設計中的核心守則之一。也許這在軟件中成立，但是在Web上，這不對。 Web上真正重要的是，在每個獨立頁面，用戶是否能夠快速、簡單地前進到流程中的下一個步驟。</p>
<p>在 「好的創新」 （Creative Good）, 我們把這叫做「聰明的不一致」 ： 確保流程的每個頁面都給用戶提供他在流程中的那個位置所真正需要的東西。 只因為了和網站的其它部分保持一致，加入多餘的導航因素，是很愚蠢的。</p>
<cite>—Mark Hurst, <a href="http://www.creativegood.com/">Creative Good</a> 以及<a href="http://www.goovite.com/">Goovite.com</a> 的創辦人 <br/>(摘自： <a href="http://www.goodexperience.com/blog/archives/000028.php">頁面範式</a>)</cite>
</div>
<br/><hr/>
<h1>文案也是界面設計</h1>
<h2>每個字母都重要</h2>
<p>文案也是界面設計，偉大的界面是寫出來的。 如果你認真考慮每個像素，每個圖標，每個字體， 那麼你要相信每個文字都是至關重要的。 當你寫界面時，要常常要設身處地的為閱讀你的界面的人著想。 他們需要瞭解什麼？ 你怎樣才能簡潔明瞭地闡述 ？ </p>
<p>你標注一個按鈕的名字是 提交 還是 保存 或者 更新 還是 新建 或 創建 ？ 這就是文案。你是寫3句話還是5句？是用一般的舉例說明，還是詳細闡述？ 如何標注新內容？是 『新增的』 還是 『更新的』 抑或是 『最新更新』 還是 『修改的』 ？ 是使用：『新消息： 5』 還是 『5個新消息』？是 『5個』 還是 『五個』 ，是『5個消息』還是『5個帖子』？ 所有這些都很重要。</p>
<p>你也需要和你的讀者講同樣的語言。 只因為你寫的是一個Web應用，這並不意味著你可以使用技術行話。想想你的客戶，想想這些按鈕和詞語對其意味何如。 不要使用縮寫 或者 大多數人不懂的詞語。 不要使用內部隱語。不要聽起來像一個工程師和另一個工程師的談話。 保持簡短和親切。 說你要說的，別說廢話。</p>
<p>好的書寫就是好的設計。 界面用詞和設計要相輔相成，這很少有例外。 圖標要有名字， 表單項要有示例， 按鈕要有標籤，流程要有一步一步的指示， 退款政策也要有一個清楚的說明。這一切都是界面設計。</p>
<br/><hr/>
<h1>統一界面</h1>
<h2>合併管理功能到公共界面</h2>
<p>管理界面—就是那些用來管理選項，人員等的屏幕界面。—看起來很低劣。這是因為大多數時間都花在了對公共界面的設計上。</p>
<p>為了避免 這種 低劣管理界面 的併發症， 不要分開去開發系統管理界面。 而要把管理功能（例如，編輯，增加，刪除）嵌入到應用界面開發中。</p>
<p>如果你必須維護2套分開的界面（如： 一個一般用戶用，另一個管理員用）， 這2個都會很難受。 實際情況就像同一個稅你交了2次。 你強迫自己重複 並且 這還意味著事情變麻煩的機會大大增加。</p>
<div class="quote">
<h3>拒絕分離的界面</h3>
<p>應用軟件就是全部。 所有可以被改變的，增加的 或者調整的，都應該直接通過應用的管理區域完成。這使得我們能精確感知我們客戶的需要，從而通過解決他們的問題和疑問來幫助他們。 我們的客戶也不必擔心，必須登入分開的界面來完成不同的工作。一分鐘前，他們也許在處理和客戶的約會，隨後一分鐘他們也許要添加新僱員。他們不會為了在不同的應用間跳來跳去而煩惱，通過一個統一的界面，他們能夠很快的適應這個應用軟件。</p>
<cite>—Edward Knittel, <a href="http://www.kennelsource.com/">KennelSource</a>銷售和市場部總監</cite>
</div>
<br/><hr/>
<h2 class="chapter_title"><a name="ch10"></a>代碼 <span>第十章</span></h2>
<h1>更少的軟件(Less software)</h1>
<h2>讓你的代碼盡可能簡單</h2>
<p>你或許認為代碼量加倍軟件複雜性也相應加倍，但實際上，<strong>每增加一些代碼，軟件的複雜性就隨之指數式增長。</strong>代碼的每一點增加，每一點改動，每一個相依性，每一個前指性（Preference) 都有著聯動效應。輕率地增加代碼，不用多久，你就會造出一個可怕的大稀泥巴。</p>
<p>對付複雜性的辦法就是更少的軟件。更少的軟件意味著更少的特徵（features），更少的代碼和更少的浪費。</p>
<p>關鍵在於將每一個困難的問題（要求很多的軟件）重新描述成一個簡單的問題（要求少得多的軟件）。你解決的問題也許不是和原先百分之百一樣的問題，那也沒關係。用20%的努力解決原先問題的80%就是一個很大的勝利。原先的問題幾乎從來就沒有糟糕到值得花5倍的精力去解決。</p>
<p>更少的軟件意味著撇開水晶球。處理今天面對的問題而不是預測未來的問題。為什麼？對明天的恐懼常常是毫無結果的。不要讓幻想的問題把你拖住。 </p>
<p>從一開始，我們就將產品的設計基於更少軟件的概念。只要可能，我們就將問題簡單化。我們發現，對簡單問題的解決方案不僅更容易實施和支持，也更容易理解和使用。這都是我們用來區別於競爭對手的做法的組成部分。我們造的產品要做更少，而不是做更多。</p>
<ul>
<li>軟件越少，管理越易</li>
<li>軟件越少，代碼就越少，維護就越少（員工更快樂）</li>
<li>軟件越少，改變的代價就越低，適應也更快，改變主意也無需更改如山的代碼 </li>
<li>軟件越少，臭蟲越少 </li>
<li>軟件越少，支持越少</li>
</ul>
<p>決定哪些特徵包括進去，那些特徵拒之門外，這也和更少軟件相關甚密。不要怕對難以實現的特徵說不。只要不是必不可少的基本特徵，就不要包括進來。這樣既省時省力，也減少混亂。</p>
<p>同時也要慢下來。把一個主意丟在一邊，平靜一個星期後，再看看這是否還是一個好主意。這額外的醞釀時間，常常會讓你想出一個更簡便的解決方案。</p>
<p><strong>鼓勵程序員提出反建議</strong><br/>你想聽到："你建議的方法要花12小時，但我這樣做只需1小時，它不做x，但它做y。"讓軟件推你回來。告訴程序員用他們認為最好的方法去戰鬥。</p>
<p>還有，尋找可以避免編寫更多軟件的途徑。用屏幕文字的方式建議用戶繞道而行，從而避免對於軟件模型的更改。比如，建議用戶上載指定尺寸的圖片，而不是在服務器端作圖像處理。</p>
<p>對你的應用（app）中的每一個特徵，問問自己：有沒有不需要這麼多軟件的方法來加進這個特徵？只寫需要的代碼，不多不少。你的應用將會更簡練而健康。</p>
<div class="quote">
<h3>沒有任何代碼比沒有代碼更靈活</h3>
<p>好軟件設計的"秘密"不在於知道在代碼裡放什麼，而在於知道代碼裡不放什麼！這在於辨認出硬點和軟點在哪裡，還知道哪裡該留下空間而不是試圖塞進更多的設計。</p>
<cite>—Brad Appleton, 軟件工程師<br/>(摘自 <a href="http://bradapp.blogspot.com/2005/02/there-is-no-code-that-is-more-flexible.html">There is No CODE that is more flexible than NO Code!</a>)</cite>
</div>
<div class="quote">
<h3>複雜性和大小不成線性比例</h3>
<p>打造軟件最重要也是最鮮為人知的規則：複雜性和大小不成線性比例…… 2000行的程序比1000行的程序要用多於兩倍的開發時間。</p>
<cite>—<a href="http://www.ganssle.com/">The Ganssle Group</a> (from <a href="http://www.ganssle.com/articles/keepsmall.htm">Keep It Small</a>)</cite>
</div>
<br/><hr/>
<h1>為快樂而優化</h1>
<h2>選擇能讓你的團隊歡欣鼓舞的工具</h2>
<p>快樂的程序員也是多產的程序員。這就是我們為什麼要為快樂而優化。你也應該這樣。不要單憑行業標準或性能指標來選擇開發工具和開發方法。看看無形的東西：這其中存在激情、驕傲和精湛技藝嗎？每天8小時在這樣的環境下工作真的會快樂嗎？</p>
<p>這一點在選擇編程語言上尤為重要。儘管與公眾看法相悖，編程語言並非個個生而平等。雖然幾乎每個語言都能寫出幾乎每一個應用，對口的那個（the right one）不僅僅是讓你的努力成為可能和可以忍受，而是讓你覺得愉快和充滿幹勁。這都是為了使得每天工作的小小細節快樂有趣。</p>