如果問一個產(chǎn)品經(jīng)理,，你最頭痛的事情是什么?估計十有八九會聽到產(chǎn)品/項目延期這個答案。
項目延期,，意味著產(chǎn)品沒有如期投入市場，意味著要開始加班加點趕進(jìn)度,，意味著可能加班加點趕出來的產(chǎn)品存在大大小小的BUG,，你原先設(shè)想的XX功能，XX體驗沒辦法實現(xiàn),，你的KPI可能會有危險,，你的年終獎可能泡湯,。。,。
為什么會延期呢?除掉人力資源和開發(fā)資源等一些我們無法改變的客觀原因之外,，我覺得重點要關(guān)注以下幾個問題：
1)前期需求討論，UI評審時間過長,，壓縮了后續(xù)開發(fā)時間
有的時候我們會陷入對某個需求細(xì)節(jié),、UI細(xì)節(jié)的反復(fù)討論。特別是在UI評審的時候,，對于設(shè)計大家都有各自審美觀,，有的人喜歡留白，有的人喜歡緊湊一點,，有的人覺得頁面豐富一點好,，有的人覺得簡潔干凈一點好。眾說紛紜,，好不容易確定下來了,，時間也沒有了。留給開發(fā)的時間自然就變少了,，但是工作量可一點都沒變,。開發(fā)們也是人，再怎么加班加點也不可避免出現(xiàn)延期和代碼質(zhì)量下降的問題,。
面對這個問題,，產(chǎn)品或者設(shè)計師應(yīng)該要：
首先，提高自己的專業(yè)度,。這是你的領(lǐng)域,，你要展現(xiàn)你的專業(yè)說服他人，而不是被老板或者其他人帶著走,。你要有自己清晰的認(rèn)識,，為什么這樣做?為什么不那樣做?這樣做的目的是什么?你的依據(jù)是什么?準(zhǔn)備多套方案，說明你個人最推薦的方案是什么?次推薦的方案是什么?最不推薦的方案是什么?一定要有理有據(jù),，如果有數(shù)據(jù)支持,，就展示你的數(shù)據(jù)!
其次，要有嚴(yán)格的截止時間點,。任何的討論如果沒有時間限制,，那就不會有結(jié)果,。你組織評審或討論的時候,，明確地告訴大家我們一定要在某個時間點達(dá)成一致，如果沒有達(dá)成一致,，那就使用我的推薦方案;
第三,，明確重點,，不要在細(xì)節(jié)上過多糾結(jié)。有的功能或者設(shè)計點,，并不是最重要的,，對用戶影響比較小，我們就不要在這個上面浪費(fèi)時間,。集中力量放在重點流程和核心頁面上,。有些時候，你留白多少,，用戶其實并沒有感知,。那為什么我們要在這樣的事情上去糾結(jié)呢?我一直認(rèn)為在這些問題上，只要不影響用戶對產(chǎn)品的使用流程,，不會讓用戶在使用過程中產(chǎn)生歧義或者誤解,，沒有必要去糾結(jié)。如果你的老板一定要這樣改,，那就改,。我們的焦點應(yīng)該始終放在產(chǎn)品的核心流程上。
2)實際開發(fā)過程中前松后緊
這個問題在實際工作中也經(jīng)常碰到,。在開發(fā)周期的評估時候,，節(jié)奏安排不當(dāng)。前面慢悠悠,，后面發(fā)現(xiàn)哇靠時間沒有了,，拼命趕進(jìn)度。
為什么會這樣呢?我不是技術(shù)出身,，但是開發(fā)同學(xué)交流下來,，感覺有兩個原因：一是對風(fēng)險點評估不充分，二是開發(fā)人員埋頭只關(guān)注自己的任務(wù),，沒有考慮相關(guān)模塊的開發(fā)時間,。
對風(fēng)險點評估不充分，這個和需求理解程度,，個人能力都有關(guān)系,。沒有充分理解需求或個人經(jīng)驗?zāi)芰]有達(dá)到一定程度，是不會或者很難預(yù)見風(fēng)險點的,。我的建議是開發(fā)在評估開發(fā)周期的時候,，可以：
將需求拆解成細(xì)化的用例。就是開發(fā)完成這一個需求,，需要涉及到哪些開發(fā)工作,，需要涉及哪些后端接口，需要涉及到哪些模塊聯(lián)調(diào),，需要測試如何測試等等,。拆解成這樣的用例,，既可以把開發(fā)周期更細(xì)化，也可以發(fā)現(xiàn)一些風(fēng)險點;
各自評估,，集中討論,。將需求拆解成用例或故事要點之后，開發(fā)同學(xué)可以按照各自情況提出自己的預(yù)計時間,。如果同一個功能,，A的工期是1個工作日，而B可能覺得要5個工作日,，兩者之間相差較大,。那這時候就要進(jìn)行討論，為什么會這樣?是否有風(fēng)險點沒有發(fā)現(xiàn)?還是誰的技術(shù)方法有問題?這樣一來,，大家都可以了解彼此的想法,，互相彌補(bǔ)自身的思考盲點;
3)需求變更
需求變更，不僅對于程序員來說是一種痛苦,，對于產(chǎn)品經(jīng)理來說也是,。我們都希望需求確定之后不要再變更，但是現(xiàn)實總是很骨感,。畢竟市場和需求可能是變動,，畢竟前期調(diào)研再充分也可能存在誤區(qū)，現(xiàn)在變更總比開發(fā)完成之后再改來的好,。
但是變更需求極有可能影響原定的計劃,，我們又該怎么辦呢?
第一，冷靜地判斷變更需求的優(yōu)先級,。這和我們評估需求優(yōu)先級一樣,，不重要不影響用戶使用的就延期安排;重要的自然往前排。這點就不贅述了;
第二,，尋找合適的解決方案;和開發(fā)同學(xué)充分討論,，實現(xiàn)新需求的方法有哪些?找到能解決問題同時時間成本最小的方案，盡量將延期影響壓到最低;
4)只關(guān)注自己的任務(wù)
這其實是很要命的一點,。只關(guān)注自己的任務(wù),，忽視了上下游相關(guān)業(yè)務(wù)模塊的聯(lián)系?？赃昕赃觊_發(fā)完了,，發(fā)現(xiàn)和XX模塊對接不上啊!這個接口設(shè)計前端用起來很麻煩啊!于是乎，我們又一起重新寫一遍,。延期的紅色警報又要響起來了,。
解決這個問題，我們可以試試：
閱讀需求文檔時,，請不要只看自己負(fù)責(zé)的模塊,，把所有需求都過一遍，理解需求的上下邏輯關(guān)系;提前和相應(yīng)的同事溝通技術(shù)方案,。這一點全靠自覺,，畢竟不這樣做最后返工的肯定有自己。
開發(fā)負(fù)責(zé)人可以在正式開發(fā)之前組織大家集中花一個時間段,，把需求疑難點,，需要彼此配合的拿出來討論。磨刀不誤砍柴工,，這會讓大家后面工作的更有效率,。
每天站立會議溝通開發(fā)進(jìn)度，就說自己做到哪里了,，有發(fā)現(xiàn)什么風(fēng)險,，需要哪些同事或者模塊來配合?也不要發(fā)什么日報，就是每天面對面溝通一下,，這個比什么效率都高,。日報只是起一個總結(jié)和匯報的作用，冷冰冰的幾句文字比不上同事之間面對面的交流,。這點對小團(tuán)隊來說特別重要,，就那么幾個人你還非要搞那么多流程，何必呢?