设计与开发怎么做，网站和产品设计与开发详解？

最近小编在翻看一本比较小众的书：《硬件产品设计与开发：从原型到交付》，没成想翻开前言和第 1 章都很惊艳，尤其是第 1 章总结的《产品开发的 11 宗罪》，真的让我受益匪浅。

以下原封摘自图书内容的万字长文分享给你，愿我们人生路上总有顿悟觉醒时刻，不论道理大小，皆为人生之幸事。

— — 产品开发的 11 宗罪 — —

托马斯•爱迪生有句名言：“天才是 1% 的灵感加上 99% 的汗水。”这句话同样适用于产品开发。诚然，开发“天才水准”的产品需要灵感（开发普通产品亦然），但更多的是付出辛勤的汗水。也就是说，开发好产品既有赖于灵感和才智，在极大程度上还需要依靠认真、谨慎的工作，以确保每个细节到位、不出错。例如，确保软件不会占用过多内存，使用正确的电容隔离电源等。

前言中提到过，大部分产品开发以失败告终。据我观察，在详细产品设计和开发开始之后，失败通常不是因为缺少“灵感”（比如产品创意不佳），而是因为产品开发过程中所犯的错误。换句话说，在大多数产品开发中，产品创意本身是好的，而失败往往源于把创意转化为产品的过程。本章将介绍有碍产品开发或使产品开发项目流产的一系列常见因素。大多数项目因掉入一些基本的陷阱而最终失败，其实这是完全可以避免的。本章将简略介绍这些陷阱，让大家大致了解其危害，但不会深入讲解过多细节，本书后面将详细讲解避开这些陷阱的策略和技巧。

在讲这些恶和罪之前，先介绍产品开发的一些基本原则，这些最基本的真理决定着产品研发的成败。

1.1　产品开发的基本原则

复杂的问题往往源自简单的真理。比如，黄金法则（你希望别人怎样对待你，就怎样对待别人）就是大多数宗教律法的基础。在物理学中，我们只知道四种基本力，但这四种力似乎支配着宇宙中的一切，许多科学家多年来一直忙于追寻真理和探索未知。

在产品开发中也存在这样一条真理，它其实也是一条基本原则，即“越早发现问题，代价越小”。换句话说，产品开发在很大程度上就是一项尽快发现问题的活动。

据我个人观察，产品开发的成败在很大程度上是由这条基本原则决定的，本书后面所讲解的大部分内容与如何应对这条基本原则紧密相关。

谁都喜欢意外惊喜，但是产品开发过程中发生的“意外”几乎都是负面的。“你还记得我们在设计中使用的那个漂亮的电源芯片吗？它没能正常工作！”“事实表明，没有一家厂商能为我们设计的那个外壳做出模具。”类似的这些“意外”，总是让人哭笑不得。

意外往往会导致改动，比如采用新的电源芯片，或者重新设计出容易制作模具的外壳。在产品开发初期，做改动是比较容易的。

研究人员做了大量研究，试图找出在产品开发周期中不同阶段做改动和付出代价之间的对应关系。最终的研究成果都差不多，如图 1-1 所示。这张图来自美国国家航空航天局发表的一篇论文，反映的是在商业飞机研发过程中，错误发现时间段和修改错误所付出的相对平均代价之间的关系，图中的虚线是根据相关数据绘制出来的曲线。随着产品开发阶段向前推进，做改动所要付出的代价呈指数级增长。

图 1-1：在不同产品开发阶段做改动需要付出的代价

为了说明这种现象产生的原因，我们来做个假设。假设有一个做外科手术的机器人，它的软件内部有一些算法，用来根据要做的手术确定各种执行部件（引擎）的正确驱动方法。有时，算法或执行部件会失效，比如在某些情况下，算法可能给出了手术刀要移动的错误角度，或者执行部件出现故障，没能按照预期移动。

上述这些问题可能会引发手术事故，为了减少这种可能性，添加一个独立的软硬件系统来监视机器人的动作或许是个不错的选择。这个软硬件系统相当于第二双“眼睛”，用来确保机器人的所有动作都正常。当机器人出现问题时，独立的软硬件系统能够向医护人员寻求帮助或者停止手术。

表 1-1 列出了在开发手术机器人的不同阶段添加这套安全监控系统时所要付出的代价。

