按理来说，在小组开需求讨论会时，协商需求开发进度的流程是这样的：
提出需求→研发沟通实现方案→研发确定日期→确定日期→沟通完成→需求推进
在同研发确定需求日期时，有这么两种处理方式。
1.根据需求，锚定时间
跟研发掰扯清楚什么时候应该做好什么功能真是一门学问。
最近老大宣布之前给研发定的目标，在约定时间截止时，完成度不到20%，消息一出，整个群里，一片死寂。
并非研发不出实力，相反，在近期996的常态加班要求中，两个研发每天都是差不多赶到10点多下班，持续保持每周至少60个小时的工作时间，可技术壁垒单纯靠时间堆砌来攻克，本身就有点自不量力。
计划制订者，想当然地估计目标时间，哪怕是在两个初次接触客户端开发的研发已经明确表态有很多困难的前提下，还满脸期待地望着开发，鼓励开发同学，期待奇迹能发生。
这种yy的后果，就是整个团队在已经付出巨大的精力和时间下，依旧面对完成度不足20%的问责而产生的由里到外的丧…
只有刚刚好的紧张氛围是最佳的，在一个计划周期内，去除常规化的一些工作，最好只有一个需要攻克的难题，因为只有这样，在解锁一个难题之后，团队可以立刻得到一个来自其他方向的正向反馈，这样团队除能够收获解决难题的成就感，也能得到外部激励，进而继续保持动力。
2.调整需求，妥协时间
假如确定了在某特殊日期前（如：双十一），要上线新的功能配合运营活动，用户参与活动的方式，可选的可能就有声音、面部表情捕捉、虚拟现实、手势识别等等，为了确保在上线日期前有一套完备的功能可以满足活动需求，与其要求研发加班加点，追赶时间地打破自身节奏，去尝试觉醒状态下的加班实在不一定是好的决策。
产品经理需要权衡功能点开发的权重强弱，敢于放下自己一意追求的亮眼设计，沉下心在有限的力量下面做好折衷方案，作出平凡却不平庸的方案，如此之下，再去沟通研发，哪怕是加班也是能够有说服力的了。
