環境、現狀與反思

1 我們今日的窘境

1.1 環境

　　我們所處的環境是一個追求“革命性技術”的業界。公司追求著多、快、好、省地解決問題的捷徑，管理者關注的只是軟件進度、發布版本、成本和利潤，在他們背后，軟件缺陷已經埋了下來。專注代碼質量的程序員往往不受青睞，因為他們思考的更多，在開發進度方面往往不盡人意。當項目負責人無法評估或不關注代碼質量時，客戶只會得到一堆調試不良的代碼。

1.2 人才流失

　　今天的程序員大多數都不會長期從事某一種技術，這與收入緊密掛鉤。程序員會傾向與轉型為更高收入的技術隊伍，或者退出IT業。隨著市場供求關系，各個陣營市場占有率，利潤等多種因素左右著程序員的收入。即便是在某個技術上十分出眾的程序員，面對經濟上的現實差距，也無法抵抗金錢的誘惑而轉投其他技術隊伍。現在的市場，不再尊重那些資深從業者，而是迎合“現學現賣”的投機者。歸其根本在于，對代碼質量的低要求，使得技術硬手無用武之地。

1.3 系統交互復雜

　　今日的信息化系統已經不能由獨立的公司或軟件產品承擔，而是趨于多公司，多平臺的相互協作與交互。現實的挑戰就是，更大的系統，更多的平臺，更繁瑣的流程，更復雜的整合需求，以及更多的標準。

1.4 技術快餐

　　與之前不同，現今的開發者更為大膽。他們敢于將未經驗證的新技術應用與產品或項目。開發者可能經過短暫的學習（一周或者幾天）就將學到的并不熟練的技術應用于項目，之后的風險全部轉嫁的測試或者客戶身上。而此后也不再對這些新技術繼續安排學習。程序的可靠程度和可維護性大大降低。

1.5 產品團隊不堪重負

　　與項目不同，產品的代碼版本及分支路線更為復雜，其生命周期更長。當你進入某個產品項目，你很可能面臨的是，缺失或低質的項目文檔，多種風格并存的代碼以及潦草的少的可憐的注釋。那些最先搭建系統的前輩可能已經離職，開發團隊組成也許已經經過幾代，你聽到的最多的是抱怨。面對那些延期的bug和新的需求，沒人通曉這些堆積如山的代碼，牽一發往往動全身。閱讀和理解代碼占據工作的大部分，面對客戶的各種要求往往不堪負重。

2 一些成功的經驗

2.1 提高代碼質量

• 改進QA流程 多數QA僅僅依靠大范圍的人工測試來評價項目質量，即多數公司的QA依靠的是測試團隊。理想情況下，大范圍的測試并不會有很高的錯誤檢出率。（如果你的團隊，每次發布版本，你們的新建和重新打開的bug數量仍然很高，我只能說你們的公司尚處于軟件作坊階段，真正成熟的團隊，是不會允許交付測試團隊一堆調試不良的代碼的，即便是在趕工時。）檢查缺陷最有效，同時也是檢出率最高的方法，就是——代碼審查。因此，必須在計劃階段，就為代碼審查預留時間，以便讓開發人員參與進來。
• 激勵手段 在績效結構中，應該與質量、進度、復雜度等掛鉤，而不是單純地只看進度。
• 測試每一個關鍵里程碑 理想情況下，測試每個版本，測試用例做到100%的覆蓋率。但現實中，出于時間、成本等因素，測試不可能細化到邊邊角角。但對每個里程碑進行全面回歸測試是最低的要求，這樣軟件的bug更少，開發團隊更能受到激勵（例外是測試報告不盡如人意）。
• 樂觀的對待錯誤 不要把測試當成是對代碼的雞蛋里面挑骨頭，不要埋怨為什么測試現在才測試出之前某個版本的缺陷。PM一定要避免開發團隊和測試團隊之間的相互指責。
• 要求清晰、簡潔、明清的測試報告 測試報告應該言簡意賅，不要過于追求樣式華麗，技術型文檔能夠用一句話說明白就別啰嗦。
• 使用缺陷核對表 “缺陷核對表”我也想不起它的出處了，也或許是我的主觀創造，但從項目實踐角度講，“缺席核對表”能夠有效降低缺陷數量。下列顯示了一種簡單的缺陷核對表：

