上半年工作，項目經驗總結。

06-02

上半年工作，項目經驗總結。

前台需求分析：

做的比較大的項目有：定製3.0項目、首頁改版項目。

定製3.0項目涉及到頁面較多，流程較複雜需要考慮的更周全更細緻，還要貼近業務流程。整個業務流程並沒有完全統一和規範，線下操作也沒有固定的套路，導致往線上轉移的時候有多重不定方案可選。方案一多，導致團隊搖擺不定，最後需要團隊決策人來進行拍板。

此項目還涉及到比較關鍵的因素為支付環節，支付環節是電商平台最終要的環節沒有之一。此環節影響到成交率，和用戶重要體驗問題。經過本次優化，解決了很多以前的嚴重問題，例如：支付方式的拓展、支付失敗和重新支付的提示選擇、支付頁面的優化等等。但是還是有一些問題沒有解決，開發團隊的不夠重視，決策者和產品團隊的思想不統一，決策者也並沒有很好的參考其他人的意見，獨斷裁決。這也是公司的弊病之一，也許大小公司都會遇到這種事情，以具體情況而定。領導的能力直接決定了團隊的發展前途。

通過此項目學習到的東西：

站在用戶的角度考慮時，往往也會出現多種解決方案和設計形式，在沒有經過數據和客戶的驗證之前，往往通過團隊的決策人的自己喜好來決定方案。只要決策人言之有理即可。
在業務流程沒有確定套路時，先窮盡枚舉所有情況，按照最長不重複業務線進行流程設計。最長不重複業務線指的是包括流程中的不重複出現的異常情況，需要考慮流程中涉及的所有人員和所有狀態，以及所有能操作的功能。
在做需求分析時，像此類新業務流程，需要考慮用戶的接受程度。如果用戶接受起來有一定難度，需要教育，則需要在流程中加入必要的說明指導文案。
需求分析時往往會陷入一種矛盾：業務流程的複雜度和設計上追求的極簡主義相矛盾。這種矛盾如何解決？答：以業務流程通順為前提，設計上的追求其次。

首頁改版項目涉及到整個公司的業務邏輯和主要戰略方向的校正，是至上而下的策略，這種需求不可能由某一個產品經理或產品團隊來做決策，因此公司領導層的話語權和決策直接影響了項目和需求的走向。公司的戰略和主要業務是什麼？如何分析？一是：看公司的組織架構。二是看公司員工的時間精力集中在什麼業務上。三是看創始人的領導方向。

做首頁改版時先要分析和整理清楚的就是，公司的主要業務是什麼，主要的優勢在哪裡，面向什麼樣的人群，這些人群的痛點是什麼，首頁需要展示出什麼樣的內容來吸引這樣的人群，以及如何幫助他們解決他們的痛點。

類似這樣的戰略業務布局時，先需要抓住主要的問題，然後也是通過分析方法對每一個問題得出設計方案：

相互獨立，完全窮盡。窮盡枚舉法，羅列出所有的可能的解決方案，然後逐一篩選。
參考其他優秀的設計方案。（此步驟在競品分析過程中）
不同角度，不同分類分析法。例如：按用戶角度分析、按公司角度分析、按領導喜好角度分析。
等等。

通過此項目學習到的東西：

思考問題的高度要提高，還有對未來的業務的規劃需要和老闆站在同一水平上。
有需求時，先不要直接著手做需求分析，像這種沒有標準答案的，沒有前人案例參考的情況下，更不能上來就做需求分析，還是要先提出問題，提出正確的問題，並和團隊大家統一思想，然後在進行後續工作。團隊統一思想，統一公司的發展方向，接下來做得事情才有意義。著急上線，也是上的一堆垃圾。所有的一切基礎是有效溝通。
大項目，需要團隊合作的進行需求分析，在團隊成員水平參差不齊的情況下，要針對不同能力的同事指定不一樣的結果標準，並指導水平較低或者新員工，有效的進行需求分析並有效產出。

後台需求分析：

做的比較大的項目有：產品需求流程、CRM客戶信息管理。

