以下為本人在公司內部關于項目質量和工作效率郵件回復的一此意見和想法。

1、 談流程

不可否認流程的重要性，但我們需要根據具合格情況分析，不斷的梳理和優化我們的流程，讓流程更好的指導我們工作，而不是束縛。目前，我們的流程慢慢多了起來，感覺不如以前敏捷了。經過rpm改造后，無論在測試環節還是發布階段，較之前失去了很大的靈活性。測試階段，開發bugfix后想在測試環境驗證，每次必須重走aone的流程及打包布署，相比之前的build效率真的差了好多。當然，也許是我們項目組對這個流程熟練度、方法還不夠，很多環節有待改進。

發布階段，目前統一由SCM來發布，必然會導致開發對線上環境及發流程更加陌生，同我們提倡的打破邊界，敏捷響應有些相背。再者，SCM資源有限的原因，要支持ITU眾多產品線，能否應付的過來，始終是個問題。發布統一管理有好處，同樣也帶來了弊端，ITU不同于網站，大多數的技術團隊共同在維護在幾個應用，而itu的應用多、規模相對小、環境各異，這樣的產品線采用統一管理性價比不高。希望相應的owner，能不定期的搜集各產品線的意見和反饋，不斷的優化，讓我們的流程更合理。

2、 談自測

我們團隊一直在強調自測意識，也在這方面不斷的總結和改進。我覺的要提高自測，首先應讓每位開發同學形成較好的自測意識，而不是自上而下的命令式管理，只有自己有這方面的意，才會去思考、去想辦法，去實踐。再者，需要PM或技術經理去思考，目前階段實行自測會有什么困難，如沒有系統的自測方法、時間不充足（需要熟悉下階段的UC、下迭代的設計、單元測試補寫等），找到這些困難或問題，就容易對癥下藥了。最后，不斷總結和積累自測方式，優化項目流程。自測不是一種形式，而要追求效果，開發自測同樣需要計劃和方法，所以我們需要向QA同學請教，總結過去 bug常犯的錯誤，整理自己的check項。相信通過這樣的一些自測方法，能真正提高我們的項目質量，打破同QA的界線，我們的開發、測試資源比例可以得到更大的優化，將以前開發階段緊，測試階段松的狀況加以改善，使整個項目過程中的緊張度趨于平緩。

3、 談故障分

“盡量不要讓故障分成為大家包袱，可以考慮被實施產品對事故級和A類才對個人計故障分，B和C類故障分記在主管頭上！”，個人也比較支持駱駝的觀點。目前大家對線上故障都小心翼翼，大家對質量的意識很高，這當然是好事，但同時帶來的影響是效率低了。我的觀點是，作為增值服務的互聯網產品，我們更需要快速迭代增量提供用戶價值，盡快獲取用戶反饋并改善產品，產品推出的遲早，不僅影響獲得回報的時間，還影響到獲得價值的多少，錯過了一個時間窗口，產品可能就不再有任何價值。所以，我們需要找到一個平衡量點，可接受的質量狀況達到最大的效率。

從客戶第一角度談質量，某些時候，客戶可以接受服務偶而不可用重啟下，卻不能接受產品沒價值、交互性太差，操作太復雜。所以，對于客戶來說什么對他們更重要，就需要我們每個人去分析和評估。所以，我們一味只注重質量，而忽略客戶真實需求，那就太悲哀。我的觀點是，case by case，帶著這樣的觀點去思考和解決問題。

4、談敏捷項目團隊

從打破邊界，我想到了一體化的敏捷項目管理團隊，一個目標一致、自我管理的團隊，應該具備良好的目標意識和執行力，不僅能管好自己的一畝三分地，同時也能站在項目、團隊的角度看待問題。PD出現了問題，開發積極去彌補；開發出現了問題，QA積極去彌補，項目團隊的目標非常一致。每位項目組成員一定要把好每一關，萬不可把問題向下拋，因為還有開發或QA會把關，所以差不多就行了，這樣往往就是災難的開始。