摘要在軟體開發過程中，經常聽到說：某某專案文件相當規範，某某專案文件相當不規範，那麼，專案文件不規範常見的現象是什麼呢？造成專案文件不規範的原因又是什麼呢？
本文介紹「a專案」的文件檢查情況，一位資源的qa對檢查的結果進行反思，總結專案文件不規範的常見現象，分析其中原因。
案例背景
「a專案」是乙個專案群，涉及電子政務某方面業務的多個專案，約有20個子專案，共有6支開發團隊為子專案提供開發、維護工作。該專案具有兩大特點：(1)、子專案數量較多，根據合同事數量計算，大大小小的子專案約二十個，每個專案的規模都很小，只有兩、三人 ；(2)、「a專案」週期很長，於2023年啟動，至今有8年，每個子專案的週期很短，一般的只有一年時間，甚至不到一年或者只有半年。
為加強專案文件規範，專案經理對qa提出要求，在三個月的時間內，對其中的6個子專案的文件進行嚴格檢查，發現不一致性問題，並要求專案經理對不合格項及時進行整改。qa在檢查文件的過程中發現，有的文件編號、名稱不規範，版本記錄比較混亂，文件主體內容隨意剪裁，標準文件模板使用張冠李戴，該寫的文件沒有寫，很多文件沒有進行流轉審批等問題。
案例分析
通過這次集中的、檢查反饋出的問題，qa在思考，專案文件不規範問題主要有哪些常見的現象呢？造成這些情況的原因是什麼呢？
專案規範分為活動規範，文件規範，與專案質量分為過程質量、產品質量互相呼應。乙個是工作方式方法是否符合標準流程要求，乙個是介質文件是否符合標準模板要求。然而在軟體專案活動過程中，軟體專案、工程活動相對規範，但專案文件不規範相對嚴重，從而引起我們的思考：
一、 文件不規範的常見現象
在軟體開發過程中，不同公司的質量體系、不同專案的質量要求不同，文件不規範各不相同，它與公司質量標準、專案質量要求緊密相連，專案文件不規範常見的現象如下：
1.專案編號、專案命名不規範。
同乙個專案編號不同。有時乙個專案有乙個甚至多個編號，如：某專案編號有時使用yksx，有時使用yksx(tl)。
同乙個專案名稱不同。專案名稱包括有：專案簡稱、專案全稱，如：
它的簡稱有時命名「xx工程專案」，有時命名「xx資訊系統」 ；它的全稱有時命名為「上海市xx資訊管理系統」，有時命名為「xx工程專案資訊管理系統」。
無論是專案編號，還是專案名稱(專案簡稱、專案全稱)，每個專案都有乙個統一的編號、簡稱、全稱。
2.文件編號、文件命名不規範。
每份文件都有乙個編號，如某專案文件編號由wd_pa_pro_yymmdd_姓名拼寫組成，其中wd表示公司名稱，pa表示專案編號，pro表示文件型別、此處指的是專案過程書，yymmdd表示日期，姓名拼寫表示姓名的拼音三個字母組成，不足三位的補「x」或「y」。而在使用過程中，有的不知道pa是表示專案編號，有的日期格式寫成yyyy-mm_dd，有的隨意增加其它內容。文件命名通常由編號與文件型別名稱組成，如專案過程書文件規範的命名是「wd_pa_pro_yymmdd_姓名拼寫專案過程書」。
3.文件頁首、頁尾不規範
一般正規的文件，頁首頁尾大都使用公司的logo或公司的簡稱，它是公司的標誌，也說明這乙份文件不僅是代表專案組，也是代表公司的形象。而頁首、頁尾上的logo或標誌應該是固定的，專案組不應該隨意性修改。
4.文件的版本標識不規範
根據配置管理的定義，文件控制級別為中、低的文件是不需要進行版本控制的，比如那些一些臨時性的、一次性的、中間性的文件，而文件控制級別較高的文件要進行版本管理。在一些控制級別的文件中，如：使用者需求說明書，概要設計說明書等，無論修改有多少次，沒有留下版本記錄。
有的文件標識有版本記錄，乙個版本對應乙份文件，比如《使用者需求說明書使用者需求說明書等，這樣維護文件容易出錯。
5.文件主體的裁剪、格式不規範
與標準文件模板相比較，專案文件主體內容裁剪不規範，隨意性增加或刪除文件目錄的內容，如：標準模板上主體內容有5章，而專案文件經過裁剪後只寫3章，或者是寫6章，增加一章的內容。對於文件格式，大都是不完全遵循標準文件模板。
6.文件審核意見沒有簽名批覆
在專案文件中，大部分文件結尾部分都有相關人員的簽名審批，文件在流轉過程中有相關的干係人閱讀，如果他們沒有意見則同意簽名，這是對文件進行走查、驗證管理的乙個重要證據，也是對專案文件質量進行控制的乙個重要手段。雖然如此，但很少人對閱讀這樣的文件後進行簽名批覆，或者是口頭指出意見，或是郵件回得提出問題，但最終的結果是，從專案文件本身是無法看到簽名批覆的，既沒有書面形式的，更沒有電子簽名的。
7.模板使用不規範
在專案不同階段，每個階段要產生哪些型別文件，基本上固定的。如需求階段要產生《調研報告》、《使用者需求說明書》、《需求確認書》。而不規範命名如：
在試執行試階段，用於規劃、指導試運的文件，質量體系稱為《試執行計畫》，而在使用時將它命名為《專案實施試執行方案》。如彙總所有調研內容的文件是《使用者需求說明書》，而專案經理有時卻將它命名為《使用者需求調研報告》。
8.文件的位置存放不正確
為便於文件管理，專案都建立了乙個個資料夾，將相關的文件分別放置在不同的資料夾下。
有的將《專案建議方案》放在專案啟動目錄下，有的將《需求變更單》放在系統維護目錄，其實上，無論放在**都是沒有錯的，但它不符合規範，同時也不利於文件的使用，間接影響了專案。
9.該寫的文件不寫
開會沒有《會議紀要》，會上發言承諾信誓旦旦，會後忙碌全拋腦後 ；溝通交流沒有備忘錄，需求變更、系統問題沒有記錄，過後問題弄不清楚 ；下達命令沒有計畫，安排工作排腦袋。對於專案活動不規範，直接影響文件不規範，那就是沒有此文件。
二、 文件不規範的原因分析
缺乏獎懲措施，當專案文件規範時，缺少獎勵，如：口頭鼓勵，通報表揚，增加獎金 ；當專案文件不規範時，沒有相應的懲罰措施，如：通報批評，扣除獎金。
在一些外資大型it公司，在專案實施規範的獎懲方案中，專案經理、質量經理共同掌握團隊成員獎金的分配權，專案經理對團隊成員70%的獎金擁分配權，質量經理對團隊成員30%的獎金擁有分配權，當專案不規範時，質量經理可以進行許可權範圍內的獎懲。
對專案文件的作用認識理解不夠。只要客戶滿意，系統穩定、功能健全，專案文件作用不太，主是依靠正在使用的系統，及客戶的滿意度。對專案文件的規範認識理解不夠。
在軟體開發過程中，資訊的傳遞主要是依據面對面溝通、系統演示等方式進行交流為主，以文件介質交流為輔，專案文件是否規範也就無所謂。
專案經理或專案組成員不熟悉規範，不知道規範的文件應該是什麼樣子。在實施過程中，因為他不清楚，又不想辦法進行諮詢，而是根據個人工作經驗，或掌握資源進行專案文件工作。
其它。三、 專案文件規範的作用意義
專案文件是過程活動的終極成果，也是產品系統的過程文件，它是客戶想法與最終產品的橋梁、中介文件。通俗說，專案的使用者需求說明書，它是軟體開發的依據 ；專案的需求變更單、系統問題維護記錄單，它是需求變更、系統修改的憑證 ；專案文件是專案相關資訊、憑證、經驗等的載體，它的意義很廣。從專案組的角度出發，專案文件規範的主要意義包括：
通過客戶審計。**it專案大都有審計部門，如果專案文件不規範，很難通過客戶的審計，如果審計通不過，往往要求返工，或是驗收通不過。
通過第三方監理。隨著資訊化建設不斷加強，資訊監理不斷深入，如果專案文件不規範，通不過第三方監理。類似這樣的還包括專家驗收、第三方測試等。
專案實施規範可以促進專案文件規範，有規範的活動就形成規範的工作成果，反過來，專案文件規範可以促進專案實施規範。
專案文件規範，為以後的開發、維護工作奠定良好的工作基礎。
專案文件與產品文件的意義與區別，產品文件具有反覆重用性，而專案文件具有一次性特徵。
小結在客戶對文件命名沒有特別要求的情況下，應嚴格按公司規範執行，而不僅是專案經理、專案團隊的個人理解或認識。
在專案文件審批流轉過程中，有人認為那是走形式，與其說是走形式，倒不如認為是走流程，走流程是按規範辦事的一種表現。在文件流轉過程中，每個人要做好本職工作，如果流程有問題，則由提交給流程改進人員改進，而不能因為流程不好而放棄，這樣既讓流程改進人員錯過一次改進的機會，同時又滋長個人不按規範辦事的行為。
質量管理 關於專案不規範的思考
案例背景 a專案是乙個專案群，涉及電子政務某方面業務的多個專案，約有20個子專案，共有6支開發團隊為子專案提供開發 維護工作。該專案具有兩大特點 1 子專案數量較多，根據合同事數量計算，大大小小的子專案約二十個，每個專案的規模都很小，只有兩 三人 2 a專案週期很長，於1999年啟動，至今有8年，每...
關於「扶不扶」的深度思考
馬年春晚上開心麻花的小品 扶不扶 中，一句 人倒了可以扶起來，人心要是倒了就扶不起來了！傳遍了大江南北，在笑料十足的小品演繹中，不僅僅是諷刺了乙個可憐而又可悲的社會現象，更多的是影射出當今社會人心的冷漠。無獨有偶，就在小品播出後不久，新聞中 網路上報道了多起因摔倒而無人敢扶或是被人扶起後被誣陷的一幕...
關於操作不規範的處罰規定
一 發件錄單 各站點發件必須在當天晚上12點前錄單，超時錄單5元 票罰款 不錄單每票罰款10元，延誤遺失總部不予受理 中心代錄運單，收取5元 票手續費。二 發件掃瞄 各站點發件必須在班車發出前做發件掃瞄，不掃瞄10元 票罰款，延誤 遺失件總部不予受理。三 到件掃瞄 各站點在班車到達站點3小時內必須做...