產品需求流程本來是整個後台處理流程：產品需求流程、方案需求流程、直接下單，三大流程其中之一。一期先開發了產品需求流程。產品需求流程是為了把現在線下的詢價，下單流程轉移到線上。並不是單純地把線下業務搬到線上而已，而是需要通過電子化的方式，更高效的完成工作，避免線下扯皮的情況。同時也促進供應商的電子化進行，也算是對行業做出了典範吧。

產品需求流程統一了詢價和下單兩個流程，需求分析階段需要考慮到銜接的流暢性，以及整個流程的可逆操作，保密性，各方參與的時機和操作的內容。後台需求和前台需求是不一樣的思考方式，後台需求講究更嚴謹的邏輯，以及對每一個步驟的記錄和數據留存，每個狀態的監控和操作的參與人員，許可權的區分設置。涉及的方面更多，對產品人員的挑戰越大，需要思考到每個角色每個人員的每個操作的規則，規則要合理嚴謹，要保密，要有記錄。

後台流程要遵循當下實際的線下操作流程，覆蓋線下業務場景的同時，需要考慮到各種異常情況，以及異常情況下的處理。

通過此項目學習到的東西：

流程狀態的梳理，每個狀態對應的操作要合理，狀態的描述要準確。不一定有操作才有狀態，對於每一個關鍵業務節點來說都需要一個狀態來展現，前台則不同。
參與的角色和人員多的情況下，需要考慮到每個角色參與的時機，操作，狀態，銜接。在某一個角色走異常流程時，其他角色的狀態也需要同步變化。
後台需求要儘可能的保留有用的數據記錄，為了以後對大量數據進行分析和統計，來做出更好的體驗方案。
表格設計和角色審核參與時，需要遵循線下規則，因為線下已經經過長時間的檢驗和實踐證實了這些表格和審核流程的必要性。當然也不排除線上有更優解的方案，例如：詢價表單的改造，讓銷售人員填寫的內容更多更精準，更有利於供應商報出更精準的報價。當然這也有兩面性，好的一面剛才已經說了，壞的一面是對銷售人員的要求更高，需要有更完整的用戶數據來支撐詢價，利大於弊還是弊大於利，具體的體驗需要上線後的實踐檢驗。
做產品時需要增強和努力學習的部分是對商業本質的思考，一是產品詢價單讓銷售人員填寫的更精準這是對客戶對公司對供應商都利好的策略，只不過是讓客戶輸出更多的信息。對比以前的少量數據多次報價而言，多次報價都是垃圾數據，並沒有什麼實質價值和可用性，因此更有價值的策略應該是讓詢價單更精準。二是會員等級體系的設計，對於企業用戶來說，更有利有價值的是折扣，而不是通過積分來拉攏企業採購人，這是對採購人的利好，而不是對企業有價值的利好，因此應該選擇折扣而不是積分策略。對商業價值本質的探索，有待提高！！！

CRM客戶信息管理是為了快速上線一個簡單的銷售管理客戶的工具，目的是快速讓銷售人員使用起來，跟蹤客戶，方便領導管理。其實CRM是個很大的板塊，包括客戶管理、員工管理、組織架構管理、許可權管理、日程管理、知識庫管理等等。

最基礎的部分是組織架構的管理，有組織架構才有上下級關係和部門管理。通過組織架構才能衍生出許可權管理、員工管理、客戶管理分配等功能模塊。

本次需求特殊，直接跳過了組織架構的基礎，直接到銷售管理客戶的部分。

通過此項目學到的東西：

在某需求比較著急時，可跳過一些基礎功能的建設，但是往往會導致後期做基礎功能建設時的重複工作，例如：組織架構管理上線後，需要新錄入部門、員工、上下級信息。
TO B業務和TO C業務再次展示出不同邏輯，TO B客戶的客戶信息的展示方式不同。一個企業可能對應多個部門（每個部門一個聯繫人），也可能對應一個部門。這樣的話，一個企業也就可能對應內部多個銷售人員，在這些展示方式和管理方式上是和TO C業務不同的。
項目初期，需要快速完成一些功能的開發，這時需要快速響應，完成上線。但是也需要同時對整個業務的發展做一定的規劃，對未來的業務擴展同時帶來的功能上的擴展留下餘地。