【转】Getting real

【转】Getting real

刚才偶然看到的，

这本小书是37signals公司写的，一家小公司，没听说过36signals吧，哈哈，

但你一定知道ROR，震惊的是，ROR就起源于这家小公司。。。

小书一本，完整的章节请看 http://gettingreal.37signals.com/GR_chn.php

 节选：

首要任务 chapter 4

什么理念才是伟大的

通过亲切友善和人性化来把自己和大公司区分开来

竭尽全力将你的软件定位在一个点上。你的软件代表的是什么？它到底是有关什么的？在你开始设计或写任何代码之前你必须清楚地知道你做这个产品的目的 — 它的前景。把理想放大些。为什么要有它？它和其他类似产品不同的地方在哪里？

这个理念会引导你的每个决定，指引你不偏离航线。任何时候有比较出格的举动时，问自己，“我们是不是还在坚守着自己的理念做事？”

你的理念必须是简洁的。应该一句话就能把想法传达到。以下是我们每个产品的理念：

• Basecamp : 项目管理即是沟通
• Backpack : 把生活中的凌乱归整
• Campfire : 用及时通讯软件来开展团体交流太逊了
• Ta-da List : 和及时贴便条做斗争
• Writeboard : 用不着麻烦微软的WORD

举个例，我们Basecamp软件的理念是，“项目管理即是沟通”。我们强烈的感觉到对一个项目的有效沟通是引导一系列责任，参与，投资和能量的关键。它把大家统到同一个目标上来增强共识。我们清楚地知道如果Basecamp能做到这点，那么其他事情也就会一一水到渠成。

这 个理念引导着我们尽可能地保持Basecamp的透明性和开发性。我们不把沟通局限在公司内部，相反我们向客户敞开。我们不考虑太多权限地问题， 相反我们更鼓励各方的参与。就是这个理念使我们放弃了图表，表单，报告，状态分析和电子表格的功能，相反的我们专注在优先问题的沟通上，如果每日新信息， 评论，该日备忘项目和文件的共享。把有关你理念的重大决定做在前面，将来其他小的决定就会变得容易多了。

白板上的哲理

有一次Andy Hunt和我编写一个借记卡的交易开关。有一个要点就是同一个交易不许向用户的借记卡二次收费。也就是说，不管操作过程中怎样出错，错误都只能发生在交易最终产生前，不能允许出现重复的交易。

因此，我们在共享信息的白板上用大字写下：要从客户角度出发，容许客户犯错误的可能。

还有其他大约半打多类似这样的信条，在我们创建一些复杂的产品，需要下有技巧性的决定时，这些信条给我们指引了方向。它们使我们的软件有强大的内部凝聚力和外部的统一性。

 节选

在初期时忽略细节

先粗后细

我们太过痴迷于细节。

• 两个原素之间的留白空间
• 完美的首个字母大写字形
• 完美的颜色
• 完美的用词
• 代码只能四行长，不能七行
• 90%与89%之差
• 760px与750px之差
• $39/月与$49/月之差

成功和满意来自于细节

然而，细节中并不只有成功。细节中你还会遇到停滞不前，意见不合，无数的会议和延迟。这些东西会掩煞你的信念，降低你成功的几率。

你可有常常一整天被困死在一个设计原素或一个程序代码上？可有不时觉得你今天的进展实在算不上什么真正进展？过早专注于细节就会导致这些结果。要做完美主义者有的是时间。但不是现在。

别在第一周就担心标题字体的大小。不需要在第二周就搞定什么是最佳的绿色的色调。更不用在第三周就要把“提交”按钮向右移动三个像素。先把该放的东西放上去。然后去用它。保证它是可用的。最后才去把它调整到完美。

细节是在你使用的过程中才会显露出来的。只有在使用中你才能看到什么需要进一步关注。在使用中你才会感到缺了些什么。常常走路绊倒脚你才会清楚地上什么坑洼是需要填补的。那些是当你被迫要留意的时候才需要的细节，不是一想到细节就去搞定它。

魔鬼隐藏在细节中

在选修了几堂绘画课后，我彻底摆脱了“马上投入到细节中”的态度...如果你一开始就画细节十有八九出来的画作会不怎么样。事实上，从你一开始那么做就完全错了。

你 必须一开始把全局的比例分配搞对。你要从最大的一块着手，慢慢过渡到最小的。草稿必须体现模糊的主题。然后你着手润色，使整体画作具有生命力。着 色先从浅，中，深三个色调下手。这么一来你的草稿就会有明暗了。接下来，在你画作的其他部分都要秉持三个色调的应用原则。如此反复直到整体成型...

永远，都要从大到小去做。

— atrick Lafleur, Creation Objet Inc. (摘自 Signal vs. Noise )

 

 

 节选

当问题成为问题的时候才去担心

不要把时间浪费在还未成为问题的问题

你真的的需要考虑当用户到达10万以上的时候会出现的问题吗？它可能已经是两年以后的事了。

如果你现在只需要三个程序员你真的有必要雇八个吗？

你难道真的马上需要12台高端服务器即使两台就足以让你顶一年？

就先掠过吧

人 们总是预先花很多时间在还不知道会不会发生的问题上。靠，我们推出Basecamp的时候还不知道如何向客户收费！因为产品是月付费的，我们知道 还有30天的时间来搞定付费方式。我们把预先省下的时间用在解决更紧急的问题，直到产品推出后，我们才着手付费问题。结果很顺利（它迫使我们用最简单的解 决方案，没什么花哨的东西）。

别整天操心还没成型的麻烦。别过度开发一个产品。到适当的时候再添加硬件和系统软件。如果进度推迟了一两个星期，别担心，还没到世界末日。只要诚实: 解释给你的客户听，说你们正经历着成长的烦恼。他们也许不会因此无比感动，但他们起码会赞同你的坦诚。

关键是: 如果你已经掌握了你需要的信息就及时做决定。这样你就能把注意力集中到需要马上解决的问题上来。

 节选

从说“不”开始

不轻易实现功能

构建部分而不是残缺不全的秘诀是说不

每一次你对一个功能说yes时，你正在收养一个小孩。你必须带着你的孩子通过一连串事件（例如设计，实现，测试等）。一旦这个功能出现了，你就被拖住了后腿。尽量为客户少发布一个功能，再看客户是否愤怒地离开。

不要成为 yes-man

不轻易实现每个功能。让每个功能证明自己，并且表明自己是生还者。这就像"Fight Club."。如果那些功能就像为了进来在走廊苦候了三天，你只考虑他们。

这 就是为什么你从说不开始。每一个向我们提出的 — 或者我们自己提出的 — 新功能需求都遇到一个 NO 。我们倾听但是不采取行动。最初的回应是“不是现在”，如果一个需求或者功能不停的过来，我们知道才是时候对它进一步观察。那么，只是那么，我们才开始考 虑实现这个功能。

当你不采纳他们的功能建议时，你如何回复他们的抱怨呢？首当其冲的是，你要提醒他们为什么他们喜欢这个应用。“你喜欢它因为我们说NO。你喜欢它因为它没有做其他100件无关紧要的事情。你喜欢它因为它不试图始终讨好任何人。”