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

在軟件開發(fā)公司，項目型軟件開發(fā)過程中，有諸多因素影響軟件產(chǎn)品的質量。

由于產(chǎn)品質量的問題往往需要軟件公司、客戶投入額外的時間和成本進行產(chǎn)品質量的修復，如果產(chǎn)品質量問題嚴重有可能需要推翻重新設計開發(fā)。

所以，軟件產(chǎn)品質量的重要性對于軟件開發(fā)公司不言而喻。

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

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

一、需求調研分析

1. 調研前期

需求調研前，產(chǎn)品人員會向客戶收集基礎資料，并對資料閱讀分析，以便后續(xù)用戶調研工作的順利高效的開展。

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

1）客戶資料收集不全

問題描述：調研人員向客戶收集資料時，沒有明確客戶所要提供資料的類型和范圍，導致調研前期資料分析不足，影響后續(xù)用戶訪談的調研效率。

產(chǎn)生原因：主要原因是部門沒有標準、規(guī)范的客戶資料清單，對新入行的調研人員提供指導和參考。

解決辦法：根據(jù)以往項目，總結客戶資料清單，幫助產(chǎn)品調研員明確前期所要收集的客戶資料。

2）客戶資料收集和存檔不規(guī)范

問題描述：沒有明確項目雙方的資料收集對接人員，導致客戶不同部門人員資料提供給項目不同角色的人員。同時，項目沒有明確客戶資料的統(tǒng)一存檔位置，導致收集的客戶資料散落在不同角色人員手上。影響產(chǎn)品人員第一時間分析資料。

產(chǎn)生原因：立項時，雙方?jīng)]有明確項目對接人。資料存檔時，沒有指定項目文件的統(tǒng)一存檔位置。

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

3）客戶資料理解偏差

問題描述：調研人員分析客戶資料時，存在理解時間長、分析不夠透徹、分析范圍遺漏的情況，影響后續(xù)用戶訪談的工作開展。

產(chǎn)生原因：調研人員對行業(yè)相關知識了解不夠。

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

2. 調研過程

需求調研時，產(chǎn)品人員到客戶現(xiàn)場進行用戶訪談調研，通過用戶調研收集和記錄客戶的需求。同時，通過需求調研分析逐步收集和完善客戶資料。

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

1）需求收集不夠全面

問題描述：需求調研中某個業(yè)務活動的具體場景僅描述其中一種常見情況，對于其他特殊情況沒有收集、記錄和分析。影響后續(xù)產(chǎn)品的規(guī)劃設計。

產(chǎn)生原因：需求調研時，僅收集某個業(yè)務人員的描述的需求，沒有充分收集整個部門和其他上下游部門的需求。

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

2）需求細節(jié)不夠詳細

問題描述：客戶需求描述的內容不夠具體、清晰，導致產(chǎn)品設計階段需要反復與客戶進行溝通和確認。

產(chǎn)生原因：一個是調研人員行業(yè)經(jīng)驗少，無法對客戶的需求進行深入的追問。另一個是客戶也不明確需求要描述到什么程度合適。這就形成你不問我不說的情況。

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

3. 其他

客戶時間安排沖突

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

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

解決方法：確定項目完成時間，與客戶共同明確項目計劃。項目啟動會時，邀請雙方領導參與，共同重視項目計劃的執(zhí)行。

二、產(chǎn)品設計

1. 功能設計

在完成需求分析后，會根據(jù)需求分析的結果規(guī)劃產(chǎn)品的功能架構，并根據(jù)功能架構列出產(chǎn)品功能清單。

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

1）細節(jié)功能設計不到位

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

產(chǎn)生原因：需求調研分析期間遺漏，功能設計期間沒有仔細思考模擬各種場景。

解決方法：設計人員要沉下心，認真根據(jù)已分析資料模擬用戶真實場景，若有發(fā)現(xiàn)不明確或有遺漏的功能需第一時間與用戶進行再次溝通確認。

2）通用功能沒有抽象

問題描述：對于系統(tǒng)中的通用模塊沒有抽象，導致相同功能重復描述，同時也給后續(xù)的功能變更埋下了隱患。

產(chǎn)生原因：設計人員沒有從全局的解度審視產(chǎn)品功能，往往看一塊做一塊，沒有做好統(tǒng)一的產(chǎn)品規(guī)劃功能。

解決方法：在提高產(chǎn)品設計人員設計能力的同時，加強對產(chǎn)品功能設計的審核。

