如何打造企业级喜爱的软件产品？

今天谈一件不是自己的专业的事，近期学习一本书《启示录》，将学习心得与大家分享一下，取个标题：如何打造企业级喜爱的软件产品?

好的产品具备三个基本条件，价值、可用性、可行性，三者缺一不可。“价值”就是客户愿意采购，是否觉得你的产品有用，有多喜欢你的设计，产品没有价值，开发团队再优秀也是无济于事的。“可用性”就是软件的功能是否实现，是否实现最佳的用户体验。“可行性”就是技术上是否可以实现，寻找可行的技术方案。

如何打造用户喜爱的产品呢？我这里将书的内容进行总结与归纳，方便大家学习，如果你正在打造一套软件产品，以下的内容可能会帮到你。

一、市场需求与机会永远不会消失殆尽

要想在市场上崭露头角，必须发现新的热点，开拓新的市场，大家都在挖空心思寻找下一个热门产品。成功的产品往往不是什么全新的事物，只是新瓶装老酒，之所以成功，是因为这个“新瓶”做得更好、更方便、更便宜，改变了消费者对以前“老酒”的印象。

谷歌初入搜索领域时，遭到了很多人的白眼，大家都认为搜索市场已经饱和，最后谷歌专注于提供有价值的信息，厚积薄发，颠覆了整个市场格局。同样的苹果公司推出iPod时，市场上的MP3播放器不下千种，广东地区做MP3的工厂就有几千家，但苹果以卓越的功能很快就引领了市场潮流。

最后，只要市场上还有蹩脚的产品就有机会。

二、只有挑选合适的产品机会，才能向用户提供实用的解决方案

创业公司必须要用灵敏的嗅觉，从纷至沓来的机遇中迅速评估、挑选出市场潜力、可行的创意，过滤那些没有价值或时机尚不成熟的点子。

评估产品的机会目的在于，淘汰馊主意，避免浪费时间和金钱，挑选合适的产品机会，团结团队，理解产品，整合资源。

为了有效地评估产品机会，应问以下十个问题：

1、产品要解决什么问题？（产品价值）

2、为谁解决这个问题？（目标市场）

3、成功的机会有多大？（市场规模）

4、怎样判断产品成功与否？（度量指标或收益指标）

5、有哪些同类的产品？（竞争格局）

6、为什么我们最适合做这个产品？（竞争优势）

7、时机合适吗？（市场时机）

8、如何把产品推向市场？（营销组合策略）

9、成功的必要条件是什么？（解决方案要满足的条件）

10、根据以上问题，给出评估结论？（继续或放弃）

上述问题并不涉及到具体的解决方案，机会评估只讨论解决什么问题，挑选我们最合适的产品机会，然后再向用户提供解决方案。

三、制定产品原则，开发正确的产品

制定产品原则意味着决定什么是重要的、什么是不重要的、哪些原则是根本性的、战略性的，哪些是临时性的、战术性的。产品原则是与公司的价值文化严格统一的，好的产品原则甚至可以激发设计产品的灵感。有了重要性之分、主次之分，当团队在产品的细节设计上有争论时，我们不妨回过头来，仔细看一下我们的产品原则。

制定产品原则，告诉你哪些产品可以做，哪些不能做。根据创业公司的愿景、使命来制定产品原则，规划产品的路线图，哪些是公司应该聚焦的产品。

四、用高保真的原型来取代说明文档

产品说明文档在不同的公司、不同的团队都要有明确的书写规范，高保真原型是最直观的产品说明文档。产品原型可以让用户验证产品的创意，加深产品经理对产品的理解，避免开发团队浪费时间和精力开发没有把握的产品。测试的作用是理解目标用户如何看待产品解决的问题，发现原型与用户期望不一致或者不相容的地方，从而完善产品。对一个用户用心的观察，可以发现产品设计中的很多细节性问题。一切的错都是产品的错，用户永远没有错，我们要明白这一点。产品经理要敢于承认自己的错误，虽然付出了心血的东西，自己很难割舍，但是我们需要明白，一旦错误的产品面向市场大众时，它所引起的损失是不可估量的。

产品说明文档包含的范围很广，名字也挺别多，有产品需求文档、市场需求文档、业务需求文档、功能规格书等等，内容覆盖范围、详细程度、文档本身的质量差别很大，就连形式也是变化多端，有的是word文档，也有Wiki页面，也有用专业的需求管理工具生成的。由于是文字，很难将产品的功能特性写清楚，结果花了大量的时间编写，却很少人阅读。

使用高保真的原型来取代说明文档，可以详细体现产品的功能需求、信息架构、用户体验、交互设计、视觉设计等。放在真实的客户面前进行可用性测试，观察他们是否清楚如何使用，是否渴望使用你的产品，只有通过可用性和价值性测试，产品说明文档才算合格，产品才值得开发。

