需求管理和BUG管理對於專案來說很重要，甚至會影響到專案的成功與否。但由於需求管理過程不盡人意，很多專案最終失敗，延期或者超支完成。

從事專案管理工作，不知道大家有沒有一個感受，就是雖然產品在不斷的更新迭代，但是需求還是會源源不斷的增加，感覺怎麼也不會減少。這時候就需要就要結合需求管理了。

需求池是對來自各方繁雜需求的一個結構化的彙總和統計，它的主要作用在於對需求進行評估和管理。

需求池主要產品是用來收集和管理各方來源的各類需求，這裡不僅僅是簡單記錄需求是什麼，還會記錄這個需求相關的一些關鍵要素。另外初次進入需求池的需求是透過簡單篩選和評估的。總的來說，需求池管理有兩個原則：有進有出、寬進嚴出。

需求古管理(Requirement management)是完整管理模式中的一環，同其他特性諸如完整性、一致性等不可分割，彼此相關而成一體。需求管理指明瞭系統開發所要做和必須做的每一件事，指明瞭所有設計應該提供的功能和必然受到的制約。

一款好的需求管理工具，需要配備方便管理和直觀查閱兩個最基本的要素。

整合包含任務協作、即時溝通、資料管理、目標管理等功能於一體，在融入許多成熟專案管理理念的同時，還不斷創新形成了一套全員參與、全員監督的模式。

因為需求的類別，一般直接影響到需求的優先順序，所以首先要先進行歸類。

BUG類：使用者使用產品具體功能時遇到的問題，影響正常使用；體驗最佳化類：使用者使用產品過程中遇到的問題，雖不影響正常使用，但體驗不好，不好用；使用者體驗新加需求：考慮到使用者需求，產品經理單獨建立需求提交處理；

特別注意：

1. 建立單個需求，定時對需求池進行整理

父子級代辦需求管理

2.在管理需求池時，要把同一模組的需求進行歸類整理，這樣在處理該模組時可以一次性解決，提高工作效率

4. 提及技術的需求一次性不要太多，做到敏捷開發，系統自帶任務匯出模板功能，方便任務整理與再次建立。

花錢請更牛逼的程式設計師

還有專案經理，測試，產品，等等。

這些都是能用錢解決的小問題

軟體開發過程中有bug是很正常的，而且這些基本是在開發完成之後才出現的，所以去糾結究竟是程式設計師的問題還是系統架構的問題，沒有太實際的意義，還是要針對每一個bug怎麼修改拿出具體的方案。

bug多有兩點因素。

1.業務場景考慮不周全，說白了就是需求沒有分析清楚。

2.程式碼編寫能力問題，程式碼規範很重要，同時對各種類庫框架的使用要熟練掌握，這樣才能編寫出好的程式碼，而不是隻會copy的碼農。

找原因是最主要的

1、是技術問題？

2、是態度問題，不認真。

最後一句話，還是專業的人做專業的事情。一定不要為了省錢，請太新手的程式設計師開發程式。

給的低了，招聘不到好的程式設計師，工作低了 新手程式設計師問題多多，

1、的問題就是技術不過關 哪裡都是問題，工作效率不高，你還不如請好一些的程式設計師。

2、工資低了 態度的問題就出來了 大家都懂的，就怕給你磨洋工 態度問題是最要命的 哈哈

可以從以下幾個方面考慮：

1、自身的工作態度問題。

自身的心態也就是責任心的問題，做事不負責，寫完了也不檢查，不測試，這是對自己和他人的不負責。大多數是這種情況產生的。

2、自身的能力問題。

由於技術能力有限，寫出的程式碼質量不高。考慮的不夠全面，程式碼中邏輯不夠好。

3、Leader設計及檢查不到位。

一個專案是有一個團隊共同完成的，其中專案經理佔主導作用，專案的框架設計很重要，而且過程中要不斷的檢查，才能保證專案的質量，不能說專案搭建好了，就不管後面提交上來的程式碼了。

4、測試。

開發過程中需要多測試，出現的問題要及時修改，避免上生產出現問題，影響使用。

以上僅供參考，如有問題，敬請指正！