2. 原型設計

功能設計后，會根據(jù)功能清單使用原型工具Axure RP進行原型設計。

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

1）組件設計不統(tǒng)一

問題描述：原型設計過程中組件沒有統(tǒng)一，比如同一內容的文字說明在不同模塊文字沒有統(tǒng)一；列表的排序沒有統(tǒng)一；使用日期或時間的組件沒有統(tǒng)一。

產(chǎn)生原因：部門沒有統(tǒng)一的規(guī)范說明；同時，設計人員項目經(jīng)驗不足。

解決方法：建立標準組件庫（有分移動版和Web版），所有項目設計的組件原型統(tǒng)一從庫中調用。建立部門的原型設計自檢清單，將常用的自檢清單做為設計人員設計完成后的必檢內容。加強設計人員對標準組件的學習和了解。

2）標注說明不清晰

問題描述：對原型標注說明時，沒有標注或對標注不清晰、不完整。對于特殊或重點的邏輯說明沒有特別重點標識。比如：原型字段的長度、按扭功能的校驗規(guī)則等標注說明沒有等。這些問題對于有經(jīng)驗和責任心的開發(fā)人員，會跟設計人員進一步確認和完善，而對于新手往往會忽略。這些問題在測試或用戶使用階段?暴露，影響產(chǎn)品質量和客戶體驗。

產(chǎn)生原因：部門沒有制定統(tǒng)一的標注說明模板和要求。導致根據(jù)各自偏好進行標注。

解決辦法：制定需求詳細設計模板，部門成員統(tǒng)一以需求詳細設計模板做為最終的交付產(chǎn)物。

3）原型設計速度慢

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

產(chǎn)生原因：部門人員大部分新人，原型的技巧沒有那么熟練，交互原型設計加重了他們的工作量。

解決辦法：使用標準組件庫中的原型組件并使用線框圖方式，組件間的交互統(tǒng)一并采用文字描述，減少交互效果設計帶來的工作時間。

3. 需求評審

需求評審效果不佳

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

產(chǎn)生原因：公司及產(chǎn)品人員對需求評審的重視度不夠，內部沒有儲備行業(yè)的專業(yè)性人才。

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

三、產(chǎn)品開發(fā)

1. 需求詳講

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

產(chǎn)生原因：產(chǎn)品事前沒有將相關材料交付開發(fā)人員，開發(fā)人員沒有事先了解資料，導致詳講效果差。

解決辦法：事前產(chǎn)品人員將資料分發(fā)到項目開發(fā)人員手中，事前由開發(fā)人員準備問題，詳講會上由產(chǎn)品人員根據(jù)問題清單重點澄清開發(fā)人員疑惑問題。

2. 需求變更

問題描述：產(chǎn)品人員進行需求變更時，沒有詳細考慮導致一個需求需要反復，而且有時客戶提的需求設計完成后，又不再需要。同時，需求變更沒有同步同知相關開發(fā)和測試人員，導致相關人員開發(fā)完成后才接收到變更的內容。

產(chǎn)生原因：產(chǎn)品人員對需求變更的隨意性，導致需求變更和管理混亂。

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

3. 版本提測

問題描述：提交測試的系統(tǒng)，測試過程中發(fā)現(xiàn)流程不通，開發(fā)的bug數(shù)量多，出來的系統(tǒng)與設計的原型存在不符的情況。

產(chǎn)生原因：開發(fā)時，各個模塊由不同開發(fā)人員開發(fā)，提交測試時，沒有進行系統(tǒng)的集成測試。開發(fā)人員在系統(tǒng)開發(fā)過程中發(fā)現(xiàn)問題，沒有及時與產(chǎn)品人員溝通，并按自己理解的思路進行開發(fā)。

解決辦法：產(chǎn)品人員從開發(fā)起及時關注系統(tǒng)的開發(fā)進度，每日與開發(fā)人員進行站會了解開發(fā)的情況及溝通開發(fā)過程中的問題。開發(fā)完成后，第一時間進行系統(tǒng)驗證，保證系統(tǒng)流程的暢通。

四、總結

其實想打造好一款好的產(chǎn)品是不容易的。

產(chǎn)品需求調研到最終產(chǎn)品上線運行是經(jīng)過多個階段的，每個階段都可能由不同的人員參與，信息的傳遞也有可能層層丟失。

所以軟件開發(fā)是一項工程，需要通過管理保證軟件的進度和質量。

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