「準備」  就如當學生上課前要預習功課一樣做好準備，將要調研的內容提前列好，提前學習專研行業的術語、業務。有準備的溝通，能讓對方感受到你的誠意，願意跟你溝通，表達想法；有針對性地提前學習，能讓雙方的溝通在同一個專業水平層次上，互相溝通更順暢。

        然後是溝通的對象，要找出用戶方的關鍵干係人，一般關鍵干係人分為領導層和執行層，領導層決定了軟件產品的定位及方向，項目背景是什麼，為什麼要做這個產品。執行層是實際的產品用戶，這層面的用戶更關注產品的業務流程是否合理閉環，交互體驗，操作便捷。

       溝通調研的順序要根據實際情況而定，如果跟領導層有過合作，比較熟悉，可以「以點帶面」先跟領導層溝通，大方向把握後再跟執行層用戶細化需求。如果對領導層的意圖把控信心不足，可以先跟執行層用戶做個摸底調研，心裏有底後，再跟領導層溝通，以農村包圍城市的方式。

    「溝通」  調研跟記者採訪、訪談節目一樣，需求調研的人員就是記者、主持人，要能挖掘用戶的需求，引導用戶提出他的需求。直接問用戶你有什麼需求，你需要什麼功能，是需求調研的大忌，而是要提出你的方案，讓用戶去選擇改進。比較常用的方法是繪製流程圖、原型，把產品的流程、交互形象地圖形化出來，讓用戶很有針對性地去提需求。

    「確認」  每個人的生成環境、知識水平不一樣，你理解到的可能跟用戶表達的意思是有出入的，站在客戶的角度理解客戶需求的描述，無論你覺得客戶要求是否合理，都應當跟客戶複述你的理解，判讀你的理解是否跟客戶所想的一致。

    「分析」  收集到用戶的想法信息後，就需要進行分析，鑒別信息是屬於「需求」還是「要求」，往往用戶提的都是「要求」，我們要通過現象看本質，透過要求找出用戶真正的內在需求。下面舉一個簡單的例子，說明需求和要求的區別：

        【要求】：有一個表單目前設計是仿報告模板(見下圖)，讓用戶再上面填空，但客戶覺得輸入框太亂，要把布局進行調整，輸入的文本框都集中起來，同時要求輸入框加上提示。

        【分析】：對於客戶的要求進行分析，把輸入框集中起來，解決了輸入框歸集，但是原來仿造報告模板來做這個表單頁面的效果就沒了，仿報告模板的表單填寫方式對於輸入框的上下文非常清楚，不用那麼多啰嗦的注釋或者提示。

        【需求】：所以真正的用戶需求，其實是「表單填寫時，哪裡是輸入框需要填寫，不夠突出」，分析到最終的用戶需求之後，就好辦了，原來的布局不變，只要要一個底色，把輸入框的白底凸顯出來，用戶使用時就直觀了。改造前和改造後的表單編輯頁效果如下：

    「信息化意義是什麼」  在我目前的工作經歷內，思考信息化根本目的是為了：規範和經驗共享。 比如一個表單，可以用一段文字表達，不是更自由，為什麼要分割成一個個輸入框，實際是為了規範大家的填寫內容，同時確定模板，大家填寫時不用考慮要填寫哪些字段，模板已經定好了。比如一個oa流程，之前線下簽字，每個新人都要培訓一次，先誰簽字，然後誰簽字，形成線上系統後，系統自動生成審批流。比如以前大家開車，記性好的方便，路盲就苦逼了，現在有導航，經驗都可以共享了。

    「數據流」  數據是系統的靈魂，一個業務系統最底層，最核心的就是數據，一個業務系統能產生什麼數據，這些數據之間又有什麼聯繫，以及數據實體之間是如何進行流動，數據的源頭是什麼。可以使用E-R圖也稱實體-聯繫圖來對數據進行表達，從而為後續的原型設計、技術設計打下基石。

    「業務流」  如果說數據是食材，業務就是菜譜。業務流將數據的操作，數據的變換進行集成，比如一條請假申請，先通過員工申請提交、再到主管審批、再到人力確認等。一系列業務流，把數據進行一步步加工出口。

    「原型設計」  有了數據流和業務流的基礎，就可以進行具體用戶交互界面的原型設計，類似造一個汽車前，先話一個設計圖。軟件產品開發也有設計圖，就是原型設計，可以通過簡單的畫圖工具，或者成熟的原型工具BalsamiqMockups、axure進行設計的快速實現，把交互的想法和軟件的思路快速繪製出來，進行設計的落地並跟客戶有效地交流確認。

    「可靠性原則」  軟件可靠性和硬件可靠性本質區別在於：後者為物理機理的衰變和老化所致，而前者是由於設計和實現的錯誤所致。

       保障策略一：【低耦合高內聚】。講應用進行業務拆分，拆分後的每個服務都是獨立的，可單獨維護和擴展，服務之間的調用通過接口約定進行通信。對比早期系統的設計都是單體架構，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本，存在的問題是一旦某個環節出現性能問題，整個應用跟着一起連累，更新某一個小功能，可能導致所有應用都被傳染，一榮俱榮一損俱損。

       保障策略二：【不在一棵樹上弔死】。主備機制，重要的環節要有雙通道，運用分佈式技術，對重要的服務進行多台負載均衡。對於重要的第三方服務，如短訊服務，要申請至少兩個不同廠家的接口，一旦某一個運營商由於網絡攻擊等原因停服，另外一個接口服務就可以提供應急服務。

       保障策略三：【事前諸葛亮】。系統運行過程中，都會產生各式各樣的故障，報錯，往往都是平台事故的前奏，如果能事前感知到系統的生命體征，就需要構建一個預警體系，給系統的重要接口、重要服務進行24小時定時自動檢測，一旦出現服務不可用，第一時間通知處理。

       保障策略四：【保護現場痕迹】。理想情況下，每個用戶操作都是可追溯的，每個數據記錄變更都是可還原的。出現接口異常、用戶操作報錯、用戶質疑平台數據時，日誌庫就會起到重大的作用，它默默地記錄著系統操作的所有變更，為破案提供重要的線索。

    「安全性原則」  道路千萬條 安全第一條。特別是涉及金錢交易的系統，安全尤為重要，要麼都沒事，一出事可能就是災難性的。登錄、用戶信息等加密傳輸肯定是要的，sql注入等安全性檢測也是必須的。

     「可測試性原則」  對於可測試性原則我個人沒有太多的經驗，也在學習中，引用《