表 1-1：开发手术机器人在各个阶段做改动需要付出的代价

显然，我们越早认识到需要添加安全监控系统的必要性，就应该越早添加这种系统，相应地，需要付出的代价就越小。某些问题如果在产品规格确定阶段就发现了，那么改正错误需要付出的代价就相对较小；但如果在实际使用过程中才发现，那时再修改错误付出的代价就会很大（说不定还会上头条新闻呢）。问题发现晚了不是糟糕一点点，而是会导致满盘皆输。

所有针对产品的改动都遵循相同的规律，那就是，做改动的时间越晚，所付出的代价越大。比如，当一个电子元件在设计完之后才发现不能用，我们就不得不重新设计和测试电路，可能还得调整相关的机械架构和软件架构，以便消弭元件尺寸、发热、通信协议等方面的差异。不要总想着亡羊补牢，在设计和开发阶段就要做好准备，确保所选用的元件耐用。

然而，我们面临的难题是，不论我们如何努力，都不可能在规格确定和产品设计阶段把所有问题找出来，有些问题在制造、测试，甚至发货时才会暴露出来。在本书后续内容中（特别是第 5 章和第 6 章），我们将会讲到，这些问题可以通过在不同开发阶段之间反复迭代来解决，这种方法对产品中那些很容易发生故障的零件尤其有效。

讲完产品开发的基本原则之后，接下来该讲讲产品开发中的那些“罪”了，它们一般会破坏产品开发过程，造成不利的影响。

1.2　懒惰之恶

前述产品开发的基本原则时，我们就已经提过，把今日之事拖到明日是个糟糕的想法，对那些有可能发现潜在问题的事项来说更是如此。这个恶习最直接、最具体、最常见的例子往往出现在产品测试环节。

第1宗罪：将重要测试推迟到产品开发结束

把重要测试推迟到产品原型开发出来之后，这明显会延迟发现问题和做适当改动的时间。这里所说的“重要测试”是指高级测试，常称为集成测试或系统测试，旨在测试产品对用户的有用性（这个过程有时也称为产品验证）以及产品的软硬件、机械子系统间的协同工作能力。对于产品开发来说，新手往往认为“首先把产品造出来，然后再做各种高级测试”。乍看上去，这样做似乎合情合理，而且有些高级测试的确需要把产品全部组装起来之后才能做。然而，这样做会推迟我们发现问题以及做改动的时间，这会让我们付出更大的代价，尤其是需要大改的时候。

比如，我们需要对一个已制造好的报警产品做可用性测试，判断报警声是否足够强。设计报警系统时，我们并没有意识到用户与报警器经常不在一个房间。当重要警报响起时，我们设计的声音系统（扬声器和相关电路）就没有足够的功率来完成报警工作。补救办法是更换扬声器并更新电路。更换扬声器时可能需要改变报警器的外壳大小，而这可能需要花几周时间，还要花不少钱。改动电路意味着换新的 PC 主板，这也需要花不少钱和时间。所以，这个所谓的“制造好”的产品实际上并没有真正完成，我们还得再花几周甚至几个月才能把这些意想不到的工作做完。

在这个例子中，如果做外壳设计之前就早早地把拟建的声音系统放在实际应用场景中测试，确保它能够正常工作，就能节省大量时间，免除额外的开支。甚至在开始设计声音系统之前，我们就应该做好几件事：

• 找来同类产品，了解一下它们的声音有多大。如果它们都使用了高音扬声器，就表明这样做可能是有原因的；
• 考察产品的潜在应用现场；
• 拜访产品用户，了解产品的日常工作状态，可能的话，让用户模拟使用产品的场景；
• 使用智能手机和扩音喇叭模拟报警声；
• 尝试不同音调和音量（使用分贝仪测量），了解哪种声音能引起用户注意。

尽早对电路、软件、机械架构做测试不仅有利于保证产品的可用性，还有助于降低成本、缩短产品开发时间。

请注意，有效测试可不是件小事，第 5 章和第 6 章将讲解更多相关内容。

1.3　假定之恶

开发产品时，我们往往会想当然地认为自己知道市场需要什么样的产品。只有把产品推向市场，根据订单数量，我们才能确切地知道有些想法是否正确。