軟體開發過程中，BUG的出現是不可避免的。其原因很多，大多數的BUG是由於開發人員的粗心大意引起的。人非機器，一個變數命名書寫錯誤、一個邏輯判斷的疏漏都必定會導致BUG的存在。軟體有BUG並不可怕，關鍵在於這些BUG能夠被及時發現、快速修復。在專業的軟體專案開發過程中，BUG的管理體系和質量監管工作是必須的。通常我們會採用一個BUG跟蹤系統來科學管理軟體所產生的BUG，比如JIRA、BUGZILLA 等軟體都是非常優秀的質量跟蹤管理工具。另外不可或缺的，必須在團隊中配備測試人員，對每次軟體版本更新進行詳細的測試工作。軟體測試工作非常重要，是保證軟體產品能夠保質量交付的前提。在標準的軟體開發過程中，測試工作是貫穿始終的，並且不同階段有不同的測試目標和方法。比較常見的是

1、單元測試：在開發階段每當編寫完畢一段功能程式碼，都需要進行單元測試。單元測試可以防止在編碼的級別上出現錯誤。例如語法、變數、事務邏輯等。

2、整合測試：當多個模組或者構成一個完整業務過程的多段程式碼完成時，必須進行整合測試。整合測試的目的是確保各個模組或者多個程式碼片段能夠協同工作，並完成預期的業務流程。

以上兩點是在開發過程中隨時需要進行的測試工作。

3，業務測試：在軟體構建一個可執行的版本之後，需要進行業務測試。此項工作需要業務人員或者需求提出方參與測試，以確認軟體在業務需求實現上，是否正確、達到了預期的要求。

4，使用者體驗測試。當了軟體的執行質量、業務功能趨近完善後，應當對軟體的操作使用體驗做進一步的測試，並進行最佳化，以使軟體產品更加易於操作使用。

減少軟體BUG的發生，出了在開發過程中保持認真細心的態度，更重要的是軟體的架構設計管理方法。注意兩點：

1，儘可能讓程式碼自動化構建。計算機程式總是比人細心。多使用IDE的模版程式碼生成以及自動化構建工具，減少人工程式碼的書寫和配置。

2，元件模組封裝，避免同樣的功能反覆編碼。你應該將常用的功能或者業務程式碼進行封裝，隱藏內部實現，以儘量簡單的介面對外提供使用。

3，不要讓程式碼複雜。應該用盡量簡練的編碼實現功能。程式碼寫得越少，就越不容易出錯，當BUG發生時也更容易找到問題所在

言歸正傳，自己寫的程式bug非常多怎麼辦？

我相信這種情況會隨著時間的推移不斷減少的，但目前應該如何應對呢？

首先我們要知道，每個程式設計師都會寫bug，如果把一個系統從無到有開發出來過程中不會產生bug，那一定是不可能的。

至於bug多和少的問題，我認為需要和三方面有所聯絡。

第一：態度。程式設計師對待系統的態度是怎樣的？對待需求的態度是怎樣的？對待技術準確性的態度是怎樣的？

如果被這三個問題問倒，那麼我可以很負責任的告訴你，你的態度非常有問題。一個優秀的工程師應該敢於對自己的程式負責任，敢於對自己的技術負責任，敢於對自己實現的需求負責任。

端正自己的態度是第一步，當你發自內心嚴格要求自己的時候，才是你走向大牛的第一步。

第二：功夫。程式設計師的核心價值就是放之四海皆可用的需求實現能力。而需求的實現可以有非常多的技術方案。舉個例子，一個for迴圈可以有命令式和函式式兩種實現方式，那麼你選擇哪一個？

函式式可以呼叫類庫的實現，而命令式需要你嚴格把控每一步的執行過程，也就會更容易產生bug，如果單從實現功能的角度，那為什麼不直接採用函式式呢？這就需要你對於一項技術的鑽研程度。

功夫下到了，你的技術就會過硬，更能夠預見可能出現的問題，從而避開各種bug。總之一句話，技術一定要好好下功夫。

第三：細節。不管你生活中是否大大咧咧，寫程式碼的時候都要看好每個細節。放過細節是非常可怕的。一個好的程式設計師往往也非常細心。你也可以培養在生活中細心的好習慣，將生活安排的井井有條。避免因為混亂而導致出現差錯。

這樣也可以讓你在寫程式碼的時候減少由於混亂的書寫風格而隱藏更多的bug。

綜上三點，就是我認為可以減少bug的終極奧義。希望可以幫助到你。

------------------------

我是一名程式設計師，每天的工作就是寫bug，然後測試解決bug，然後繼續寫bug，日復一日，年復一年，突然有一天發現我寫bug越來越少了。 任何程式都有bug，bug是無法避免的，只能慢慢積累經驗，這樣以後寫的程式碼bug就會少了~