問題描述	根本原因	缺陷類型	嚴重程度	出現次數	解決方法
修改下拉列表內容后，進行操作會觸發未處理異常。	數據完整性約束被破壞，阻止操作。	設計缺陷	嚴重	4	禁止修改下拉列表選項。
上傳大文件報錯。	服務端限流。	配置缺陷	一般	2	修改配置文件的消息大小限制。
...	...	...	...	...	...

　　這份表格是否好用，在于其更新的頻率與用戶群。它能夠幫助PM及時發現bug集群，并可以通過例會或郵件打預防針，防止缺陷核對表上的bug蔓延。

2.2 為人才流失做準備

• 注重文檔的積累并注重代碼注釋和編碼規范
• 推動團隊內部的交叉培訓
• 在某些共識的環節上推動自動化
• 建立健全的雇員框架

2.3 一些成功的系統整合經驗

• 組建跨職能團隊 公司各個智能部門都有義務參與進系統整合，通過關鍵用戶來平衡各部門的需求。
• 制定合理的進度計劃 PM能夠頂住壓力，制定現實的計劃，而不是通過削減范圍或質量來迎合公司。
• 認真評估資源 很多項目需要外部開發人員參與，所以需要對這類資源進行能力評估，以便合理安排進度。
• 并行上線 在新系統沒有通過最終審核之前，請保證舊系統的良好運作，同時維護好舊系統的數據。
• 做好打持久戰的準備 不同于制作網站或OA，整合項目牽扯到更多的需求，更復雜的系統和業務流程，因此，請做好需求頻繁變更以及打持久戰的準備，并讓團隊了解現狀，防止團隊因為長時間的開發和過少的里程碑而形成挫敗感。

2.4 有效降低產品的維護成本

• 創建并維護文檔 文檔如代碼一樣是寶貴的組織過程資產。雖然敏捷軟件開發注重可以工作的代碼，但是，也不能打著敏捷的旗號來抵制文檔。一些必須有的文檔，比如：需求說明書、軟件規格說明書、開發計劃、設計文檔、測試報告、變更控制等，需要納入到配置管理中去，并且在維護過程中進行同步。
• 嚴格遵守編碼規范 編碼規范必須在項目組內部達成共識，所以開發人員必須嚴格遵守，有條件的推薦進行自動化的編碼規范審查。
• 做好配置管理 請參考本人博文 SVN與SCM。
• 推動自動化 推動測試、發布、代碼審查的自動化。
• 推動交叉培訓 不要等到人員即將離職才分享他的經驗，要在工作間隙，利用暗時間，推動團隊形成交叉培訓的習慣，使關鍵技術不會局限在單點。
• 快速處理產品問題 對于延期的bug要盡快處理，越晚處理，其修復成本越高，一旦開發者離職，讓其接任人員來修復這些延期bug則有些強人所難。
• 對新技術提高警惕 評估新技術帶來的風險與收益，選擇那些滿足企業宏觀目標的技術，盡量不要在高風險項目上引入未經實踐的技術。對于技術探索項目，范圍不要太大，而且，一次不要引入兩個以上的新技術（也有保守的公司，規定技術探索項目，只能引入一個新技術點），以便能有效地評估收益和影響。在引入新技術的過程中，一般用1/3的項目時間快速學習和吸收，用1/3的的世界培養團隊自立，最后1/3的時間讓團隊成員完全掌握。
• 完善項目管理 建立完善的項目管理流程，能夠形成以客戶為中心的，有完善體系的產品團隊，即有效地協調需求、開發、測試、質管、實施等不同資源，快速應對來自不同客戶的需求。

2.5 讓團隊成員參與項目管理

　　如果團隊成員沒能參與項目管理，則項目管理將大打折扣。為了讓團隊的每位成員都參與到項目管理中去，有以下建議：