假定之恶有两种常见的形式：

1. 以为自己知道用户想要什么样的产品；
2. 以为用户知道他们想要什么样的产品。

1.3.1　第2宗罪：以为自己知道用户想要什么样的产品

在产品开发中，设计师和开发者常常以为自己知道一般用户需要什么样的产品，这个问题在产品开发中很典型。设计师和开发者往往把自己的想法强加于人，认为别人想要的东西与自己想要的东西不会相差太大。

我这么说你可能不会感到意外——此刻正在阅读本书的你可不是寻常人。你可能对技术特别感兴趣，想学习更多有关产品开发的内容。痴迷技术是件好事，若没有你我这样的人，人类可能还处在狩猎采集的原始社会。但是，不论好坏，大部分人不像我们这样痴迷技术。从另一个角度看，在我写作本书时，美国亚马逊上最畅销的技术书是 Raspberry Pi User Guide，总排名第 583 位，之前有 582 本书卖得比这种严肃的技术图书要好。

此外，当谈到想要什么样的产品时，技术发烧友的需求往往不具代表性。我们喜欢那些具备更多功能，有更多定制性的东西，一摆弄就是几个小时。普通用户通常对这个工具能否有效完成指定工作以及外观是否吸引人更感兴趣。图 1-2 展示了两组人所喜欢的工具的不同之处。

图 1-2：技术发烧友想要的（上）与一般人想要的（下）

我们很有可能清楚其他技术发烧友需要什么样的产品，但往往对那些普通用户的需求不是很了解，因为他们的想法与我们大不相同。苹果公司的大部分产品例外，这些产品的开发基于史蒂夫•乔布斯及其身边的人对用户需求的深度思考。苹果公司开发的产品都很成功，我认为原因有两个：首先，苹果开发的产品是史无前例的，比如在 iPod 问世之前，如果你问用户他们想要什么样的 MP3，往往得不到什么有用的信息，因为之前没人用过；其次，乔布斯是为数不多的天才，他推崇以人为本的设计理念，拥有深厚的审美功底，并且了解技术和工程师。

即便没有乔布斯式的人物为我们工作，我们仍然有一些策略可用，这些策略能够帮助我们发现普通用户的需求。但这并不像听起来那么简单，我们很容易犯下面的错误。

1.3.2　第3宗罪：以为用户知道他们想要什么样的产品

既然技术人员不知道用户想要什么，那我们就直接问用户想要什么吧。用户总该知道自己想要什么吧？很遗憾，并不是这样的，用户常常不知道自己想要什么，他们想要的东西大多是自己臆想的。

我父亲是一位退休的市场研究员，他说市场研究的第一定律是：“如果你问用户他们想要什么，你会得到一个答案。这个答案可能对也可能错，你要学会自己甄别！”

对于这句话，我一直不太懂，直到我开始做产品开发，才真正弄明白了其中的含义。在产品开发过程中，我发现用户提的要求很可能与他们的实际需求不匹配。我们之间经常出现这样有趣的对话。

这个结果让所有人感到非常沮丧、非常失望！

事实证明，目标用户设想的产品有可能与他们实际拿到手的产品差别巨大。要想了解用户真正想要什么，就要让用户多尝试各种功能、多接触各种原型，观察他们是否真的喜欢。要尽早开展这种调查，不要等到产品做出来之后再做，不然我们就只能祈祷自己的假设是对的了。

1.4　模糊之恶

在产品计划和开发中，目标模糊不清或不够具体是导致产品开发失败的一个主要原因。目标模糊不清会造成两个重大问题：

1. 对于开发什么产品，相关人员看法不一；
2. 如果不知道产品细节，很难估算出产品开发所需要的资源和时间（几乎不可能），至少在某种程度上如此。

模糊之恶有三种表现形式：

1. 缺少详细的需求；
2. 缺少详细的项目计划；
3. 未指定责任。

1.4.1　第4宗罪：缺少详细的需求

产品需求反映了我们对产品的理解，它可以确保所有相关人员对产品的重要特性有一致的看法。创建产品需求时，我们必须尽量把所有对用户和自己有重要意义的方面记下来，不然，最终结果可能与我们想要的有出入。

我们举个常见的例子，假如市场部写了如下需求：

