作者/Jeff 编辑/儒商诗人

来源于：人人都是产品经理

作者：Jeff 姐夫

全文共 6209 字，阅读需要 13 分钟

/ BEGIN /

我负责的产品线是一个服务流程化的系统，主要是用于在销售完成售后之后，让服务人员通过系统流程化的为用户提供服务，处理业务。

这个系统包含两部分：一部分是内部服务人员使用的工单系统，一部分面向用户的H5页面——可以大致归类为一个To B的产品。

公司原有的工单系统由于是定位于SAAS系统，希望提供给行业一个通用的解决方案，然后最终发现并不能销售出去。

因此我接手这条产品线的第一个大版本就是：对整个工单系统进行的重构。

这个版本从今年四月份开始设计，到最近终于要准备上线。

5个多月期间，我经历了一个完成的产品周期，自己也从单纯设计页面，渐渐成长为可以慢慢提出自己的一些想法并推动实施的人。

虽然版本成功上线了，但由于其中走过非常多的弯路，导致开发与我们产品都是非常的疲惫。

因此我称之为一次“失败”的迭代。

成功固然可喜，但失败却十分宝贵。

通过这次失败，我踩了基本上一个刚入门的产品经理都会踩的坑。因此。我在此做一次复盘，希望大家引以为戒。

迭代后的复盘

一、沟通

作为一个产品经理，沟通是一个非常重要与关键的技能。不管是需求的获取、方案的讨论以及最终的执行，都极度依赖于产品经理的沟通能力。

关于沟通，我将分别用三个产品经理工作中最常沟通的角色来依次说明我踩到坑与解决的方法。

1.1 需求方——天坑1：需求传话筒

作为一个主要面向内部用户的产品，产品主要的需求方就是公司的服务人员。刚开始我很欣喜的发现需求方给过来的需求是如此的“明确”，甚至自带“解决方案”。

相较于普通的To C产品，一天到晚做用户调研，揣摩用户心理，然后提取需求——这种内部产品的需求沟通与获取看似如此之“简单”，作为产品经理只要画画原型，然后推动方案实现就好。

因此一开始我就抱着这种想法，一接到服务人员的需求，马上去实现，充分体现了年轻人的“朝气”与“活力”，直到有一次我踩到了下面的坑：

一次，服务人员反馈过来说，我们H5页面的提示不够详细，他们每个服务订单都需要在微信上跟用户解释与提示很多东西，希望能在H5中增加更多的提示语，同时把需求提示的地方，时机与文案都给了过来。

面对如此之“明确”需求，我当然是马上开干，拉着设计马上设计出提示语展现的样式，然后推动开发进入开发。由于只是提示语的修改，没多久版本就上线了。

一段时间之后，与服务人员一次无意中的沟通发现，他们的与客户微信沟通并没有因为提示语的上线而减少。

1.2 开发——天坑2：产品该不该懂技术

关于产品该不该懂技术，不同人有不同的看法，主要分为两种看法：

产品经理不要懂技术，过多的思考技术的实现会局限产品的创意；

产品经理应该懂点技术，这样设计的产品不至于飘在空中，不能实现。

在做产品之前，我写过一段时间的代码（几个月的网页前端）；同时由于是产品重构，是大版本，作为一个产品新人，我在前期设计的时候充分发挥了“不怕苦，不怕累”的精神，兢兢业业、勤勤恳恳的设计完了产品的每一个细节，恨不得把一天掰成两天，也因此为了赶时间，我没有与开发做任何沟通。

最终到需求评审会议上，见识了一回什么叫刀光剑影：当我讲解完我的方案时，开发马上来一句：这个基于我们现有的工期安排与技术架构，是无法实现的。

结果，在过完第一次评审之后，我把设计方案做了大幅度的调整，甚至要去修改整个方案最底层的流程逻辑。

但是由于马上要第二次评审，服务重新梳理整个流程，因此，只能基于原有的方案强行修改，导致最终方案虽然可以走完整个流程，但是在某些环节的衔接上出现“畸形”。

1.3 测试——天坑3：异常情况处理

作为一个产品新人，方案设计的时候，最难的不是满足主流业务场景的需求，最难的是去思考各种异常情况与解决方案。

