产品规划的概要说明

最近有朋友向我咨询，说自己是一个新入行的产品经理，自己的职责也比较明确了，但是感到还是无法下手，主要就是搞不清楚产品设计的流程，不知道从什么时候就是开始，什么时候就是结尾，我当时也无法说清楚，只是答应下来我会想一想，看如何才能比较准确的说明这个问题，这段时间工作比较忙，虽然想的差不多了，但是一直没有记录下来，今天恰好有些时间，就抽空写了出来，供各位新入行的朋友参考。

以下的说明都是我工作中的个人经验，切不可当成理论知识，仅供参考。 其实说到产品设计流程，我感觉不如从一个产品的规划周期说起，其实整个产品设计流程就是包含在这个周期当中的，理解了这个周期，那么具体在设计过程中就能明白自己应该担负的责任和工作范围。

产品周期一般分为五个阶段：

1 概念化阶段：这个阶段主要是提出一些产品概念，市场需求，对于产品而言，仅仅是一些描述而缺乏具体的量化指标，但是这个阶段是周期的基础，只有积累一定量的需求，才能为产品经理的具体工作提供依据。

在这个阶段中，产品经理主要是负责提出概念和进行概念表述，描绘一个产品的轮廓，让相关部门和高层接受这个概念，得到支持和资源分配。 这个阶段可以分为两个步骤：市场数据获取和需求分析。

出现的成果主要为：《市场需求反馈记录》和《需求分析报告》

2 产品化阶段：这个阶段主要是对概念进行图纸化和量化，设定产品指标，形成可设计的功能和产品原型，并且通过公司认可，纳入公司产品开发计划中。 在这个阶段中，产品经理主要是负责对产品进行量化的工作，量化的内容应该包括产品功能，产品模型，开发进度，所需资源。

这个阶段可以分为三个步骤：市场沟通，产品设计和计划确认。 出现的成果主要为：《产品设计文档》，《产品开发计划》和《产品立项单》

3 技术化阶段：这个阶段主要是把图纸化的产品原型进行物理化，依据产品设计文档开发出具有实际操作价值的实物（这里的实物是指可以实现具体功能的物理载体）。

在这个阶段中，主要依靠研发生产部门进行，产品经理的职责就是协调各种资源，全力保障技术化阶段能够按照产品开发计划进行。

这个阶段可以分为两个步骤：产品开发和产品验收 出现的成果主要为：可交付的产品和《技术》

4 商品化阶段：这个阶段主要是把交付的产品形成具有销售价值的商品，就是对该产品进行商业化包装，这个包括两个部分：内涵商业化和外延商业化。

内涵商业化是指对产品本身进行的商业化过程，比如产品说明书，销售手册，包装元素等； 外延商业化是指促进商品销售的元素确定过程，比如媒体准备，软文准备，渠道准备等。

在这个阶段中，产品经理的主要职责就是负责内涵商业化的整体过程，协助销售部门完成外延商业化的过程，完成产品发布。

这个阶段可以分为两个步骤：商业化和产品发布

出现的主要成果为：可销售的产品和产品发布，以及大量的商品化元素。

5 市场化阶段：这个阶段主要就是跟踪产品发布后的销售进度（我习惯于跟踪3个月），积极推动销售部门完成销售任务，并随时了解销售反馈，进行记录，调整产品在一个产品年度的策略，并对产品的下一步发展提供依据。 在这个阶段中，产品经理的主要职责就是和销售部门进行沟通，协助解决销售过程中遇到的产品问题。

这个阶段可以分为两个步骤：产品跟踪和产品总结

出现的主要成果为：预定的销售渠道完成和销售反馈记录

一般的产品规划周期就是由这五个阶段组成的，在进入到市场化阶段后，其实就可以进入到第一个阶段中了，产品规划的周期本身就是一个螺旋史式发展的过程，从概念开始，逐渐完成一个完成产品的周期，其中包含了多个这样的产品规划周期，而产品经理作为产品的全程参与者，其责任将大大超出横向部门的职责范围，其重要性和不可替代性也是显而易见的，我们可以看到，在那些产品经理体系建立比较完善和重视的企业，其产品的市场感知度相当强烈，产品的市场替代能力也非常强，从而也推动了企业的产品创新能力和开发能力。

我记的有人曾不解的问“你们产品经理到底是干什么的？感觉你们什么都干，但又好象什么都得依靠其他部门！但是好象还没有什么权利，都得靠和人家说好话来进行”

