德正仁和,倔强生长
希望您已经跃跃欲试,急不可待地在您的软件上开始 Getting Real。但是想用最少的资源来创造伟大的软件,决不是那么简单。您需要有正确的点子、激情、时间与能力——决定着您最终所能达到的高度
明知快速升级迫近,使你在发布前把精力集中放在最关键的部件。 与其试图加入更多东西,不如开始真正完善核心功能群。 那么你就可以在真实世界推出产品。 一旦它在那里了,你可以开始收集客户的反馈意见,你就会知道其后的哪些方面需要注意
避免在你的客户和研发/设计之间竖起一堵墙。 不要把客户支持外包给呼叫中心或第三方。而是自己来做。 你,和你的整个团队,应该搞清楚客户的意见。 当客户烦恼时,你需要知晓。你要听他们的抱怨。你也要因此烦恼。
为了闹出个大动静和引起期待, 学学好莱坞风格的运作: 1) 挑逗 , 2) 预演, 3)上演
我们希望人们来体验我们已经完成的产品、界面和有用的东西。一旦他们着迷了,就更有可能升级到一个付费产品(付费产品提供更多的项目或页面,让人们获得更多的功能,比如:文件上传和ssl数据加密)
当你刚开始构建时,你知道的是最少的。而做得越多,用得越多,你才能了解得越多。这才是你应该做出决定的时候——即当你有足够多信息,而非信息少的时候。
你或许认为代码量加倍软件复杂性也相应加倍,但实际上,每增加一些代码,软件的复杂性就随之指数式增长。 代码的每一点增加,每一点改动,每一个相依性,每一个前指性(Preference) 都有着联动效应。轻率地增加代码,不用多久,你就会造出一个可怕的大稀泥巴
界面设计相对来说是比较轻量级的。一纸草图修改起来简单,成本也低。html页面的设计修改起来或是推翻也比较简单。修改程序就不是这么回事了。界面先行可以让你保持灵活;先行编程则会让你陷入花费额外开销的圈套
不要随便招人。真的。不要招人,另想办法。让你陷入烦恼的这件事是真正必要的吗?你不做又会如何呢?能不能用某种软件或者改变做事方法来解决呢?
尽你所能的,整合你的团队,这样才能有一个健康的,反复的讨论贯穿整个流程。建立一个制约平衡的系统。不要让事情在翻译中迷失。让广告撰写者和设计者一起工作。支持的疑问一定要让开发者看到。
做少一些功能,跳过一些细节,如果一些捷径能加快软件进度就大胆用,这些都是OK的。当你做下去的时候,你会对下一步的方向有更准确的把握。太多的故事,建模,甚至HTML演示都是比较虚的构想。一个运作着的软件是真实的
专注于真正必须的。好点子可以尽量坦白。摆出产品应该成为什么样的任何点子,然后砍掉一半。减少功能直到只剩下最必要的功能。周而复始
竭尽全力将你的软件定位在一个点上。你的软件代表的是什么?它到底是有关什么的?在你开始设计或写任何代码之前你必须清楚地知道你做这个产品的目的 — 它的前景。把理想放大些。为什么要有它?它和其他类似产品不同的地方在哪里?
当真理应用到Web技术的时候,改变必须是简易和低廉的。如果你不能如飞一样的改变,你就会败给能够做到的竞争者。这就是你需要追求更小质量的原因
做少。靠做得比对方少来打败他。解决简单的问题,把繁复困难棘手的问题留给大众。不做更多,相反的我们做的更少。不赶超,相反的我们试着退一步,守后
Getting Real-引言
小西, , 思维革命, Getting Real, 0想构建一个成功的Web应用么? 那么正是时候Getting Real. Getting Real 是一种更小规模,更快速,更高质量的软件构建方法