为什么做不出好产品-从市场到研发和技术团队(210207)

今天这篇文章主要讨论对于传统企业信息化建设中的相关软件产品和业务系统。一个软件究竟如何能够算得上是好产品？简单来说软件产品的核心仍然是业务价值的创造，而对于好产品则是最大化创造了业务价值+很高的用户满意度。

软件产品和传统产品区别

对于传统产品来说用户花钱购买，产品具有使用价值。而对于软件产品其价值又在哪里？软件产品的特殊性在于没有软件产品业务照常可以运转，那软件产品的重点就变化为了通过信息化实现的自动化，软件产品是一种工具类的产品，借助产品用户可以实现更高的工作效率，工作效率的提升带来的业务更加敏捷和高效。

一个最简单思路就是只要产品完全按照用户的需求得以实现，测试完整后发布，那我们产生出来的应该就是好产品。但是这里混淆了产品和项目的概念， 项目很多时候关注的是项目目标是否真正达成，而产品最终关注的一定是业务价值是否提升和实现 。

从这个层面我们就更加容易理解产品生命周期长于项目周期，在项目启动前有业务价值驱动的产品规划和需求分析，在产品上线后有进一步的运维和使用分析。通过前面的分析，我们再把好产品的产生过程做个简单的分解：

产品过程 = 需求输入+加工和生产+输出推广。

需求输入和需求分析

在进行需求收集和分析的时候，我们更多的是关注用户究竟要什么，关注用户需求的收集和需求挖掘。那我们不得不问，我们的产品是满足那些用户的需求，满足哪些岗位的用户需求？用户提这些需求的出发点是如何的？这些需求对整个流程绩效和业务价值的提升究竟是如何的？

提出这个往往会导致我们的需求分析很纠结，原因很多时候不在于系统，而在于业务本身架构和流程设计，系统的建设往往不是在解决企业业务流程的割裂，而是在助长流程的割裂，这也是产生大量的烟囱式的业务系统的原因。

这个责任往往并不完全在业务系统开发方面，但是提出这个问题的原因在于要意识到企业架构和高端流程和数据分析对企业后续业务系统规划建设的重要性。

IT和业务系统的建设应该按优先级分期和迭代进行。那如何来分析收集到需求的优先级，对于这点我认为唯一的优先级衡量标准就在于 功能对业务价值的贡献度 。这个业务价值有很多衡量标准，但是初步考虑可以考虑的即是流程效率提升多少，系统对业务能力的支撑能力提升多少？人力资源投入节余多少，人员效率提升多少等内容。

现在我们谈UCD和交互设计，关注用户体验，可以看到易用性越来越受到重视，但是我们一定要意识到系统的易用并不一定就代表了系统本身存在的价值高。 一个系统首先是要有存在的价值，自动化了流程支撑了业务，其次再考虑如何通过易用性更好的提升效率 。对于企业内业务系统不同于传统的互联网产品，企业大型业务系统一定是存在一定的学习成本，但是我们强调掌握了这些操作和学习后你能够获取最高的使用效率。

简单总结就是在输入阶段真正关注需求后面隐含的业务领域和业务价值，而不是单纯地接受用户需求。一个好的产品不是单单地去满足需求，而是引导需求。

产品开发过程

在搞清楚了我们究竟需要生产加工什么后，接着的问题就是如何保证这个产品能够按照要求，按质按量地产生出来。在这里借助CMMI里面的一个说法：

一个好产品的产生都离不开人，流程，方法工具技术三个方面的内容。

对于软件产品开发中人相当关键，或者说团队相当关键，对于一个新产品的开发，如果想临时的去组建一个开发团队就能开发出一个好产品那简直是天方夜谭的事情。如果已经有一个成熟的磨合过的团队，那么对开发出好产品就更有信心。按敏捷方法论里面的说法，即是这个团队 建立在充分信任上的高效沟通，建立在基础技术技能上的能力互补，建立在目标一致上的团队学习。

在这个基础上对团队提出更高的要求，即 由单纯对技术的关注转化到对业务和产品价值的关注。 技术可以成就一个产品，同时也可以毁掉一个产品。团队开发功能，如果不清楚功能本身带来的业务价值，不清楚功能对用户真正带来的贡献，或者根本就不清楚功能在业务流程或业务中位置和作用，那么如何做出一个好产品？产品不是一个玩具，产品不是按照技术人员的想法，而是应该考虑最终用户的想法。从这个意义上来讲，也是我们对团队要专门分离需求人员的原因，同时需求还可以进一步分离为业务分析人员和系统分析人员。