我笑了，我说“产品经理就是一个产品的父亲，虽然能够主导产品是什么样子，但是还得依靠他妈不是！再说了，你看见现在有几个当爹的在家里有权的！”

11:18 | 固定链接 | 评论 (2) | 引用通告 (0) | 记录它 | 产品经理

固定链接 关闭

http://spaces.msn.com/members/eyoungzhang/Blog/cns!1psOyCMptlQn_4oAm76O0JYA!144.entry

微软公司的产品生产管理经验

微软公司如何去做一个软件产品呢？

产品，最初来自一个大家认同的好主意

就D在瑞特蒙得园区数年来的经验而言，对一位高级软件设计师来说，任何一个研发新产品的设想与建议都是受公司鼓励的，哪怕一时还没有用。如果你又能纠集几位与你差不多的同事认同你的设想，同时也能在公司整个市场战略中找到你设想产品的位置的话，你拿到预算经费的可能性已经很大了。

一个好主意当然也要来自群众。因此，在早期的微软，每隔一段时间，便会将小组内全体人马集中到\"与世隔绝\"的风景名胜之地。好吃，好喝，好玩，然后便\"胡思乱想，畅所欲言\"。每个人都要求到台上来畅想一番，你心中的产品应该是个何等模样？其目的无非是一个：集思广益。好主意，当然是\"宁肯错抓一千，不可放过一个\"，有过此种经验的微软人都会对这种极认真的\"玩\"记忆犹新。

一个好的产品，起始于一个好的Spec

光有一个好主意不足以使你心目中的产品形象化，更不能组织生产。虽然有几个同事认同了你的主意，但你还必须把你的产品是什么东西，向方方面面交待清楚。也就是说，你要开始做你的Spec。

Spec是英文Specification（软件详细加工说明书）的缩写字头，行内人已习惯只说这前四个字母。反正，越简单越好。

一个完善的Spec是美国任何一个大型软件项目最为重要的一步。这在美国软件业同行中恐怕也是全民共识。就如同你要造一辆汽车，总要先把一张张蓝图一丝不苟地画清楚。不过，也有相当一部分软件工程师在动手做自己想做的软件项目时，并不真的从写Spec开始。比如D吧，直到加入微软前，都没写过Spec。那时候，D所编写的大多是功能单一的程序。一般是搞明白了每一个程序的输入输出要求，便动手干起来再说。边写边改，十分灵活。一个程序跑通了，结果出来了，也就大功告成了。今天，就算在美国大学里或某些科研机构中，许多人也还是这样做。但程序一大，或者作为一个工业产品，这种干起来再说的办法显然不行了。

实际上，做软件又不同于造汽车。汽车必须一辆一辆地造。软件却只要做一套，如果想批量生产，压拷贝就可以了。有过十几年的软件生涯，在微软又浸泡过几年之后，D倒是觉得，做一项软件工程可能更像拍一部电影。而Spec则更像是拍电影用的剧本，一剧之本。

到东京去出差，D曾有机会读过日本人为某个软件项目写的Spec。在这一套Spec中，对该软件产品应该包含的一切，事无巨细，一一定义罗列。计划中的每一个文件与函数都用自己定义的伪语言（一种接近自然语言的算法语言）写出来了。翻着翻着，D便想，虽然按这本Spec来写程序的程序员，理论上只需将函数中一行行伪码，用写程序时的真实电脑语言置换一下就可以了。

但是，其一，程序员一定少不了那种被牵着牛鼻子走的无可奈何的感觉；

其二，编写这样一本详细的Spec，几乎相当于用伪码将这个软件写了一遍。这样做，不是将直接写软件会遇到的问题转移到写Spec中来了吗？效率高吗？这个Spec肯定要用极

大的努力去写。日本人的确是在拿做汽车的精神在做软件。日本人有他们的道理与风格。

但在D看来，一个好的电影剧本,有一个故事，有一系列人物和一系列故事发生与展开的时间地点等场景。但在电影的拍摄过程中，从一部电影文学剧本到一部电影，又给导演、演员、摄影、音乐服装等留下了许多发挥的余地与创造的空间。

就像一个好的剧本一样，软件的Spec也是从一系列Features（功能，特色）开始的。Feature这个字应该是指，软件包括哪些功能与特征、软件将要做哪些事情、事情与事情之间的关系、事情与软件用户间的关系。功能多少有点像剧本中的故事与人物。

