從業那麼久，之前做的要不就是軟體外包，要不就是C端的產品，對於B端，或者企業內部系統還真沒怎麼接觸。

　　最近這兩年都是接觸愜意內部業務系統，其實也就那麼一回事而已，產品的設計還是那樣，只是會多了一個業務方、對接人，相比起C端使用者的不明確，需要自己去研究，自己去嘗試，企業內部業務系統，會有更明確的需求，同時也會更坑。

　　企業內部系統還有一個特點，就是偏重業務流程、偏重底層功能/邏輯的設計，而比較忽視介面、整體功能設計，畢竟做得再爛你也需要用（雖然這麼說，自己還是需要對自己有要求）。

記錄了一些坑及應對方法：

1、對接人的專業性

　　一般到了一定規模的企業，都會選擇一些統一的介面人，這些人的崗位可能是某個職能部門的負責人或者某個運營人員或者某個崗位，他們的工作職責就是將部門內的需求彙總。

　　有一些只是做意見的搬運工，有一些還會做設計或者調研。如果只是前面的搬運工那就很好，大家責任清晰就好，他們做好運營、推廣、收集。產品做好調研、設計，確保質量。

　　如果是後者，那就麻煩了，他們在收集到需求之後，會存在一定的扭曲或者優先順序安排，干擾真正的使用者需求。

應對方法：

　　A、建立自身的工作節奏，不要被對方帶著走。但是又要協調好與對方的關係，維護好良好關係。

　　B、儘量接觸一線、真實的使用者獲取最原始的需求描述，如果接觸不到，也儘量接觸到二線或者該部門的頭頭，不然被玩死都不知道怎麼事。

　　C、設計儘量通用、靈活、簡單，而不做複雜的、個性的邏輯在裡面，如將規則寫在程式碼等，儘量抽離出來，寫在配置檔案裡面，最好是通用一套邏輯而不要做過多特殊邏輯。

　　D、逐步培訓、教育對接人，提高對接人的業務調研、梳理的專業度

　　E、沒有調研清楚的需求堅定不做。一般企業內部業務系統，都是線下已經有很成熟的業務，所以線下穩定執行，再搬到線上並且優化效率。如果沒有調研清楚，沒有線下穩定執行，那線上必然也會出問題。

2、試執行的必要性及細節調整

       很多時候，做了專案或者做了一個系統出來，沒有一個試執行的階段，直接釋出，直接更新，然後直接開始下個階段的工作。但是上次的功能設計是否有問題？執行是否提高效率？最重要是上次的設計，是否就完善，不需要再調整？

       我做過很多專案，極少一上線就百分百完美，因為沒有人是完美，特別是那麼多不同性格、不同專業的人在一起做一個專案，特別是從0到1的專案，更加多意外情況發生。你當時沒想清楚，沒設計好的，都會在上線之後爆發出來。

       所以最簡單的做法，就是在真正上線之前，找一個小部門試點先執行，並且收集一波意見優化一下細節，再真正全域性推廣。

       而對於那些已經上線系統的優化迭代也同樣適用，一次大的迭代，對功能有比較大的改動的核心迭代，必然需要試執行並且有一兩個小迭代版本來優化下細節，完善下該功能。（當然儘量在上線前，產品細節、質量儘可能的好）

3、使用者想要的，不是真正的

       這個基本做產品的都會遇到，特別是企業內部的，更為艱難。因為C端產品，很多時候使用者是不會說話，只會通過一些行為或者一些場景來表達出他們的需求。

       但是企業內部業務系統，或者B端產品，他們會說出他們的需求，而且都會經過他們思維轉換。舉個例子，某個需求，他們表述想要一個“備註”功能，但是當你深入追問、瞭解他們的使用場景的時候，就會發現他們並不是想要個備註去填寫一些內容，而是想要一個可以存放證明的地方，做成一個附件上傳，會比單純“備註”更有價值，因為附件可以支援更多樣式，而備註只支援純文字。

       而且企業內部的業務系統，很多時候經過對接人的轉換，那扭曲的需求會更加嚴重，所以這對產品的要求也會更高。同時這也是很容易區分低階產品與高階產品的差異，純粹聽對方要什麼就做什麼的產品，其實只是個需求分析師。對需求進行思考，並提出多種解決方案，更好去解決使用者的問題，這種才是真正的產品經理。

4、沒有正確與否只有適合與否

       企業內部的系統，大多是基於企業線下業務，核心業務流程其實全世界都一樣，就是進銷存啊一進一出這樣（幾乎所有系統，都是輸入、處理、輸出三步驟）。但是每個公司的業務細節都不一樣，很多時候遇到業務部門要求A，但是經過調研瞭解外面的通用設計，應該設計成B。但是業務部門就堅持A，那這種情況下，就只能做A了。

       為什麼呢？因為你找誰來判斷A還是B合適呢？我曾經看見過兩個總監在討論一個事情，明白人都知道A總監說的是對的，但是B總監硬說出一套似是而非的理論，而且比較野蠻。但是誰能做判斷？除了老闆，沒有人可以做裁判，因為除了老闆，他們就是最大的了。

       同樣道理，在企業內部，除了業務部門的頭頭或者老闆外，沒有人能拍板決定對方提的要求是有問題，業務部門說線下就是這樣，你做不一樣，到時候用不起來，那全是你的責任了。

       而且關鍵是，正如沒有什麼是不能做的一樣（開發最喜歡拿這個來忽悠人），他的設計必然存在一定合理性及可執行性，就算明知道沒價值及有問題，也只能做。

       應對的方法也像第一點一樣：接觸對方的老大，儘量讓對方老大參與並作出判斷，如果對方老大也支援他，那隻能做了。

5、要一次一個專案就做好，不要幻想有第二個迭代

       一開始的時候，我還是保留C端的做法，分多個迭代不斷完善功能、系統。做了一兩次專案、迭代之後就發現，如果公司研發資源不多並且該專案不受重視的時候，最好就一次性做好。

　　A、儘量設計的完善一點，儘量靈活配置，允許撤回、編輯等，少留一些坑給自己

　　B、除了主業務流程外（輸入、處理、輸出資料），伴生的需求（通知、匯出資料、管理員許可權）也儘量思考完善點，省的下次不知道什麼時候才有資源搞第二個版本，儘量將業務實現閉環，從一端到另外一端

　　C、如果可以，儘量約簡單約好，然後再疊加複雜的限制、或者使用邏輯在裡面，這樣可以確保第一個版本沒問題

　　企業內部系統還有很多很多的坑，做了兩年左右，發現內部系統跟做軟體外包一樣，沒有對錯，只有負責人開心不開心而已。要做好企業內部的系統比單純做C端的產品對產品的要求更高，需要懂得專案管理、人際關係處理等一系列技能。