• 这个产品有四个轮子；
• 这个产品有一个电机；
• 这个产品容易驾驶；
• 这个产品有一个引擎；
• 这个产品的引擎烧汽油；
• 这个产品可以在美国的所有道路上行驶，在甲、乙、丙等国也都可以；
• 这个产品很有魅力。

设计师和开发者是那些被古怪的设计所吸引的实用主义者，他们会去做一些他们认为可以满足这些需求的东西。然而市场部想要的产品与设计师和开发者最终造出的产品有很大不同，如图 1-3 所示。

图 1-3：市场部想要的样子（左）与设计师和开发者认为的样子（右）

从上述例子可以看出，由于不同部门的人对同一产品的理解不同，最终导致结果很难让所有人满意。

尽管图 1-3 中汽车这个例子有些夸张，但是它阐述了这样一个基本事实：需求可以确保所有人对正在开发的产品形成一致的看法。必须谨慎地把对我们重要的东西添加进去，否则将来可能会产生许多问题（这些问题通常是我们不愿看到的）。在汽车这个例子中，市场部提到的一些附加需求可能有助于造出一个更好的产品，比如“80% 以上的目标用户希望产品设计中体现‘性感’”。

缺少详细的需求不仅会让相关人员对最终产品感到惊讶和失望，还会造成功能蔓延问题，这是因为在产品开发之前，我们并未定义好产品的所有功能特征。有关功能蔓延问题，后面还会细讲。如果我们一边开发一边确定和实现产品的功能需求，就需要对互相依赖的系统做大量重建工作，以便适应我们新发现的需求。

1.4.2　第5宗罪：缺少详细的项目计划

一提到项目计划，我就能听到你的叹息声。

对大多数人来说，做项目计划的痛苦，就像填税单一样。项目计划执行起来也苦，不亚于给牙齿做根管治疗。

更糟的是，对于如何推进一个项目，产品计划也不可能完全准确：事情很少能按照计划顺利地开展下去。即便那些相对简单的项目也总会发生意外，最终表明我们最初的假设是错的。常见的意外情况有：项目骨干暂时或者永远离开项目团队，元件供应商从美国市场撤离，产品设计比预期的情况更棘手，管理层突然决定提早三个月发布产品，等等。

既然项目计划这么令人痛苦，又不准确，那又何苦要做项目计划呢？

关于这个问题，艾森豪威尔说得好：“计划本身毫无价值，但计划至关重要。”虽然在工作开始的第一周，项目计划通常就无法按部就班地执行了，但是花费大量时间和精力来做计划是必不可少的。我发现，做项目计划虽然很无趣，但是不管什么规模的项目，要是没有非常详细的项目计划（通常包含几百个定义好的任务，要用到的资源、时间、成本以及相互间的依赖关系），开发起来就非常痛苦。虽然我很清楚大多数计划最终被证明是错的，但是详细的计划至少可以让我大致估计出项目需要花费多少时间和精力，并且有助于跟踪项目进度，以此判断项目进展得比预期是快是慢。

制订详细的项目计划迫使我们全面思考各种问题，有些问题在做粗略计划时很容易被忽略。制订详细计划有助于我们记住那些容易忘记的重要细节，并且有助于我们理解相互之间的依赖关系。

1.4.3　第6宗罪：未指定责任

在项目计划中简单地创建一项任务，给出截止日期和预算，并不能保证项目在指定的时间内使用给定的预算完成。一个常见的问题是，任务即将开始时，才发现项目计划中漏掉了一个细节，它可能让我们无法按时开始工作，我们还可能遇到一些影响预算和时间的问题。任务刚开始，就会出现一些混乱的情况，比如谁负责哪一部分，多个部分应该怎样聚到一起，等等。

为每项任务指派一个负责人会极大地提高项目成功的概率。任务负责人不一定是任务的具体执行人，任务负责人主要负责监督任务执行进度、预算，协调沟通，确保一切进展顺利。为任务指派负责人有两方面的作用。

首先，任务负责人能够堵上项目计划中存在的漏洞。项目计划中普遍存在的一个问题是漏掉了某些任务和细节，比如忘记把某个任务添加到项目计划中了。在整个项目中，任务负责人盯着任务的方方面面，确保一切按照计划和预算进行。任何影响时间进度或预算的问题都应该提前解决，任务负责人要对项目计划做必要的更新。