有了功能的准确定义与描述，接着要设计用户如何使用这些功能。即，你的软件会涉及哪些输入输出设备，比如鼠标、键盘、电脑屏幕与打印机。这就又涉及到，软件产品的各种功能在这些设备上的所有可能的表现形式，在软件业内习惯称为界面①。也就是说，软件用户为了使用这些功能，与这些功能交流对话时用的界面。界面的设计，关系到软件产品是否方便使用，是否通情达理，善解人意。界面反映了你的软件是否具备某种人性。打开PC的电源，你在电脑屏幕上看到的一个又一个画面，就是Windows最开始的界面。从一个电影剧本的角度看，界面多少有点类似故事与人物活动时的场景。

过去的20年，年复一年，电脑的界面发生着巨大的变化！在20世纪70年代初，电脑的输入手段只限于拨盘开关、穿孔卡片与纸带，最豪华的装备也不过是台电传打字机罢了。输出设备只有一台宽行打印机或者绘图仪。电脑的CRT终端还只能算大型机上尚未普及的奢侈品。因而，\"界面设计\"从来都没有成为一个软件设计中的主要问题。那时开发人员主要的注意力都在算法上，他们要考虑如何用小得可怜的机器内存与慢得让人焦急的CPU来完成计划中的工作。80年代，图形屏幕终端开始普及，界面设计提上了日程。一门新的学科，软件心理学也随之诞生。今天，在已走进千家万户，甚至人们衣服口袋中的各种电脑中，商业软件的界面已变成了软件设计中举足轻重的一个部分。

功能与界面设计这两个过程，并不一定需要电脑编程人员介入，就如同写剧本并不一定要有导演和演员参与一样。功能与界面设计，甚至无须电脑专业的人员介入，但设计人员要对该软件所应用的领域有充分的了解，对该领域如何使用电脑要有充分的想象力与创意。设计人员还须对市场上已有相关产品胸中有数，并找准自己的设计在市场上的位置，扬长避短。这其中也应包括了对正在设计的软件与其他市场上同类软件是否\"兼容\"的一系列技术上与商业上的考虑。公司大到如微软，设计人员还需要具备一定的人际交流与协调能力，使自己的设计得到市场上大部分同业厂商中潜在的同盟军与合作者认同的能力。

功能与界面的设计完成之后，才是Coding设计开始之时

完成了上述过程，接下来的设计工作要交给软件工程师来做了。这有点像电影开拍前还需要准确的分镜头剧本一样。工程师们现在要设计和制定一个技术规则了。这个技术规则包括，采用哪些软件技术，用什么样的软件工具语言，在一个什么样的环境与平台上，如何将整个项目分割为一块块的子任务，详细的子任务清单等等细节。这个过程当然也要强调想象力与创造性，但更重要的是技术上的可行性，子任务间相互配合与协调的高效率，以及完成整个功能与界面设计的准确与无误。

一方面，照这样做出来的Spec，对每一个子任务如何完成并未给出更详细的约束。另一方面，所有的界面，与产品应该包含的功能，都通过演示程序在电脑上实时演示过了。设计中的问题，也通过这些演示看得清清楚楚了。在你的产品设计真正定稿之前，以上过程会反复几次。这是公司里产品研制过程中最民主的阶段。全体人员\"没大没小\"，\"横挑鼻子竖挑眼\"，畅所欲言，直到大部分同仁认可为止。

以上步骤，是D在微软公司工作时，完成一个软件工程Spec的过程（如果更详细的话，就要变成专题论文了）。到此为止，产品已经是看得见摸得着的东西了。这样，一个Spec可以成文，人手一份了。

有了一个Spec，目标已经很明确了。接下来就是一张抵达目标的时间表，从整个大组，直到每个工程师都要遵循。这张表，大家习惯称为\"Milestone\"，也就是公路边那一块块标志着离下一站还有多少公里数的小石碑。这张表，以及将其分解到的每一个小组与个人，（针对个人，又可称做每人的日程表（Schedule））虽然这主要是大小头目的任务，但如果工程师自己兴趣的话仍有足够的权力参与。值得指出的是，如果已经有了一个全组反复参与下做出的Spec，那么这个时间表的产生，也就很清晰明了，并无太大困难的工作了。但时间表一经确立，就变成约束你自己的纪律了。再说一遍，这是微软公司内最重要的纪律！

目标有了，路线有了，走完每一站的时间也有了，就该轮到一个个自命不凡的研发工程师们上阵了。在一个个的Milestone之间，微软风格的Spec，是留下了足够的余地给他们在编程过程中去\"八仙过海，各显神通\"。

有了网络，研发管理变得十分\"松弛\"