如何提升研發的可測試性架構設計

》中的一句話//cloud.tencent.com/developer/news/309024：測試是軟件開發過程中很重要的一部分，會佔用大量的時間和人力。如果想要高效的測試和獲得高質量的軟件產品，我們必須在軟件項目的啟動初期就開始關注軟件質量。

      「健壯性」  對於規範要求以外的輸入能夠判斷出這個輸入不符合規範要求，並能有合理的處理方式。

        第一層判斷：前端的輸入的有效性控制，不能讓非法的文字傳入後端，比如報價金額填一個中文，最終可能導致統計報錯。

        第二層判斷：前端與後端的接口約定，接口對數據類型要有一個判斷，後端對於前端傳過來的數據進行鑒別，有異常的要進行拋出。

        第三層判斷：數據庫字段類型約束，對於關鍵的數值型字段，後續還會針對這個字段進行統計、計算、分析的。在數據庫層面進行字段類型約束。

    「編碼規範」  引用《任正非公開信：全面提升軟件工程能力與實踐，打造可信的高質量產品》//news.cnblogs.com/n/616385/中第一句話：我們要優化並遵循公司各種編程規範，遵從架構與設計原則，熟練使用各種編程庫和 API，編寫出簡潔、規範、可讀性強、健壯安全的代碼。

    「單元自測」  《信息系統項目管理師》教材中提到一個名稱：質量成本，它包含：預防成本 → 鑒定成本 → 內部損失成本 → 外部損失成本。預防成本是最小的，隨後的成本逐步增加，一旦發生外部損失成本，可能造成索賠、信譽等重大影響。

        預防成本包含：代碼規範、培訓、代碼審核、自測等測試之前的階段。

        鑒定成本包含：測試人員投入、測試環境投入、測試報告輸出階段。

        內部損失成本包含：測試之後的返工修改。

        外部損失成本包含：一旦預防和鑒定都沒有修復存在問題，上線後事故造成的損失成本，包含人力的投入、補救措施的投入、索賠等。

        所以代碼的質量不能完全依賴於測試來保障，自測是代碼質量保障的第一道關卡，也是成本最低的一個環節。

     「提測範圍」  如果是黑盒測試，測試不涉及研發代碼，對於代碼修改影響到的功能、接口，一般是通過UI交互操作進行檢驗。所以提測範圍的約定尤為重要，研發人員修改需求後，影響到的流程、功能等內容一定要描述清楚。

     「測試要點」  測試人員針對提測範圍，結合歷史總結的測試功能要點總結，進行本地提測範圍的測試規劃，初步形成測試要點初稿。

     「測試評審」  測試要點初稿，要經過主要研發人員和測試組長進行評審，避免漏測試、理解錯誤情況。

     「測試報告」  針對產品測試bug形成總結報告，分析各產品質量，統計研發-測試投入比，從而推動開發團隊加強自測，從源頭上把控產品質量。

    「版本把控」  系統發佈前和發佈後的新舊版本文件都要進行備份，這個是實施的基本規範。發佈目錄一般會分為「實施目錄」、「更新目錄」、「備份目錄」。

    「更新後驗證」  根據以往的經驗，實施人員更新後，經常會出現幾種情況：配置文件漏了、配置文件改錯地方、數據庫漏更新、整個文件目錄更新錯了等情況，所以更新後的線上系統驗證是非常必要的，可以防止低級的系統級別錯誤。

    「分佈式部署」  網站服務分佈式部署，多套實施目錄同步更新，最好要藉助自動化工具進行更新，避免遺漏，一旦分佈式系統，有些節點更新了，有些節點沒更新，可能造成嚴重的數據混亂和不可挽回的數據後果。曾經有一家上市公司，就由於更新部署問題，導致公司倒閉：《

