在一個軟體研發項目的管理實踐中，專案工作的分解一直是一個很重要的工作，但是不同的專案經理對這個問題的操作方式又常常會千差萬別，其中一個很常見的分歧在於，是橫向分解還是縱向分解？本文試圖對此進行一個簡單的探討，希望能給處於專案工作分解困惑中的專案經理們一點借鑒。 首先解釋一下這兩個概念： 橫向分解是指基於技術架構層次進行的人員角色分工和任務分解。比較常見的一種情況是，項目的技術架構採用展示層、業務層和持久層三層架構，然後這三層分別採用struts、spring和hibernate架構，於是人員招聘時分別對相應的架構使用提出要求，具體任務分解時先由專案經理分解好模組任務計劃，然後由設計師定義好各模組的層次間介面，再將具體編碼任務分解給程式員。 縱向分解是指基於業務模組的任務分解。比較常見的一種情況是，專案經理首先擬定出整體項目進度計劃，再按模組對專案工作進行分解，設計師關注模組間的介面和技術體系的一致性，具體模組內的設計和實現由各模組的責任人相對獨立地完成。 橫向分解是目前普遍採用的方法，優點就不多說了，網上應該有很多相關的介紹，缺點卻是很明顯的：首先，對於普通編程人員來說，設定檔編寫起來相當煩瑣，常常缺乏編譯期檢查，就算有工具支援往往也沒有編寫代碼來得順暢。其次，看懂一個簡單模組的代碼通常也要在代碼和設定檔間轉來轉去，比較吃力，特別對於接手前人工作的程式員來說，簡直是個災難。再次，橫向分解是建立在模組內層次間良好溝通的基礎上的，對於層次間的溝通要求很高，如果這一項工作做不好會使整個項目陷入泥潭。 當然指出橫向分解的缺點並不是要對此種方案進行全盤否定，而且方案的缺點有很多在項目中是可以規避的，只是這種方案的成功實施是建立在很多假設的基礎上的，比如說項目具有一定的規模，相關人員具有從事相關崗位工作的技術能力，層次間介面能夠良好定義，項目成員間能夠進行良好溝通等等，如果這些假設很多都不具備，那實施這個方案就會帶來災難。 筆者曾經碰到過一個案例，是個視頻門戶的營運系統項目，項目總共只有10人，專案經理卻堅持要採用橫向分解，說是大公司像微軟、IBM都是採用的這種方案，我只問了他兩句話：你從哪兒知道大公司都是採用這種方案？你是大公司嗎？當然他並沒有認真考慮我提的問題，依然大刀闊斧地實施起了他的專案管理策略：首先設定兩名QA負責測試，一名美工負責做頁面，剩下的六人分為前台三人負責展示層和後台三人負責持久層，他自己只做項目進度計劃。
剛分完他就發現業務層沒人做了，由於業務層跟展示層聯絡比較緊密，自然這個任務就落到了前台三個人的頭上，但很快就出現了前後台進度落差巨大的問題，於是業務層任務又改為由後台來做了，但由於介面沒有很好地討論好，整合測試又出現了很多問題。 其實很多剛起步或規模相對較小的軟體公司都採用的是縱向分解的方案，由於資源有限，項目較多，又缺乏高水平的系統分析和設計人員，有的項目甚至從需求分析到編碼測試都由一人完成，機械地套用橫向分解的方案是根本行不通的。當然縱向分解方案對人員素質提出了較高的要求，不但要熟悉展示層的相關技術，也要瞭解持久層的基礎知識，還要熟悉商務程序，重要的是市面上缺乏面嚮應用的分層的整合型的架構，能夠方便程式設計人員快速地開發出設計良好的公司專屬應用程式。