对于流程是产品质量保证的一个关键环节，只是我们再考虑是重流程还是轻流程，是传统还是敏捷？但是我们必须要强调的一点就是 敏捷往往有更加严格的纪律和执行力，而不是抛弃流程，而是采用精益和价值驱动的思想，保留最有价值的流程 。原来我们看到有个提法叫软件作坊，这里我不认为它是一个贬义词，我们可以看看现在传统的手工业作坊，往往有更加严格和缜密的流程。问题仅仅是流程下本身的生产率问题。

再回来看工具和技术，首先一定要注意到 开发人员要避免技术狂热型，很多时候成也技术，败也是技术。没有最好的技术，只有最适合的技术 。我们可以看到现在很多还采用PHP开发的互联网内容管理网站，这些网站都是很好的产品，类似当前敏捷项目管理工具禅道就是PHP语言开发的。

对于技术和工具的选择一个重点就是 满足需求+开放扩展性 ，产品的开发过程本身也是迭代形式的，只要技术有良好的开发扩展性就可以了，那我们可以预留足够的接口适应扩展和变化。

输出和推广

即使是内部的信息化产品，也时刻不要忽略了产品需要去推广和宣传，信息化产品开发出来后的实施往往才是产品最终能否成功的一个关键问题。对于实施我想用产品推广和内部运营这个词，即要把产品推出去，而推出去的基础当然又是产品能够带来用户价值。

通过产品本身的功能宣传，品牌宣传，培训，后续的ITIL流程等多个方面来保证产品在推广阶段的即时响应，提升用户的满意度。同时在推广的过程中不断地收集用户的反馈意见，作为下个迭代版本的需求输入。

酒香也怕巷子深，拿我们SOA产品线举例就是一个典型的例子，虽然做过很多大集团好几千万以上规模的SOA集成平台和ESB总线项目，但是公司的品牌，产品的品牌并没有很好地推广出去，知道的人很少。如果一个好的产品没有推广出去，没有更多的客户使用，不仅仅是产品本身业务价值的实现问题，同样也导致产品很难持续迭代改进和优化。

团队和技术而非过程本身

一个好产品必须是可用加可行，可用代表会产生价值，可行代表可以实现。一个软件产品要成功最终的衡量标准还是用户的使用和喜爱程度。用户经常会主动想起来要用你的软件，即成功一半，用户在用的过程中感觉很易用，即成功了一大半。

现在有两组人，一组是技能全部达标但是个性突出不喜欢受太多约束的人；一组是技能不达标，工作态度都挺好的人。要真正能够成就一个好产品必须选择第一组人，因为第一组人唯一要做的就是统一产品愿景和目标，激发激情。

人和过程始终是两个重要的概念，高度自治的团队是自发的而不是被动接受。

一个平庸的团队再好的过程也只能做出平庸的产品 ，特别是当我们期望在产品开发过程中实践培养团队成员的时候，我们将受到巨大的考验。影响力是一个大的群体在团队心智成熟的时候不断影响加入的人，以大影响小，而不是一两个优秀的人就能够简单的影响到整个团队。

团队对整个产品核心功能所能够实现核心业务价值的共识是另外一个做出好产品的基础 ，软件产品开发和传统制造最大的区别在于产品设计和产品制造过程并不能简单机械化的分割，即使编码活动也是一项创造性的活动。

如果团队成员每个人都只能讲清楚自己做的一两个模块，而无法对整个系统全貌有一个清晰的了解，无法清楚自己做的模块在整个系统中的位置，无法知道模块和其他模块如何协同满足了业务需求。那么整个产品仅仅是简单的零件组装，很难集成和协同。

开发人员也应该清楚整体业务和流程， 开发人员只关注技术，不关注业务；只关注单个功能，不关注流程实现。或者说团队中需求分析根本就不到位，如果在需求眼里看到的都只是一个个孤立的功能点或用例，而不是一个完整的业务场景或流程，那么产品注定是失败的。产品价值正是在于多功能模块间的协同来完成业务目标。

