第8篇原创

1、研发阶段不要轻易变更需求

工作中不管是需求变更还是原型变更，这是很常见的情况。并且也会出现项目已经在研发阶段了，还出现变更的情况。对于这样的情况，大家都可以说是处变不惊，见怪不怪，处理起来也是得心应手。

看起来大家能够很好的处理这种情况，并没有什么问题，但恰恰相反，正是这样面对需求变更的处变不惊、见怪不怪，以及处理来的得心应手，从侧面突显出来产品经理的问题。

在未开发阶段的需求变更，这是一定会出现的，而且还是十分常见，有时候甚至1天变化4-5次。但当需求进入了研发阶段之后就不一样了，如果这个时候还继续需求变更，先不说这种变更是谁造成的、对于产品来说是不是良性的，但我都认为都是产品经理的问题。

因为这种变更是对研发小伙伴的不负责，对他们工作的践踏。用场景还原的话，就是研发在产品说的位置挖洞打水井，挖了几天，突然告诉研发，我们的位置错了，这个位置下面只有土没有水，我们要换个位置接着打，随后产品给了一个新位置，研发就换个位置重新来。结果挖了几天产品又说位置错了，这个时候对于研发来说不管是身体还是心理上都是双重打击。

2、需求问题要敢于发声

在管理需求的时候，面对所有的需求问题，我们都要勇于发声，拒绝任何没有依据的需求变更，发表自己对于需求的看法。下面个真实的案例。这个案例来自“晓庄同学产品笔记”号主给我们分享的案例。

话说有一天，晓庄的领导给晓庄说：“来，晓庄呀！，这个首页我觉得可以把这个功能入口放到最上面去，之后把tap栏换掉，把原tap栏切换的功能用平铺的形式展现。”说完这些，便让晓庄去修改原型并通知研发变更开发内容。

这个时候，面对领导的需求，我相信大部分产品经理都是表示，好的没有问题，之后就跑去给开发说改功能了，并且在研发那里大倒苦水，说领导是逗比，我也没有办法只能改需求，我好可怜之类的话，换取研发的“同情”，让他们“乖乖”的改代码，再和研发一起吐槽领导，吐槽完了晚上在陪着研发加班。

（我先表示，面对不可抗拒的领导需求时候，我也是这样的。毕竟领导表示我不听，我不管，我就是要要的时候。我也只能和研发一起加班画圈圈。。）

面对这种领导式需求时，除非遇见领导表示我不听，我不管，我就是要要这种极端情况，我们作为产品经理应该勇敢的站出来发声，告诉他：“可（想）以（屁）呀（吃），但是，我们需要先进行用户测试，在根据测试反馈修改方案。如果用户反馈很好的话，我们也可以快速的推出，做的更好。如果不行的话，我们能够很好及时止损。若是直接就变更的话，研发前期的研发时间就白费了”。把其中的利害关系给领导阐述清楚。一般情况下领导听后都会说没问题，你给我方案就行。

当然，如果发生了上面我说的特殊情况，那么我们可以向“晓庄同学产品笔记”号主学习，告诉领导直接我们为什么要这样设计，设计思路是什么。这样也都能够说服领导，让领导暂时放弃变更的想法。如果还是不能说服，那么我们只能先根据领导的需求进行变更，后续和研发一起加班画圈圈。。

3、会议目的以及准备

我们的日常工作中，始终是围绕着各种各样的会议和撕逼进行着，其中的会议我们可以大致分为任务汇报，例会和评审讨论会：

1、任务汇报：主要是面向领导的短会，核心是和领导信息的同步以及寻求帮助，所以在给领导做任务汇报的时候，我们要注意领导关注的内容，不需要详情的步骤。需要注意，别一开口就是我需要什么资源，但是对于什么问题一概不提，这样会使领导感到莫名其妙，随即拒绝任何的请求。所以，在汇报的时候我们说明当前进度，存在的问题以及解决方案，如果不能解决就表述需要什么帮助，完成的时间是否提前或延期，还需要哪些资源等这类型的问题。

