1. 需求期望管理
ref： http://www.woshipm.com/pd/4165949.html
好的项目管理流程，推动项目进行，提高成功率
软件需求 期望管理
需求痛点 客户期望
需求确认：
最容易忽略的事情，大家都知道，但是做好的不超过一半；
增加用户确认环节：当客户提出需求，可以出一个单据让客户签字；
确认后执行：
很多时候执行被阻断，建议初级项目经理强硬一点，执行规章制度，拒绝他们没有错；
需求确认 麻烦 管理进度的法宝 保护自己 一定要去执行
需求控制，重中之重：
减少 新增 替换
需求减少 太少见
需求新增：
按照关键时间点 稳定迭代，新增需求考虑是否对后续架构，现有的迭代计划，未来的迭代计划 有冲突？
有很大冲突或者影响 反思一下下一代的架构设计，考虑重构；
谈钱
谈影响： 掌握新增需求的原因 客户的角色，新增需求的影响： 质量无法保证、进度无法保证、成本超支，无法承担后果。讨论之后的事情大多数有利，客户收回新需求，或者客户协调领导给你新派资源。
需求替换
减掉某个需求 增加某个需求
控制好成本和资源
项目经理和产品经理必须要有足够的控制力，掌控生产工作的范围；
严格执行制度；
能够自己制定制度，这个制度就可以成为你的方法论；
识别风险：
提前、主动识别风险
养成主动识别风险的习惯，掌握市场动态
2. 时间不够瞄?准核心需求,分清主次
ref: http://www.woshipm.com/pmd/4153963.html
矛盾：
一方面，好需求需要时间挖掘和思考；
另一方面，工作的特殊性质，不允许我们有太多的思考时间。
时间，成了产品经理极大的矛盾。
产品经理的工作性质：
研发生产线的最上游： 确定了需求，设计出产品方案，激活整条产线；没有方案，研发没有活儿干，研发产线瘫痪状态。
产品经理的时间和产线密切相关，因此即使1周的完全用于思考的时间也是很宝贵的。
时间永远是奢侈品：
好的需求 值得花2个月以上的时间 持续探索和思考
工作中我们没有时间
岗位晋升，团队规模越来越大，对需求的数量和速度要求越来越高，时间矛盾也越来越重。
2.1 释放时间：
需求挖掘:产品设计:团队沟通 7:2:1
实际 3:3:4
压缩沟通时间 ： 完整的需求文档和交付文档
团队沟通的目的： 帮助团队理解产品设计，确保功能效果与产品设计相符合，可以借助需求文档和相关交付文档实现。
交付文档 沟通的替代方案。好的交付文档 应该是 开发过程中0提问。借助文档的阅读，对产品的设计没有任何疑问，文档能够清晰完整表达出产品的设计理念以及具体做法。
用沟通代替交付文档，时间损耗极其低效。
沟通很重要,产品经理要求优秀的沟通能力，但不是所有的沟通都提倡。
2.2 小需求策略
交付文档可以节省时间，对于需求的持续挖掘，远远不够；产品经验越丰富，对产品经理的要求越高，花费的时间越长。
- 渴望高价值的双向需求，
- 避之不及 单向需求
- 小需求： 成本低 不会给用户带来十分杰出的价值 ，不会对用户带来非常高的价值，陈本低不会给团队带来很大负担；每一个小需求价值有限，累积起来改善用户体验；
小需求特点：
- 小需求 带动研发生产线，快速推动研发团队，为产品经理带来较大的时间差；
- 存在很多以改善用户体验为目的的版本，产品经理花的时间少，研发投入的时间多；
小需求策略的优点：
- 多出来的时间，产品经理可以进行连续思考，对于重要需求，可以推出2个、3个小需求加以完善，争取到两虚4周的思考时间；
- 先获得较多的时间筹码，需求价值越高，花费时间越多；
注意
- 小需求仍要好好思考；否则整个产品的生产过程会极为混乱；
- 不是不需要思考的需求，而是思考时间较短的需求；
- 应急策略，不要发展成为偷懒的拖延策略，争取到的时间差应该充分利用来思考需求；
- 时间多也不要偷懒；这部分时间决定了产品经理未来的晋升空间和发展空间；
- 小需求也有期限性，依靠小需求完善版本，不能连续超过4次，也就是两个月的时间，至少挖掘一个有价值的需求；
- 连续使用多次小需求策略，降低团队的期望值，影响产品经理在团队中的影响力，向团队传递出产品经理只会修修补补、能力不足；期望产品经理 能够找到高价值的双向需求，能让产品实现几何级的增长，改善完善性质的小需求仅仅是附加品，顺手为之；
- 每个人的耐心是有限的，不过问不代表放纵，只是给到了一个比较长的观察周期，切忌调整公司和团队的耐心；