從需求到設計開發，産品品質問題如何分析

本文簡述了軟體開發面對項目型軟體開發過程中可能面臨的品質問題，同時強調了軟體産品品質的重要性。作者總結了自身所遇到的問題，按不同階段和類型進行分類和整理，希望能為讀者提供幫助。

在軟體開發公司，項目型軟體開發過程中，有諸多因素影響軟體産品的品質。

由于産品品質的問題往往需要軟體公司、客戶投入額外的時間和成本進行産品品質的修複，如果産品品質問題嚴重有可能需要推翻重新設計開發。

是以，軟體産品品質的重要性對于軟體開發公司不言而喻。

筆者身處一家軟體開發公司，面對開發資源有限、項目工期緊張的情況，也遇到産品品質的問題。在此，将項目過程中遇到的問題進行總結分析，希望對即将或正在面對此類問題的讀者能夠有所幫助。

根據遇到的問題，按各個階段和問題分類，歸納如下：

一、需求調研分析

1. 調研前期

需求調研前，産品人員會向客戶收集基礎資料，并對資料閱讀分析，以便後續使用者調研工作的順利高效的開展。

在實際過程中，我們遇到了以下三個主要問題：

1）客戶資料收集不全

問題描述：調研人員向客戶收集資料時，沒有明确客戶所要提供資料的類型和範圍，導緻調研前期資料分析不足，影響後續使用者訪談的調研效率。

産生原因：主要原因是部門沒有标準、規範的客戶資料清單，對新入行的調研人員提供指導和參考。

解決辦法：根據以往項目，總結客戶資料清單，幫助産品調研員明确前期所要收集的客戶資料。

2）客戶資料收集和存檔不規範

問題描述：沒有明确項目雙方的資料收集對接人員，導緻客戶不同部門人員資料提供給項目不同角色的人員。同時，項目沒有明确客戶資料的統一存檔位置，導緻收集的客戶資料散落在不同角色人員手上。影響産品人員第一時間分析資料。

産生原因：立項時，雙方沒有明确項目對接人。資料存檔時，沒有指定項目檔案的統一存檔位置。

解決辦法：項目啟動會時，雙方明确甲乙雙方項目負責人。同時由項目負責人指定客戶資料統一存放位置。

3）客戶資料了解偏差

問題描述：調研人員分析客戶資料時，存在了解時間長、分析不夠透徹、分析範圍遺漏的情況，影響後續使用者訪談的工作開展。

産生原因：調研人員對行業相關知識了解不夠。

解決辦法：日常工作中通過讀書分享、項目總結分享和邀請業内專家講座、教育訓練的方式加強調研人員對行業知識了解。提供行業常用相關的網站、微信公衆号，在有行業術語、公式等無法了解情況時，提供相關的幫助和參考。同時，提供公司内部資深調研人員資訊，讓新手可以的一時間找到解決問題的公司内部專家。

2. 調研過程

需求調研時，産品人員到客戶現場進行使用者訪談調研，通過使用者調研收集和記錄客戶的需求。同時，通過需求調研分析逐漸收集和完善客戶資料。

實際過程中，我們遇到了以下兩個主要問題：

1）需求收集不夠全面

問題描述：需求調研中某個業務活動的具體場景僅描述其中一種常見情況，對于其他特殊情況沒有收集、記錄和分析。影響後續産品的規劃設計。

産生原因：需求調研時，僅收集某個業務人員的描述的需求，沒有充分收集整個部門和其他上下遊部門的需求。

解決辦法：部門提供需求調研的檢查清單，幫助和提醒調研人員調研時注意事項。此外，需求調研的成果要彙總和客戶相關人員進行再次确認。

2）需求細節不夠詳細

問題描述：客戶需求描述的内容不夠具體、清晰，導緻産品設計階段需要反複與客戶進行溝通和确認。

産生原因：一個是調研人員行業經驗少，無法對客戶的需求進行深入的追問。另一個是客戶也不明确需求要描述到什麼程度合适。這就形成你不問我不說的情況。

解決辦法：除了加強調研人員日常業務知識學習外，還要培養調研人員遇到客戶簡單回答時多追問的習慣。

3. 其他

客戶時間安排沖突

問題描述：與客戶安排的調研時間會被推遲和需要反複的确認。

産生原因：客戶沒有足夠的重視項目或有緊急重要的會議沒有時間安排，導緻調研的日期一再被推遲。

解決方法：确定項目完成時間，與客戶共同明确項目計劃。項目啟動會時，邀請雙方上司參與，共同重視項目計劃的執行。

二、産品設計

1. 功能設計

在完成需求分析後，會根據需求分析的結果規劃産品的功能架構，并根據功能架構列出産品功能清單。

實際過程中，功能設計時會存在以下兩個問題：

1）細節功能設計不到位

問題描述：功能設計時，僅考慮正向流程，逆向或其他特殊流程沒有考慮。導緻後期使用者測試期間又要重新調整功能設計。

産生原因：需求調研分析期間遺漏，功能設計期間沒有仔細思考模拟各種場景。

解決方法：設計人員要沉下心，認真根據已分析資料模拟使用者真實場景，若有發現不明确或有遺漏的功能需第一時間與使用者進行再次溝通确認。