我也是一名程式設計師，而且還是一名工作6年的C++程式設計師。當初也是一名菜鳥，沒有出眾的智商，沒有大神的動手能力。剛實習的時候，程式Bug一大堆！

工作到今天，我的程式依舊有Bug，只是Bug的級別不一樣了。修復Bug的代價也不一樣了。

程式出Bug的原因

我覺得程式出Bug，得分析一下原因，然後定向解決問題。

程式語言的Bug：我平時遇到的C++的Bug主要有：變數未初始化，記憶體訪問越界，野指標等等，這些都很隱蔽。如果是這種原因，可以藉助第三方工具檢查，比如valgrind。

業務邏輯的Bug：其實因為程式語言出現的Bug都還好解決，如果是業務邏輯上出現Bug，這主要是因為不瞭解專案的業務邏輯。要解決這方面的問題就需要仔細研究好業務邏輯，動手之前要在紙上畫畫業務邏輯。這方面的Bug修復起來的難易程度取決於程式設計的好壞！

優秀的程式架構花費小的代價修復Bug，混亂的結構需要花費巨大的精力修復Bug！

現在對我剛實習時做的第一個專案記憶深刻，我第一個專案其中有個個業務邏輯應該使用MVC設計模式，但是當時沒有經驗，資料，操作，檢視所有都糾纏在一起。後來每修復一個Bug，都需要修改很多程式碼，而且還很容易帶來新的Bug。

所以，對於C++就需要學好各種設計模式，設計優良的架構。要想少出Bug，需要在動手之前，徹底弄清業務邏輯，最好是落實到紙上，做到了然於胸！

從事軟體開發多年，bug幾乎伴隨著整個軟體開發的週期，從開發週期到維護週期都可能存在bug，只要從事軟體開發就會有bug的存在，但是能力高的人寫的程式碼框架相對bug會少很多，初級的或者水平差的做出的東西bug會多一些，在實際開發過程中是否產生bug，有時候不一定完全是程式設計師能決定的，還有本身專案的框架以及開發時間有關。

現在就個人的一些經歷分析下為什麼會產生bug，產生bug從大的方向上講有這麼幾個原因，第一點程式設計師本身能力不足，這種是最直接的產生bug的原因，特別是經驗不足十分容易導致出現一個奇怪的bug，所以在成型的公司一般不會輕易讓新手參與到專案開發中，即使參與也是比較簡單可控的模組，對於複雜的功能基本上都會留給工作經驗豐富的程式設計師，因為要解決新手製造出的詭異的問題還不如直接老手親自完成，初級的程式設計師還在糾結於用程式碼如何實現上，所以出現一些奇怪的現象也是特別正常的事情。

出現bug第二種原因，本身的框架相容性不夠或者可擴充套件性不強，由於框架問題導致在實現的時候可能無形之中增加很多問題，舉個例子如果增加一個新的模組需要改動的程式碼關聯程式碼特別多，這種就會增加bug的出現，或者增加一個新的功能模組，之前的框架相容性不強都會增加很多無用功，所以搭建好一個軟體框架對於後續功能的開發都有非常重要的作用。

第三種出現bug原因，測試力度不夠，在產品出廠之前檢測加大壓力測試能極大的減少產品問題的機率，所以有些企業的軟體測試部門的權威不小於研發部門，這樣無形之中能夠提升軟體測試的力度，有些公司測試部門依附於研發那麼產品的質量必然容易打折扣。

想要完全排除bug這幾乎在軟體開發裡面不可能發生的事情，要做的只能是儘量減少bug的產生而不能安全排除bug的存在，告別bug了也就告別軟體開發了。對於一個普通程式設計師來講如何減少bug出現，現在就以個人的經驗總結幾條

1.夯實程式設計基本功

編寫程式碼就是用基礎程式語言來完成功能模組，這依賴於程式語言的基礎，所以基本功完善起來，就能減少出錯的可能性，在任何情況夯實基礎都是正確的選擇。

2.提升框架能力

站的角度更高一點就容易發現問題，只是侷限於一個模組，做的東西容易帶有侷限性，導致再次新增新的模組出現不相容問題，站在架構師的角度考慮問題，在實現程式碼的時候就能減少後續的相容性麻煩。

3.加強內測，不停重構

很多程式設計師實現完功能就覺得萬事大吉了，實現的功能是不是最優的，在特殊場景下是不是能夠經得住考驗這都是要慎重考慮的事情，發現功能不是很完善的地方就去重構選擇更加最佳化的方案。

減少bug，主要的原因還是從自身出發，排除外界的影響，自身的基本功上去了，bug相應的會減少很多。