其他

序：昨日吃飯，路上遇到了同事L，談起他以及他所在項目小組工作，L告訴我他的一個真實的、新鮮出爐的故事，雖然L以前也聽過我有關於部署實施的培訓課，但是他說在工作中真正在吃了虧之後，才能更好地體會到其中的問題。情境：故事實際發生在上周四周五。計劃的事情如下：同事L的項目組服務於業主Z，業主Z計劃在周四晚上開始停機，對IT基礎支援環境的Oracle資料庫進行升級，計劃從9i升級到10g。IT基礎環境的維護工作，做為長期的外包服務，業主Z是交給了第三方服務商J負責進行。同事L的項目組根據計劃，藉著此次I

文章目錄 Introduction"What Is Struts and Why Should I Care?""Struts is a Web Application 'Framework'?""... And Frameworks Are Important Because?"How Does Struts Work?"Bottom Line Benefits of MVC"Case Study: Right Hand Manager

在周一公司內部和部門經理一起進行的項目周會上，專案經理基本上會按照以下的議程給管理者彙報：上周工作計劃的完成情況以獲得的成果或者產出；上周實際執行情況與上周預計的計划進行差異分析，提出改進；本周的工作計劃以及對項目目前風險的分析；呵呵，聽報告其實是個苦活，如何從聽彙報中瞭解項目工作的細節，找到可能專案經理忽略的問題或者風險，分析問題的關鍵點，並且給出意見，是專案經理們給管理者的考驗！從前端時間對專案經理Review的工作實踐，我們發現目前很多專案經理在制定計劃能力需要提升，目前已經將培訓需求提交

續（挖掘篇）其實想瞭解業主IT方對項目的底線，壓根也不需要舉這樣的理由，但是專案經理已經在周會上在使用者面前這麼說，其實已經沒有責怪他的必要了，而且現在不是責怪的時候，而是應該接著深入分析項目情況，瞭解項目目前的困難以及癥結，才有可能給出正確的、具體的指引。因此，我們管理中心的同事接著詢問目前項目的主要問題以及改進措施。專案經理回答主要是溝通效率的問題，目前改進措施是：正式發郵件給業主IT方，要求周會業主的業務方必須參會；另外，要求監理人儘快熟悉系統；落實責任，責任到人，落實我們彙報給誰落實，避

     這個案例是我從一個應聘人員那邊聽到的，該應聘人員是一位比較資深的專案經理，他來應聘公司的CMMI改進工程師。據他說最牛的時候曾經帶著16個團隊的成員同時負責7個並發項目，他1人作專案經理，2位技術經理，其它為開發人員，這些項目的周期從5個月到1年不等。這些項目有配了2個QA人員，在談到QA對他項目有什麼協助時，我請他舉一個印象最深的例子。他談到了一個關於需求確認的例子：    

今天瞭解到某Java平台的管理系統本周三在外地進行培訓，但是在培訓的現場，有省市二十多位使用者代表在作業系統時出現系統“假死”的情況。整個情況與博文《曆史為鑒：穩定高於一切！》非常相似。當然，現在發現問題，總比在生產上線後出現問題去解決好得多！亡羊補牢，為時不晚：下周將針對應屆新員工的IT系統穩定性培訓，延伸到老員工，進行穩定性的相關知識掃盲，詳細見《給公司的應屆新員工加餐，讓他們知道如何“死”！》，只有讓同事們知道，搞“死”系統的幾種常見方法，才能避免在編寫代碼的時候，自掘墳墓；開展Weblo

情境：D原先進行中一項工作T1，承諾今天下班前完成；中午的時候，D的領導E給他下了一個任務T2，要求在明天下班前完成，結果D放下了T1，去執行T2。由於T1工作我負責監督，所以當發現T1沒有按時完成的時候，我詢問了D為什麼，D給我的解釋是出現了突發事件，並且問了我他遇到的困擾：“領導給我安排新的任務，但是和進行中的任務在時間上出現衝突，該怎麼辦？”分析：我給他的回答和分析如下：原則性如何把握，是因為領導交辦下來的任務就優先保證呢？還是承諾優先？工作T1也好、T2也好，簡單化的領導任務優先方式是不