其次，任务负责人必须确保谁负责哪项任务一清二楚，杜绝职责不清、相互推诿的现象发生。“等等，我还以为这事是你负责的！”类似的说辞不应该出现。

比如，在为获取美国联邦通信委员会（FCC）认证而开展的测试中，我们的产品中必须运行一个特定的测试软件程序，把硬件逐个设置到不同状态，这样每个状态下的射频辐射都可以使用少量产品测量出来。这项创建测试应用的任务很容易被忘记，在最初的项目计划中有时也会漏掉它。如果拖到安排测试时才记起相关测试程序，那么我们可能无法按时完成测试，整个项目可能就会拖延几天甚至几周。等到测试程序准备好了，我们又需要找合适的时间来进行相关测试。

相比之下，如果有人专门负责 FCC 测试任务，这个问题就很有可能不会发生。比如，如果小苏负责这个任务，她可以在预定测试之前几个月打电话给检测室，问清楚她需要做什么以确保测试如期开展并顺利完成。此外，检测室也会告诉小苏他们需要一个测试应用。“啊呀！我们忘记把开发测试应用列在项目计划中了。”小苏会把这件事报告给项目经理，项目经理会在项目计划中加上这个任务，分配相应的资源，更新整个项目计划。像这样，任务负责人的重要作用就凸显出来了。

1.5　无知之恶

无知之恶是指我们对某些事情一无所知。我们甚至不知道要担心什么，一直处在一种悠然自得、浑然不觉的状态下，直到后期遇到需要对产品做改动的问题时才幡然醒悟。有时，甚至在产品发布之后才悔悟。

要消除无知之恶，首先需要依靠那些在技术领域和非技术领域有经验的人，你可以把他们招入麾下，也可以让他们担任项目顾问。他们都有各自的绝招，能够准确地定位问题。

减少无知的另一个方法就是阅读本书：本书的一个主要目标就是帮助大家找出那些对产品开发造成不良影响的问题。

当然，我们不可能知晓一切。但是，有一种问题很容易给我们带来大麻烦，接下来就会讲到：如何让行政管理部门满意。

第7宗罪：忽视法规

在无知之恶中，一个最具代表性又常见的例子就是产品设计完成后才发现不符合政府的相关法律法规，比如产品可能会因为达不到欧盟的相关要求而遭到禁运，或者只是因为产品上的 CE 标志贴得不正确而被禁止入境。

一般来说，产品要上市销售，必须满足两类基本要求。一类是商业需求基础上的“标准”要求，一方面是要满足用户的需要（比如功能、尺寸、颜色等），另一方面也是业务的需要（比如盈利能力、设计语言与其他在售的设备保持一致等）。

第二类需要满足的要求是外部机构提出的，比如法规、标准、认证等，这些要求出自政府、保险公司等机构。这类要求有个专门的称呼——“强制性要求”，通常用来确保产品安全和产品性能（比如，在欧洲销售量杯可能就需要证明其精确度达到了某个水平）。有关这类要求的更多内容，第 10 章会讲解。

这些强制性要求在产品开发中很容易被忽略，很多人甚至没有意识到它们的存在。即使我们意识到了，找到那些适用于我们产品的要求也并非易事，这是因为不同政府部门有不同的法规，政府的不同部门也有不同的规定。（但愿它们不要相互矛盾！）在某些行业，保险公司和其他组织会强制要求产品通过一些标准，这些认证只有产品通过指定考核才能获得。

由于不了解这些强制认证的情况普遍存在，并且通过这些认证也并非易事，因此第10 章将专门讲解这部分内容。这里只举几个常见的强制认证的例子。

• FCC 认证。在美国市场上销售的几乎所有电子产品必须通过该认证。事实上，美国大部分电子产品在上市销售之前必须通过第三方测试和认证。其他国家也有类似的规定。
• UL 认证。UL（美国保险商实验室）是一个独立机构，从事各种设备的测试工作，检测这些设备是否存在安全隐患。对于可能存在安全问题的产品，UL 会根据特定标准对产品做测试并对生产厂家进行考察，确定被测产品对消费者不存在安全风险之后，才会为这款产品颁发 UL 认证，并允许它贴上 UL 认证标签。UL 认证是企业自愿参加的，没有法律规定产品必须通过 UL 认证，但是有些法律认可它，有些消费者和保险公司也希望看到它。
• CE 认证。CE 认证要求产品遵循欧盟所有相关法律。不同类型的产品必须遵守不同的法律规定。根据法律规定，在欧盟市场销售的绝大多数产品必须通过 CE 认证。