• PM需要從團隊成員角度思考某些問題 PM需要理解和接納程序員的某些工作風格和激勵因素。
• 適度的授權 對有能力的成員授權，不僅能提高其積極性，也能讓PM能專注于其他業務。
• 常開會，開小會 經常與成員溝通，了解項目現狀，但不要開那種冗長的會議。
• 對于團隊性決策力求達成共識 PM不要以權壓人，對于如編碼規范這類影響較大的規定，需要促成團隊成員的共識，而不是自我的獨斷專行。如果PM搞獨裁，那團隊成員也會玩非暴力不合作。
• 在員工入職培訓時強調項目管理 在入職培訓課程中，明確項目組的各種規定，流程以及工作各種輔助管理軟件的使用。

3 IT治理

　　IT治理就是要明確有關IT決策權的歸屬機制和有關IT責任的承擔機制，以鼓勵IT應用的期望行為的產生，以聯接戰略目標、業務目標和IT目標，從而使企業從IT中獲得最大的價值。

3.1 IT治理成敗20條

10條有效運用資源的方法：

1. 針對IT治理價值，與開發者保持坦率的溝通，解決其中問題而不是壓制言論。
2. 組建公司級跨職能IT治理委員會，保證治理順利推行，保證技術體現客戶最大利益。
3. 建立量化指標，利用公認的指標評估治理進度。
4. 保證IT基礎設施各部分的透明。
5. 將公司IT治理策略延伸到外包商。
6. 建立能表現業務目標的全景視圖。
7. 將IT治理視為促進企業成長的基石，利用獎金引導員工的正確行為。
8. 對公司員工和團隊內跟不上變化，相關技能欠缺等等跡象多加注意。
9. 在軟件開發周期的每個環節都實施IT治理，以防留下盲區，導致差錯。
10. 推進自動化，但不拋棄人工評審流程。

10種白白揮霍資源的行為：

1. 未經解釋就強制推行的官僚流程。
2. 架屋疊床的監督層級。
3. 無人能懂的報表。
4. 被隔離于代碼之外的開發者。
5. 僅限于單個部門的努力。
6. 企圖一切盡善盡美的緊張神經。
7. 僅在一兩個方面實施IT治理的開發流程。
8. 缺乏跟蹤IT管理的支出和效果評估。
9. 重復創造的策略。
10. 對IT治理資源充足程度的盲目自信。

3.2 衡量IT治理和相關投資成效的10個問題

1. 管理層是否支持和實施IT治理？
2. 開發者是否參與其中？
3. 是否是公司的主動戰略行動？
4. 是否增加了企業透明度，使部門和員工權責分明？
5. 是否讓引入新技術和企業合并時的基礎設施融合更加容易？
6. 能否幫助員工改進行為？
7. 是否給所有干系人提升價值？
8. 能否做到極盡精益和高效？
9. IT基礎設施可否隨時抽檢，而保證沒有問題？
10. 是否減少了軟件缺陷？

4 雜談——終結IT業七大流言

1. 信息技術是精確的科學 現實是， 建立應用依靠的是程序員的代碼，而編碼是一門藝術，程序員是匠人，信息技術同樣需要工藝。
2. 下一個版本能解決這些問題 軟件開發商的常用伎倆。
3. 開箱即用 企業級軟件往往很難達到開箱即用，這往往是軟件廠商的吹噓。
4. 代碼文檔完善 現實是，開發人員被進度和變更壓榨了120%的時間，無力維護文檔。
5. 文檔說明一切 文檔質量參差不齊，有時不得不聘請外部顧問。
6. 團隊不需要“黑客”和“牛仔” 前者指那些擅長安全技術的人員，后者則指那些技術強硬但特立獨行的人員，他們的共同特點是技術過硬，工資不菲。其實開發團隊中如果有掌握安全技術的成員，能使你開發的系統更安全；而如果能駕馭牛仔，他將能幫助團隊沖破圍城。
7. 最大的安全威脅在公司外部 現實是，絕大多數攻擊源自公司內部。

參考文獻：