瑞特蒙得园区内，研发队伍的管理其实是非常松弛的。除了极少数临时工（Contractor），每位员工单独拥有自己一间十余平米的办公室，均有一套价值千元、高低任意调节、按人体功能设计的工作台与工作椅。书架、文件柜、白板、至少两套PC，这些都是标准配置。许多人喜欢在自己的房间里贴满各自心爱的照片、卡通，摆放或悬挂花草、盆栽、风铃......。将沙发床、健身器、音响设备搬进房间的也不在少数。

看到别人有趣，D也将70年代戴着领章帽徽的军人半身标准照放得老大，端挂在墙上。照片之下再标上一行大字：中人占领了美国（Chinese Soldier Takes Over USA）！

除不考勤上下班时间之外，公司还从早10点到下午2点，每一小时一趟的班车，在园区内与园区边设备豪华的健身俱乐部间穿梭。公司支付一切费用，员工可游泳，或网球......，活动筋骨，锻炼身体；一年四季，或小组，或大组，或整个公司，三日一小宴，五日一大宴。美食美酒，Party不断；新上档的电影、热门棒球赛、NBA篮球赛、橄榄球大赛、歌星演唱会，......，公司赠票给员工全家，请你务必赏光。一年三百六十五天，公司开满了各式各样的进修课程，鼓励诸位踊跃参加。如诸位能大体上不影响日常工作，而学校又肯收你，读博士、读硕士，公司均乐于为你支付学费。听起来真是神仙过的日子。

其实也不只是\"听起来\"。头一回参加全公司每年一次的Party，D还真的小有震撼。在西雅图湖东区的一个大农场，幸亏有这么大一块地方容得下这么多人和车。那时公司还只有7000人，但7000辆车密密麻麻地排在一起就已经是很大一片了。那一天，几英里之外，便

站满了值勤的。一辆辆贴着微软特别通行证的车辆，打扮如嘉年华会。方圆数百英亩的会场上早已搭起了一座座各色帐篷，摆满中国的春卷、日本的生鱼片、比利时的巧克力、美国的烤牛排、老俄的鱼子酱......，几乎全球的各色食品应有尽有。所有人，一律免费自助。不怕你肚子大，就怕你吃不下。所有饮料，包括低度数酒，当然也是无供应。各种各样的音乐，混杂着烧烤的焦香在农场上空飘荡。加拿大国家马术队在做着精彩的跳跃。一架架飞机拖着彩带在天上盘旋，一朵朵花伞从天而降直落靶心。这是前来助兴的奥林匹克跳伞队。今天还有吗？五万人了，一天又要吃掉多少吨美食呢？D还真有点怀念这让微软人自豪的华宴。

不过，公司终究不是疗养院。公司更不可能养\"大爷\"。任务已经明确了。Spec已交到你手中，Milestone已清清楚楚。好酒好饭无非是让你上阵时精力充沛、生龙活虎罢了。就如同那第一流的奶牛场，请你听音乐，给你做按摩，为的是请你多出牛奶。

既然公司已待诸位如上宾，吃饱喝足之后，就轮到把诸位的\"牵出来溜一溜\"了。公司也必须对诸位一举一动了如指掌，方不为过。因此，每天，诸位从使用Card Key（身份证兼开门的电子钥匙）进入办公大楼开始，你打过的每一个电话，你每一次访问源码库和数据库（作为可选项，你在办公室内电脑上每敲下的一个键），其时间、地点都记录在案。如有必要，均可查询。

一般而言，在你决定要结束一天工作离开办公室之前，应给小组的每一位同事发一个日报告（Daily Report），有事则长，无事则短。这样，同事们相互间知道你今天有哪些值得骄傲的进展，发现了什么问题，有什么需要求助？再加上周报告与月报告，这是不可偷懒的\"琐事\"。各级头目基本上靠这些电子邮件来了解和掌握工程的进展。（聪明如中国人，便有人也有这个本事，一天便干完预计三天的工作，然后写上三份Daily Report定时发出，乐得赚来两天假期。多好的管理都有漏洞，但这是以你完成任务为前提的。当头儿的知道不知道也都睁一眼闭一眼了。）

如果有必要，每天三五成群、共进午餐通常是大家一个非正式讨论工作的时候。此外，除非公司有活动，小组通常每周仅有一次例会，探讨那些E-mail中不容易说清楚和解决的问题。

