产品经理方法论
以往金蝶的产品设计师或需求规划师在做产品时，更多考虑的是功能，往往就会出现一个列表界面上有一排按钮，在我看来就是功能的罗列。这些功能其实并没有考虑用户的使用场景，这就给用户带来了困惑：一方面，用户不知道什么场景下用什么功能；另一方面，如果他们操作错误，但产品设计人员没有考虑到，就会产生一些意想不到的后果。
作为一个工具型产品，一个好的ERP产品应该能让用户在最短时间内让他找到想要的功能，能用最短路径操作产品，不用长时间在页面上逗留。一个不好的产品，首先用户找不到他想要完成的工作，不知道应该打开哪个页面，不清楚在一堆按钮中点哪一个，点了之后又莫名其妙出来一些错误提示……什么是好产品？就是不要让用户去思考的产品，关键是：怎么能做到？
这个问题的解决不能从狭义的用户体验的角度去优化，这里所说的狭义的用户体验是指交互、视觉层面的优化：给设计师一个功能点，让他们从交互、视觉上优化它，这其实是很难实现的。从根本上讲，一定要从业务场景出发，从用户诉求出发，为什么用户会需要这个功能？这也是我觉得用户体验部和业务部门的契合点。我们这边的业务人员在规划产品时，我觉得很多是没有站在用户立场上的，但我觉得你们是很有用户视角的，我看过你们整理的业务流程图、方法论、固定资产流程图等成果，那全部都是用户视角，但我们的设计人员就缺乏这样的用户视角。
那用户视角又是怎么来的呢？用户视角是基于业务场景来的，业务场景又是基于业务价值来的，所以对于这个问题，我先一层一层从最高的层级开始谈起。在我看来，我们要做的这个系统是一个软件，这个软件本身是没有价值的，是使用软件的人，以及这些人通过软件在一起协作交互，才能让软件产生价值，并且这个价值对于系统内部本身是没有意义的，他是对外部提供价值的，我们把软件、用户、协作划定在一个框架内，将其视为是一个黑盒子。
在《编写有效用例》（Writing Effective Use Cases）那本书里，它把一个目标系统叫作SUD。我们首先要搞清楚的就是：这个目标系统对外提供哪些价值？这是第一层是业务价值，说白了就是这个部门为什么存在。举个例子：资产管理这个部门为什么存在？因为这个企业会买很多固定资产，这些资产如果买过来就当成费用入账了，那企业当期的利润就会很差，同时企业也逃避了缴税。因此在做资产管理的时候，我们要了解在财务上这部分固定资产是怎么入账、怎么折旧、怎么出报表的。那么这件事的外部价值是什么呢？它是供内外部的审计人员、审计署、证监会查看的，这是为什么要做这件事的原因，也是资产管理部门对外提供的价值。
第二层是业务流程，它是从第一层业务价值出发，把黑盒子打开，你就会发现为了实现业务价值，不同的企业会有着不同的业务流程，这和企业的岗位设置有关。
对于刚才说的第一层价值，我一般会用一个用例图来表示，对于一个SUD系统而言，业务诉求就像是一个发条，驱动整个SUD系统内部运转起来。而第二层的业务流程，我一般会用泳道图来表示，我会在图上方标明用户角色，下方画出业务流程，流程的节点是用户目标，箭头是业务流转。这个流程图要越简单越好，一张图只说明一种场景，比如，同一个业务流程，主成功场景有2个，失败场景有3个，那就画5张图，而不是把5张图合成1张。这样做的好处是，每张图足够清晰，便于讨论。
从第二张图里，我们了解了一个业务流程中，每个用户都怀揣着自己的目标开始协作，那接下来就到第三层：用户目标层。用户目标，可能跟软件有关，也可能跟软件无关，我们往往说哪些是线上操作的，哪些是线下完成的，但实际上从整体来看，用户要做的就是对外提供服务。这一层关注的是，用户要完成这个目标，要怎样快速找到入口？怎样以最短的操作路径实现目标？以前我们做产品规划的时候，前两层的考量是不完整的，甚至我们直接就进入了第三层，也就是功能的罗列。
所以总结来说，我做产品的逻辑就是：从业务价值出发，根据公司的岗位及职责，梳理出业务流程，再根据流程中的用户目标，对应到产品操作和功能点上。每一个功能点，其实都是可以从上到下追溯到的。
为什么重视用户体验？如何在产品线推广用户体验的理念和方法？
我是学理科的，理工男的思维就是要知道为什么。我的第一个项目是给一个区卫生局做社区卫生服务系统，项目完成后，卫生局局长来验收，他用了之后说：我本来以为还要你教我怎么用，没想到不用教我就会了。我觉得这句话就是对我工作的最高表扬。之后，我接触了《编写有效用例》那本书，它从层次和范围的角度，把需求怎么收集、整理说得很清楚，书中还讲了如何用用例文本的方式描述需求，怎么才能站在用户的角度把需求讲清楚，这是我非常推崇的方式。
来到金蝶后，我从开发到架构师，再到产品经理，一直都在尝试推广这个方法，因为业务人员原来也是要画用例图、泳道图、原型图的，只是他并没有按照一定的层次、结构去组织。我推广这套方法的时候，并没有推翻他们原有的工作方式而一味地按照书中的方式来做，如果那样的话，我相信这件事没人会配合，要别人走出舒适区还是很困难的。我只是对工作产出的质量提高了一定的要求。比如说泳道图，我就规定上面一定是角色，下边是功能，如果节点太多，就想一想是不是能够拆掉。然后探讨业务场景、业务价值，给谁提供业务价值？外部用户的关注点在哪里？……这些问题产品人员之前没有想过，或者想过，但只存在他脑子里，现在我要把它显性化，让整个团队都知道，包括业务人员、测试、设计师、甚至开发都清楚这件事。
我最常问的三个问题就是：这个功能是给谁用的？他用这个功能是要达到什么目标？达到这个目标的最短操作路径是什么？每次做产品演示的时候，我对每个功能都反复问这三个问题，目的就是为了强化每一个产品人员、开发人员的概念，让他做设计、做功能的时候也会去问这三个问题。
金蝶云苍穹与用户体验部合作工作总结与建议
首先我觉得产品交互规范对我们产品有很大帮助，其次是在调研的时候，用户研究员和规划师之间观点的碰撞，对我们也很有启发，虽然是一个调研，但最终输出的结果完全是两套。
（1）深入合作
改进方面的话，我觉得两个部门合作得还不够深入，用户体验相关的方法和理念，业务部门本身做得不是很到位，如果未来有用户调研相关的项目，希望用户体验部的同事能够多参与进来。之前和用户体验部合作的项目，最后输出的内容让我很吃惊，因为你们是完全站在用户视角来看产品，而我们是从专业视角，以为在做专业的事情，但实际上是工程师思维，不是用户思维。我觉得基于调研结果，双方应该有更多的讨论，而不应该是输出结果后，大家各讲各的就结束了。
不过现在我们面临的问题不是通过用户调研能解决的。我在做资产管理的时候，刚才提到的用户体验的方法我从头到尾都在贯彻推行，但现在转做费用后，我一直都没有推动去做这件事。一方面是因为费用是已发布的产品，另一方面，自发布以来，研发内部的研发管理会有很多大的调整，对费用模块的冲击是很大的。所以我这段时间根本没有精力去把这个业务捋顺成我想要的样子，我也不指望别人能把这个事情捋顺。因为这些需求都存在于规划师的脑子里，所以在这方面，用户体验部的同事能支持的工作可能不多。
（2）陪伴式参与
虽然用户体验部会在产品线推广一些方法类的课程，但我看来这种授课的方式其实并不是很理想，对各业务线真正好用的不是授课、不是教师，而是教练，就是通过陪伴，遇到问题的时候能从具体的问题点上给予指导和建议，我觉得这才是打入到产品线，给产品线带来更多价值的方法。
其实在我之前，也有人推过要写用例，但都没成功，为什么？因为大家都想用现成的，直接拿来用的，如果不是现成的，那原来的办法也好使，所以就会退到原来的方式上去。所以在双方部门合作方面，我觉得你们可以采用这种陪伴式的参与，直接给到产品线以价值。
（3）了解业务
如果对业务不了解，未来双方的合作其实很难深入，但我觉得用户体验部的同事对业务的理解也不需要达到精通、专家的地步。比如说：当我给不懂财务的新员工进行培训的时候，我不会讲账要怎么记、报表怎么出、什么是勾稽关系等等，我会给他讲为什么要做这件事，先弄清楚大的概念，具体的细节点可以在做具体项目的时候，基于这个概念逐渐深入。所以我觉得对你们来说，有这种提纲挈领式的培训就够了。
理想的设计师是什么样的？
首先我觉得理想的设计师应该是能参与业务讨论的，能够跟业务人员一起就业务进行讨论；
其次我觉得工作效率要很高，当然要想提升效率，就得增加交流，如果能够每天都在一起进行探讨，我觉得对双方工作效率，以及你们学习业务都有很大帮助。现在这种交流方式，必然会省略一些细节方面的信息，这其实是跨职能团队和专业化团队之间的矛盾，我觉得也是各有利弊吧。
如何收集需求、分析需求？
需求首先来自于我们的需求规划师，他一定是这个领域的业务专家，这是用户体验部的同事不具备的。他了解这些业务，所以本身就能输出一部分功能需求；其次，来自于线上运营，EAS虽然是To B的产品，但也会通过RMP提单进行线上的运营。用户通过线上提交错误类提单、应用类提单等，需求和应用类提单就是改善我们功能最主要的两大块需求来源。所以需求规划师不仅有业务背景，并且也在不断地回复需求类和应用类提单的过程中，积累各种各样的业务场景。第三，我们会有样板客户、战略客户，他们会给我们提很多产品需求。
一般来说，对于用户需求，聪明一点的用户会告诉你他想要一个什么样的功能，但这个功能不是需求，只是他的一个解决方案。我们要问他为什么想要这个功能，按照刚才我说那三个层次去追溯分析他的业务场景。
除了这三处需求来源，其他需求主要就是通过调研收集的。如果说我们现在的工作方法有什么不足或风险点的话，那就是调研不到位，但To B产品本身的特点，又决定了它不可能和用户一起做研发。
如何排定优先级？
首先我会从产品线的完善程度地角度去排第一优先级，比如：固定资产模块现在覆盖了EAS 70%-80%的功能，而费用可能还不足，那我在接下来的资源投入上会重点做费用，来补齐短板。
其次就是对于某一个模块内的功能，如何排定优先级。这个就比较暧昧了，因为我们现在还没有用户、没有客户。如果说有明确的项目目标，如：5月4号互联网金融要上线，那与此相关的业务场景、功能需求就是要优先开发的。但像合并报表，去年没有用户也没有目标，那这种需求的优先级我们会在产品演示的时候，一方面讲一下在下一个冲刺周期，我们要完成哪些功能；另外我们会跟老大聊一下，让老大从整个产品线的角度，结合下一步的方向帮我们排定优先级。如果以上这些都没有，那就挨着顺序一个一个的做。做的过程中，我们也会结合目前的用户情况，比如：现在人人端的用户群体更多，那我们就优先做与此相关的功能。但其实无论是哪种方法，在这个产品达到最低发布门槛之前，这些都是研发内部拍脑袋决定的。To B产品跟To C产品不一样的地方就在于它必须要达到一定的程度才能发布，在达到这个标准之前，其实优先级都是最高的，除非你有明确的客户。
个性化需求与通用型需求如何平衡？
我在EAS做产品经理最大的感受就是要不断地面对各种原型客户、样板客户、集团战略客户等等。对于他们提出的需求，实施会在一个很大的表格里列出本次上线要的功能点，总部研发就像法官一样去评估，个性化的功能就要机构去实施，标准化需求总部预计什么时候上线。只要能在客户要求的时间周期内开发出补丁，这个项目就算是成功了，所以我们经常做的事情就是排各种优先级。这里边不乏有一些是适合标准产品的需求但没时间做的，就会规划进下一个版本，但对于当时这个项目就赶不上了，可能机构就会做二次开发，对于这种开发上线的功能，总部也很少会拿来放到标准产品里。在做功能需求的时候，所有都要进行权衡。
如何预估功能在市场的接受度？
一般我会问规划师这个功能的业务场景是怎样的，对于一个通用型需求，可能有很多种应用场景，我会要求规划师至少讲三个实际的业务场景，没有真实场景的时候，猜测的模拟场景也可以，我会通过这些场景来判断这样设计合不合适，同时也会要求测试重点按照这几个场景进行测试。
有时候可能一些场景，规划师也没考虑到，那就等到有真实用户提出来的时候再纳入进来考虑，我们不可能事先把所有情况都调研一遍再规划功能。产品发布出去不是完事了，而是刚刚开始，真正的改进都是在后续的运营中不断迭代实现的。
所以To B产品面临的问题比To C产品更严重，To C在一开始的时候还能找到很多用户做调研，To B初期可能一个都找不到。所以做To B产品，对规划师的业务背景、业务经验要求还是很高的。
如何积累业务经验，培养业务能力？
如果没有专业背景，做To B产品还是很难的。我一开始做财务线的产品经理的时候，看过很多财务类的书籍，也系统学习了财务会计的视频课程，不然根本就听不懂需求在说什么。
在了解了业务之后就要培养自己的产品化思维，我觉得这个过程中最重要的就是要有用户思维，要去理解用户的业务场景、业务价值。我觉得这才应该是金蝶的核心竞争力，它不应该只存在于规划师的脑子里。应该让业务场景、业务价值不断累积、不断迭代，成为大家共同的经验，在此基础上再形成不同行业的解决方案。
现在的工作方式导致业务场景、业务价值都存在于不同规划师的脑子里，而售前人员的脑子里也会有很多业务场景，他们根据不同企业的体量和行业特性，给出不同的解决方案，你会发现他们出的方案跟研发产品的落地之间是严重脱节的。如果按照我的方法来积累不同的业务场景，其实一个项目从上到下都应该是一致的，不会脱节。一个理想的情况应该是有一个列表，上面写明：费用报销有多少多少场景，Cloud支持哪些、EAS支持哪些、金蝶云苍穹支持哪些等等。我觉得这才To B产品的核心竞争力。
赞 91
打赏推荐阅读