比刪庫還慘！45分鐘搞垮一家上市公司，只因一次失敗的部署？

》//mp.weixin.qq.com/s/NlcuW-5ahkE4dmjcUPv98g

    「安全保障」  首先是服務器、數據庫資源安全管理，

近期的微盟「刪庫事件」就是超嚴重的事故。//3g.163.com/news/article_cambrian/F6OUCNSS0519DTSV.html

    「巡檢制度」  分人工和自動，類似域名過期時效、服務器資源過期時效、服務器磁盤空間、內存、cpu、網站是否可訪問等都可以形成自動預警。人工操作就是一些數據庫或者服務器的定期維護重啟等。能形成程序自動預警的盡量做成程序自動預警。

    「性能分析」  對於服務器和數據庫資源的監控巡檢，上面以提到，這裡講的性能分析主要包括數據庫性能分析和網站的性能分析。

      數據庫性能分析，可以通過數據庫的慢日誌進行查詢時間的排查，如果有使用阿里雲數據庫實例的話，阿里雲的後台自帶有慢日誌的統計查詢和索引推薦。

      網站的性能分析，可以通過網站記錄的詳細請求日誌進行分析，針對請求用時比較長的數據進行判斷，是否需要優化。

    「備份機制」  包括定期的數據庫備份、服務器硬盤的快照，以及研發內部的源碼備份等。要進行模擬演練，一旦發生重大病毒事件，或者硬盤壞道，如果能快速恢復保障業務化運行。

    「風險防控」  每月針對線上已發生的產品問題進行總結復盤，明確後續保障措施。同時分析排查隱患，明確下月質量保證實施計劃。