俗話說項目不止，問題不止。產(chǎn)品就是用來解決問題的，那么在項目過程中都會遇到哪些問題呢，寫下來記錄那些套路。也希望跟大家交流一下，大家都是怎么解決的。

1.項目初期---產(chǎn)品(戰(zhàn)略層)規(guī)劃，需求收集階段

在產(chǎn)品初期一般會經(jīng)歷需求搜集階段，那么需求的來源都在哪里呢。需求的來源有領(lǐng)導(dǎo)層提出的，業(yè)務(wù)部門，運(yùn)營部，客服部反饋的用戶意見等等，及公司內(nèi)外部人員提出的需求。自己通過數(shù)據(jù)分析需要調(diào)整的，產(chǎn)品業(yè)務(wù)層調(diào)整基礎(chǔ)框架調(diào)整，產(chǎn)品重構(gòu)等等都是需求來源。那么在這個過程中都會面臨需多問題。首先領(lǐng)導(dǎo)層提出的需求。領(lǐng)導(dǎo)層的需求往往有兩個方向。

[[207267]]

一個是大方向的做什么什么功能或者說做一個什么什么樣的平臺。一個方向就是交互層層面的流程不順，顏色不好，按鈕位置不好啊，什么的。我們內(nèi)部趣稱叫“微調(diào)需求”哈哈哈。對于與我來說一般大方向的調(diào)整都會遵從領(lǐng)導(dǎo)的。因為領(lǐng)導(dǎo)層最了解行業(yè)前沿。即使領(lǐng)導(dǎo)錯誤的決定額要跟隨。因為我們也要有試錯的。不斷的去嘗試這個市場。對于另外一個方向的我一般是回去默默搜集數(shù)據(jù)分析哪些可以分版本逐步迭代改進(jìn)。其次業(yè)務(wù)部門提出的需求他們永遠(yuǎn)站在自己的角度，要么就是自己也說不準(zhǔn)，看市場別人家是啥咱也要啥。

弄不清楚這個是否適合自己公司目前發(fā)展的現(xiàn)狀，而且來恨不得今天給你說的這個功能恨不得明天就能用了。你說你做為一個產(chǎn)品統(tǒng)籌協(xié)調(diào)呢，你說你怎么辦，怎么辦。那么你自己要有一個大局掌控和判斷的能力啊。自己要有一個判斷哪些可以做哪些不可以做。運(yùn)營部，客服部等等一些其他需求。自己要根據(jù)公司的戰(zhàn)略需求，項目需求，產(chǎn)品需求區(qū)分項目等級呢。在扯一下一般項目分5級，夠用了。

2.產(chǎn)品設(shè)計階段---原型設(shè)計，業(yè)務(wù)流程圖設(shè)計

設(shè)計階段產(chǎn)品出需求原型和業(yè)務(wù)，產(chǎn)品流程圖這個過程是一個反復(fù)溝通，確認(rèn)，調(diào)整的過程。這個過程中會出現(xiàn)爭議。這個功能不是我想要的，這里不對，不應(yīng)該這樣做了，都是問題。這時候就是你要有足夠的產(chǎn)品經(jīng)驗，要有大量的同類產(chǎn)品思維，看過市場上同類產(chǎn)品的做法。比如說業(yè)務(wù)想要這種功能但是做起來不叫復(fù)雜，比較難做。那怎么辦，是不是有另外一種做法呢。拿實際例子來講，我們的客戶回訪系統(tǒng)想要幾天回訪一個客戶想在過兩三天后再次對該客戶進(jìn)行回訪想要自動提示，經(jīng)過自己分析看市場上的客戶管理系統(tǒng)其實要一個回訪計劃列表的功能也可以解決的。

3.需求原型基本都能確定了下面就是---視覺稿交互層面的設(shè)計了

在這個階段跟設(shè)計師會有一些意見和做法看法的爭論，如果有條件允許的情況可以做用戶調(diào)研和A/B測試。如果有數(shù)據(jù)支撐可以按照數(shù)據(jù)結(jié)果來做。其實我個人對設(shè)計層面和交互層面的東西一直是你說你說你有理，婆說婆有理的。***是做一些聽取用戶的看法。