2）通用功能沒有抽象

問題描述：對于系統中的通用子產品沒有抽象，導緻相同功能重複描述，同時也給後續的功能變更埋下了隐患。

産生原因：設計人員沒有從全局的解度審視産品功能，往往看一塊做一塊，沒有做好統一的産品規劃功能。

解決方法：在提高産品設計人員設計能力的同時，加強對産品功能設計的稽核。

2. 原型設計

功能設計後，會根據功能清單使用原型工具Axure RP進行原型設計。

原型設計時，我們同樣面臨着以下三點的問題：

1）元件設計不統一

問題描述：原型設計過程中元件沒有統一，比如同一内容的文字說明在不同子產品文字沒有統一；清單的排序沒有統一；使用日期或時間的元件沒有統一。

産生原因：部門沒有統一的規範說明；同時，設計人員項目經驗不足。

解決方法：建立标準元件庫（有分移動版和Web版），所有項目設計的元件原型統一從庫中調用。建立部門的原型設計自檢清單，将常用的自檢清單做為設計人員設計完成後的必檢内容。加強設計人員對标準元件的學習和了解。

2）标注說明不清晰

問題描述：對原型标注說明時，沒有标注或對标注不清晰、不完整。對于特殊或重點的邏輯說明沒有特别重點辨別。比如：原型字段的長度、按扭功能的校驗規則等标注說明沒有等。這些問題對于有經驗和責任心的開發人員，會跟設計人員進一步确認和完善，而對于新手往往會忽略。這些問題在測試或使用者使用階段 暴露，影響産品品質和客戶體驗。

産生原因：部門沒有制定統一的标注說明模闆和要求。導緻根據各自偏好進行标注。

解決辦法：制定需求詳細設計模闆，部門成員統一以需求詳細設計模闆做為最終的傳遞産物。

3）原型設計速度慢

問題描述：采用帶互動的原型設計方式，但互動對設計人員的原型技能撐握能力要求高。同時，在原型設計确認完後，需要對原型進行修改和優化時，調整原型的時間也變長。

産生原因：部門人員大部分新人，原型的技巧沒有那麼熟練，互動原型設計加重了他們的工作量。

解決辦法：使用标準元件庫中的原型元件并使用線框圖方式，元件間的互動統一并采用文字描述，減少互動效果設計帶來的工作時間。

3. 需求評審

需求評審效果不佳

問題描述：需求評審前沒有将評審資料發放給相關人員，需求評審時沒有需求和設計專家參與，需求評審并沒有得到建設性的建議。

産生原因：公司及産品人員對需求評審的重視度不夠，内部沒有儲備行業的專業性人才。

解決辦法：提高大家對需求評審的重視度，提前做好需求評審準備。教育訓練和儲備專業性人才，邀請客戶的專家共同參與需求評審。

三、産品開發

1. 需求詳講

問題描述：需求詳講階段，未做到項目所有相關開發人員參與，而且參與人員的聽講效果不佳，導緻産品人員在開發過程中要再次進行解釋，影響産品開發進度和品質。

産生原因：産品事前沒有将相關材料傳遞開發人員，開發人員沒有事先了解資料，導緻詳講效果差。

解決辦法：事前産品人員将資料分發到項目開發人員手中，事前由開發人員準備問題，詳講會上由産品人員根據問題清單重點澄清開發人員疑惑問題。

2. 需求變更

問題描述：産品人員進行需求變更時，沒有詳細考慮導緻一個需求需要反複，而且有時客戶提的需求設計完成後，又不再需要。同時，需求變更沒有同步同知相關開發和測試人員，導緻相關人員開發完成後才接收到變更的内容。

産生原因：産品人員對需求變更的随意性，導緻需求變更和管理混亂。

解決辦法：增加需求的評審制度，外部需求變更需要由客戶送出需求變更單，避免客戶的一句話需求，實驗性需求或個人喜好的需求導緻公司投入成員。内部需求變更需要由負責人進行稽核，需求變更通過同步相關開發和測試人員。

3. 版本提測

問題描述：送出測試的系統，測試過程中發現流程不通，開發的bug數量多，出來的系統與設計的原型存在不符的情況。

産生原因：開發時，各個子產品由不同開發人員開發，送出測試時，沒有進行系統的內建測試。開發人員在系統開發過程中發現問題，沒有及時與産品人員溝通，并按自己了解的思路進行開發。

解決辦法：産品人員從開發起及時關注系統的開發進度，每日與開發人員進行站會了解開發的情況及溝通開發過程中的問題。開發完成後，第一時間進行系統驗證，保證系統流程的暢通。

四、總結

其實想打造好一款好的産品是不容易的。

産品需求調研到最終産品上線運作是經過多個階段的，每個階段都可能由不同的人員參與，資訊的傳遞也有可能層層丢失。

是以軟體開發是一項工程，需要通過管理保證軟體的進度和品質。

以上内容希望對于讀者有所幫助和參考。

作者：refurbish ； 公衆号：Bruce林奮進頻道

本文由 @refurbish 原創釋出于人人都是産品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協定

該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。