闭门造车是另外一个做不出好产品的原因。 当我们没有具体的目标用户，或者找不到目标用户进行调研和访谈的时候，我们是否该凭空的想象业务系统功能？我们做的系统现在是否有相关的业界参考？我们在模仿其他类似系统的时候是否是完全照搬？为了解决或回答这些问题，一是尽可能地参考和学习业界标准和经验，一是遵循产品构思和设计思路，尽可能早的和用户进行原型设计的确认和验证。 做产品其一解决的是明确要做的东西是用户想要的，其二才是明确要做的东西是可以实现出来的。

做技术的脱离了技术，没心思钻研技术；做技术的忙着开始做管理，又没有基本的管理技能。团队岗位角色和职责的错位，从事过程和管理工作的人越多，离我们能够做出一个优秀的产品越远。团队很大，忙得死去活来的就是那几个人，长期脱离技术的可能还在那指手画脚，一大帮人在那检查你的输出而提不出任何有建设性得意见。没有人会从用户或产品化角度去思考和探索。

要做出好产品团队必须有一个好的产品基因， 这个基因不是过程和方法，而是团队成员对产品的激情，对市场的理解，对用户的尊重，对技术的兴趣。 这篇不谈过程，是意识到目标统一和技能达标的团队远远大于过程规范的重要性。正如前面说的，如果团队本身不达标，妄图通过过程改进去解决问题一开始就是错误。

理解市场并成为深度用户

如何做好一个产品？简单来讲就是要理解市场和理解产品，市场驱动产品研发，如果连市场真实需求都不清楚如何能够做好一个好的产品。在互联网时代，如果单独拿SaaS类产品来说，很多产品当前还收费，实际上可以看到即使这些产品免费估计也没有什么人会真正长期使用。即：

一个好的产品不怕收费，但是一个垃圾产品免费也无法获取流量

因此理解市场，理解用户对于产品经理来说始终都是首位的。传统的STP营销方法论仍然适用，即理解市场，细分市场，然后找到细分市场和自己的差异化定位。

做传统产品你可能还可以面对真正的用户展开需求调研和分析，但是对于互联网产品很多传统需求调研方法论行不通，因此需要转换思路。

其一是对已有竞争类产品的分析 ，微创新这个概念很好，现在多大部分产品都很难算得上完全从0到1的创新，而是微创新，因此更需要站在巨人的肩膀上去思考。把所有同行产品全部分析清楚，并真正注册使用和体验一定时间，那么你对自己的产品架构也就清楚了。

其二是短周期迭代 ，短周期迭代不是简单地缩短上线时间，更加重要的是要通过上线最小化版本来快速地获取用户需求，从用户使用过程中反馈的问题才是真实的需求。

其三是数据驱动思维， 一个全新的产品上线后进入运营和不断迭代优化阶段，而这个时候产品转运营，运营最重要的又是数据驱动。一说到运营很容易想到独立的运营团队，但是这种运营团队更多是偏于产品内容的运营，而产品经理要关注的是产品功能使用过程中采集的日志数据分析。哪些功能被高频使用，哪些功能上线无效果都应该被记录和分析。

一个好的产品经理一定是一个深度用户，懂得换位思考。

赋予产品灵魂

一个好的产品往往也会打上产品创始人或产品经理的烙印， 产品经理是能够真正赋予产品灵魂的人 ，是能够真正将一群人构建为一个核心产品团队的人，是一个能够真正实现产品价值的人。

只有产品经理的高度领袖能力和全身心的投入才可能真正将产品从0到1孵化出来，他可能没有做太多具体事务性的工作，但是却会出现在产品打造全过程中的任何关键 点。他们会参加需求调研和分析，总体产品设计，架构方案，产品测试和验证，市场推广和运营等任何关键点和关键环节。他们做的所有活动和跟踪的唯一目标就是让产品能够真正根据自己的构思和想法孵化出来，而不是在这个过程中不断地偏离轨道而没有修正。

好的产品一定需要细节的打磨

一个好的产品往往是产品经理大量实践，深思熟虑后产生的构思，不断地沉淀和细化并融入的。 试想一下，如果一个产品经理本身都做事懒散，粗枝大叶不关注细节，无法做到自律和严格要求，那么又如何确保产品经理设计的产品本身具备足够的易用性和气质。

对于软件产品来说，产品最终交付给用户的不应该仅仅是功能可用，更加重要的是软件产品使用过程中带来的美感，使用时心情的愉悦，而这些往往都需要持续的积累和打磨。而你的每一点心血都最终融入到产品气质中。