4.高保真原型產(chǎn)出以后就是開發(fā)階段了

在此階段你要有PRD文檔和高保真原型座位產(chǎn)出物與開發(fā)來進(jìn)行溝通講解需求。在這個階段開發(fā)需要評估這些需求采取什么樣的技術(shù)框架和技術(shù)語音。會遇到這功能做不了啊，比較難做啊，實現(xiàn)起來時間長啊怎么辦，怎么辦。那作為產(chǎn)品需要你來推動來把產(chǎn)品做出來呀。

首先自己也多少了解一些技術(shù)知識點，在需求評審會議之前自己先審視一下，功能邏輯師傅合理，是否是真的需要改功能，在需求評審會議的時候，大家在看你的業(yè)務(wù)流程圖，產(chǎn)品框架圖，需求原型的時候，講解需求的時候多用第三方的口吻敘述，學(xué)會講故事。千萬不要說我覺得這個功能很簡單的，少有個人主觀意識。多用數(shù)據(jù)支撐和用戶意見，領(lǐng)導(dǎo)需求。有些開發(fā)出身的產(chǎn)品經(jīng)理很容易犯這樣的錯誤。You can you do IT對吧。

5.項目測試階段---專業(yè)測試人員測試，全員測試

產(chǎn)品在測試階段同樣也會遇到一些問題，有時候會遇到測試階段的需求變更，這是最頭疼的事兒，同樣在開發(fā)過程中也會遇到，尤其在開發(fā)過程中遇到的需求變更這些需求要一分為二的對待，看那些需求是在開發(fā)進(jìn)度允許的情況下可以添加進(jìn)去的，那些大的改變是不能加進(jìn)去的，可否在下次迭代的時候添加進(jìn)去。

那這個時候就要好好審視一下前期的需求調(diào)研，用戶調(diào)研，視覺設(shè)計，交互有沒有做用戶調(diào)研，在調(diào)研過程中出現(xiàn)了差錯。說明前期的方向就是錯誤的。一般到測試階段不要在添加大的需求進(jìn)來否則項目會處在一個無休止的修改的狀態(tài)，不如早點上線驗證需求，在做進(jìn)一步的迭代和改進(jìn)。

在此階段還會遇到一些問題比如做出來的效果與實際需求不符怎么辦，氣死你。在項目過程中注意節(jié)點把控和節(jié)點質(zhì)量評估驗收。避免進(jìn)入到下一個環(huán)節(jié)項目處于一個失控的狀態(tài)，否側(cè)項目又處于一個不止何時才能上線的尷尬。

6.項目上線后---產(chǎn)品已進(jìn)入用戶使用階段

有些產(chǎn)品前期不做用戶需求調(diào)研，做出來的產(chǎn)品有些用戶會反饋流程路徑不太對了，bug，等等注意收集用戶的反饋，數(shù)據(jù)指標(biāo)的反饋。有些產(chǎn)品功能也加了，用戶的使用率不高，不能對用戶進(jìn)行更有的促活。那么我們就要反思是不是入口太深了，用戶不容易發(fā)現(xiàn)。還是設(shè)置的門檻過高。要及時調(diào)整。寫在***項目不止問題不止，作為產(chǎn)品的負(fù)責(zé)人你要面臨各種各樣的問題，十八般武藝樣樣都得懂一點兒。

要善于協(xié)調(diào)和溝通。多占在客觀的角度去看待問題和描述問題。沒有解決不了的問題，促膝而談，攤開了說，別都事兒事兒的。都是為了工作。都是一個鍋里的粥，出了事兒都得單著。只不過作為產(chǎn)品你是只是個代表，出了事兒你背著，有了榮耀那是團(tuán)隊的。不是你一個人的。在產(chǎn)品項目開發(fā)的過程中會面臨各種各樣的問題。只有把各種問題想在前面，說道這里又要扯到項目開發(fā)過程中的風(fēng)險點管理了。這個這次不說了。有問題咱解決問題就。其他別扯。