更让人吃惊的是，使用高保真原型还可以大大缩短产品上市时间。因为已经通过测试的高保真原型彻底解决了以往需求说明文档随时修改的问题。所以与其花很多的时间去编写说明文档，既没有读，又无法测试，还不如创建高保真的原型，与团队一起测试，交给目标客户进行测试，也许要反复修改多次才能确定原型，总比开发几个月后，做出一个糟糕的产品再重新返工更划算。

五、在产品发布前，至少保证特约客户是满意的

使用特约用户是确保产品不偏离用户需求最简单有效的办法，同时也是向潜在用户宣传、推荐产品的最佳手段。寻找特约用户可以解决两个问题：深入洞察目标用户的需求，又赢得用户对产品的推荐。

虽然客户不能直接给出产品需求，但他们能帮助你确定产品需求，挑选目标客户为特约客户，配合开发团队验证产品设计、回答问题、试用软件。如果能满足特约客户的需求，他们会乐于推荐产品。

特约客户最清楚产品要解决的问题，因为这些麻烦正在困扰着他们。让特约客户提前试用产品，越早使用产品就意味着越早解决他们的麻烦。

一般不要向特约用户收软件费用，否则合作关系将会变味，我们需要的是开发产品的伙伴，不要变成特约用户开发产品，最终变为了特约客户的特定要求，而不是满足通用客户的要求。

如果在邀请特约客户时遇到困难，很可能是因为产品要解决的问题不像前面想象的那么重要，这就意味着将来也很难销售出去，如果真的出现这种情况，我们要再次验证产品的创意是否有价值，可能需要重新考虑产品计划。

六、市场调研不如尽早、反复地进行可用性测试

调研的方法有很多，包括用户研讨会、用户调查、产品使用分析、拜访用户、可用性/现场测试、同类产品分析。市场部门夸大了市场调研的作用，而产品部门只看到了其局限性。结果有的团队忽视市场调研，产品偏离了正确的方向，有的团队太依赖市场调研，陷入了偏执。值得重视的是，市场调研结果可以作为研发产品的依据和参考，但不能决定产品研发的方向。成功的产品是基于以下两点认识：深入理解用户需求，以及明白什么样的解决方案在现阶段是可行的。

建议最好的方法是尽早地、反复地进行可用性测度，观察用户使用现有产品的反应，收集反馈意见，了解他们的真实想法，从用户的视角重新审视产品，不光阅读反馈信息，更要观察，记录用户的行为和反应。

合理地利用市场调研工具和方法可以回答以下几个关键问题：

1、谁是目标用户？

2、用户会怎样使用产品?

3、用户能想明白怎样使用产品吗？障碍在哪里？

4、用户为什么选用你的产品？

5、用户喜欢产品的哪些特点？

6、用户希望如何改进产品，增加哪些功能？

七、产品迭代并不是一味地增加功能

客户说：想让我掏钱买这款产品，除非增加六项功能，不然····大多数产品团队被客户的要挟，不断地增加产品功能，很多情况下，添加的新功能不仅不会为产品增色，反而会让产品性能变得更糟糕。

一旦客户妥协，你就变成了定制软件商，开发出来的产品无法被广泛应用，没准你答应的六项功能并不让客户满意，因为到达交货之时他们才意识到这六项功能不是他们想要的。

我们可以进行请用户测试产品、向客户人员、销售人员了解情况，根据产品上的实时数据分析，通过分析这些数据，再结合产品的路线图及产品原则，列出想要添加的功能。

迭代改进产品不是简单地满足个别用户的要求，也不能对用户调查的结果照单全收，你应该找准方向，分析关键指标，有针对性地改进产品。

八、采用增量式敏捷开发模式取代传统模式，摸着石头过河

在增量式的观点中，产品开发可以切分为一个小段或区间，称为迭代，这种方法的好处是，可以增量式的快速进行验证与确认设计输出，从而提高开发质量和效率。

敏捷增量式开发在一个相对小的功能部分通过所有活动，包括所有的验证和确认活动，产生一个产品版本，然后再增量式地添加下一个功能部分。这是“深度优先”的模式。它每一个功能都是从客户的需求出发，进行设计、然后验证与确认的过程。这种小步快跑的模式，就叫迭代。

敏捷开发就是螺旋式开发，基本概念就是将产品功能切成为独立的、可以验证的小功能。这些通常是4-6周的时间，一些软件开发中会降到1-2周的时间。通过这种快速的迭代，提升项目的进度和质量。可以按照以下步骤来完成：1、产品开发任务必须可线性分拆到独立验证的部件中，也就是说，如果某一工作任务完成后，经过验证，后续的重构工作不会很多或只需少量的工作。这一点非常重要，这也是很多专家认为敏捷开发不适用硬件开发最重要的主张，因为硬件开发在迭代后重构时间过长。

2、将工作分解到5个或更多的迭代，理想的情况下，每次迭代时间长度为2-4周。

3、每次迭代结束时验证产品的质量，并修复所有的主要缺陷。

