这里是修真院pm小课堂，每篇分享文从
【背景介绍】【知识剖析】【常见问题】【解决方案】【编码实战】【扩展思考】【更多讨论】【参考文献】
八个方面深度解析pm知识/技能，本篇分享的是：
【项目管理与需求变动的探讨 】
1.项目管理之于产品经理。
（1）项目管理的定义
项目管理的定义是：指在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望的过程。或者说运用各种相关技能、方法与工具，为满足或超越项目有关各方对项目的要求与期望，所开展的各种计划、组织、领导、控制等方面的活动。对于互联公司来说项目管理的职责划分有两种情况：
一部分公司的项目管理工作主要由项目经理来做。这种情况产品经理主要是负责市场调研、用户研究并根据用户的需求，定义和设计产品，然后考虑产品的商业模式、运营推广方式等。但是即使是这样作为产品经理你也得在一定程度上去做一些项目管理的事，主观上作为自己精心设计的产品你肯定会担心产品在实现的过程中会出现什么问题，有没有什么需要完善的，在开发那里是不是由于一些需求而耽搁下来。客观上来说影响开发的进度最大的还是需求的实现和变更上，所以项目的进度和成本质量都与产品经理息息相关。不过这时候由于项目经理的存在其实作为一个pm你对于项目管理来说只是一个辅助的作用，大部分工作都由项目经理来给你承担。
然而互联网公司更多的是产品经理来兼任项目管理的工作。我们今天主要要谈的就是这一种，产品经理的项目管理。
（2）产品经理怎么去做好项目管理
由于一个项目往往牵扯到多个部门的协作，因此整个项目进行下来，极其依赖于各个部门之间的配合。就拿现在大部分互联网公司的项目流程来说吧。一个需求或项目从立项到完成，往往需要产品、设计、开发（前、后端）、测试配合。从上图我们可以看出在项目的不同阶段，产品经理都有着不同的工作目标。而每个阶段的时间节点，也是由产品经理去把控。这就要求了产品经理对时间管理有着极其严格的要求，否则很容易出现项目delay的情况。对于我们公司来说主要流程是：客户确定需求——和开发确认技术可行性并估时——估时完成交由客户报价签合同——竞品调研，写story，画原型——和客户确认原型——Ue组内评——需求评审——需求讲解——Ui设计和开发——demo——测试——上线。
其中最容易出现问题的就是开发阶段，错误评估开发难度、开发结果与实际出入很大。这些问题均会产生一系列连锁反应，可能导致测试阶段无法正常进行，或导致项目Delay。但这并不是说一定都是开发的责任，产品经理也要承担一定责任。可能由于产品的需求不明确，或者中间又加了一些需求再或漏掉了效果图上的交互细节。
因此，基于以上的问题所在，产品经理需要定期去了解项目开发进度，把控开发时间。
比如说，开发说可能要延期，那产品经理需要知道延期的原因。到底是开发评估时间过少还是中间有新的需求插入。如评估时间过少，要了解是什么原因导致的，是开发前期疏忽漏掉了一些功能的工作量还是其他什么原因。如是新需求插入，则需由产品评估需求的优先级，评估好优先级后要去协调是否可以把一些需求放在下一期做以保证项目进度的及时完成。在此过程中，要有合理的掌握度，既不能对项目进度完全不知，又不能频繁的去问开发，以免因打断开发思考而被打。最好是在项目开发的中间阶段，抽时间和开发开个项目进度会，了解一下当前进度，并对开发阶段遇到的问题进行引导、解决。另外据我了解咱们公司每天开发都会开一个晨会并发一个晨报这也是及时了解开发进度的途径。
另外做好时间节点的重要性。
2.需求变动之于产品经理
需求变动要分阶段来考虑，要是再交付开发人员之前需求变动还算能接受，我们视具体变动情况来考虑，但是如果是在开发过程中或者几近开发完成时那简直是噩梦。这里讨论的是外包公司的场景，对于做自己公司产品来说大同小异。
（1）需求变动的场景
当我们把原型画好提交给开发，程序员们辛辛苦苦的熬了很多通宵、加班后，产品完成了一半甚至已经完成了客户提出的功能需求，客户、企业用户突然改变了需求，不想这么做了，提出了新的需求，新的变动，这样对于我们整个团队来说，正如晴天霹雷，很恐怖的事情啊，因为有时候，用户只是简单的一句话，但是对于系统的调整来说工作量是非常大的。
需求变更，本应是客户的权力，但确实也为我们的开发工作带来了很多问题。如果确需变更，当然要满足客户需要。问题是不能让变更权力滥用，把一些无关痛痒的变更宠惯养成堂而皇之的变更。对于客户提出的变更，无论大小都给予解决，客户对此是非常满意，然而，项目进度却拖的很长，项目一再延期，这样导致开发小组中的部分成员有些不耐烦了，来一点需求，修改一点，这样确实很烦人的，作为pm你也很有可能彻底得罪了一波开发人员。
但是如何我们对客户的要求一概不理，自顾自地按照最初的需求和计划实施，最终很可能由于没有用户的参与，使得系统与用户的需求相差甚远，导致验收通不过，甚至可能导致项目的收款困难。
（2）为什么会出现需求变动
现实中的软件开发就是这样，新开发的软件不可能一次性全部都提出来，可能客户自己都不知道自己想要开发软件是什么样子，只是简单的实现他自己的功能，咱们做出来的1.0版使他们逐步的有意识的帮助他们理清这个软件的样子。需求变更的表现形式是多方面的，如客户临时改变想法、客户的习惯、项目预算增加或减少、国家政策的改变、客户对功能需求改变等。我们理解了这些就会明白用户变更需求的合理性。所以我们要正确的认识客户的这种需求变更，应以平和对等的心态来面对。
（3）怎么正确去面对需求变动
作为PM有一个好的应对方案会使变更需求这一问题在开始阶段就会把影响降到最低。
（1）合同制（虽说没有法律效益，但是在一定程度上可以约束客户），咱们以后要让客户知道需求变更的代价；在和客户接触时应该挑明态度，特别是要让他们清楚需求随意变更所带来的代价和风险。如果客户认为代价太大，那么开发人 员就没有必要及时修改，按原来的进度走，但仍要记录变更，待下一版本在修改。
（2）确认客户是否接受变更的代价
把变更需求带来的一些成本和开发周期的延长都明确的告诉客户，一定要有邮件以便需要时当成证据哦。
(3)每月变更记录上报双方领导
最后，实施顾问要将有关变更措施和记录随时抄报双方最高层留档备案，可采取简报、文件、抄报、抄送、会议等多种形式。掌握主动权，逐步让不合理的随意频繁变更，成为客户不好意思开口的尴尬事件，尽快形成正常的项目执行氛围和良好的工作习惯，也为可能受到变更所带来的责任问题留下伏笔。
（4）深入了解客户需求
最后一点也是我觉着最重要的一点，开始和客户确认需求时一定要认真仔细深入理解客户的想法。不可为了签合同而随意答应客户，具体实施要具体情况来定。 尽量在一开始就减少后续需求变动的可能性。
3.沟通的重要性
作为pm来说出了我们都知道的确认需求，做调研，写story画原型。更多的还有一项重要的能力就是沟通。我们今天谈的项目管理和需求变动都是对于一个产品经理来说沟通能力的考验。具体怎么样的沟通技巧就是因人而异，每个人都有自己的处事方式，但有一点我想说就是沟通之前想好沟通的内容和目的，有针对性的去沟通。具体方式那就看个人发挥了，语气和缓，有理有据，有争执赶紧撤，找机会再聊。
作者：想做产品的审计狗
链接：https://www.jianshu.com/p/fe08b8de66f0
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
更多内容，可以加入IT交流群565734203与大家一起讨论交流
这里是技能树·IT修真院：https://www.jnshu.com，初学者转行到互联网的聚集地