老蔡說:
1、背景
2、存在問題
3、制度與監控
4、QA審計方法與組織級技術管理的介入點
我們業務軟體分公司，有200+人員，下設業務擴充部（市場），5個產品線（開發為主）、整合、支撐等各部門
此外，還有一個專案推進部（PMO）
產品線下設各專案組。需要注意的是，由於產品線由經營指標導向，而專案組是產品線下屬機構，所以，PMO實際上只是一個弱PMO。
這種組織結構形成有歷史原因。即使從現狀看，也不可能做成強PMO，因為畢竟各產品線的業務各異，與客戶、各干係人的介面不可能透過PMO進行。
實際上，有一定矩陣式的特點。
產品線經理的考核，主要是經營指標導向的，雖然也有一些其他指標，但明顯弱多了。
因此，產品線經理非常注意經營指標，而忽視其他一些關鍵指標，甚至出現一些短期行為，這都是可以理解的。具體的說，主要有以下問題：
1、專案管理的隨意性。名義上，產品線下屬的單位是3-5個專案組，專案組的負責人叫專案經理。實際上，這些專案經理即便上了PMP課，在實際工作中，仍是非常隨意的作坊式工作。而產品線經理不會對這些進行輔導，只關注客戶的實時要求、經營指標等。
2、對質量的極度忽視。在CMMI的觀點中，把質量提高到前所未有的高度。在我們的實踐則相反，只要使用者無投訴，基本上不會當成專案經理什麼大的過失，軟體做的好壞完全以客戶評價定。
3、由於無質量要求，那麼系統設計、技術架構、新技術引入也都談不上，開發工作在低水平上重複，程式碼複製率很高，複用率很低。這樣，開發人員就缺乏一種技術成長的感覺，也會缺乏團隊歸屬感。
Kerry 說:
產品經理的確只對產品的特性負責，專案經理對專案進度、風險、成本等進行管理
老蔡說:
4、由於管理的隨意性，人為偏好，技術成長困難等因素，導致員工的受挫感的傳播，團隊難以形成好的氛圍。
Kerry的問題我先解釋下。我們的“產品線經理”是專案經理的直接領導，PMO不是專案經理的領導。所以，他們負責的面向是完全一致的。其他問題等最後一起聊吧。
5、各類管理資訊無法到達分公司管理層，導致分公司工作被動，有時是客戶投訴到總公司時，分公司領導才得知此事的情況。至於組織層面的整體技術管理，根本不可行，如同昨天說到的知識管理案例也是這麼回事。
根據以前管理產品線的經驗，針對這些問題，我的考慮是（1)透過《專案流程》的制度，把職責、流程、流程中各角色職責、基本行為規範、基本軟體過程定下來。
（2）透過組織級QA審計，檢查各專案的流程執行情況，同時取得一手資訊，避免資訊被專案經理、產品線經理兩個管理層面遮蔽。
（3）在資訊通道開啟之後，技術管理等其他管理手段逐步介入。
現在就著上傳的4個文件給大家說明一下我們的工作方法
Richard李明-專案主管-北京說:
嗯有流程，資訊流動好像不是很好
老蔡說:
李明的問題，正是我要說的。
Richard李明-專案主管-北京說:
請繼續哈
老蔡說:
首先，流程執行的第一個要求是客觀，實際怎麼執行，怎麼表達。
我們是行業應用軟體，一是軟體開發流程，這是一個時間段。在這個時間段中，可能會出很多很多版本，一般1周至1個月出一個版本。
出版本後，要升級到現有系統去，那麼就需要製作升級包，升級手冊、資料庫指令碼什麼的。升級操作是一個“點”而不是一個時間段，但由於它非常重要，所以我們也要記錄和審計。
開啟《版本開發流程單》，這份文件，就是要求每個迭代版本開發時填寫。
評審等過程，簡化為簽字，而不像CMMI要求的那樣出評審報告。
對於大的版本，比如1個月出一次的，一般來說，會有與使用者的原始交流，即使用者提出原始需求。
然後需求人員進行分析，出需求規格文件。
再和開發人員、專案經理開會，確認做哪些，哪些跟客戶解釋不做或以後做。這個會議，不要求出評審報告和會議紀要，只要相關開發人員簽字認可。
接下來專案經理根據大家評審的結果，進行規劃版本；後是測試。
最後專案經理稽核整個版本包，產品線經理複核。
如果是一個緊急補丁，很多過程可以簡化。
這樣，實際上用於“流程”的時間，也非常少。
等到版本或補丁製作完，開始準備上線時，需要進行現網操作稽核
這個細節就比較多，因為維護支撐部其實沒有參與前期的開發，那麼他們就會對專案組期待很大，而自己不去關心版本的內容。另一面，專案經理也會有同樣的期待，這裡就有一個漏洞了。
QA審計要關注到這個升級操作是否明晰，是否可執行，是否可回退等。
甚至，如果現場實施人員，同時也是次日保障人員，是否可能？對於一個簡單的補丁一般沒有問題，但如果大版本肯定不行。
這樣，理論上，專案成員只用了簽字、填表的時間成本，就把關鍵的專案資訊都透明出來了。
補充上，剛才漏了。在CMMI中，提倡對每個專案的軟體過程進行定製。
在實踐中，我認為基本不可能。
所以我的做法是，根據專案的重要程度，新系統開發還是迭代式，分別管理。具體見《專案檢查點》上的說明。
這樣，PMO維護一份專案清單，同步給各產品線，大家按照專案檢查點上的要求，結合整體的專案流程，這樣實際上就等同於，定義了5-6種標準過程，選擇使用（PMO與產品線事前溝通選擇）
最後說下執行的情況。
在最初，我摸索這個方法的時候，儘管要求專案成員填寫的資訊不多，但透過有限的資訊，以及相關的工作產品文件，可以發現一些疑點或不清晰的地方，然後找相關人員訪談確認（這個訪談也跟CMMI不同，重實質不重形式上的覆蓋率）。
這樣，發現了很多並不是一般意義上的流程執行問題。
例如，可以發現補丁包製作錯誤，發回專案組重做後，才同意上線。
（嚴格的說，是否同意上線不是QA的權力，QA審計是事後的稽核點。因我是分公司管理層，才可以這麼做）
當我把這個方法移交給QA時，發現執行情況不理想。受CMMI薰陶過多，每個流程單十幾分鍾就稽核完了，要麼就是完全違反流程，要麼就是沒有任何問題。
為此，我重新考慮了我自己的稽核的方法，設計了《QA審計報告》文件。本來我認為QA審計應該不受限於審計報告，而以主觀經驗帶入為好，但這樣導致我對QA無法監督，而QA發現問題越少也無所謂。現在不得以加入文件化的審計報告
這樣，一方面，審計報告中體現出QA對專案原始資料的蒐集。這些蒐集主要不是透過詢問專案人員，而是訪問SVN、Jira等
透過原始資料的蒐集後，對於軟體過程審計，應當能分析出一些有意義的結果。
什麼是有意義的結果呢？例如，一個大版本，開發人員200的，有測試報告，但Jira上卻沒有BUG記錄？或者只有少量的小BUG，這肯定不對。
“軟體產品質量審計”這個小節，側重關注產品定義是否清晰，實際上與配置管理關係很大。很多專案組的配置管理非常混亂。
部署包和升級步驟，基本上就是組織級技術管理的主要介入點之一（新系統開發的評審也是重要的介入點）。
在這個點上加強控制，可以提高升級的成功率，減少回退和次日的問題數量、緊急補丁數量。
這個部分，也是要求QA做獨立意見的。
徐文錦 - IT Consultant - singapore 說:
問一下你們有幾個環境除了dev 和production
老蔡說:
當我看到審計報告時，如果對QA意見明顯不認可，可以找QA談，順便指導QA的工作。
最後，版本上線情況跟蹤分析，實際上形成了一個閉環。
可以關注到，專案經理、產品線經理是否有進行後續跟蹤（很多產品線經理根本不管）。
然後與其他版本建立相關性，可以分析是否存在屢次升級失敗，是什麼原因等。
透過這個審計報告模板，基本上QA的工作可以保證達到一定的細膩度。對於分公司層面進行上線最後的確認也不會太盲目。
主要內容就這些了。麻煩徐文錦再表述一下問題？
徐文錦 - IT Consultant - singapore 說:
我說的是, 從開發環境到生產環境中間還有幾個環境幾個步驟
老蔡說:
正常情況下，開發環境就是開發人員的工作電腦＋資料庫；測試環境在公司，也獨立於開發環境。生產環境不在我們公司。
獨立的測試環境，和正確的版本製作方法，理論上可以保證版本升級的正確性。
不過，在實踐中，專案組混同開發與測試環境的事情也不少見
各位，還有問題嗎？
徐文錦 - IT Consultant - singapore 說:
個人感覺不讓開發人員接觸測試環境即QAT 可以較大的提高軟體質量.
老蔡說:
是的，我們是這個要求。但是，從分公司管理層面，到開發人員有管理層級的差距。如果去問專案經理，很可能還告訴你他們分的很清楚，只有在工作實踐中的QA資料才能發現問題。
吳柯-管理-北京說:
你們是為自己的母公司開發軟體嗎？
老蔡說:
不是，為電信行業客戶開發。
吳柯-管理-北京說:
哦，一個大軟體公司，業務軟體分公司是一個大產品線
老蔡說:
不是。我們的分公司，你可以理解成一個獨立公司，除了財務不在我們，其他職能多少有一些。
吳柯-管理-北京說:
哦
產品版本和專案版本怎麼同步？
lastwinner-pm-bj 說:
跟上進度了，老蔡今天講的這個層次相對較高了
我想問一下，這樣做，對QA的技術素質貌似要求很高呀？
老蔡說:
無所謂產品版本和專案版本，在配置管理混亂的情況下，只能根據各個專案的實際控制來說。實際上，基本是一個地點的一個專案一個版本。產品，只是概念上的，用於包裝給客戶的。
徐文錦 - IT Consultant - singapore 說:
QA其實是軟體開發中非常重要的一個環節
吳柯-管理-北京說:
這樣啊
徐文錦 - IT Consultant - singapore 說:
microsoft的office team   dev和qa的比例達到1:10
老蔡說:
lastwinner，由於歷史原因，我這邊的QA薪酬相當不低。
徐文錦 - IT Consultant - singapore 說:
而且嚴格的專案一般是要求qa或者專門的deployment team 出包和部署
吳柯-管理-北京說:
哪質量難以得到保障，產品發展代價反而更大
lastwinner-pm-bj 說:
怪不得分配的任務要求這麼高
徐同學說的微軟的情況，國內很多公司夠不適用的，連用友這樣的公司都做不到
徐文錦 - IT Consultant - singapore 說:
我覺得國內公司特別是小公司對於qa的要求太低  很難保證產品質量
吳柯-管理-北京說:
比如一個專案裡發現的BUG，修改後其他專案未必用得上
lastwinner-pm-bj 說:
國內很多公司都不適用的（剛把都打成夠了）
老蔡說:
我們是要求測試人員出包。即開發人員宣稱程式碼已經好了，然後測試人員打上版本標籤，從SVN庫中取檔案，用事先提供後的指令碼構造編譯出包。實際上，個別專案組做的到，大部分做不到。
吳柯-管理-北京說:
這個是對的
徐文錦 - IT Consultant - singapore 說:
一般這個過程可以採用自動整合/編譯/部署  ,不過一般需要專門的部署團隊
吳柯-管理-北京說:
版本一定要專人
老蔡說:
我的方法是，開發人員可以幫助測試人員寫指令碼。但提交測試和部署的版本包，一般是在開發人員無法接觸的情況下生成的。
吳柯-管理-北京說:
除了SVN以外，還用到什麼輔助開發管理的工具嗎？
lastwinner-pm-bj 說:
老蔡你說的 "做不到"，指的是程式碼的版本管理做不到還是說實際上他們宣稱的程式碼已做好是不符合實際的？
老蔡說:
這樣，只要測試透過的包，拿去升級一定沒有問題。
lastwinner-pm-bj 說:
老蔡-技術總監-福州 says (13:24):
這樣，只要測試透過的包，拿去升級一定沒有問題。