因为需求是易变的，因此不像传统开发那样，一开始就制定整个产品的详细开发计划。而是提倡小步快跑的方式来开发整个产品功能，通过一个小计划接着一个小计划，通过反复迭代，最终实现产品的自我完善。能够看出，这种短节奏、快调整的开发模式，对于传统开发模型来讲，最大的好处是灵活多变，反应敏捷，任何时候，只要市场有变化，就马上调整下一步的开发计划，甚至是彻底放弃，及时止损。

上有位朋友这比较传统开发与敏捷开发的区别，传统开发方式比喻成普通火炮，而把敏捷开发比喻成导弹，两种武器打击目标过程就能形象的说明两种模式的区别，火炮打击目标，要想打的准，则要寄托一开始够准，而对目标运动轨迹估计的够准，一旦炮弹发射出去，就无法对速度、方向进行控制了。任何瞄准偏差，没有预料到的目标移动轨迹变化，甚至风向的变化都会导致炮弹打偏，这就是传统开发的特点，一开始就要做详细的需求分析及规划，你得对产品有足够的了解，而且对需求变化不友好。

而导弹就不一样了，只要设定好目标定位，并不需要一开始就精确瞄准，导弹发射出去后，会持续的收集自己的位置、方向、速度并根据目标的方位不断的调整，最终能够较精确的长距离中目标。这就是敏捷增量式开发的特点，摸着石头小步过河模式，不需要一开始就有详细的需求分析及规划，能顺应市场需求的变化。

九、视觉美感与功能可用性同样重要

假设我们去买车，我们的客户需要什么样的车？是功能重要，还是安全，还是可靠性重要，其实我们国人更需要的是“颜值”，顾客还需要强大的功能，全景天窗，无钥匙进入，一键点火，隐藏式C柱，悬浮式车顶···国人要面子，车子是身份的象征，需要更有豪华感，空间够大。

许多企业级软件认为产品视觉设计不重要，协调的配色、优美的字体、漂亮的布局只是花哨的外表，没有实际意义，重要的是功能和价值主张，但我们坚信，视觉设计虽然不能达成功能和价值，但可以满足用户的情感需求。

如果向用户展示两款具有同样功能的产品原型，一款具有良好的视觉设计效果，另一款只是由粗糙的线框图组成，用户对两款产品的反应是截然不同的。

良好的交互设计满足产品功能、可用性的要求，而良好的视觉设计满足用户的情感需求，总之，良好的用户体验是产品交互设计、视觉设计共同合作的结果。

十、以最小可行性产品MVP推出市场

产品经理定义只满足基本要求的产品，一旦基本产品定义完成，通过用户测试，它就是一个不可分割的整体，去掉任何元素都不可能达到预期的效果，这样我们能够把开发时间减少到最小，然后，推出产品，准备下一步的产品更新迭代。

MVP因为在初期的低成本、快速而受到一些人的追捧，但他们却忽视了潜在的成本，对低质量的MVP，耗在迭代改进上的时间精力也可能要恐怖得多。而这个过程对于一个内心不够强大、热爱行业的设计师来说，很可能就慢慢磨灭了他对设计的热情，所以MVP及迭代都应参照产品路线图。

十一、产品发布后的快速响应也是改进产品的最佳时机

产品发布后，多数公司会迅速撤走为研发产品和发布产品整合的资源，急于投入下一个项目，殊不知此时正是收集反馈信息、改进产品的最佳时机。急于撤军是项目管理和产品开发流程中的大忌。只要稍微延长项目周期，观察用户对产品的反应，效果就会有天壤之别。产品发布后的几天至一周内，所有项目成员应该留出时间作为快速响应阶段。这个阶段的主要工作是快速响应、处理产品发布后的用户反馈意见。关键问题不在于是否会出现问题，产品永远不可能完美，总会存在问题，关键问题在于能多快的解决问题。

最后说一下，定义产品经理与其它角色的关系

产品经理的职责主要分为两项，评估产品机会，寻找创意；探索产品的解决方案，定义要开发的产品。现代软件团队中涉及产品经理、用户体验分析师、项目管理人员、开发团队、运维团队、产品营销人员。

产品经理与项目管理：产品经理的职责是探索（定义）有价值、可用、可行的产品；而项目管理则关注如何执行计划，按期交付产品。

产品管理与产品设计：产品设计中包含用户研究、交互设计、视觉设计、原型制作，目标是让用户明白如何使用产品，并且让用户高频率的使用。舒适的用户体验是产品管理和用户体验设计共同作用的结果。企业级的产品，用户体验是其明显的软肋，所以要想在竞争对手中脱颖而出，最简单的办法就是提供优秀的用户体验。

产品管理与技术开发：产品经理负责定义正确的产品，开发团队负责正确的开发产品。开发团队最了解哪些产品构思是可行的，同时，产品经理应该只定义最小可行性产品，当一款简单的产品投入到市场中时，观察市场中用户对它的反应，这也证明了这款产品是否受到了市场的欢迎。

综上所述，好的产品具备三个基本条件，价值、可用性、可行性，三者缺一不可。“价值”就是客户愿意采购。“可用性”就是软件的功能是否实现，是否实现最佳的用户体验。“可行性”就是技术上是否可以实现。