一个人肯定是存在思维惯性与思维盲区的。但正是这种惯性与盲区常常造成产品的各种各种BUG。

同时有些极其特殊的异常情况，有时候我们可能已经想到了，但是觉得实际使用时不会出现，因此没有出相对应的解决方案，结果到测试时会被测试各种嫌弃（当然，被QA在测试过程中检测出来已经是非常幸运了，如果是老板或者用户提出这个问题那才是真正的严重）。

我们这次版本中，有一个页面在逻辑层面做了限制，只允许同时只有一个人进入该页面；该页面中有个按钮点击之后会触发业务流程的流转，同时跳出该页面。

QA在测试的过程中，一人同时打开两个该页面（本产品是web产品，该页面只限制只用同时有一个人打开该页面，但没限制一个人大概多个该页面），在一个页面点击的触发流程的按钮，然后在另一个页面再次点击该按钮，然后就出现了BUG。

理论上，这种BUG，在用户实际使用过程中是不太会出现的，但是一旦出现，就会降低用户的产品体验。

但是从另一个角度来讲，这种异常流程的处理会消耗大量的开发资源，当这种异常流程处理提给了开发，开发会觉得你特别的“事儿”（我本来不知道这个词的，但是最近经常被开发用这个词说指摘，然而我到现在还是不太能准确理解这个词是什么意思）

二、方案设计

作为一个产品新人，接到这个版本任务时，十分兴奋。

新人常常有一个毛病，就是拼命压榨自己的时间，提高效率，巴不得马上就能完成设计，快速出成绩。

但这为我的整个方案设计埋下了很多问题。

首先是设计全局性的问题。

本次产品重构的过程中，与非常多的列表页，并且列表的字段也有很多重复的地方，然而我设计的时候直接就是凭感觉来安排每个页面每个字段的前后顺序，最终原型提交到UI手中的时候，UI不得不花时间，重新整理各个字段的前后顺序，保持所有页面的统一。

第二点是设计通用性与可扩展性的问题。我们本次设计工单系统的时候，我们把订单与工单在设计时看做一体，做了严格的一对一强耦合的关系。

结果出现了当服务人员需要关闭工单的时候，把原本不需要关闭的订单也必须一起关闭才行。

本版本也不支持一个用户一笔订单中购买多个服务的场景。为了解决这个问题，我们有不得不重新梳理订单与工单的关系，在今后的版本中将两者解耦。

第三点是设计的完美性。作为一个处女座的产品，相信很多新人会跟我一样，对自己的设计会追求完美，力争覆盖所有的用户场景，帮用户尽可能的解决所有问题，让用户用到我们产品的时候，会有一种惊喜的感觉。

在本次工单系统的设计方案中，我这很多流程环节，设置了一些在特定条件下，不需要服务人员手动去触发流程，而是系统根据一定条件，进行自动的流转。

当这个方案提交给开发的时候，遭遇到了很大的抵触：因为每种设计背后都必然会对应着开发成本，我们的开发认为这些开发成本极高，相较于对服务人员的效率提升来说是得不偿失，我们应该把这些开发精力放在解决主要矛盾上。因此这些自动流转的功能在最终需求评审的时候被砍掉。

三、最终执行

在经过千辛万苦的需求收集与方案评审之后，终于进入了开发阶段，然而此时才是万里长征第一步。

3.1 需求变更

虽然需求变更是万恶之源。然而在实际的开发，难免会出现需求的变更。

这来自于两方面：

开发在开发过程中发现实际的开发难度大于原先所设想的难度，要求砍需求或者变更需求；

我们产品自身在这过程中，发送我们原来需求存在漏洞的，需要完善与变更。

不管来自于哪方面，最终的结果都是需要变更需求。

本次迭代有一个流程环节是通过数量来控制状态的流转：需要达到一定数量才会发生流转，而之前的系统是数量一发生变化状态就流转。同时，我们每一个列表页对应着订单一个状态。

在开发这个功能的时候，我们的后端工程师发现这个状态的流转控制，开发的成本远大于原先预想，因此要求变更需求。经过一个多小时的讨论，我们最近决定把状态流转的条件跟以前保持一致，但是在一个列表页中同时承载这两个状态。

3.2 消息同步