图 1-4 给出了上述三种强制认证相应的产品标签。不过，请注意，大部分的强制性要求并没有相应的认证标签。

图 1-4：FCC、UL 和 CE 的认证标签

1.6　完美之恶

除了要做好自己的工作，产品开发中还多了一个追求完美的动机，即想开发出成功的产品。产品开发工作必须接受很多人的评判，可能是数百万人。产品开发成功，我们将收获赞誉和财富；产品开发失败，我们将损失声誉和金钱。在产品开发中，追求完美风险很大，有可能会导致很多错误。那么，产品开发中过度追求完美会造成什么问题呢？

1.6.1　第8宗罪：新功能至上主义

这里的“新功能至上主义”是指一种在产品开发过程中不断给产品添加新功能的倾向。显然，这种行为违反了产品开发的基本原则。但它并非完全不可取，我们需要慎重研究，避免因此而付出惨痛的代价。

“嘿，如果在产品中加入这个功能会不会很酷？”在产品开发中，这样的想法可能是最重要的，也有可能是极度危险的，它的好坏取决于你如何以及何时提出它。

在产品开发的最初阶段，即定义需求期间，提出“嘿，如果在产品中加入这个功能会不会很酷”这种问题是很受欢迎的，因为这个阶段的主要任务是尽可能多地收集好的创意和想法。为此，我们应该与潜在用户交流，倾听他们对这款产品有何要求，还要研究类似产品，做一些调查，尽可能多地列出产品应该具备的功能与特征。之后，综合考虑各种特征对产品的价值以及实现它们需要付出的成本或承担的风险，再对这些特征做精简，从而得到一份最终功能列表（需求）。

需求一经确定，我们就能更好地评估出开发这款产品所需要的工期和预算，并着手开发过程中最有趣的部分：制造东西。

显而易见，在需求确定之后再给产品添加新功能，会造成开发时间延长和成本增加。其实，除了“这个想法很棒，我在一星期内就可以把它加入固件”（经常变成几个月）这种明显的成本之外，添加新特征可能还会带来一些如下未曾预料的影响。

• 新功能可能会在无意中破坏其他功能。
• 添加新功能往往需要改动产品的基本架构，这是非常困难的，因为最初的产品架构并未将这种新功能考虑在内。改动基本架构会使原架构变得脆弱，很容易出问题。
• 随着产品功能的增加，功能间的关系会愈发复杂，测试工作量呈现指数级增长。仅添加几个新功能，往往就会带来大量额外的测试工作。

总之，功能蔓延会导致开发时间延长和成本增加。

乔布斯曾经说过：人们往往以为“专注”就是全盘认可自己所专注的事，这完全是错的。“专注”还意味着你必须否定另外 100 个好点子。你必须小心做决策。事实上，我对我们的很多工作引以为傲，不管这些工作做了还是没做。创新就是对 1000 件事说“不”。

项目开始时，最好选定一组有限功能，并且在开发过程中尽量不添加新功能，专注于那组选定功能的正常实现。不要给产品添加太多“粗糙”的功能，这样我们能够把产品更快地推向市场，并且让产品价格更低廉，从而让大部分消费者喜欢我们的产品。

1.6.2　第9宗罪：不知何时停止“打磨”

一块石头打磨得越久，它就越光滑。到了某个时候，我们觉得它已经足够光滑，于是不再继续打磨。

同样，在产品开发中，我们可以不断改进产品，只是这样做要付出更多时间和精力。比如，有些工作表单总是怪怪的，屏幕布局看起来不够好，稍稍调整一下就可以使电池续航时间增加几分钟，等等。

在我们花费时间和精力不断改善产品的过程中，有些事情正在悄然发生。虽然我们再多花一点儿时间就能把产品做得更好，但是这显然推迟了用户尽早用上这款产品改善生活的时间。同时，预算也快用完了，又无收益产生，而且竞争对手还有可能抢先发布类似产品迅速占领市场。在这种情况下，时间并不是我们的朋友。