公司内部不仅是省掉了许多会议，员工所有的公司布告与通知、出差购票与报销、领取杂物、查找资料、借阅图书，微软公司的网络将这些都包办了。行政后勤人员在前方第一线无事可做了。因此，比如D的部门，除一位为全体人员服务的秘书外，百分之百，包括总经理在内，全部是为第一线干活的工程师。

一张企业网（Intranet），将一个个不考勤、不开会、整年嚼着口香糖的\"美国大兵\"，紧紧地网在一起，成为一支协调一致的队伍。也使得拼杀在第一线的队伍，将自己的行政与后勤，统统甩给了公司内的少数直属部门。微软创造了在美国也是极高的前后方人数比。网络，用盖茨先生的话讲，是公司的神经系统！

产品的按时完成，源于雷打不动的 Milestone

\"Deliver，Deliver And Deliver\"，这句话的中文意思是说：一是按时出货，二是按时出货，

三还是按时出货。这是在微软瑞特蒙得园区工作的，任何一个研发队伍的大小头目，都要牢记在心的最重要的一句话。相信这也是美国任何一间软件公司都要追求的一个目标。虽然每一个大的软件项目，比如在微软，从Windows 95到Windows XP，几乎每一次都比预计的时间延后投放市场，虽然理想与实际总是有一段距离，但理想总是要追求的。相对而言，对完成Windows这类规模已达几百兆字节、又要涵盖数以万计PC硬件厂家的底层系统软件，微软还是做得相当出色的。

员工各自的Milestone，是从每位工程师到大小头目最重要、也最醒目的目标。花香鸟语的微软园区里，前面讲了那么多事，都可以请随尊便，都是为了在诸位的Milestone上，容不得半点含糊。Milestone，可以说是微软公司软件产品项目管理中的核心。坦率地讲，90年代初，直到D离开岗位（以后，就不便妄言了），微软的进度管理是相当苛刻的。新老员工一视同仁，并不会因为你是新加入的员工给你更多的学习时间。在一群自命不凡的聪明人中，别人可以完成，你却不能，这种压力是可想而知的。在那个年头，无论几点钟走进微软园区，停车场上永远停着一片片的车辆。加班加点是普遍的事情。所以，不考勤的好处就是不必付加班费。将沙发床搬进办公室，连跑回家睡觉的时间都省了。无怪乎，法官大人对垄断案的判词中要指责微软每周平均60小时的工作时间。

除了朋友间的相互帮助，政治思想工作外，那是心理医生或者教会分管的职责，不在公司的议程之内。除了电子邮件中乃至会议上就事论事的争论外，美式的日常管理中较少听得到对哪位员工正式的批评意见。会议上听到的大多是\"你好我好他也好\"的正面鼓励。打工的诸位要想发现与自己相关的问题，就看听话的诸位，能否敏感地直觉到，你好我好中的奥妙与异同。

如果老弟真的糊里糊涂，完不成任务，而又自我感觉良好，那么，一年两次的评审（review）就是毫不含糊地与你清账的时候了：你自己给出一番自我鉴定，你的顶头上司也会给你一个鉴定，一项一项为你打出一个分数来。这次不再会是\"你好我好他也好\"，这关系到你这半年的奖金、股票、工资乃至你是否还干得下去。因为这也关系到你上司，他的奖金、股票、工资乃至他是否还干得下去。

坦率地讲，无司为你准备了多么优秀的工作条件，提供了多好的福利待遇，努力为你营造一个松弛的环境，早期员工所承受的压力也是无须掩饰的事实。压力就是来自不太容易\"泛竽\"的Team Job和雷打不动的Milestone。

在D的微软岁月中，D未解雇过自己的员工，也未见过开除员工的现象。但用不着多久，完不成任务的员工大多选择自动辞职。以下随便捡出几个实例：

1992年，D曾从加州硅谷聘请了一位已有5年软件工作经验的同胞加盟D的部门。但上班仅一周，这位同胞便跑来向D辞职。他抱怨，他无法承受这种不给切入时间便得立即上阵的压力。他没有信心按时完成任务，这与他过去5年的经验不相符合。三十六计，走为上。

1993年，Visual Basic 未能按时出货，该部门从上到下正职领导全部辞职。

1995年，一位毕业于中国名校，加入微软前又曾在北京某一知名软件企业工作过数年

的北京老乡，跑来向D投诉：他在自己工作部门内受到洋鬼子无法忍受的不公正待遇，希望D利用自己的位置给予申诉与帮助。D费尽了力气，才发现，这位自视甚高的老弟实在是忍受不了 Milestone的压力，精神开始变得恍惚了。虽然D为此事，求助了许多公司中包括其他中国人在内的同事，也包括今天任微软（中国）公司总经理的唐俊能否为他更换一个压力相对轻微些的位置，均未能解决他的问题。公司毕竟是公司，何况众矢之的微软公司。

