上周我总结了，我作为一个产品新人在第一次负责的迭代中，遇到的一些问题，犯的一些错误，主要是三方面：第一个是沟通，第二个是设计，第三个是执行。上周的文章：一个产品新人的第一次失败迭代复盘（上）我将在本文从这三个点展开来讲下我对怎么避免这些问题的方法与思考。
1 沟通
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 设计
2.1 异常流程
产品设计使我们作为一个产品的本职工作与技能。
作为一个产品新人（包括我自己），常常有一个毛病：就是想快速的完成任务，快速的出成绩，得到别人的认同。这种着急的心态，常常导致我们做产品设计时会陷入正常的业务流程中，而没有考虑异常流程的处理。
关于异常流程的处理，有一个七字真言在实际的工作中，十分的实用：增删改查显算传。
增删改很好理解：就是当数据增加、删除、修改时页面会出现什么情况；查就是怎么获取数据，这包括筛选，搜索，排序；显的意思是数据该怎么显示，算是页面内的数值是怎么得到的，怎么计算的；传是各种各样数据是怎么传输的，实时还是非实时，哪些需要提交服务器或者从服务器获取等等。
2.2 全局性
在我们公司，有KPI的评级体系：当你把本职工作做到最好，只能得到B；只有当你对你的工作提出更好的改进方案并实施时，才能拿到A。
回到我们设计中来，我们接到一个需要，把他尽善尽美的完成，按照上述的评价标准，你最好只能是个B。那怎么拿到A呢？那就是产品设计的时候，不止考虑到当前的需求，更高考虑整个业务流程与业务的发展。设计产品的时候充分考虑全局性，通用性与可扩展性。
要考虑到这个层次，首先要要求你本身对你所负责对接的业务流程十分熟悉，甚至熟悉程度超过该业务的业务人员。同时在开始设计之初，先不要去考虑具体细节与流程，而是去考虑这个需求影响到现在的几个业务模块，这些业务模块与本需求需要修改的模块之间是怎样的关系，有哪些影响。在大体设计完成之后，再去思考，本次设计方案与哪些模块发生了关系，如果关联模块发生的改变，本模块该怎么处理。
简单来说就是，需要时常跳出具体需求，把整个产品作为一体来考虑方案。
3 执行
3.1 需求变更
不管前期需求设计的多么完善，实际开发中难免会出现需求变更。引起需求变更的原因主要有两种：
- 一是开发在开发过程中发现实际的开发难度大于原先所设想的难度，要求砍需求或者变更需求；
- 二是我们产品自身在这过程中，发现我们原来需求存在漏洞的，需要完善与变更。
关于前一种需求变更，我们需要与开发讨论是否有更方便，但不会影响最终效果的方案来解决这个需求，如果由那我们可以去变更需求；若没有，那作为产品我们应该说出可以说服开发去心甘情愿大费周章去开发的理由，同时也需要考虑到项目可能延期带来的后果。
关于后一种需求，我们变更时，先去与开发沟通，承认问题，希望开发能接受这个变更。
同时不管哪种原因变更了需求，最好做到以下两点：
- 变更完需求，告知整个项目组，包括测试，开发，设计等；
- 变更完需求，记录下变更情况，包括变更内容，变更原因，变更时间，变更人。
3.2 需求完善度
当我们对某一页面的细节做了些许变更，其他没有变更时。描述清楚变更点后，可以写其他与现状保持一致。但是别忘了吧这个页面之前的需求地址给出了，方便新人对这个页面不熟悉时，也可以找到这个页面详细的需求描述。
4 总结
这是我对我第一次产品迭代的复盘与思考。希望对大家有所启发。
做了一段时间的产品经理，我慢慢发现，作为一个产品经理，本质上是一个资源的协调者，我们需要做的是在公司有限的资源下，尽可能的满足业务的发展需求。换句话说，产品经理是用来解决“社会主义初期的主要矛盾”：业务日益增长的需求同匮乏的公司资源之间的矛盾。
因此作为一个产品经理，需要锻炼与发展的也就是资源协调的能力：这包括协调沟通能力与抽象提炼重组的能力。
相关阅读
一个产品新人的第一次失败迭代复盘（上）
作者：Jeff，一个做过市场，当过运营，写过代码，创过业的产品新人。
本文由 @Jeff 姐夫 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自PEXELS，基于CC0协议
爱盈利-运营小咖秀 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；
