總結一下：產品前期會遇到的問題與思考

一、當咱們對客戶的需求沒有真正理解清楚時，咱們作出來的東西客戶必然不滿意。客戶只知道他不滿意，但怎樣才能使他滿意呢？他不知道，因而就在一點兒一點兒試，因而這種反覆變動就這樣發生了。若是咱們明白了這一點，深刻地去理解客戶的業務，進而想到客戶的心坎兒上去，最後作出來的東西必然是客戶滿意的。當客戶提出業務變動的時候，咱們必定不能被客戶牽着走，客戶說啥就是啥。咱們要從業務角度深刻的去分析，他爲何提出變動，提得合不合理，我有沒有更合理的方案知足這個需求。 二、咱們作需求就應當首先理解現有的管理模式，而後站在信息化管理的角度去審視他們的管理模式是否合理，最後一步一步地去引導他們按照更加合理的方式去操做與管理。 三、一個軟件項目的需求調研首先必需要進行角色分析，而後對不一樣的角色分別進行調研。 四、敏捷開發認爲，需求分析階段不可能解決全部的需求問題，所以在設計、開發、測試，直到最終交付客戶，這整個過程都應當不停地用開發的成果與客戶交流，及時得到反饋。
返回頂樓	回帖地址 已投票

一、當咱們對客戶的需求沒有真正理解清楚時，咱們作出來的東西客戶必然不滿意。客戶只知道他不滿意，但怎樣才能使他滿意呢？他不知道，因而就在一點兒一點兒試，因而這種反覆變動就這樣發生了。若是咱們明白了這一點，深刻地去理解客戶的業務，進而想到客戶的心坎兒上去，最後作出來的東西必然是客戶滿意的。當客戶提出業務變動的時候，咱們必定不能被客戶牽着走，客戶說啥就是啥。咱們要從業務角度深刻的去分析，他爲何提出變動，提得合不合理，我有沒有更合理的方案知足這個需求。 二、咱們作需求就應當首先理解現有的管理模式，而後站在信息化管理的角度去審視他們的管理模式是否合理，最後一步一步地去引導他們按照更加合理的方式去操做與管理。 三、一個軟件項目的需求調研首先必需要進行角色分析，而後對不一樣的角色分別進行調研。 四、敏捷開發認爲，需求分析階段不可能解決全部的需求問題，所以在設計、開發、測試，直到最終交付客戶，這整個過程都應當不停地用開發的成果與客戶交流，及時得到反饋。
返回頂樓	回帖地址 已投票

一、當咱們對客戶的需求沒有真正理解清楚時，咱們作出來的東西客戶必然不滿意。客戶只知道他不滿意，但怎樣才能使他滿意呢？他不知道，因而就在一點兒一點兒試，因而這種反覆變動就這樣發生了。若是咱們明白了這一點，深刻地去理解客戶的業務，進而想到客戶的心坎兒上去，最後作出來的東西必然是客戶滿意的。當客戶提出業務變動的時候，咱們必定不能被客戶牽着走，客戶說啥就是啥。咱們要從業務角度深刻的去分析，他爲何提出變動，提得合不合理，我有沒有更合理的方案知足這個需求。 二、咱們作需求就應當首先理解現有的管理模式，而後站在信息化管理的角度去審視他們的管理模式是否合理，最後一步一步地去引導他們按照更加合理的方式去操做與管理。 三、一個軟件項目的需求調研首先必需要進行角色分析，而後對不一樣的角色分別進行調研。 四、敏捷開發認爲，需求分析階段不可能解決全部的需求問題，所以在設計、開發、測試，直到最終交付客戶，這整個過程都應當不停地用開發的成果與客戶交流，及時得到反饋。
返回頂樓	回帖地址 已投票

一、當咱們對客戶的需求沒有真正理解清楚時，咱們作出來的東西客戶必然不滿意。客戶只知道他不滿意，但怎樣才能使他滿意呢？他不知道，因而就在一點兒一點兒試，因而這種反覆變動就這樣發生了。若是咱們明白了這一點，深刻地去理解客戶的業務，進而想到客戶的心坎兒上去，最後作出來的東西必然是客戶滿意的。當客戶提出業務變動的時候，咱們必定不能被客戶牽着走，客戶說啥就是啥。咱們要從業務角度深刻的去分析，他爲何提出變動，提得合不合理，我有沒有更合理的方案知足這個需求。 二、咱們作需求就應當首先理解現有的管理模式，而後站在信息化管理的角度去審視他們的管理模式是否合理，最後一步一步地去引導他們按照更加合理的方式去操做與管理。 三、一個軟件項目的需求調研首先必需要進行角色分析，而後對不一樣的角色分別進行調研。 四、敏捷開發認爲，需求分析階段不可能解決全部的需求問題，所以在設計、開發、測試，直到最終交付客戶，這整個過程都應當不停地用開發的成果與客戶交流，及時得到反饋。
返回頂樓	回帖地址 已投票

