站在移動(dòng)端開發(fā)人員的角度，談?wù)勴?xiàng)目開發(fā)中產(chǎn)品經(jīng)理該如何更合理地處理需求變更和項(xiàng)目拖延的問題。

引子：當(dāng)開發(fā)人員說“技術(shù)無法實(shí)現(xiàn)”的時(shí)候，是想表達(dá)什么？

• 需求太傻了，完全沒必要做；
  比如那種根據(jù)手機(jī)殼顏色變換主題顏色的功能。

• 時(shí)間和資源不夠，成本太高，不想去做；
  比如項(xiàng)目周期就兩個(gè)月，自研 IM 的功能根本完成不了，而且實(shí)現(xiàn)的效果未必有第三方IM功能好。

• 從項(xiàng)目代碼上改動(dòng)太大，開發(fā)人員不愿做；
  比如，之前遇到一個(gè)需求：應(yīng)用所有頁面除了以下兩種情況其余都可以調(diào)起搖一搖客服彈窗：已經(jīng)有彈窗出現(xiàn)的時(shí)候，不能調(diào)起搖一搖客服彈窗；在客服頁面或引導(dǎo)蒙層頁面，不能調(diào)起。按照常規(guī)的實(shí)現(xiàn)方式，需要每個(gè)頁面和每個(gè)對(duì)話框都去實(shí)現(xiàn)一遍是否啟動(dòng)搖一搖客服的邏輯，這樣代碼改動(dòng)會(huì)很大；如果之前的頁面邏輯時(shí)每個(gè)頁面或?qū)υ捒蚨际抢^承一個(gè) Base 類，那實(shí)現(xiàn)起來就簡(jiǎn)單很多。

• 不理解這個(gè)需求的價(jià)值，認(rèn)為實(shí)現(xiàn)這個(gè)功能沒有價(jià)值；
  開發(fā)不是代碼機(jī)器，要交代清楚產(chǎn)品的需求價(jià)值。

• 自己的技術(shù)能力有限，無法實(shí)現(xiàn)；

• 從技術(shù)角度看，根本無法實(shí)現(xiàn)；

如何和開發(fā)談需求變更？

首先思考一個(gè)問題：為什么會(huì)有需求變更？
原因可能有以下幾點(diǎn)：
1.自己原來沒想清楚，現(xiàn)在想明白了，需要變更需求；
2.需求方或老板的需求變了；
3.當(dāng)前的市場(chǎng)環(huán)境變了；
4.需求文檔或原型寫得不清晰，或團(tuán)隊(duì)間的理解不統(tǒng)一，以為需求變了；

對(duì)于1和4是自身主觀原因?qū)е碌男枨笞兏?，需要提升自身的產(chǎn)品能力，完善需求文檔或原型；對(duì)于2和3環(huán)境的客觀原因，不可控；

在自己想清楚確實(shí)需要變更需求時(shí)，需要做好以下幾點(diǎn)，和開發(fā)溝通需求變更：

• 1. 更新需求文檔或產(chǎn)品原型
  口頭溝通的需求，很容易被忘記，必須記錄在案，方便后續(xù)撕逼，或測(cè)試做測(cè)試用例；而且開發(fā)一般也是根據(jù)需求文檔或原型做開發(fā)的；

• 2. 闡明需求變更的原因
  不管是主觀還是客觀原因造成的需求變更，都應(yīng)該主動(dòng)背鍋，詳細(xì)說明需求變更的意義，同時(shí)要尊重開發(fā)，不要以一種“指揮”的口氣下發(fā)你的需求，然后讓他們干活。產(chǎn)品經(jīng)理通常不是開發(fā)人員的老大，不能直接指揮他們，而是要說服、激勵(lì)他們，讓他們發(fā)揮能動(dòng)性去做事，和他們溝通遇到分歧，切忌跋扈專橫地做決定，要尊重他們的想法，并說出自己的設(shè)計(jì)初衷，好好商量。

• 3.在變更需求時(shí)，一定要及時(shí)同步相關(guān)的開發(fā)人員和測(cè)試人員，避免信息不對(duì)稱，出現(xiàn)做無用功和不必要溝通的情況；
  不要出現(xiàn)iOS實(shí)現(xiàn)了新需求，而Android還是按照老需求去做；或是測(cè)試人員按照原有需求邏輯去測(cè)試新需求的情況；

• 4. 明確好需求變更后的排期
  大的需求變更，影響到項(xiàng)目上線時(shí)間，產(chǎn)品經(jīng)理最好能協(xié)調(diào)延遲上線，畢竟大家按照原有項(xiàng)目進(jìn)度都有心理預(yù)期。如果排期實(shí)在無法改變，需要大家加班時(shí)，也要提前打預(yù)防針，避免臨近上線才加班趕進(jìn)度，同時(shí)，加班時(shí)最好能夠陪同，避免出現(xiàn)需求的疑問，無人解答；

如何應(yīng)對(duì)項(xiàng)目的拖延

通常情況下工程師一般不會(huì)偷懶的，如果需要催，一般是項(xiàng)目流程或安排不太合理，造成拖延。項(xiàng)目拖延的原因以及解決辦法：