前言寫一篇系統建模領域的文章，是懷著忐忑不安的心情來寫，不敢褻瀆這個領域的思考者，因為特定場合下工作良好的思路/模式在另外的場合下可能會失敗得很慘。如果存在普遍適用的方法/模式，軟體將會只提供該種方法/模式的支援了，為什麼還要讓人操心呢？在談論複雜的時間建模的案例前，我們先來看看一個簡單的系統模型，不存在時間緯度的需要，看看需要考慮的問題。我在十年前在某OA產品中使用過，因為產品的思考，盡量通用性的考慮，採用過以下類似的通用資料模型，目的是“最大化靈活度”，用SQL語句來表達的建模結果如下：/*

這個問題在培訓的時候，有同事就已經問了我們，既然我們每周都有項目周報，還需要在周會的時候專門製作彙報PPT資料嗎？呵呵，恰巧我們去參加周會的時候，確實有遇到過同事開啟項目周報和客戶一起討論開會:)這個問題，我們是這樣理解的：用項目周報Word檔案彙報，給人的感覺不太專業，特別是有領匯出席會議的時候，所以平時我們需要養成良好習慣； 用PPT方式進行彙報，可以引導聽眾Focus在某個專題，關注點不會太分散，而不會被無關的其他文字所幹擾；

情境：近日某一項目本周和業主進入商務的工作量確認階段，據專案經理P反饋，雙方在討論工作量時談得很痛苦。業主方在Review我方的工作量評價明細時，由於我方對工作任務項的細化分解比較細緻，因而業主方要求我方提供從人員投入和時間緯度來檢查工作量。雙方在談論資源投入的工作量時，對資源投入的分歧較大，討論了一個下午，僵持不下。分析：業主和我們進行工作量的討論，不是在買菜討價還價。我告訴專案經理P，雙方談了一個下午都僵持不下，證明雙方都還是想努力達成共識的，都很痛苦才是正常的表現。對方有控制支出的衡量，你

情境：自公司成立以來，以往由業主方召開的項目初驗會議，都未發生過項目初驗上出現問題。我一直認為，中國人的從眾心理一般都挺嚴重的，加上我們對項目品質的認識以及對專案管理的重視，就沒有碰過一回結論為：初驗不通過的初驗會。這次，這樣的事情都給我趕上了，剛聽到部門經理Z講的時候，我都覺得有點不可思議！你能理解嗎？因為會議之前，同事Z告訴我他得參加項目S初驗會，我還非常堅定地告訴他沒有什麼必要，既然現在有專案經理P在管理項目，就讓P去全權負責初驗會議，我當時還對Z說，我和你打賭，你去不去初驗結果都一樣是通

項目E上周完成了初驗，專案經理G一直想將他的經驗總結下來，給後續的同事進行學習，我也非常鼓勵他去做這件事情，今天收到他的總結大綱。呵呵，將大綱先發為快，我非常期待聽一堂他的總結課，我想從以下的大綱，您應該會講得很有意思的:) (註：一下內容摘自同事的郵件，其中每一點都可以寫成一個獨立完整的小故事，期待G同事的作品) 一、項目啟動1、  “變數”初始化NULL值的後果——項目的前提條件確定和與業務方交流模式的確認2、  牌桌上到底有幾個人？——瞭解項目干係人3、  “關於XX若干曆史問題的決議”—

情境：業主的項目E由多方合作來進展，目前已經開展了近一個月的時間，我方負責實施落地，另一方H負責項目的顧問需求分析。周一與QA對項目E的工作情況進行監控，瞭解在多方的合作中，存在具體工作與合約約定不一致的地方。而我方的項目組員在這一分工立場上，原則站位還不夠清晰。在幾方專案經理都在場的項目周會中，當顧問需求合作方H對我方的同事說：“我們寫的需求可能要求很高的，到時候不能落地吃虧的還是你們，所以不如你們直接主導需求調研，併產出需求。”我方的專案經理Y基本上就預設了，雖覺得有不妥，但又不知如何回應。

續《 使用者投訴：為什麼你們的項目沒有經過效能測試就準備在周五上線？！》，投訴回電後，馬上電話協調部門經理的管理者，安排資源跟進死機的問題，為項目小組的周五上線做積極的準備。回到公司，根據電話的安排，組織該部門SDU（我稱為特別行動小組，港行稱為飛虎隊），開到使用者的現場去瞭解和排查問題，其中有一個SDU的成員，原定進行中公司的應屆新員工的培訓，被要求集合歸隊出發。在出發前，除了安排好培訓工作外，還給正在培訓的學員安排了周六一個加餐，要求他們在周六晚下班前，編寫出讓Tomcat掛起死機的代碼！原

情境：（續原文《曆史為鑒：穩定高於一切》）某項目組的系統在培訓的時候出現：40個左右的終端使用者在操作我們的培訓系統時，系統沒有了響應，終端使用者操作的瀏覽器一片“空白”，後台伺服器類似“掛起”，需要重新啟動背景中介軟體伺服器。剛開始，專案經理和技術經理對此現象的風險意識不夠，在多方教育下，逐步認識到目前發現並且解決問題才是最佳處理事機，等待上了生產系統，由於更多人員使用，會有太多幹涉要素會加大分析和解決問題的難度。經過教育後，項目組投入核心技術人員花了一個星期對問題進行排查：從業務角度，分析是

我認為，對於脫離了作坊式生產的軟體公司，用保姆盯小孩的方式來進行人員的引導和培養應該是行不通的。公司的管理層（不包括專案經理），都不能同時應付那麼多的“小孩”，也不應該那樣去對待“小孩”。估計那樣會有點吃力而且沒有收到良好的效果。 對於目前以項目組為單位的形式下，要把握好人員培養這一關，專案經理起著一個很重要的召集人的角色。但是部分的專案經理的首要任務是完成專案工作，而且主觀上在安排分配工作上都喜歡用“好用”之人，特別在項目比較緊急的情況下，就很難存在培養這一說了。這是人員培養的時間方面的問題。

前日下午過了下班時間，看同事A還沒有回去。問A為什麼還不回？A說正在整理下午的內部設計評審的內容。接著又詢問了下午他們內部設計評審，總有多少人蔘加並且提出了多少個問題（其實想通過這個問題瞭解到提出問題的效率以及能力）。從回答的資料上來看，我覺得對於項目的第一次技術評審，該資料還有很大提升的空間。簡單看了一下他們項目組的模型設計，我給A幾點建議：美觀上去改進，給人看起來舒服，特別不要出現斜線、斜線交叉、實體對齊以及大小自動調整；多用Note表達一些設計者的意圖，特別是在一些不能按常規思維考慮的地方

前段時間參加了一些項目評審會議，發現同事對評審工作的存在一些常見的誤區，現將這些問題羅列出來，拋磚引玉，以便管理中心的CMMi推進小組跟進。 一個是對評審的方式的理解存在誤區，評審不是一定邀請大批同事參加一個評審會，這樣的工作方式很多時候會變成效率低下浪費資源的方式。評審其實可以分正式評審與非正式評審兩種形式，而且往往在正式評審之前，多採用非正式評審的方式進行預先評審。非正式評審會的處理形式如下：召集人（多由專案經理承擔）組織項目成員編製階段性成果的產出物，收集電子的產出物，完成評審的提交物；召

情境：昨天同事H和我溝通，談到了項目在開展時存在的問題，聊到公司的工作量評估和考核辦法。目前工作量在售前的時候，由售前人員評估後經過部門經理的審閱，和業主客戶進行共識確認。可是等到專案經理進入的時候，就會發現，售前評估的工作量少了，工作量有增加，該怎麼辦呢？而且公司對項目的考核機制也包括工作量的考核，考核工作量的基準應該是那個呢？分析：同事H反映的問題應該有一定的共性，從H的描述中，我們可以看到這個問題可以通過以下兩點去改進：售前階段加強項目工作量的共識：使用專家評估法對工作量進行評估，增加評估

昨日同事H已經確定離職，我找他談話，聊到給我們的建議，兩點中的其中之一是關於人員培養方面的考慮。同事H告訴我們，他認為要更加關心人員的培養，而培養人這個工作只是某個人、某個部門去關注去執行是不夠的。現將他的思路點滴記錄整理下來，供我們自檢：項目的目標如果只是項目，對於項目的人員成長相當不利；項目組之間的交流對於提升項目群組成員的能力非常重要，一年一度的公司開放日給各個項目組有了展示和交流的舞台，但是如何將開放日平民化是需要去努力營造的環境；關注人的發展，給每個人（不僅是個體受關注的同事）的發展做