知识点PMP有哪些知识点可以迁移到产品领域( 三 ) |迁移|领域|

例如，将项目的功能点数*每个功能点的平均工时，参数估算的准确度取决于参数模型的成熟度和基础历史数据的准确性。
虽然在产品工作中一般都是研发同学估算所需工时，但是产品经理如果对工时有一套自己的估算方法，就不容易被忽悠，而且在对工时提出异议时，也能有理有据。
05 如何控制需求变更
产品工作中不可避免的问题之一就是需求变更。
需求变更和Bug一样是我们想避免但是却避免不了的，需求变更控制不好很可能会影响项目工期。而且频繁的项目变更，会打击团队的士气，同时也会影响产品经理和程序猿同学的关系，不利于建立信任关系。
并且，频繁的需求变更会带来另外一个问题：变着变着就忘记最后的结论是啥了！
因为频繁变更，有时候忙起来就会忘记更新需求文档，到最后验收的时候，产品自己都忘了最后的结论是啥，就容易造成扯皮，大家各执一词。
如果你倒霉一点，很可能还会遇到一个尴尬的事，老板经常会问这样的问题：“这个地方为啥是这么设计的，我记得当时不是这么说的啊？”
这个时候，如果你当时没有记录的话，就会一脸懵逼……飞天大锅稳稳的扛在了身上。 PMP中对于需求变更的控制非常严格，有一套完整的变更流程：

本文插图
项目经理对于不影响基准，包括时间基准、成本基准，的变更可以自己做决定，但是一旦涉及到基准的变更，就需要提交给变更控制委员会进行批准。
变更控制委员会的人员是由项目的各个关键相关方组成的，有高层领导、项目经理、研发负责人、客户代表等多个利益方组成。
所以经过他们审批批准的需求变更，大家都是知情和认可的。这样的流程能极大程度控制变更的数量，也能保证变更的质量，同时能起到及时知会各方的作用。
变更关键的一点是，不管变更有没有被批准，都需要记录到变更日志，亲身经历的血泪史证明，这真的是个好习惯！！
变更日志内容至少要包括以下四项：

当时发生的问题
提交的变更和提交人
需要变更的原因
变更被批准或被驳回的原因

这些内容方便对变更进行追溯，也可以在下次遇到类似问题的时候照搬作业，还是后面总结经验教训的素材，可以沉淀为组织资产，一箭三雕~
06 如何进行沟通
项目经理和产品经理，有一个最大的共同之处：很多时候都需要沟通，不是在开会，就是在开会的路上。
PMP总结了导致沟通不畅的九大原因：

本文插图
我们在日常沟通的时候要注意规避这些不利的因素，在沟通时要注意简洁清晰，详略得当。
什么时候应该详细，什么时候要简洁，我们可以参考下桥哈里窗格：

本文插图
桥哈里窗格分为四个象限：
1. 你知道，我知道：开放区
处于这个区域，说明是一些共同常识，这部分的沟通可以尽量简洁，比如生活常识，通用公理，行业通用术语这种。
2. 你知道，我不知道：盲目区
这是属于我的知识盲区，这种情况下，你就要尽量详细的给我描述背景，传递我理解这件事所需要的背景或者知识。
认知理论上有一个现象专门对这个进行了描述：知识的诅咒，对于我们知道的东西，往往认为这很简单，对方也肯定知道。但你要知道隔行如隔山。
3. 你不知道，我知道：隐秘区
这是我的秘密，属于我个人独有的知识。适当开放自己的隐秘区，可以增进彼此的关系。