內部業務系統的一些經驗總結

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

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

　　企業內部系統還有一個特色，就是偏重業務流程、偏重底層功能/邏輯的設計，而比較忽視界面、總體功能設計，畢竟作得再爛你也須要用（雖然這麼說，本身仍是須要對本身有要求）。

 

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

一、對接人的專業性

　　通常到了必定規模的企業，都會選擇一些統一的接口人，這些人的崗位多是某個職能部門的負責人或者某個運營人員或者某個崗位，他們的工做職責就是將部門內的需求彙總。

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

　　若是是後者，那就麻煩了，他們在收集到需求以後，會存在必定的扭曲或者優先級安排，干擾真正的用戶需求。

應對方法：

　　A、創建自身的工做節奏，不要被對方帶着走。可是又要協調好與對方的關係，維護好良好關係。

　　B、儘可能接觸一線、真實的用戶獲取最原始的需求描述，若是接觸不到，也儘可能接觸到二線或者該部門的頭頭，否則被玩死都不知道怎麼事。

　　C、設計儘可能通用、靈活、簡單，而不作複雜的、個性的邏輯在裏面，如將規則寫在代碼等，儘可能抽離出來，寫在配置文件裏面，最好是通用一套邏輯而不要作過多特殊邏輯。

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

　　E、沒有調研清楚的需求堅決不作。通常企業內部業務系統，都是線下已經有很成熟的業務，因此線下穩定運行，再搬到線上而且優化效率。若是沒有調研清楚，沒有線下穩定運行，那線上必然也會出問題。

 

二、試運行的必要性及細節調整

       不少時候，作了項目或者作了一個系統出來，沒有一個試運行的階段，直接發佈，直接更新，而後直接開始下個階段的工做。可是上次的功能設計是否有問題？運行是否提升效率？最重要是上次的設計，是否就完善，不須要再調整？

       我作過不少項目，極少一上線就百分百完美，由於沒有人是完美，特別是那麼多不一樣性格、不一樣專業的人在一塊兒作一個項目，特別是從0到1的項目，更加多意外狀況發生。你當時沒想清楚，沒設計好的，都會在上線以後爆發出來。

       因此最簡單的作法，就是在真正上線以前，找一個小部門試點先運行，而且收集一波意見優化一下細節，再真正全局推廣。

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

 

三、用戶想要的，不是真正的

       這個基本作產品的都會遇到，特別是企業內部的，更爲艱難。由於C端產品，不少時候用戶是不會說話，只會經過一些行爲或者一些場景來表達出他們的需求。

       可是企業內部業務系統，或者B端產品，他們會說出他們的需求，並且都會通過他們思惟轉換。舉個例子，某個需求，他們表述想要一個「備註」功能，可是當你深刻追問、瞭解他們的使用場景的時候，就會發現他們並非想要個備註去填寫一些內容，而是想要一個能夠存放證實的地方，作成一個附件上傳，會比單純「備註」更有價值，由於附件能夠支持更多樣式，而備註只支持純文本。

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

 

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

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

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

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

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

       應對的方法也像第一點同樣：接觸對方的老大，儘可能讓對方老大參與並做出判斷，若是對方老大也支持他，那隻能作了。

 

五、要一次一個項目就作好，不要幻想有第二個迭代

       一開始的時候，我仍是保留C端的作法，分多個迭代不斷完善功能、系統。作了一兩次項目、迭代以後就發現，若是公司研發資源很少而且該項目不受重視的時候，最好就一次性作好。

　　A、儘可能設計的完善一點，儘可能靈活配置，容許撤回、編輯等，少留一些坑給本身

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

　　C、若是能夠，儘可能約簡單約好，而後再疊加複雜的限制、或者使用邏輯在裏面，這樣能夠確保第一個版本沒問題

 

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