之前有一個項目，是給一家大型的國有企業(yè)做一個關于資產(chǎn)管理的APP。因為這家公司是國有企業(yè)，所以他們要求我們每周都要去他們公司一趟，畢竟兩家公司不在一個地方，隔得還是有點遠。因此通過雙方領導確定要做這個項目以后，產(chǎn)品經(jīng)理也開始慢慢的切入到這個項目中來了。

我們要做的第一步就是調研需求并收集整理需求，于是我們整理了一個需求調研計劃表。這個表主要就是從調研部門和調研時間安排2個維度來展開對客戶方的需求調研。在調研開始之前，我們準備了一個PPT，準備在調研開始之前先和各個業(yè)務部門的領導和主干業(yè)務人員開一個會議，給大家通知一下我們調研的主要內容、主要要達到的目的、調研的時間安排等。

開完會議后，我們便開始一個部門一個部門的做調研了。雖然這個項目的性質是互聯(lián)網(wǎng)性質的項目，但是我們的做法還是有點像做傳統(tǒng)IT項目那樣。做調研我們是兩個人一起，一個人負責問，而另一個人主要是負責記錄。很快的，我們便用了2天不到的時間就搞定了所有業(yè)務部門的需求調研。所謂的搞定就是指收集好了所有部門的需求并做了記錄，然后接下來就是畫原型和寫產(chǎn)品相關的文檔了。

我先用visio畫了一個關于資產(chǎn)管理的整個的業(yè)務流程圖，然后我又按照不同的模塊維度畫了幾個分開的業(yè)務流程圖。然后從邏輯上先推導這樣做是不是通的，畫好流程圖后我便開始及時的整理了需求分析文檔。其實，我們當時的需求分析文檔寫的顆粒度是很粗的，因為我們要將具體的實施方案和實施步驟放在我們的項目實施方案中來寫。然后，做完這些以后，我們便開始參照需求分析報告搞了一個概要設計文檔。

其實，在這個過程中，我們在之前做的需求分析文檔和項目實施方案這2個文檔是可以合成一個文檔來寫的，就是一個需求分析報告就可以了。而我們也是由于客戶的要求，所以將一件事做了2次。做好這些以后，由于之前我已經(jīng)將產(chǎn)品的大概的原型勾勒出來了，所以現(xiàn)在要做的主要就是再對一些地方進行調整和完善。

原型做好后，我又在原型的基礎上將產(chǎn)品的詳細設計報告和功能清單整理了出來。完成所有準備工作后，我就及時召開了一個項目內部的評審會，而此次會議的主要目的就是大家對該產(chǎn)品進行評估并提出修正意見。

會議開始后，大家都是七嘴八舌的開始了激烈的討論。有的開發(fā)同事說這個功能點之前沒有做過，估計不好做，能不能換一種方式來實現(xiàn)這個功能；又有開發(fā)說，這些細節(jié)方面的東西我在這個demo上都看不到，這個你和客戶確認過嗎？還有的開發(fā)說這個地方的功能是多余的吧，能不能刪除不要呢？

于是，在一個需求評審會議下來你會發(fā)現(xiàn)你的這次需求分析做的還是很不到位，總結起來也就是有一些幾點的問題：

1、對需求調研和分析的顆粒度做的太大了。我們只是將大的方向和大的方面的需求做到了，但是對于細節(jié)方面的東西和客戶確認的不夠，同時自己分析的也不夠深入。

2、我們對技術的理解程度不夠，開發(fā)做事是站在他們對技術的理解層面上來提出意見的。而產(chǎn)品經(jīng)理做的需求是站在用戶使用的角度上提出的問題，所以維度不同，在需求評審時就會出現(xiàn)偏差。但是，產(chǎn)品經(jīng)理如果懂技術的話，這種問題就會在設計階段就及時的規(guī)避掉了。

3、對開發(fā)過于妥協(xié)。作為產(chǎn)品經(jīng)理，我們要把控整個項目的實施進度，于是當開發(fā)提出這個問題在技術實現(xiàn)上有點難度的時候，我們總會覺得只要能夠實現(xiàn)這個功能就可以了。技術上不好實現(xiàn)，那就換一個簡單的方式甚至是不要這個功能。如果你這樣想，那就很危險了。我們是對開發(fā)妥協(xié)了，可是客戶會對我們妥協(xié)嗎？況且你實現(xiàn)的功能客戶一看就說這不是我想要的結果，此時你又要做何選擇？你是繼續(xù)要求開發(fā)必須實現(xiàn)這個功能還是極力說服客戶不要這個功能？此時你將陷入兩難的境地。所以，最好的辦法就是不對開發(fā)妥協(xié)，除非是有些地方實在是無法實現(xiàn)的時候，這個時候再和客戶溝通看是否可以換一個方式來實現(xiàn)。

所以，需求分析階段如果做的不到位或不細致，最終你會在后面的階段感受到說不清的尷尬。如果你想在后面的項目過程中好受一點，那就在需求分析上多下點功夫吧。