2、例会：主要是面向研发的站会。例会的核心在信息和短时间上面，用一句话来说就是在短时间内同步大家的信息。因为信息不同步造成失误的例子比比皆是。在例会上我们需要和研发或设计同步当前进度、遇见的问题以及需要的资源，并且根据实际情况配合处理这些问题，保证进度正常推进，能够准时交付出去。最后一个是讨论会，这个讨论会也会我们开的最多了，为了寻求最好的解决方案。

3、评审讨论会：主要是解决问题的长会，在评审讨论会上，我们可以是和研发确定原型需求的问题，一起讨论是否可以实现或是进行研发分工。也可以和其他部门一起讨论新方案的可实施性，能不能实施，还有没有优化方案。还可以是大家一起对一个目标进行头脑风暴，从中寻求解决方案等等。

这三个便是工作中常见的会议，除此之外我们还需要注意：

一、明确会议干系人

不管是什么会议我们都需要事先明确干系人，要知道在会议上大家都有发言的权利。如果没有明确的干系人，任何人都能够参加，这样会使会议时间和耗损呈几何级数增长。时间大家好理解，成本的话可以按照，成本 = （参会人每个人小时平均薪资 x 会议时间）x 参会人数，计算得出。那如何明确干系人？我们可以事先和其他人一起明确职能范围，确定哪些事情谁负责，谁不负责就行，看起来很简单，但确实是一个坑。

二、明确会议核心和背景

这个更好理解，每一次会议我们都要有核心目标以及将相关背景告知所有参会人，让大家不光知道“我们来干什么”，而且还知道“在什么背景下做的”。我们可以从国家、行业、公司、团体、产品、个人上进行表述。国家：当前的国家政策、法律法规。行业：行业趋势，我们在做什么。公司：公司的战略方向以及公司资源。团队：团队背景，成员组成。产品：相似竞品，存在问题，真实情况。个人：能力侧重。

三、统筹记录

做好每一次会议的纪要，将大家的观点方案以及最终拍板结果进行记录，并且给所有参会人进行传阅签字。避免后期撕逼丢锅。

四、提前预约

要知道突然把相关干系人拉起来开个会议，大概率人员不齐。其次，大家一脸懵逼，都没准备就开始会议要么，嗯嗯啊啊的先确定，后面出事表示自己不知道。要么就是直接被喷。所有我们要提前预约，得到干系人的同意后，确定一个明确的时间，进行会议。

最后，我们还是需要控制会议的频率，不管是研发、设计或者是我们产品，相对独处的时间才是最珍贵的。研发可以专心思考代码逻辑，设计可以进入他们的“灵感时刻”，而我们也可以花更多的时间进行思考。

4、要有研发计划

我们一定要有详细的研发计划，上面清晰的记录着每个阶段，大家需要交付什么东西，同时这个阶段我们需要根据自身团队来制定，可以是天，也可以是周，甚至是月。不然没有截止时间，大家的工作就会拖来拖去，最后致使项目延期。

制定计划的时候，我们需要遵循上面的会议须知一样，先明确干系人：所有的研发、设计和测试，确定会议核心：制定详情的研发计划，告知研发背景：急不急，提前预约时间：什么时候开会，最后做好记录。并且要注意，我们是大家一起商讨出研发计划，不是个人制定，所以，要和大家一起讨论这个计划的可实施性，大家能否完成？有没有不合理的地方，然后根据大家的意见进行修改，最后得到研发计划。

有了研发计划之后，我们只需要偶尔日常例会的时候进行跟进当前进度即可，如果遇见了问题及时解决，如果因为问题需要延期，那么我们可以及时更新至研发计划中。这样增加大家工作的积极性的同时也避免了大家的加班。

总结

主要说了四个工作上的建议，分别是：研发阶段不要轻易变更需求、需求问题我们要大声说出来、会议目的以及准备、以及最后的要有研发计划。

主要说了下工作中的会议，我们要明确干系人、确定核心、讲述背景、预约时间、做好记录。

- END -