1996年，D深感自己三板斧已经耍尽，\"宝刀\"已老，已无法胜任微软公司高级软件设计师的重压，乘着公司尚未讨厌自己之时，向盖茨先生递出辞呈，飘然而去，实也一例。虽然形式不同，其本质一样。

......

对员工的充实与培训是公司的责任。但在美国，照顾弱者通常是社会与各级的任务。在战场上，冲不上去的士兵，无论在哪个里日子都不好过。

细致的源码管理，与严格的质量控制

Milestone与按时出货，关系着每位员工在公司内的\"生死存亡\"。但还有更重要的，关系着公司自己的生死存亡，那就是产品的质量！

在美国，不仅是微软，任何一间真正的公司，在他们的\"多快好省\"总路线中，\"好\"字永远是摆在首位的。有人说，老美有钱，可以把钱往里砸。但也有人说，这其实更是一种文化。看看上海外滩上那一排排百年沧桑的花岗石大厦，的确是一种文化。再看看北京故宫那金碧辉煌的建筑群，那是更古老的文化。无论各路专家如何诠释这些文化，这里都包含着一件共同的组成部分，让人叹服的质量。

微软研发产品，的确不吝惜金钱。他已花了足够的人力物力去做市场的调查，去琢磨产品的Features（功能、特色），去反复完善产品的设计。在程序员开始动手Coding（编写程序）之后，公司还要组织几乎和研发人员人数1：1的测试人员反复测试设计中所有的功能。这是一支千万人的庞大的队伍（如果算上微软外承担了贝塔测试的数千家公司，人数将多达几十万人）。从产品的第一次合成（Build）开始，到阿尔发（α）出货，到β出货，直到投放市场前最后一分钟（已经是数千次合成过了），这支队伍数年如一日，一直都在做着永不停歇的质量测试，不停地寻找一个又一个各式各样的问题。即使是这样，由于一个大型软件的特殊性，它的所有功能间排列组合所产生的近天文数字的不同情况还是难以完全覆盖。这也是为什么每次微软的Windows产品投放市场之后，仍能发现其中某些问题的原因。庆幸的是，至今为止，尚未发现过严重的弊病。试想，几千万份软件在上亿台PC上运转，如果也像某些公司的某些做法，将大部分测试交由市场去完成，这样大规模的产品，待到问题\"百花齐放\"，那垮台的就不仅是微软，一时间，会为全球的PC业造成难以估计的灾难。

人们常说，股票价值数千亿美元的微软公司，除了几千个聪明的脑袋就没有什么了（园区虽然漂亮，那几幢楼可值不了这些钱）。脑袋值多少钱，多少有点虚。从这些脑袋里写出的一串串源码才是微软看得见的财产。

微软公司当然有一整套严格的制度与措施。在这套措施的管理之下，你写的每一行码，

都会保存得十分妥当和有序。每个程序员的源码都会、也必须定期存档（Check In），这是你创造的财富，也是你的工作纪录。无论什么原因毁坏了你的硬盘，或损毁了某个文件，你自己再也无法挽救时，打个电话，就会有人在一个新硬盘上恢复你昨天下班前所做过的一切。

就D的部门而言，事前对每位程序员的源码风格不做硬性规定。但每一阶段，小组都会对全组的源码做一次统一的整理（Code Review）。签上各自的姓名，补上必要的说明，并使全组程序简明、易读，书写风格大体一致。一套仔细有序的源码保存与查询，不仅仅是质量控制的必要保证（大大加速发现和修改错误的过程），也同时保障了产品的连续性。一个公司才有可能，\"走了张屠户，不吃混毛*\"，才能应上那句话，\"铁打的营盘，流水的兵\"。

源码还必须有一套无懈可击的保护系统。源码在软件公司，犹如钞票在银行。Windows NT 4.0中文投放市场前夕，北京某个著名电脑公司向微软派来了四位得力干将，作为OEM代表，在微软提供的园区内办公室，由微软协助共同解决该公司预装NT4.0有可能出现的硬件兼容性等技术问题。四位老弟，刚一上班，网上一转，大概是颇有发现，立刻将余事扔到一边，找来软盘，捡其所好，先下载再说。未料到，文件尚未拷完，公司保安人员已站在了办公室门口。幸亏该北京公司反应及时，立即将四人调回中国，息事宁人，未酿成不必要的风波。

