起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識從需求到設計開發，產品質量問題如何分析
本文簡述了軟件開發面對項目型軟件開發過程中可能面臨的質量問題，同時強調了軟件產品質量的重要性。作者總結了自身所遇到的問題，按不同階段和類型進行分類和整理，希望能為讀者提供幫助。
在軟件開發公司，項目型軟件開發過程中，有諸多因素影響軟件產品的質量。
由于產品質量的問題往往需要軟件公司、客戶投入額外的時間和成本進行產品質量的修復，如果產品質量問題嚴重有可能需要推翻重新設計開發。
所以，軟件產品質量的重要性對于軟件開發公司不言而喻。
筆者身處一家軟件開發公司，面對開發資源有限、項目工期緊張的情況，也遇到產品質量的問題。在此，將項目過程中遇到的問題進行總結分析，希望對即將或正在面對此類問題的讀者能夠有所幫助。
根據遇到的問題，按各個階段和問題分類，歸納如下：
一、需求調研分析
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協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論，等你發揮！
