研發人員分工明確．主要的三個角色：ＰＭ（Program Manager)、Dev(Developer)、Tester三者分工明確，接口清晰，PM來定義需求、書寫出每個功能（Feature)特性的設計文檔（Spec),Dev寫代碼來實現這個Spec,Tester來測試Dev做出來的東西是否符合PM定義的Spec,三個角色并無必然的上下級關系，只是分工合作來完成某個功能。
tuenhai:有一次,tuenhai對項目的需求作了一些說明，PM竟然把我的說明作為需求，就匆匆進行開發……后來實在沒有辦法，tuenhai只得撤了他。從某種程度上講，需求比coding更重要。高階主管參與需求制定是有必要的，但項目經理絕不能因此偷懶，不寫需求。定需求要求相關人員交流討論多次，各方都滿意后，才能進行下一步的開發。如果一個PM為了所謂的趕進度，省略需求，甚至省略文檔，如此沒有大局觀的PM,實在是第一天就應該就地免職。
二. Raid 不僅僅是跟蹤軟件功能方面的Bug,其他各種問題如需求文檔的改動，界面上的錯別字，幫助文檔的遣詞造句問題，某項任務指派等等都可以通過一個Bug來跟蹤。
tuenhai:現在公司初創，工作靠自覺，或口頭分配，工作過程無記錄，工作無法量化考核，這種情況想來就頭疼。就一個Bug管理系統，就能提高不少的管理效率。
三. 國內公司對開發這一環節一直很重視，不過需求和測試較弱一點。如果沒有很好地對項目或用戶需求的真正把握，后面的所有工作都是白費工夫，事倍功半。
tuenhai:需求的重要，前面已有論述，至于測試，小的團隊可能沒有專職的測試人員，開發人員有時要兼測試工作。測試有一定的專業性，舉一個小例子。開發人員有無測試代碼在各個平臺各個操作系統的兼容性？有可能開發人員壓根不知道要進行這樣的測試？沒有進行嚴格的測試，產品怎么可以推向市場，由用戶去幫我們測試嗎？tuenhai沒有正式做過開發或測試，但這些流程還是知道的。種種情況，令人憂心。
不單是開發，管理上的一些事情也要走類似“需求，開發，測試”的流程。如果把工作不甚嚴謹的人撤換掉，公司里可能就只剩幾個人……
四. 如果你以前沒有用過Bug管理系統，那么一開始的時候也許你會覺得這個工具浪費時間，因為一個測試人員要費神把發現Bug的詳細步驟記錄下來，有時還要貼一張示意圖，這一切不如當面說來得直接。
但是使用一段時間，你們發現BugFree很有用，它忠實地記錄著每個問題的處理過程，不斷提醒你存在的問題，永遠不會丟失和忘記，如果你參與過較大軟件項目或產品的研發，就會理解它對軟件可持續發展至關重要。
tuenhai:工作方法和過程比結果更重要�，F在公司要以1000w的投入，二年后得到5億的回報，在做這件大事的時候，如果不重視工作方法和工作過程，tuenhai怎么有信心去做好這件事情。1000w的投入，不是兒戲！公司里不少人因為信任我而加盟，如果我不把公司管理工作做好，又怎么對得起這些朋友的信任？
公司人雖然比較多，但清醒者有沒有？有幾個？
在公司初創期，雖然時間很緊，但不管怎么緊，首先是建立一個高效的管理系統。人有了，管理思想也不缺，但還要一個系統，一個工具來支撐。
第一步是招人，第二步是管理系統，第三步是做好各種實事。
web端Livid,Lexrus，碧軒，桌面端yewuyu，明日帝國，七貓都是高手，董事長pangshengdong長于商業策劃，tuenhai做事還算能抓住重點。作為初創且不出名的公司，擁有這樣的人才布局，是相當不錯的了。接下來還要引進分類廣告的專才和資本運作高手（歡迎與tuenhai聯系 tuenhai.com msn:king#tuenhai.com)。
管理系統，我已經交Livid,Lexus,及BugFree的作者王春生來完成，預計一個月內，他們會給tuenhai一個完美的答卷。
管理系統搭建完成后，就要用這個系統高效組織管理。
五.做好Bug管理，應該是從高層領導到中間層管理人員再到基層人員，都從內心認同其重要性，然后根據自己公司的實際情況制定相關的管理體系和制度，切實執行并逐步形成自己的風格。要實用，不要隨波逐流。
tuenhai:我對管理系統的建立是充分認識到其重要性，現在要讓所有員工知道我的思考。不可能我一個人去做所有的事情。根據公司實際開發管理系統，更有針對性�？梢钥紤]在BugFree基礎上進行開發�；蛘咴趩T工內部個人Blog上進行功能擴展，加上工作相關功能。
六.當我決定做BugFree時，腦子里很清楚為什么要做，做成什么模樣，應該怎么做，做出來后大家怎么用，每個環節都考慮清楚了。這樣真正實現的時候就很快了
tuenhai:也就是需求要非常清晰。對于我們公司現在要做的管理系統，需求還不夠清晰。相關人員都都提出自己的方案，然后討論，腦力激蕩。一周或兩周的討論，應該可以定出一個非常清晰的需求。需求定好，項目已經完成一半。
七. 一個好的Bug管理系統要具備以下特征：
1. 可以完備的記錄、跟蹤Bug的一生，從出生——創建新的Bug,不斷成長——記錄相關人員尋找產生Bug原因的討論過程，發育成熟——找到一個處理辦法，同時也允許Bug的復活（問題重現），繼續其生長過程。
2. 方便的查詢功能，快速找到你關心的Bug.
a)最近N個指派給我的Bug
b)最近N個由我創建的Bug
c)各處自定義條件的查詢
3. 提供各種Bug的統計信息。比如每個人頭上有多少個Bug,到目前為止Bug總數統計，最近一周的Bug曲線圖等等。
4. 方便的項目和模塊管理�？梢杂卸鄠�項目，每個項目有多個模塊，方便增加、刪除和修改�！ �
5. 方便的用戶管理。作為一個可獨立使用的系統，需要能增加、刪除用戶。
八. 應該用Bug 管理指導原則（guidance）?來替換Bug管理規章制度（rules & regulations）這個詞。
所以我認為Bug 管理就是去制定適合自己團隊實際情況的Bug 處理流程和指導原則，制定者（管理層）應該起到真正指導的作用，他們要非常清楚下面這些問題的答案：
· 我們需要測試什么：哪些軟件（網站）、哪些模塊
· 測試人員的分工：什么人負責什么模塊
· 測試工具和環境：巧婦難為無米之炊。你不能安排一個測試人員去測某個模塊，而沒有給他提供必要的軟硬件環境
· 測試的進度安排：干這一行加班是不可避免的，但是需要有度，人不是機器，長期的勞累誰都扛不住。如果時間很緊，那只能去抓重點，要有所不為
· 發現一個問題時，如何用Bug 管理工具去創建一個Bug：標題如何寫、嚴重程度、詳細重現步驟、錯誤狀況、期望結果、現場附件、這個Bug 去分配給誰
· 當一個Bug 被處理掉時，測試人員應該如何驗證并關閉
· 當一個Bug 的解決方法有爭議時，誰來仲裁
· 定期的Bug 提醒，比如當前每個人的Bug 情況
· Bug 狀態報告：Bug 數目的變化趨勢及我們應該采取的行動
· 階段性的總結反饋：哪些地方我們做的好，哪些做的不好，為什么、如何改進
· … …
沒有這樣配套的Bug 處理流程和指導原則，再好的工具都將會是一個擺設、甚至是添亂的工具。就像一個樂隊有非常出色的各種樂器，但樂隊指揮是個外行（就像成龍電影《雙龍會》一個鏡頭），那么演奏出來的一定會是混亂的樂章。
九. 已經陸續談過微軟的Bug 管理指導原則了，這里系統的總結一下：
·管理層要求所有的Bug 都要通過Raid（Product Studio）來跟蹤處理。這個看起來很簡單的Bug 管理工具是每個員工和其他同事有效協作的重要保證
·每個產品都細分模塊（Area，SubArea），每個模塊都有明確的需求定義者（PM）、開發工程師（Dev）和測試工程師（Tester）這三個角色。一個問題出現了，一定會落實到
某個人的頭上去跟蹤處理，絕不能出現?無主?的Bug
·PM 負責書寫的Spec 是這個功能特征（Feature）的?合同?，以此Spec 來指導開發和測試。當Dev 和Tester 就某個Bug 發生爭執的時候，PM 負責給出一個明確的說明
·測試不僅僅是Tester 的事情，盡管那是他們的專職工作。研發團隊中的所有人每發現產品的問題時候，都有義務把這個問題告知負責這個模塊的測試人員去記錄跟蹤這個Bug，或者干脆自己新建一個Bug 來跟蹤
·你可以創建一個Bug 指派給自己，以跟蹤某件事的處理。比如開發人員把源代碼中的某處問題用Bug 記錄下來，以后抽出時間來進行處理
·團隊中的所有人都可以創建、指派和更改Bug 的狀態
·當你創建一個Bug 的時候，描述一定要足夠詳細，讓下面處理Bug 的人和其他關心這個Bug 的同事能夠通過Bug 描述準確的重現這個問題，而不是猜測某些步驟或者跑過來當面問你
·通常一個Bug 的處理過程是這樣的：
1. Tester 發現一個問題，到Raid 中創建一個Bug，描述這個Bug 的詳細信息，比如重現步驟（Repro Step）、錯誤結果（Result）、期望的改動（Expect）、運行版本等；然后把這個Bug 指派給負責該模塊的Dev Lead
2. Dev Lead 判斷后把這個Bug 指派給某個特定的Dev
3. Dev 處理掉這個Bug 并返還給原Tester，或者請求PM 給出一個澄清說明
·管理層通過Raid 來跟蹤整體進度，以及每個員工、團隊在其中的貢獻
·有專人定期給相關同事發出Bug 的狀態報告
·每個人都可以方便的自助查詢Bug 的分布處理情況。Bug 管理系統對所有的團隊成員都是毫無保留的敞開大門（除了你不能刪除Bug，另外所有的操作都被忠實的紀錄下來）
·隨著時間的推移，管理層要逐步給出明確的Bug 解決指導方針：哪些Bug 是可以不理睬的（Won’t Fix），哪些是可以推遲到下個版本處理（Postponed）。比如在最終Build到來前的幾周，也許非常嚴重的Bug，像數據丟失、程序崩潰之類的也都要推遲到下個版本再解決了。
·當一線員工出現爭執、無法達成一致意見的時候（盡管這種情況不多見），管理層要快速給出處理意見等等。
十. 我所計劃的Bug 管理指導原則是：
·產品（WAP、彩e 或彩信雜志、網站等）中碰到的所有問題都要用BugFree 來跟蹤處理
·有一個專職的測試小組
·團隊中每個同事發現一個問題時，都有義務去告知相關的人員或者直接創建一個Bug
·需求、開發、測試三個角色的定位要非常明確。特別的，提出需求的人要把需求認真考慮好、細化成文檔，然后才能提交正式開發、測試
·發現一個Bug 時，測試人員提交給某個開發小組長，他來負責指派給具體的開發人員；產生爭議的時候由需求定義者來出面說明；?矛盾?很大時我來協調和仲裁。Bug 的處理過程都要用BugFree 記錄下來：
·每天系統自動通知頭上有Bug 的人自己還有幾個問題。我會檢查這些Bug，看到不合適的地方就去添加我的意見
·每周系統自動通知所有人前一階段Bug 的整體情況；同時測試小組要匯總上周的Bug測試情況，告訴團隊中所有同事哪些模塊容易出問題、主要有哪些類型的問題
上面這些我能夠作為?硬性要求?的，只能是前兩條：
? 任何人再向開發人員反映問題的時候，開發人員會告訴他們：創建一個Bug 來跟蹤
? 剛剛成了一個測試小組
其余的只能融化在日常工作中，管理層不斷在很多細節上要求、甚至親自示范（比如我會使用不同的產品，發現問題上Bug），去教會大家測什么、如何測、發現問題怎么辦、Bug 解決后怎么辦。
十一. 關于“數字神經系統”
讓一切可以數字化、文檔化的 信息被記錄下來，為公司的進一步發展和決策提供基礎信息支持。該系統可以用八個字來概 括：數據、文檔、自助、自動。其表現形式就是一個包括六個子系統的企業內部網：
(1). 員工管理系統 - 每個員工都有唯一的UserID，驗證密碼后方可登錄數字神經系統，訪 問公司內部信息，查看上下級關系、每個員工的個人公開信息等，此處學習 SharePoint、 Outlook和Exchange中的員工管理和展示；
(2). 信息管理系統 - 內部的信息發布展示平臺，有點象 BBS一樣，可發布公司正式通告、 員工也可自由匿名發帖；
(3). Email系統 - 現在Email的重要性對一個企業不言而喻，我們采用免費Qmail來搭建；
(4). 文檔管理系統 - 一個集中管理公司所有文檔(包括研發過程書寫的各種文檔)的地方， 學習SharePoint中的文檔庫；
(5). 源代碼管理系統 - 集成優秀且免費的CVS；
(6). BugFree - 雖然網上有免費的Bug管理系統，但是我看后覺得都不好使，和我在微軟用 的差別太大，科泰世紀公司的 Bug管理系統【見附錄二】倒也很像微軟的，但是要花錢買。 于是決定用PHP+MySQL借鑒微軟的研發流程和Bug管理工具自己開發一個，以便對我們開發新 網站、聲訊軟件、客戶端軟件和公司事務管理中出現的問題進行有效的跟蹤處理。
tuenhai:有兩種表現形式：
一是Blog的基礎上作功能擴展，加上權限，加上評分.
上部導航是我的一些欄目，每月工作，每周工作，每日工作，工作心得； Bug管理，網文收藏，我的簡歷.還可以包括自定義欄目。
每月工作，每周工作，每日工作帖子作固頂。每個帖子分三部分組成：高階主管參與的工作計劃，工作總結，高階主管評分。
每月工作，每周工作，每日工作，工作心得四個欄目本組人都可以看到。其他欄目全公司可以看到。
Bug管理用來創建Bug,指派任務，整合BugFree的功能。
右邊是一些公共的東東，上部可以是公告區，顯示公告或制度等。接著是項目文檔，本組成員的Blog地址，我有權限看到的Blog文章等。
另一種表現形式是如同內容管理系統，欄目和Blog形式一樣。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