一、當咱們對客戶的需求沒有真正理解清楚時，咱們作出來的東西客戶必然不滿意。客戶只知道他不滿意，但怎樣才能使他滿意呢？他不知道，因而就在一點兒一點兒試，因而這種反覆變動就這樣發生了。若是咱們明白了這一點，深刻地去理解客戶的業務，進而想到客戶的心坎兒上去，最後作出來的東西必然是客戶滿意的。當客戶提出業務變動的時候，咱們必定不能被客戶牽着走，客戶說啥就是啥。咱們要從業務角度深刻的去分析，他爲何提出變動，提得合不合理，我有沒有更合理的方案知足這個需求。

二、咱們作需求就應當首先理解現有的管理模式，而後站在信息化管理的角度去審視他們的管理模式是否合理，最後一步一步地去引導他們按照更加合理的方式去操做與管理。

三、一個軟件項目的需求調研首先必需要進行角色分析，而後對不一樣的角色分別進行調研。

四、敏捷開發認爲，需求分析階段不可能解決全部的需求問題，所以在設計、開發、測試，直到最終交付客戶，這整個過程都應當不停地用開發的成果與客戶交流，及時得到反饋。

 

第一是要抓住關鍵角色，大領導不用說了，固然是很重要的，要注意的是從基層升上來的中層領導，他們既能深刻理解一線，又能從他們的工做中分析成果性的東西，是理解業務流程的關鍵。

第二客戶提到了一個想法，需求人員必定不要主觀的去考慮喜歡不喜歡，而是能理性的分析這個想法的可行性，除了開發的技術可行性，更重要的是用戶的業務可行性。好比用戶有一次提了一個關於後勤物品管理想法，想法很好，我問他，誰能進行這種設定和管理呢？可是他後勤方面只有一個文員MM，明顯沒法進行這樣的工做。因而這個想法就被他本身放棄了。

第三，需求須要與用戶確認，確認的話，原型是個好東西，不論是對用戶仍是開發。Excel、Axsure等等，千言萬語不如一張原型。

第四，敏捷這個東東聽起來不錯，也曾瞭解過，可是沒用過。由於敏捷不僅僅是需求的事，須要用戶、開發、測試、管理等團隊的集體做用。須要需求人員與客戶的溝通能力、項目經理的需求控制能力和開發團隊的架構設計能力。若是團隊基本上自動測試覆蓋率不超過15%，敏捷不起來。

需求分許的開始就是系統角色的劃分和邊緣系統的交互調研。肯定角色，再肯定每個角色的業務負責人或者說是需求籤字人。事情就會好辦不少

在需求分析中這些調研能夠先從一個大會議的頭腦風暴開始，充分暴露需求，在瞭解客戶業務的基礎上作每一個部門，分角色的調研。逐步完善demo

永遠不要忽視對公司組織結構的分析和區分權重，這對創建良好的客戶關係和創建客戶對我的的信任都很是重要

調研的目的就是完成一個客戶滿意的需求文檔並最好作到簽字 。

一、圍繞需求這一塊，實際上需求的撐控不是隨便找個技術人員就能夠搞定，特別是要求業務知識比較專業的行業，例如金融、保險、證券之類。合格的需求分析師決定着整個項目的成敗。

二、需求調研亦不能僅僅需求分析師去參與，適當的有技術人員參與，若分析人員不懂技術一爲的知足客戶要求，最後只會把整個技術團隊搞死，因此作需求調研的時候必定要有高級程序員一塊兒進行調研，如有架構師參與更好，調研時候瞭解了客戶需求後，由技術人員討論後直接告訴客戶實現的可能性，若特別困難能夠當面解釋清楚，通常這種狀況下客戶也能夠接受。

三、一個合格的分析師可以把控客戶的需求是必備條件之一。項目已經在開發，開發的過程當中不免客戶會對需求進行調整，添加需求。若是前期分析師對客戶的需求把握的很好，可以透徹的理解，這時的變動亦不會影響全局，可以影響的就是新加的需求。
咱們算個帳：
若項目週期60我的月，10我的的team，項目130萬，平均每個月人員各類成本13W，原計劃6個月完成此時盈利52W，毛利40%，已經很是不錯了，IBM軟件毛利也才40%左右。再細算一下，平均天天整個team成本13W/30=4333RMB,需求把握很差，多一天的時間你的盈利就少4333RMB，多一個月就是13W，若是達到10%如下毛利的，作這個項目還有什麼意義。若是你項目比較特殊，例如政府項目之類，這種算法可能就不太合適。

若是客戶還不停的加需求，項目金額能增長的話最好，不能增長就講講現有的利弊，若是項目沒有盈利公司就會撤出整個項目組，致使項目沒法完成，這確定也不是客戶想要的結果，以此來權衡客戶。

四、若項目比較大，團隊小，最好在項目成立時候盡最大努力組織這個團隊知足現有的項目須要，並在開發過程當中儘可能避免人員流失，不然後果不可思議。若實在團隊不能知足能夠和客戶進行討論，分期分階段進行，把需求劃分一期二期等.....,把大目標劃分爲小目標，繼而實現整個目標。

還有不少不少，合格的分析師須要多年的專一，不停的浸淫。