1994年，D陪同盖茨先生访问北京。访问中，有人当面指出：微软公司的软件价格太高，不符中国国情。盖茨先生回答：既然中国能够接受收彩色电视的价格，为什么不能接受电脑软件的价格呢？

软件靠进口，当然越便宜越好。软件若能出口，那可能就是另一种考虑了。

细节决定成败--谈产品规划中的“木桶原理”

先说一个案例吧：

有两家多年为竞争对手的汽车制作企业（暂且叫A公司和B公司吧），在某年分别推出了一款新型的汽车，因为双方都在对方的公司里安排有商业间谍，所以两家制造出来的新款汽车几乎说是一摸一样的配置（当然了，汽车样式肯定是有区别的了，但是汽车里面的核心配件可以说是完全一样），并且价格也没有太大差距，上市时间也是前后脚，各自的营销队伍也非常能干，两款汽车一上市，就引起了市场的极大轰动，两家企业用尽力量对各自的产品进行销售，前3个月两家的销量几乎都是同步攀升，但是从第四个月开始，A公司的销量开始逐步下滑，随着时间的推移，甚至有些顾客要求退车，还有一些顾客转投了B公司，A公司管理层非常奇怪，是什么原因造成这种情况的呢？于是责成相关部门进行检查，要求一定要把原因找出来，但是找来找去，最终的结论是：两款车没有任何质量上的差距，性能上也无任何区别，原因不明。

这个结论是无论如何不能向高层交待的，于是又开始了第二轮的排查。 在一个下雨天，参加该车设计的一个工程师因为一直无法找到汽车滞销的原因，感到很郁闷，于是就开着该款车的样车到外面散心，因为下雨，他就把雨刷器打开了，开着开着，他就感觉有些不对劲，总觉的和以前开过的车有些不一样，但是说不出来哪里不一样，他开

始思考，到底哪里不一样呢，突然，他明白了，原来他设计的这款车的雨刷器有些短，这样覆盖的面积就要比其它车的要小，在晴天的时候感觉不到，但是一到雨天，刷的面积一小，人们就会感觉出来了，总觉的视线不是那么宽阔，严重的可能还会造成交通事故，为了验证他的想法，他在雨中和一部其它牌子的车一比较，果然，雨刷器比正常的短了4厘米，就是这4厘米，给公司造成了多大的损失，他立即赶回公司，把这个情况说明，于是公司决定立即更换这批车的雨刷器，重新投入市场，果然，销量马上反弹。 这就是细节决定了这部车的成败，其实很多时候，我们在设计产品的时候会感觉到其实最难设计，但也是最容易忽视的往往就是对细节的处理，因为从人的思维惯性来说，注意力总是放在那些最困难，最不容易解决的问题上，一旦这些问题解决，我们就会认为，这个产品没有问题了，因为所有的难点，重点都解决了，可以放心的进行生产了，这样想肯定没有错，但是因为所有的人都这么想，因此在这个同质化的时代，其体现出来的价值也打大折扣，因为产品在核心技术上的比较已经没有太大区别，区别在哪里，就在那个最容易被忽视，最容易放弃的细节处理上，要是在这里对产品设计的细节做一个定义的话，可以进行这样的说明：

产品设计的细节就是指那些不一定会导致产品成功但是一定会导致产品失败的因素。

其实这和著名的\"木桶原理\"是有点相似的，木桶原理不就是说\"决定一桶水容量的并不取决于最长的那块木板，而是取决于最短的那块木板\"，引申到我们的产品设计中，就是我上面说的那个意思，一个成功的产品并不取决于先进技术的应用，而取决对细节的处理程度。

就如同上面那个案例所说到的，两台没有任何技术差距的汽车，仅仅是因为A公司汽车的雨刷器比B公司的短了4厘米，就直接导致了市场的失败，如果我们在设计汽车的时候，肯定会重点考虑发动机，轴距，扭距，安全性这些直接体现汽车指标的数据，对于雨刷器这种\"没有一点技术含量\"的小玩意肯定不会在意，也是，如果是大晴天开车，雨刷器有什么作用，但是一到雨天，雨刷器不合理的汽车一下子就贬值了。 既然说了产品设计中的细节定义，就得谈谈在具体得工作中如何确定细节以及如何提高处理细节的能力。