另外一点，前期设计的时候，需求变更频繁。而当时为了赶进度，产品需求设计与UI设计处于半并行的状态。而我与与UI又没有保持及时的沟通，UI照着老的需求来设计。

因此最终输出给开发UI稿，开发实际开发的时候发现，UI稿上的文案与最终需求文档存在较大出入，开发不得不两边来回对照，耗费大量时间。

3.3 新人与需求的完善度

第三点是，本次版本开发过程，中途加入了两个新入职的开发与一个测试。

在设计之初时，由于开发都是一直是在做工单系统。因此有些需已有的功能，在描述时没有十分的详细。常常描述为：“与现有保持一致”。

然而当新人加入之后，由于对之前版本不了解，开发时只能凭借自己的感觉去开发。到最终测试的时候发现，很多原有的功能与交互出现了问题，最终又花了大量的实际去修改。

失败后的反思

一、沟通

1.1 与需求方沟通

在运营或者其他公司内部人员沟通需求时，他们经常会根据他们当前业务遇到的问题，直接向我们产品提出一些十分明确的需求。

但由于他们不是专业的产品，而且业务人员往往容易陷入在具体的业务中，导致他们提出的一些需求只能解决片面的或者当前业务中一小部分的问题，而不能通盘去考虑最优的方案。

因此在与业务人员沟通需求时，我们可以使用“5个Why”的方法：就是对于一个事情，连着追问5个为什么（当然，5只是一个通常的数量，需要根据实际情况进行增减）

例如，有个人跟你说,他需要你给他造一把锤子。当你接收到这个需求时，按照5个Why的方法追问他：

Q：你为什么要一把锤子？

A：我需要在墙上钉一个钉子。（第一层）

Q：为什么要在墙上钉一个钉子？

A：因为我要在墙上挂一幅画。（第二层）

Q：为什么需要在墙上挂一幅画？

A：因为我的房间太单调了。（第三层）

Q：为什么会觉得房间太单调了？

A：因为我女朋友不喜欢我的房间。（第四层）

Q：为什么你女朋友不喜欢你的房间？

A：因为她觉得这个房间没有家的感觉。（第五层）

你看当我们连着追问5个为什么之后，我们就会发现：锤子只是问题的表象。

问题的根源是：他的女朋友没有家的感觉。

因此我们最应该解决的是：让他女朋友有个家的感觉，而不是简单的给他一把锤子。

当然上述的例子，在实际的工作中，有些时候由于资源限制（人力，时间，成本，公司方向等），我们可能无法直接解决第五层的问题，当时当你了解到第五层原因时，会对你理解与解决前几层的问题有非常大帮助：可以帮助你精确的定位问题与问题的边界，同时也会让你更加理解这个需求发送的场景。

1.2 与开发沟通

产品需不需要懂技术，业界一直争论，没有定论，我只是根据我个人的实际情况与经验总结：产品可以不动技术，甚至在设计初期可以完全不用考虑技术实现；但是当你想把一个想法准备落地时，最好先与开发进行沟通，了解下方案的技术成本。

当与开发沟通时，最好不要直接问开发一个东西能不能实现。

如果你这样问只会有两个结果：一个是技术万能，啥都可以做；一个是当前技术架构不支持，不能做。

当与开发沟通时，你最好把我们当前用户遇到问题与对这个问题的思考先告知开发。让他知道我们为什么要设计这样的方案。

同时，如果可以，准备多个方案与开发进行沟通，让他们从技术角度选择一个最友好的方案。

你会发现当你做到以上这两点，有时开发不仅不会来反对一些技术成本大的方案，反倒他会从技术角度给你提出一些你没有想到的方案。

1.3 与测试沟通

测试经常会提出很多异常流程的处理问题，这种异常流程包含两种：一是我们设计之初就没有考虑到的异常流程；一个是实际运用中不可能触发异常流程或者极小触发的异常流程。

作为一个测试，他的本职工作是找出产品设计或者开发中的问题，至于解不解决我们产品应该根据实际情况进行权衡：

对于前一种异常流程，没啥好解释的，赶紧认错，修改需求，完善异常流程的处理；

对于后一种异常流程，我的建议是跟开发沟通下覆盖成本，如果成本极大那就放过这些异常情况（仅针对内部工具而言，TO C的产品最好做到尽善尽美）。

