按理來說，在小組開需求討論會時，協商需求開發進度的流程是這樣的：

提出需求→研發溝通實現方案→研發確定日期→確定日期→溝通完成→需求推進

在同研發確定需求日期時，有這么兩種處理方式。

1.根據需求，錨定時間

跟研發掰扯清楚什么時候應該做好什么功能真是一門學問。

最近老大宣布之前給研發定的目標，在約定時間截止時，完成度不到20%，消息一出，整個群里，一片死寂。

并非研發不出實力，相反，在近期996的常態加班要求中，兩個研發每天都是差不多趕到10點多下班，持續保持每周至少60個小時的工作時間，可技術壁壘單純靠時間堆砌來攻克，本身就有點自不量力。

計劃制訂者，想當然地估計目標時間，哪怕是在兩個初次接觸客戶端開發的研發已經明確表態有很多困難的前提下，還滿臉期待地望著開發，鼓勵開發同學，期待奇跡能發生。

這種yy的后果，就是整個團隊在已經付出巨大的精力和時間下，依舊面對完成度不足20%的問責而產生的由里到外的喪…

只有剛剛好的緊張氛圍是最佳的，在一個計劃周期內，去除常規化的一些工作，最好只有一個需要攻克的難題，因為只有這樣，在解鎖一個難題之后，團隊可以立刻得到一個來自其他方向的正向反饋，這樣團隊除能夠收獲解決難題的成就感，也能得到外部激勵，進而繼續保持動力。

2.調整需求，妥協時間

假如確定了在某特殊日期前（如：雙十一），要上線新的功能配合運營活動，用戶參與活動的方式，可選的可能就有聲音、面部表情捕捉、虛擬現實、手勢識別等等，為了確保在上線日期前有一套完備的功能可以滿足活動需求，與其要求研發加班加點，追趕時間地打破自身節奏，去嘗試覺醒狀態下的加班實在不一定是好的決策。

產品經理需要權衡功能點開發的權重強弱，敢于放下自己一意追求的亮眼設計，沉下心在有限的力量下面做好折衷方案，作出平凡卻不平庸的方案，如此之下，再去溝通研發，哪怕是加班也是能夠有說服力的了。