其实如何确定细节并不是简单的一件事情，尤其在本文中说明更是困难，因为我也仅仅是了解自己所处的行业特点和产品特点，而对于其它行业则一概不知，凭空总结出产品设计的细节确定方法肯定是不可能的，那我就谈谈我所从事的软件行业的一点感受吧，仅供参考，一定要具体产品具体分析。

大家经常使用软件，比如说MS word，各位会发现软件的默认菜单栏上的菜单，工具按钮栏上的按钮都是从左到右排列的，并且排列的顺序是按照使用频率做为标准的，也就是说，使用频率最高的菜单和按钮放在最左边，依次类推，排在最后的肯定是不经常使用的按钮（相对而言），这是因为人们阅读的习惯就是从左至右，在阅读一篇文章的时候，注意力首先从左边开始，把菜单栏和按钮栏以阅读习惯排列足见这个word设计者的细心之处，这时候肯定有朋友说了\"这就是你要说的细节了吧，这个地球人都知道，您老下去吧\"，确实是，这个只要是做软件，用软件的，都能体会到这一点，但是，我要说的是，这只能说是细心，还不能说是细节，细节在哪里？我认为有三点： 1）所有的菜单栏，按钮栏都可以移动； 2）预留插件位置；

3）不同文档的菜单栏，按钮栏布局可以按照撰写者的默认布局存在；

有这三点，就足以让word嬴的市场。

先说第一点，虽然大部分人的阅读习惯是从左至右，但是肯定有一些人的阅读习惯不是这样的，那怎么办，好办，我把所有的菜单栏，工具栏做成活动的，你可以随心所欲的把这些菜单，按钮移动到你想的位置，你说做成固定的不可以吗，当然可以，还减小开发难度呢，是吧，但是既然要做市场，既然要做产品，就不能因为想当然或者偷懒忽视这些细节，丢掉这部分市场，我们会有这种感觉，当一个软件做的比较死板的时候，大家宁可去放弃它也不愿意勉强使用，因为这种使用简直是一种折磨，WPS挂掉就有很大一部分是这个原因，为什么，就是因为太难用，因此金山在开发2004的时候就完全模仿word 的操作习惯，但再怎么模仿，市场丢了就是丢了。

再说第二点，预留插件位置，本来那些菜单，工具安妮就已经占据了软件界面的部分位置，但是偏偏还要在按钮栏的最后预留一部分空白区域，这个区域可不是我们想的那么简单，它是为那些集成到这些软件中的插件预留的，为什么要这样呢，因为微软知道，在windows做为主流操作系统的情况下，有许多软件厂商希望让用户能够多看自己几眼（网站中就叫流量了），怎么才能达到这个目的呢，就是在用户常用的软件中加入自己软件的按钮，这样就可以让用户在使用该软件的时候看到自己的软件（当然用不用就不好说了），其实这对于word来说也是好事情，就是借助其它软件厂商的资源来增加自身软件的价值，大家想想，无形中给word增加了第三方功能，word肯定超值了，而对于第三方厂商来说，也是好事情，这应该叫双赢吧。这个细节处理尤其在IE中体现更为明显，因为IE可能是每天用户用的最多的软件了，并且第三方针对IE的插件种类也非常丰富，因此大家都在抢这个地方。 最后一点，这个简单了，就是比如你撰写了两个文档：A和B，但是在撰写A的时候，工具栏按钮是从左到右，而B是从右到左，当你再次打开这两个文档的时候，A和B依然保持原始的按钮排列，不会因为关闭的原因而变为默认，因为微软认为\"用户既然采用了这种排列，就说明用户接受并且习惯这种排列，我们无权去改变它\"这就是专业，就是软件设计的专业，我们必须尊重用户的各种习惯和操作，不能用强制的方法来改变，这样只会使用户抛弃你，我经常会听到有些人在推广产品的时候，这样和客户交流\"你应该这样用，那样用是错的\"，\"必须先点这个按钮，再点那个按钮\"等等，其实我想笑，为什么，因为他们在强制改变用户的操作习惯，各位想想，这样的软件能走多远？现在好多软件都犯这个毛病，这就是没有在细节上做文章，没有处理好用户的操作细节。

简单地就说这三点，细节存在于一个产品的方方面面，要确定细节，一方面需要一定经验的积累，另一方面，需要平时在工作中认真一些（这也是一个产品经理必备的素质之一），仔细一些，我就说这么多了，各位朋友有什么看法，可以和我交流。

什么？有朋友说还没说\"细节的处理方法呢\"，这个确实不太好说，必须的具体问题具体分析了，我会抽时间找一个案例大家一块来分析分析最好了！