不管什么产品，总存在一个恰当的发布时机，尽管此时产品仍未尽善尽美。其实，世间并不存在完美。

至于那些把产品做得更好的想法，只要我们的产品卖得好，我们就可以把它们添加到下一代产品中，从而把产品做得更好，更好地满足用户的需求。在软件方面，我们总是有办法更新使用中的产品。

当然，这并不是说我们应该尽早发布那些还不够成熟的产品，至少不该把这样的产品交给那些定期付费的用户使用。短期内，不成熟的产品或许可以用作权宜之计，但这样做也可能会严重损害公司的声誉和品牌影响力。在“好到可以出货”与“这可能会让我们难堪”之间找到恰当的平衡点并非易事。在确定这个平衡点的过程中，决策人员之间通常会爆发激烈的争论，如果没有出现这种情况，那就说明这个平衡点很可能找得不对。

在产品开发过程中，我们也不必强求产品十全十美，只要让消费者觉得我们的产品比其他同类产品更好、更有吸引力，并且足够我们推进整体营销策略就够了。

1.7　狂妄之恶

狂妄之恶是指我们过分相信整个产品开发过程都会按照计划顺利进行。项目开始时，我们总是满怀信心。我们手头有详细的项目计划，计划制订合理，又经过许多智囊审查，会有什么不对呢？

我可以明确地告诉你一点：一旦产品开发开始，我们总能在计划中发现这样或那样的不对之处。一旦真正的设计和开发开始，我们在项目之初对那些创意和项目计划怀有的过分自信就会破裂。我们很早就会面对失败的危机，也会经常失败。在很大程度上，成功的标准取决于如何看待失败。

第10宗罪：对于失败毫无准备

在第 5 宗罪中，我提到了制订详细项目计划的重要性。相比于直觉和瞎猜，在开发初期，一份详细的项目计划能够更好地描绘出未来开发工作的轮廓。但是，不论项目计划制订得多么细致和周详，总会存在不妥之处。计划中描述的几乎都是最乐观的情况，我们应该根据实际情况不断调整计划。

我们必须为失败做好准备。

要时刻做好准备应付意外情况。意外情况都是未知的，我们无法确切知道要花多少精力才能解决。根据我的个人经验，不论多有经验的人，在制订开发计划和预算时都要预留 20%~30% 的“余地”，以便应对不可避免的意外发生。如果制订项目计划的人经验不足，或者项目中涉及全新的技术，那么项目预算可能会超支100%（甚至更多），这很容易导致整个项目夭折。

然而，为项目计划和预算留出余地在很多时候是说起来容易做起来难，当你面对一位缺乏经验的经理时更是如此。“什么？！你要为这些未知因素追加 25% 的预算？”在这些情况下，我们手边最好有一份有关项目重大风险的清单，方便我们阐释为这些未知因素做准备的原因。这份清单可能短不了，摆出具体问题通常会比给出抽象的百分数更具说服力。

1.8　自负之恶

自负之恶是指，相比于自身需求，我们往往会低估用户的需求。成功的产品和成功的产品开发都与用户的需求息息相关，而与我们个人的需求关系不大。做大量自己不喜欢的工作一点儿也不好受，解决这一难题的诀窍是把许多人召集在一起，让他们分别干自己喜欢的部分，大家齐心协力，最大限度地提高用户满意度。如果我们喜欢的方式并非产品和用户的最佳选择，我们就常常会犯下第 11 宗罪。

第11宗罪：开发技术而非产品

大多数技术人员（尤其是产品开发者）都喜欢搞些新鲜玩意儿。他们往往会把自己的工作等同于开发新技术。但是，开发技术和开发产品是两回事（当然，两者有重叠的部分）。在产品开发过程中，技术开发在很大程度上是可选的。我们可以选择为产品创造技术，在很多情况下，我们也可以选择集成现有的技术。如果通过集成现有技术能够更快、更好、更低成本地开发出产品（通常也是这样），那何乐而不为呢？

