产品经理：改需求非我本意

之前在头条写的文章，发现头条不能直接同步到简书中来。所以手动做了同步。

说实话，说起程序员节日，说起1024，我只能想起来2的十次方是1024，完全不太理解这个数字与程序员的关系。

有人说计算机是二进制，所以1024应是程序员节日，那我说PM的节日可以是1023么？因为需求是从PM手里给到技术的，所以应该要提前一天才对，这样的顺序也符合我们做项目的流程。

工作中总有程序员吐槽产品经理，感觉这个职位是抄抄抄与传话筒的职位，开玩笑说若产品经理哪天灭绝了，反而项目的进度能更快。

赤裸裸的鄙视是存在于大量的技术人员中，所以生在技术部门的产品经理，很想谈谈改需求后产品经理的感受以及我们如何去理直气壮的向技术提出改需求。

感受1：程序员和产品经理作为相爱相杀的两者，是没有任何职位高低的。

在一个项目启动阶段，产品经理会参与到整个前期业务的梳理与讨论中，反复与业务部门沟通，以确保出具的需求文档和原型是经过业务确认过的，尽量避免技术人员在后期的反复工作。

所以当技术拿到需求时，其实已经是产品经理多次与业务撕逼筛选的结果，是一个明确的，可以进入技术阶段的输出的东西。

可以说两者的工作都是深度参与项目的，本身职位是没有任何高低的。

感受2：改需求、加需求非我所愿，一切为了项目

需求确定，给到技术进行开发时，会出现很多的意外情况，比如需求修改，需求增加等。

业务部门对于需求的确认，很多都是基于已有的经验和竞品给到的。但有时候可能是基于系统原因或者业务原因，需求在进行到一半或后期的时候，需要进行修改以满足业务需求。

当发生需求改动时，业务一般都是找到产品经理进行相关的技术确认和排期确认，以确认他们修改的是否能实现，以及修改后的排期时间表。

产品经理对于这种需求修改也很抵触，但为了项目能实现最大化的价值，也是出于职业道德，会计算已有资源，技术方案，排期时间等，给到业务一个相关回复。

能做的做，产品不会推辞；不能做的，产品经理会直接拒绝业务，以确保能按时按量的完成项目。

当产品经理将需求修改给到产品经理后，程序员就不乐意了。因为之前已经确认是最终需求，结果开发到一半，改了需求，这是他们接受不了的。很可能那他们之前的工作是白费功夫，因而对产品经理这种随意答应业务需求改动的事情深恶痛绝。

而这种改需求的事情多了后，程序员对产品经理的评价就会下降很多，有时候开玩笑吐槽产品经理，说这个职位就是个传话筒，什么需求都接。

作为产品经理，看到上述两条应该是历历在目和似曾相识的，那我们如何来避免这种程序员的吐槽呢？

1、 需求分析做好

一个项目的方案在开始阶段讨论和确定时，产品经理一定要参与，确保能获取第一手信息，避免信息或者需求在传播过程中的缺失和失真，这是我们能做好需求分析的前提。

做好了需求分析，我们就能了解整个项目的节点和流程，在业务再次改需求的时候，就能了解业务的目的和想达成的目标。这样也就有利于评判业务提出的需求是否是合理的，是否是闭环的。

所以说改需求不可怕，可怕的是前期的需求分析没有做好，导致产品经理不理解需求，只能作为一个传话筒来传递业务的需求，导致我们被diss。

2、 修改需求时需要合理评估

第一个点的需求分析做好后，那么我们就要合理评估需求了。

首先，基于现有已确认的流程，业务给到的修改需求会不会影响主流程？

如果影响主流程，那么就需要重新进行项目计划评估了。因为主流程的更改，很大几率都是已有技术功能的重构，影响到整个项目的质量和交付时间；这种情况下，只有确保领导层或者说业务leader确认，我们才能进行往下的分析工作。

如果不影响主流程，我们要基于理解业务提出需求更改目的前提，合理评估，如果不确定，请与技术人员共同来评估会更准确。

其次，修改的需求是否在业务层面能完成闭环？

业务层面的需求改动，是个性化的还是共性化的需求？

如果是个性化的需求改动，基于老郭已有的经验，这种功能能往后排就往后排。如果紧急，那也是在本次项目上线后，再技术这种个性化需求。

如果是共性化需求，分析后可以进行技术，那么邮件和相关业务确认，提前和技术沟通，重新排期。

然后，修改的需求导致的变化需要告知业务与技术，并将你的意见提出来

业务改需求后，产品经理是第一个了解和知道的。对于修改的需求，产品经理经过评估后，要告知业务与技术这种需求导致的变化，同时将你的方案提出供业务参考。

此时的需求改动和方案告知技术人员和业务后，业务再有问题，直接拉着技术人员与业务开会确认，避免产品经理隔空传达需求，保证技术人员能了解本次需求改动的背后原因。

3、 处好私人关系

平时与技术baba的私人感情要处理好，避免直接起冲突，因为产品经理的上游是技术人员，良好的私人感情，不是说巴结对方，而是说作为产品经理，你要能理解对方说什么，对方想表达什么。

只有了解这些，才能在工作中高效率的与技术人员沟通，才能避免技术人员的嫌弃，处好私人关系。

4、 向上管理

项目开发到半截，业务人员突然告知说之前提的需求因为不合规，在监管层面过不去，要修改相应的流程。

但开发不同意，因为这种做到半途而废的感觉每个人都很抵触，项目可能就此卡住。那么学会向上管理是一个有效解决这种情况的方法。

要及时将项目情况和遇到的困难向领导汇报，让两个部门的领导去沟通，这样的沟通比起作为执行角色的你更有效率。

当然办法很多，老郭只是抛砖引玉了几条，各位可结合自己的实际情况灵活处理。毕竟都是为了工作，相应的职业道德大家基本都会遵循。

总而言之吧，一个项目的完整，是整个团队的结果，并不是某一个角色，某一个部门独立能解决的。

1024是程序员节日很好，但我觉得1023作为产品经理节也不赖吧。