站在移动端开发人员的角度，谈谈项目开发中产品经理该如何更合理地处理需求变更和项目拖延的问题。(以前团队内部分享总结的，重新发出来)
引子：当开发人员说“技术无法实现”的时候，是想表达什么？
- 需求太傻了，完全没必要做；
比如那种根据手机壳颜色变换主题颜色的功能。
- 时间和资源不够，成本太高，不想去做；
比如项目周期就两个月，自研 IM 的功能根本完成不了，而且实现的效果未必有第三方IM功能好。
- 从项目代码上改动太大，开发人员不愿做；
比如，之前遇到一个需求：应用所有页面除了以下两种情况其余都可以调起摇一摇客服弹窗：已经有弹窗出现的时候，不能调起摇一摇客服弹窗；在客服页面或引导蒙层页面，不能调起。按照常规的实现方式，需要每个页面和每个对话框都去实现一遍是否启动摇一摇客服的逻辑，这样代码改动会很大；如果之前的页面逻辑时每个页面或对话框都是继承一个 Base 类，那实现起来就简单很多。
- 不理解这个需求的价值，认为实现这个功能没有价值；
开发不是代码机器，要交代清楚产品的需求价值。
- 自己的技术能力有限，无法实现；
- 从技术角度看，根本无法实现；
如何和开发谈需求变更？
首先思考一个问题：为什么会有需求变更？
原因可能有以下几点：
1.自己原来没想清楚，现在想明白了，需要变更需求；
2.需求方或老板的需求变了；
3.当前的市场环境变了；
4.需求文档或原型写得不清晰，或团队间的理解不统一，以为需求变了；
对于1和4是自身主观原因导致的需求变更，需要提升自身的产品能力，完善需求文档或原型；对于2和3环境的客观原因，不可控；
在自己想清楚确实需要变更需求时，需要做好以下几点，和开发沟通需求变更：
1. 更新需求文档或产品原型
口头沟通的需求，很容易被忘记，必须记录在案，方便后续撕逼，或测试做测试用例；而且开发一般也是根据需求文档或原型做开发的；2. 阐明需求变更的原因
不管是主观还是客观原因造成的需求变更，都应该主动背锅，详细说明需求变更的意义，同时要尊重开发，不要以一种“指挥”的口气下发你的需求，然后让他们干活。产品经理通常不是开发人员的老大，不能直接指挥他们，而是要说服、激励他们，让他们发挥能动性去做事，和他们沟通遇到分歧，切忌跋扈专横地做决定，要尊重他们的想法，并说出自己的设计初衷，好好商量。3.在变更需求时，一定要及时同步相关的开发人员和测试人员，避免信息不对称，出现做无用功和不必要沟通的情况；
不要出现iOS实现了新需求，而Android还是按照老需求去做；或是测试人员按照原有需求逻辑去测试新需求的情况；4. 明确好需求变更后的排期
大的需求变更，影响到项目上线时间，产品经理最好能协调延迟上线，毕竟大家按照原有项目进度都有心理预期。如果排期实在无法改变，需要大家加班时，也要提前打预防针，避免临近上线才加班赶进度，同时，加班时最好能够陪同，避免出现需求的疑问，无人解答；
如何应对项目的拖延
通常情况下工程师一般不会偷懒的，如果需要催，一般是项目流程或安排不太合理，造成拖延。项目拖延的原因以及解决办法：
1.需求的变更。产品的需求或者由于前期准备不充足或新的用户反馈需要修改，从而增加了开发时间。
解决：参考前面所说的需求变更的问题；2.开发时间的前期预估不准确。本来需要几个星期才可以完成的事情，之前过于乐观地估计了更短的时间。
开发时间预估，我见过几种：
a. 产品经理直接给开发一个截止时间；
b. 产品经理和各端(前后端、设计)组长商讨一个开发时间；
c. 产品经理和开发人员过完需求会议后，各端组长分配任务，然后让各个开发人员预估自己负责模块的开发时间，最终综合给出一个预估时间；
第1种，完全是对开发人员的不尊重，产品经理太强势，往往最终只能被迫加班赶进度；
第2种，虽然是开发时间是和各端人员商讨的，但毕竟分配任务时，不是组长去完成任务，所以开发时间肯定和实际的时间不太一致；
第3中，给足开发者以尊重，可以自己预估开发时间，而不是只能接受任务，这样的主观能动性也会强一点，一旦出现按照规定的时间完成不了任务，也就只能自觉加班了，往往最终能够按照预期完成任务；（对于加班，作为开发的角度，我觉得还是按照这种，每天规定好自己的任务和进度，不完成就自觉加班，比盲目的加班容易接受点）
所以，对于开发时间的预估，最好能够让开发人员的自己根据任务预估每项的工作量，和截止时间，这样最终如果完成不了，他们也会自觉加班。
问题：开发人员预估时间过高的怎么办？
当然会有这种可能的出现，这是就需要和小组组长协商，适量压缩时间，或者在预估时间前，先给个预期的时间，然后让他们根据需求优选级排序来预估时间。
3.沟通遇到了问题，当工程师发现某个功能其实难度非常高， 执行压力大的时候，没有尽早沟通，deadline 快到了才说，耽误了工期；
产品经理需要时刻跟进项目进度，了解开发情况；4.产品功能的设计过于烦琐，本来可以简化的功能，却花费了大量的时间，其实这个功能根本不需要浪费这么长的时间。
产品经理在开发前就应该和开发讨论需求的合理性，避免出现功能设计的过于繁杂；
5.过多无谓的会议占用了开发的时间
不要频繁开会，开会尽量要小，会议尽量要短，避免低效会议，每个参会的人都是与项目相关的，要保证“非直接负责人不参会”的原则；没必要每天站会，一周开会2-3次汇报进度即可。6.不要临近上线增加需求，或准备上线那天，才去验收产品
开发最讨厌的就是临近上线更改需求，有些需求不是特别紧急，没必要赶在上线的节骨眼去完成；同时，产品有个提前3-4天验收产品，避免出现突发意外影响上线进度。
总结
产品经理首先要提高自己的专业度，尽量减少需求的变更，更改需求，一定要说明原因；并给予开发人员足够的尊重，才能提高与开发人员协作的效率。