以苹果和微软为例，这两家公司在产品开发方面一直都很成功，但是他们并未开发出什么革命性的技术，只是开发出了革命性的产品。从技术上说，苹果和微软都仿效了施乐的做法，在操作系统中使用了窗口和鼠标；苹果开发的 macOS X 和 iOS 操作系统都基于开源操作系统 FreeBSD；微软 Windows 操作系统最初运行于 MS-DOS 之上，而 MS-DOS 源于西雅图计算机产品公司授权的QDOS；Excel 和 Word 最初或多或少分别是 Lotus 1-2-3 和 WordPerfect 的仿制品；苹果引以为傲的 Siri 智能语音助手最初是从 Siri 公司购买的。诸如此类，不胜枚举。

当然，苹果和微软本身掌握着大量资源，它们具备从零开始创造新技术的能力。在上述案例中，他们必定也是愿意研发新技术的。但是，微软和苹果之所以能够取得如此巨大的成功，很大程度上源自他们致力于满足用户的需求，而非研发新技术。如果现有技术能够很好地实现用户的需求，他们很乐意购买和采用。

要想在合理的预算和工作量范围内开发出伟大的产品，关键是要学习苹果和微软的思维方式——什么对用户是最好的？这种思维方式不只存在于这两家公司，它普遍存在于所有成功开发新产品的公司中。

1.9　总结与反思

如前言所说，每 20 种新产品中只有 1 种能获得成功。本章介绍了产品开发中的一些常见错误，根据我的经验，这些错误着实很容易导致很棒的产品创意最终成为余下的那 19 种产品。

知己知彼，百战不殆，希望本章能够在一定程度上帮你达成目标。如果你是产品开发新手，希望本章能够让你了解产品开发所面临的一些重要问题。产品开发当然与软硬件密切相关，但是创建硬件和软件需要强大的策划能力、丰富的心理学知识、成熟的沟通能力，还需要遵守法律法规以及大量需要一箭命中的细节。

当然，只知道哪里会出错还不够，我们还需要知道如何避免错误、解决问题或至少缓解那些问题，本书后续内容会对此进行讲解。后文会讲解如何制订更有效的策略，在这些冰山中杀出生路，只有这样，产品的成功率才会更高，更有希望成为幸运的 1/20。

1.10　资源

本章介绍了产品开发中的基本原则和常见错误。以下几本书讲解了这方面的内容，我从中受益很多，或许对你们也有帮助。

• 《精益创业》（The Lean Startup），作者埃里克•里斯（Eric Ries）。本书的洞见是：如果我们对新产品开发中“到底什么有用”不是很清楚，最好尽早、尽可能多地失败，并从每次的失败中学习，从而朝着更好的方向前进。
• 《人月神话》（The Mythical Man-Month），作者弗雷德里克•布鲁克斯（Frederick P. Brooks）。这部经典作品虽然出版于 1975 年，但在今天仍然具有重要的指导意义。书中给出了软件开发的许多基本原则，其中最著名的当数“布鲁克斯定律”：在进度落后的项目中增加人手，只会使进度更落后。
• Systemantics: How Systems Work and Especially How They Fail，作者约翰•盖尔（John Gall）。作者风趣地讲述了在开发大型系统时可能遇到的问题，包括机器问题和人工问题。本书出版时间比较久远，市面上已经绝版，但应该能买到二手的。

图 书 推 荐

硬件产品设计与开发：从原型到交付

作者：艾伦•科恩（Alan Cohen）

译者：武传海 / 陈少芸

| 图书特色

• 涵盖从原型设计到产品交付的方方面面
• 了解导致产品开发失败的 11 宗罪
• 掌握电子产品的生产过程

本书细致讲解了产品开发流程中的策略和方法，全面介绍了产品开发中易犯的错误，制作电子产品的特点，产品定义、产品需求的撰写方法，各国法规的差异，电源的选择，用户界面的设计，智能平台的选择等。

书中以一款实用的电子产品为例，介绍了开发全流程，旨在帮助读者更好地将创意转化为成功的产品。

好了，这篇文章的内容营销圈就和大家分享到这里，如果大家对网络推广引流和网络创业项目感兴趣，可以添加微信：Sum8338 备注：营销圈引流学习，我拉你进直播课程学习群，每周135晚上都是有实战的推广引流技术和网络创业项目课程分享，当然是免费学！