軟件系統開發總結文檔

軟件系統開發總結文檔本次總結針對剛剛完成交付的中小企業定制化客戶關系管理（CRM）軟件開發項目展開，整個項目從需求對接至正式上線，歷時六個多月，由我們八人的開發團隊全程跟進，最終按照約定時間、符合所有核心需求完成交付，目前系統已經穩定運行兩個多月，客戶反饋良好。寫這份總結的目的，是梳理整個開發流程中的得失，沉淀可復用的經驗，也為后續同類項目提供參考，避免重復踩坑。接下來我會從項目概況、執行復盤、問題總結、經驗沉淀幾個維度展開詳細說明。1項目開發整體背景與核心目標1.1項目發起背景這次的客戶是一家做本地商貿批發的中小民營企業，一共十五名員工，其中八名是一線銷售人員。在找我們開發之前，他們的客戶信息、銷售跟進、業績統計全都是靠銷售個人微信備份、Excel表格零散存儲，大大小小十幾張表格存在不同人的電腦里，經常出現找不到舊客戶信息、數據重復錄入的情況。最讓客戶老板頭疼的是，之前有銷售離職，帶走了手上大半的客戶資源，新接手的銷售根本理不清跟進進度，平白丟了好幾個長期合作的老客戶；每個月算業績，財務要對著十幾張表格核對整整一天，還經常出錯。他們之前也看過市面上標準化的CRM產品，要么價格太高，一年服務費比他們整個部門的月薪還高，要么功能太復雜，一堆用不上的模塊，銷售人員學半天也不會用，所以才找我們做定制開發，想要一個貼合他們實際業務、簡單好用成本又低的客戶管理工具。一開始我們團隊還覺得這就是個幾千塊的小活，沒太放在心上，直到上門跟著他們待了一天，看到財務對著滿屏幕的單元格揉眼睛，才意識到這個“小活”對他們來說就是解決大麻煩的剛需，也認認真真把這個項目放在了心上。1.2項目核心開發目標結合和客戶反復溝通的結果，我們最終確定了三個層級的核心開發目標，所有開發工作都圍繞這個目標展開：1.2.1基礎功能目標核心要解決客戶現有的痛點，實現客戶信息統一存儲管理、銷售跟進記錄實時更新、跟進任務自動提醒、業績回款自動統計、權限分層管理五個核心功能，確保所有原來手工做的麻煩事都能通過系統完成，從根源上解決客戶信息流失、統計效率低的問題。1.2.2用戶體驗目標因為客戶的銷售人員大多不是互聯網從業者，對復雜軟件接受度低，所以要求所有操作邏輯必須符合他們原來的工作習慣，頁面簡潔直白，新員工不用花超過一天時間培訓就能上手，同時要支持手機端訪問，方便銷售在外跑客戶的時候隨時查看記錄、更新信息。1.2.3成本控制目標客戶預算有限，所以開發階段盡量選用成熟的開源框架，降低開發成本，后期部署和維護也要簡單，不需要專門配技術人員維護，服務器選普通的云服務器就能滿足需求，把后續的使用成本降到最低。1.3項目團隊與時間規劃我們團隊的分工是：1名產品經理負責需求對接和梳理，2名前端開發負責頁面和交互，3名后端開發負責接口、功能開發和數據庫設計，1名測試負責功能測試和兼容性測試，我作為后端開發的一員，同時兼項目協調工作。時間規劃上我們一開始就留了10%左右的緩沖時間，整體排期是：需求調研梳理兩周，架構設計與技術選型兩周，編碼開發十周，測試與問題修改三周，上線部署與培訓一周，最終實際完成時間比計劃只晚了兩天，緩沖時間剛好夠處理突發問題，這點現在回頭看是做的非常對的。2項目開發各階段執行情況復盤梳理完整體的目標和規劃，接下來我按照開發的時間順序，對每個階段的執行情況做詳細復盤，整理過程中做得好和不到位的地方。2.1需求調研與梳理階段一開始我們踩了個不大不小的坑：最開始我們讓客戶把需求整理成文檔發過來，客戶只給了三行字，說“要管客戶，要算工資，要提醒跟進”，根本沒說清楚具體規則。后來產品經理帶著我們一起上門，蹲在客戶的銷售部待了一整天，跟著他們開早會，看他們怎么錄入信息、怎么和客戶對接、怎么算業績，才挖出來很多客戶自己沒說出來的隱性需求。比如他們算業績是按照實際回款金額算，不是按照訂單金額算，這點客戶一開始根本沒提，如果我們按照常規的訂單算業績做出來，肯定要全部返工。最后我們整理出來二十多個功能點，分了核心必做和后續可擴展兩個優先級，和客戶簽字確認了需求說明書，明確了后續加需求要走變更流程，從根源上避免了需求亂改的問題，這個階段比原計劃多花了三天，但換來了后續的順暢，非常值得。2.2架構設計與技術選型階段確定需求之后，我們開會討論技術選型，一開始有人提出要用現在流行的微服務架構，說擴展性好，聽起來也專業。后來我們仔細算了算，客戶一共也就十幾個用戶，同時在線最多也就十幾個人，微服務架構部署復雜，維護成本高，完全沒必要。最后我們選了最適合這個項目的技術棧：后端用SpringBoot+MyBatis，輕量開發快，部署也簡單，數據庫用MySQL，完全能承載幾十萬條客戶數據，足夠客戶未來五到十年的業務增長；前端用Vue，做響應式布局，同時適配PC和手機端，不用單獨開發APP，節省了很多成本。架構設計上我們用了分層的單體架構，邏輯清晰，開發效率高，同時提前預留了擴展接口，如果客戶未來業務做大了，想要加功能或者拆成微服務，也不用全部推翻重來，兼顧了當前需求和未來擴展，是非常穩妥的選擇。2.3編碼開發階段我們這個項目用了兩周一次迭代的敏捷開發模式，每個迭代開發完核心功能，就發給客戶看一次，確認沒問題再往下做，避免做到最后才發現需求理解錯了，改起來成本太高。比如第一個迭代做完客戶信息管理模塊，給客戶看的時候，客戶才提出他們需要給客戶分等級，不同等級的客戶提成比例不一樣，我們原來只做了等級分類，沒做和提成模塊的關聯，這個時候改只需要調整客戶模塊和提成模塊的對接，要是等到全部開發完再改，就要動好幾個模塊的代碼，浪費很多時間。我自己負責的是業績統計和回款管理模塊，一開始做出來的月度統計報表，打開要三四秒才能加載出來，我自己測試的時候覺得不對，翻了一下SQL才發現是忘記給常用的查詢字段加索引，調整之后加載時間降到了幾百毫秒，體驗一下子就上去了，現在想想，這種小細節最容易影響用戶體驗，真的不能大意。2.4測試與調優階段測試階段我們除了自己的測試人員找bug，還特意讓客戶派了兩個經常用電腦的銷售來幫忙測，畢竟他們是真正的使用者，能找出我們發現不了的問題。比如我們原來覺得按鈕大小、位置都挺合適，他們說跑業務的時候都是拿手機點，手容易出汗，小按鈕經常點錯，我們就把核心操作的按鈕都放大了兩成；還有他們說原來的提醒聲音太小，在外面聽不到，我們就加了音量調節和短信提醒的選項，這些細節都是我們坐在辦公室里想不到的。整個測試階段一共找出了八十三個問題，其中三個嚴重的權限bug，最開始做的權限校驗有漏洞，普通銷售居然能修改其他同事的客戶信息，我們趕緊調整了全局的權限攔截邏輯，花了一天時間就改好了，最終上線前所有嚴重bug都全部修復，不影響核心使用。2.5上線部署與培訓階段我們特意選了周末上線，不影響客戶正常上班，部署完之后，我們現場給所有銷售和財務做了兩個小時的培訓，一步步演示怎么用，還做了一份圖文并茂的簡易操作手冊，存在客戶的服務器上，忘了操作隨時就能看。之后我們還建了一個答疑群，前一個月幾乎天天都有人問問題，大多都是操作不熟練的小問題，我們都第一時間回復，慢慢大家用熟了，問題就越來越少了。3開發過程遇到的核心問題與解決方案整個開發推進過程中，我們遇到了三個之前規劃階段沒預料到的問題，也總結出了切實可行的解決方法，在這里整理出來：3.1需求蔓延問題項目開發到一半的時候，客戶提出要加一個功能：給銷售提供現成的朋友圈文案，方便他們發給客戶，這個需求最開始的需求說明書里沒有，如果我們直接加進去，就要擠占核心功能的開發時間，項目很可能延期。后來我們和客戶溝通，明確這個功能不是當前必須用到的核心功能，我們先把核心的客戶管理、業績統計功能做完按時上線，這個功能作為后續迭代需求，如果客戶需要，我們再做開發，只收少量的額外費用，客戶也非常認可這個方案，既沒有影響項目進度，也滿足了客戶的額外需求。這件事給我們的教訓就是，不管項目大小，一定要提前鎖死核心需求，額外需求必須走變更流程，不能隨便答應加功能，不然很容易做著做著項目范圍越來越大，最后延期又賺不到錢，兩邊都不開心。3.2舊數據遷移問題客戶原來有十幾萬條客戶信息存在好幾個不同的Excel里，格式亂七八糟，有的缺手機號，有的重復錄入，我們一開始以為導入就是點一下的事，沒想到第一次導入，居然有將近兩成的數據出錯。后來我們專門抽了兩天時間，先寫了一個簡易的數據清洗工具，自動去重、自動補全缺失的非必填字段，把格式統一，然后讓客戶的工作人員對著自動整理好的數據手動核對一遍，最后才導入新系統，花了整整四天時間才把數據全部弄好。這件事提醒我們，只要是涉及舊數據遷移的項目，一定要提前預留出至少一周的數據整理時間，不能小看這個工作，里面的坑真的很多。3.3移動端兼容性問題我們一開始測試都是在自己的新手機上測，所有功能都正常，結果客戶拿來幾個用了三四年的舊安卓手機測試，發現有的頁面打不開，有的按鈕錯位。后來我們才知道，很多銷售的手機都是用了好幾年的舊機器，系統版本比較低，我們用了一些新的前端特性，老系統不支持。最后我們把不必要的新特性都換掉，兼容了五年內推出的所有安卓版本，又找了好幾個不同牌子不同版本的舊手機測試了一遍，最終所有設備都能正常使用了，這件事也告訴我們，面向普通用戶的系統，一定要考慮設備的多樣性，不能只在自己的新設備上測試。4項目開發總結與經驗沉淀整個項目交付完成，客戶反饋現在找客戶信息不用翻半天表格，財務算業績從一天變成一分鐘，也再也不用擔心銷售離職帶走客戶了，我們整個團隊也收獲了很多書本上學不到的經驗：首先是對定制化開發的理解，原來我總覺得開發就要用最新的技術，做最多的功能，才顯得專業，這個項目做完我才明白，定制開發的核心是貼合用戶的實際需求，不是功能越多技術越新就越好，夠用、好用、解決問題才是最重要的。我們這個項目沒有加什么人工智能預測、大數據分析這類花里胡哨的功能，客戶根本用不上，反而會讓操作變復雜，增加成本，適合用戶的就是最好的。其次是團隊協作，原來我們團隊溝通也有問題，前端催后端接口，后端說需求改了所以慢，后來我們改成每天早上開十分鐘站會，每個人說一下今天要做什么，遇到了什么問題，有問題當場說，不要攢到最后，效率一下子提高了很多。還有寫文檔，我原來特別嫌寫文檔麻煩，覺得自己能記住，后來改需求的時候，我自己都忘了當初為什么這么設計，翻了文檔才理清楚，才明白“好記性不如爛筆頭”這句話真的沒錯，哪怕簡單寫兩句注釋和說明，也比不寫強。最后是面向用戶的設計思路，做軟件真的要多站在用戶的角度想問題，用戶不會管你用了什么厲害的技術，他們只在乎能不能幫他們少干點活，省點時間。比如原來我們做的報表，默認打開是全維度的統計，客戶說我們就只要看每個月每個人的回款，其他的我們很少用，我們就把默認報表改成客戶需要的，把其他維度的統計放到二級菜單，用戶打開就能看到自己要的，體驗一下子就上去了，這點真的比堆十項新技術都有用。總結整個這個軟件系統開發項目，從最開始接下小活的不以為意，到最后交付的時候