• 1.需求的變更。產(chǎn)品的需求或者由于前期準(zhǔn)備不充足或新的用戶反饋需要修改，從而增加了開發(fā)時(shí)間。
  解決：參考前面所說的需求變更的問題；

• 2.開發(fā)時(shí)間的前期預(yù)估不準(zhǔn)確。本來需要幾個(gè)星期才可以完成的事情，之前過于樂觀地估計(jì)了更短的時(shí)間。

開發(fā)時(shí)間預(yù)估，我見過幾種：

a. 產(chǎn)品經(jīng)理直接給開發(fā)一個(gè)截止時(shí)間；
b. 產(chǎn)品經(jīng)理和各端(前后端、設(shè)計(jì))組長(zhǎng)商討一個(gè)開發(fā)時(shí)間；
c. 產(chǎn)品經(jīng)理和開發(fā)人員過完需求會(huì)議后，各端組長(zhǎng)分配任務(wù)，然后讓各個(gè)開發(fā)人員預(yù)估自己負(fù)責(zé)模塊的開發(fā)時(shí)間，最終綜合給出一個(gè)預(yù)估時(shí)間；

第1種，完全是對(duì)開發(fā)人員的不尊重，產(chǎn)品經(jīng)理太強(qiáng)勢(shì)，往往最終只能被迫加班趕進(jìn)度；
第2種，雖然是開發(fā)時(shí)間是和各端人員商討的，但畢竟分配任務(wù)時(shí)，不是組長(zhǎng)去完成任務(wù)，所以開發(fā)時(shí)間肯定和實(shí)際的時(shí)間不太一致；
第3中，給足開發(fā)者以尊重，可以自己預(yù)估開發(fā)時(shí)間，而不是只能接受任務(wù)，這樣的主觀能動(dòng)性也會(huì)強(qiáng)一點(diǎn)，一旦出現(xiàn)按照規(guī)定的時(shí)間完成不了任務(wù)，也就只能自覺加班了，往往最終能夠按照預(yù)期完成任務(wù)；（對(duì)于加班，作為開發(fā)的角度，我覺得還是按照這種，每天規(guī)定好自己的任務(wù)和進(jìn)度，不完成就自覺加班，比盲目的加班容易接受點(diǎn)）

所以，對(duì)于開發(fā)時(shí)間的預(yù)估，最好能夠讓開發(fā)人員的自己根據(jù)任務(wù)預(yù)估每項(xiàng)的工作量，和截止時(shí)間，這樣最終如果完成不了，他們也會(huì)自覺加班。

問題：開發(fā)人員預(yù)估時(shí)間過高的怎么辦？
當(dāng)然會(huì)有這種可能的出現(xiàn)，這是就需要和小組組長(zhǎng)協(xié)商，適量壓縮時(shí)間，或者在預(yù)估時(shí)間前，先給個(gè)預(yù)期的時(shí)間，然后讓他們根據(jù)需求優(yōu)選級(jí)排序來預(yù)估時(shí)間。

• 3.溝通遇到了問題，當(dāng)工程師發(fā)現(xiàn)某個(gè)功能其實(shí)難度非常高， 執(zhí)行壓力大的時(shí)候，沒有盡早溝通，deadline 快到了才說，耽誤了工期；
  產(chǎn)品經(jīng)理需要時(shí)刻跟進(jìn)項(xiàng)目進(jìn)度，了解開發(fā)情況；

• 4.產(chǎn)品功能的設(shè)計(jì)過于煩瑣，本來可以簡(jiǎn)化的功能，卻花費(fèi)了大量的時(shí)間，其實(shí)這個(gè)功能根本不需要浪費(fèi)這么長(zhǎng)的時(shí)間。

產(chǎn)品經(jīng)理在開發(fā)前就應(yīng)該和開發(fā)討論需求的合理性，避免出現(xiàn)功能設(shè)計(jì)的過于繁雜；

• 5.過多無謂的會(huì)議占用了開發(fā)的時(shí)間
  不要頻繁開會(huì)，開會(huì)盡量要小，會(huì)議盡量要短，避免低效會(huì)議，每個(gè)參會(huì)的人都是與項(xiàng)目相關(guān)的，要保證“非直接負(fù)責(zé)人不參會(huì)”的原則；沒必要每天站會(huì)，一周開會(huì)2-3次匯報(bào)進(jìn)度即可。

• 6.不要臨近上線增加需求，或準(zhǔn)備上線那天，才去驗(yàn)收產(chǎn)品

開發(fā)最討厭的就是臨近上線更改需求，有些需求不是特別緊急，沒必要趕在上線的節(jié)骨眼去完成；同時(shí)，產(chǎn)品有個(gè)提前3-4天驗(yàn)收產(chǎn)品，避免出現(xiàn)突發(fā)意外影響上線進(jìn)度。

總結(jié)

產(chǎn)品經(jīng)理首先要提高自己的專業(yè)度，盡量減少需求的變更，更改需求，一定要說明原因；并給予開發(fā)人員足夠的尊重，才能提高與開發(fā)人員協(xié)作的效率。