所在公司是一家軟體公司，主要為電子行業、航空航天等軍工企業提供資訊化產品和服務。老闆受他本人在製造業工作經歷的影響，把乙個軟體公司的組織結構設定得如同工廠，幾乎每項工作都是乙個部門只承擔一部分，不允許參與其他工作。比如售前階段，工作說明書是諮詢部負責完成，合同簽訂後，轉到實施部，實施部的專案經理和業務顧問到客戶那裡進行業務調研工作，編寫出業務調研報告和業務需求說明書，通過評審後才能繼續傳遞文件至下游，下游是設計部，負責需求分析和概要設計，再下面是開發部，負責詳細設計和編碼.。。。。。。老闆想得挺好，可是最大的問題很快就來了，軟體過程中的文件很難標準化，評審難有標準。而各個環節都希望上游的產出物一定要滿足下游的輸入要求才行，否則下游的部門就不接！，因此，設計部埋怨專案經理和業務顧問寫的業務需求不夠詳細，不夠準確，沒法做需求分析，評審一次次通過不了，同樣道理，開發部門死活不認可設計部的架構師寫的需求規格和概設，認為不能指導詳細設計和編碼工作，而架構師又認為他們只負責需求分析和概要設計，開發部要求的那些事都應當開發人員自己完成。。。。。。專案經理除了自己要寫業務需求外，整天都在協調、協調，下游環節的部門不接受上游部門的產出物，專案經理也難以判斷該不該傳到到下一棒，需要協調的事情特別多。何況他們的文件也常常被別人狂批，似乎自己也沒協調的資格。
公司前幾年合同專案不多，主要精力放在做產品上，但即使是產品開發，產品經理的業務定義同樣也很難往下傳遞。
乙個專案組由各個部門的人組成，無論是產品經理，還是專案經理每推動一步都很費勁，各個部門扯皮的現象層出不窮。就是在這種情況下，老闆設想成立乙個公司級的綜合管理部門，將公司主要的骨幹，如專案經理和產品經理集中到1個部門，進行總協調和總負責。這個部門被賦予了相當大的權利，因為老闆希望找乙個「強勢」的人能好好替他「管一管」。本人就是在這樣的背景下走馬上任的。我的部門被設定為pmo，與一般公司的 pmo不同，我直接領導專案經理，而且無論何人，不管是哪乙個部門，什麼職位，只要擔任專案經理，就都歸我領導。專案經理管理和考核著不屬於同乙個部門的的組員，即使組員是其他部門經理，甚至是技術副總監，也仍然歸專案經理領導和考核。因此，本人是乙個名副其實的pmo (officer的o,不是office的o) ，管理和掌控公司所有的專案和產品，
其實不光是我們老闆，業界推行cmmi，很多公司都夢想搞「軟體工廠、軟體藍領、流水作業。。。。。。從上世紀90年代年開始，我呆過的、諮詢過的、售前接觸過的軟體企業應該不算少了，還沒見哪家企業能真正做到將軟體開發過程搞得跟生產製造過程一樣呢！但我所在的公司就是這樣乙個組織結構和管理方式，這樣的管理方式帶來了無數的質疑和爭論，可是我們現在誰都無力從更高的層面去說服老闆，因為誰也不敢說換一種管理方式就一定會比現在好，因為這種方式雖說協調的事情多一些，效率低下一些，但是卻保證了乙個專案由多人參與才能完成，因此某個人離開對專案的影響不會太大。到底怎樣才更好，也許時間可以證明一切吧。
專案管理例項（1） 不一樣的PMO
所在公司是一家軟體公司，主要為電子行業 航空航天等軍工企業提供資訊化產品和服務。老闆受他本人在製造業工作經歷的影響，把乙個軟體公司的組織結構設定得如同工廠，幾乎每項工作都是乙個部門只承擔一部分，不允許參與其他工作。比如售前階段，工作說明書是諮詢部負責完成，合同簽訂後，轉到實施部，實施部的專案經理和業...
不一樣又不一樣的 木板接水
空地上豎立著n個從左到右排列的木板，它們可以把水擋住，但溢位最邊上木板的水將會流到空地上。已知木板間距都是單位1，現給定每個木板的高度，請求出總共能接住的水量？說明一點，這裡只考慮間距 寬度 和高度，不考慮第三個維度，因此水量是平方單位。木板高度分別是2,1,3，那麼我們可以接住2 2 4平方單位的...
我們不一樣
前輩們因自身實際的種種因素的影響而產生的認知，並不一定適用於我們自身。你可能從來不會去想乙個問題 你的觀點，來自 其實，它們絕大部分來自網路，它們或多或少地蠶食了你的判斷力。未來的路要怎麼走，沒有對與錯。有的，只是每乙個選擇所需要承擔的責任。我不想面臨，後之視今亦猶今之視昔的悲哀。我希望，未來回首，...