這話太絕對了，不過這樣做可以說99.9%的情況下都不會有問題
徐文錦 - IT Consultant - singapore 說:
如果你有興趣可以研究一下TFS 和微軟一整套的軟體開發流程
老蔡說:
lastwinner，是專案經理的意識做不到。我現在的工作層次在組織級專案管理。
lastwinner，別這麼認真啊，其實99%沒問題就已經非常非常好了。我們目前升級的回退率大概5%，加上升級有問題的情況，應該快10%了。
徐文錦 - IT Consultant - singapore 說:
一般比較正交的測試把bug降低到1%問題還是不大的, 如果有會寫程式碼的qa 那麼還會再降低Bug率
lastwinner-pm-bj 說:
如果是意識問題，那麼透過你的方法灌輸下去，多數專案經理就能具備這樣的意識，對吧？
老蔡說:
不只是灌輸啊，要循序漸進，慢慢滲透進去。
專案經理真想做，一定能做到的。
吳柯-管理-北京說:
一個產品同時支援多個客戶？
多少個？
老蔡說:
大部分產品是1個。現在慢慢2-4個的，但實際上，那個產品也有很大變更。你理解成專案或許更好些。
徐文錦 - IT Consultant - singapore 說:
問一下, 誰為版本回退/部署失敗負責?
吳柯-管理-北京說:
以現場客戶開發為主，還是在公司開發測試完後在現場只是部署？
老蔡說:
專案經理
在公司開發為主。
吳柯-管理-北京說:
這個是電信的行業特點，還是你們公司的業務特點，我們公司做金融行業，大部分是現場開發？
老蔡說:
電信行業，一般不會大部分現場開發。金融行業，聽說大部分是現場開發。
吳柯-管理-北京說:
公司開發要求客戶的需求質量比較高，變動也不能太多
你們這方面如何控制
徐文錦 - IT Consultant - singapore 說:
畢竟你們和錢打交道....軟體質量會要求比較高
lastwinner-pm-bj 說:
這種管理方式感覺能讓PM較快的成長起來，而且能對自己的工作職責範疇有清晰的瞭解
MicrosoftInternetExplorer402DocumentNotSpecified7.8Normal0吳柯-管理-北京說:
客戶不參與最後的測試嗎？
徐文錦 - IT Consultant - singapore 說:
應該是參與的吧
吳柯-管理-北京說:
你們測試完就直接上線？
蔡曉東說:
新系統開發，會參與，但參與度低
徐文錦 - IT Consultant - singapore 說:
不過國內的就不好說了....電信那些人- -#
蔡曉東說:
迭代式，很多情況已經是線上系統了，客戶要求我們1-2週上一次版本，他們沒有精力陪我們測試。要測也是等上了再說。
差不多了吧，這次記錄我自己發吧
吳柯-管理-北京說:
我們一般1-2個月一次，1-2週會不會有些短，從需求、涉及開發到測試？
徐文錦 - IT Consultant - singapore 說:
如果是迭代的話這個時間不算短,
瀑布就慘了
蔡曉東說:
行業不同。有時客戶會要求2-3天來一次。
吳柯-管理-北京說:
哦
徐文錦 - IT Consultant - singapore 說:
你們是如何避免漣漪效應的, 就是你改了一個地方其他其他也受影響
吳柯-管理-北京說:
差異還真大
蔡曉東說:
當然必須迭代。不過目前主流過程對迭代支援都不好。scrum可能會好，但是，scrum的客戶參與等是不可用的，我們必須把客戶做干係人管理，而不是類同團隊成員。
老徐的問題，分兩個層面：專案層面，看經驗；組織層面，就只能在QA質量審計，QA或者分公司管理層發現疑問，追溯下去分析了。
吳柯-管理-北京說:
用了scrum嗎？
蔡曉東說:
沒有，我是在自己的方法論形成之後，才知道Scrum。感覺Scrum也是受應用場景限制的。

組織級專案管理例項分享——來自專案管理群的討論

相關文章