与测试沟通时，注意尽量不要说：你这个问题不是问题（提出的BUG不是BUG，提出的异常流程不是异常流程）。当你这么说的时候，作为一个测试会很容易觉得你在否定他的工作。

当他提出一个异常流程而你觉得不需要去覆盖时，你可以说：恩，这个流程是会出现你说的这种异常，但是我觉得XXXX，所以我觉得可以不要去覆盖。一般来说，只要你的理由合理，测试是不会来跟你纠结的。

二、设计

2.1 异常流程

产品设计使我们作为一个产品的本职工作与技能。

作为一个产品新人（包括我自己），常常有一个毛病：想快速的完成任务，快速的出成绩，得到别人的认同。

这种着急的心态，常常导致我们做产品设计时会陷入正常的业务流程中，而没有考虑异常流程的处理。

关于异常流程的处理，有一个七字真言在实际的工作中，十分的实用：增删改查显算传。

增删改很好理解：就是当数据增加、删除、修改时页面会出现什么情况；查就是怎么获取数据，这包括筛选，搜索，排序；显的意思是数据该怎么显示，算是页面内的数值是怎么得到的，怎么计算的；传是各种各样数据是怎么传输的，实时还是非实时，哪些需要提交服务器或者从服务器获取等等。

2.2 全局性

在我们公司，有KPI的评级体系：当你把本职工作做到最好，只能得到B；只有当你对你的工作提出更好的改进方案并实施时，才能拿到A。

回到我们设计中来，我们接到一个需要，把他尽善尽美的完成，按照上述的评价标准，你最好只能是个B。

那怎么拿到A呢？那就是产品设计的时候，不止考虑到当前的需求，更高考虑整个业务流程与业务的发展。设计产品的时候充分考虑全局性，通用性与可扩展性。

要考虑到这个层次，首先要要求你本身对你所负责对接的业务流程十分熟悉，甚至熟悉程度超过该业务的业务人员。

同时在开始设计之初，先不要去考虑具体细节与流程，而是去考虑这个需求影响到现在的几个业务模块，这些业务模块与本需求需要修改的模块之间是怎样的关系，有哪些影响。

在大体设计完成之后，再去思考，本次设计方案与哪些模块发生了关系，如果关联模块发生的改变，本模块该怎么处理。

简单来说就是，需要时常跳出具体需求，把整个产品作为一体来考虑方案。

三、执行

3.1 需求变更

不管前期需求设计的多么完善，实际开发中难免会出现需求变更。引起需求变更的原因主要有两种：

开发在开发过程中发现实际的开发难度大于原先所设想的难度，要求砍需求或者变更需求；

我们产品自身在这过程中，发现我们原来需求存在漏洞的，需要完善与变更。

关于前一种需求变更，我们需要与开发讨论是否有更方便，但不会影响最终效果的方案来解决这个需求，如果由那我们可以去变更需求；若没有，那作为产品我们应该说出可以说服开发去心甘情愿大费周章去开发的理由，同时也需要考虑到项目可能延期带来的后果。

关于后一种需求，我们变更时，先去与开发沟通，承认问题，希望开发能接受这个变更。

同时不管哪种原因变更了需求，最好做到以下两点：

变更完需求，告知整个项目组，包括测试，开发，设计等；

变更完需求，记录下变更情况，包括变更内容，变更原因，变更时间，变更人。

3.2 需求完善度

当我们对某一页面的细节做了些许变更，其他没有变更时。描述清楚变更点后，可以写其他与现状保持一致。但是别忘了吧这个页面之前的需求地址给出了，方便新人对这个页面不熟悉时，也可以找到这个页面详细的需求描述。

四、总结

这是我对我第一次产品迭代的复盘与思考。希望对大家有所启发。

做了一段时间的产品经理，我慢慢发现：作为一个产品经理，本质上是一个资源的协调者——我们需要做的是在公司有限的资源下，尽可能的满足业务的发展需求。

换句话说：产品经理是用来解决“社会主义初期的主要矛盾”：业务日益增长的需求同匮乏的公司资源之间的矛盾。

因此作为一个产品经理，需要锻炼与发展的也就是资源协调的能力：这包括协调沟通能力与抽象提炼重组的能力。

/ END /