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