為了保持專案的透明度，pm一般都會定期傳送專案週報，而且一般是乙份週報模板貫穿專案始終。
其實專案在不同階段，專案管理的側重點也會相應發生變化，此時專案報告模板也應做相應調整。
今天我們聊聊專案在準備進入轉運維階段時的專案週報該如何呈現？不一樣的專案週報專案報告真的僅僅是為了告
訴干係人我們做了什麼嗎？
這樣的話，報告能發揮的力量就明顯大打折扣了(注意：好的報告是驅動專案成功的關鍵因素)。
經過大量專案的豐富實踐，針對轉運維階段的專案週報，我梳理出一套「報告四原則」：原則一.驅動專案成員的成長，使其由「需求驅動」思維轉換為「價值驅動」思維。it人員在做專案的時候，很容易掉入「只問需求，不問價值，若有問題，幹就完事」的陷阱中，這是目前國內絕大部分專案實施成員的通病。
這種專案心態表面來看對提公升專案交付效率很有幫助，但深層次思考下，其實是百害無一利。1. 需求是做不完的。如果需求本身找不到落腳點，那就是無根之萍，一是散亂不堪，二是無窮無盡造成專案範圍蔓延。
在專案啟動之初的需求落腳點是公司戰略規劃，而在專案實施過程中需將落腳點再次分解，並用一根主線串起來，串起來的這根主線，我們叫它「價值鏈」。
因此本質上來講，凡是不在價值鏈上的需求均可以不做或者擱置，否則做了也難得到專案sponsor的認可。
到時候很可能一頓操作猛如虎，一看價值在低谷。2. 要做有價值的事。我們要積極引導他們將所做的工作價值最大化，忙忙碌碌一場空是我們必須要擯棄的狀態。
我們得讓他們知道為什麼要做，做了有什麼用，用處在**。這樣才能讓他們看透需求的本質，並從中找到成就感。
如果每個需求的價值本質他們都能把握到，他們對這個行業的理解就會到乙個全新的高度，對他們的成長幫助是不可衡量的。
原則二. 保持專案的透明度，站在使用者的立場告訴他們我們做了什麼，計畫做什麼。專案能否保持始終透明，是專案成功的核心因素之一。專案sponsor出了錢並組織了乙個龐大的業務群體支援我們的專案工作，於情於理我們都需要對他們有所交代。
交代的原則應該是「事事有迴響」，需要定期告訴他們我們做了什麼，計畫做什麼。以此提公升大家對專案實施工作的信心，也能側面提公升專案團隊成員的執行力。原則三. 提公升業務領導的參與度，以便後面能獲取更多的業務支援。it人員一般比較低調、內斂，因此在專案管理過程中很多it專案容易陷入一種狀態：和關鍵使用者打的火熱，卻把業務領導冷落在了一邊(因為他們認為關鍵使用者會和他們的業務領導匯報)，進而導致業務領導對專案情況了解很少，一旦pm想獲取更多業務支援的時候非常容易陷入業務領導不支援的困境。故大膽起來吧，如果你可能需要誰的支援，就要提前鋪路。在平時的報告中「指名道姓」，以既有現象去驅動他們的關注。關注的多了，他們對專案的理解就會越來越深，才能更精準地了解自己在專案中應承擔的職責。
這樣後面你爭取資源的時候，才容易水到渠成。
原則四. 賦能業務團隊，平滑完成能力/角色從專案組到業務職能團隊的切換。
專案在試執行期間，為了快速上線，專案組往往會大包大攬。這樣導致專案在進入運維階段後，業務使用者既沒能力也沒意願去接手運維工作。
這樣就導致，運維的工作一直掛在專案組身上，從而造成很多困擾。因此得想辦法謀求運維角色的轉變，這樣就需要在報告裡做一定的策略。報告中可以積累一些平時容易遇到且通過培訓業務部門能自我解決的問題，做成運維tips。
光明正大地給業務部門賦能，為後面定崗定責鋪路。
基於以上4項原則，模板如下，以饗讀者。
轉入運維階段的專案週報該怎麼做？
為了保持專案的透明度，pm一般都會定期傳送專案週報，而且一般是乙份週報模板貫穿專案始終。其實專案在不同階段，專案管理的側重點也會相應發生變化，此時專案報告模板也應做相應調整。今天我們聊聊專案在準備進入轉運維階段時的專案週報該如何呈現？不一樣的專案週報 專案報告真的僅僅是為了告訴干係人我們做了什麼嗎？...
運維專案總結
目錄中小型公司高併發 集群搭建 2018.04 2018.04 所需技術 keepalived nginx apache mysql nfs rsync sersync inotify 專案職責 此專案為個人專案。本人全程負責專案的實施。專案 此專案是我的第乙個運維專案，基本是模擬網上的架構圖來的 ...
運維囧事 運維的苦樂之旅
人生就是一段充滿苦與樂的旅程，在人生當中有痛苦也有歡樂，痛苦不一定是負面的，有的時候還會使你進步，增強應變能力。對一般人而言，人生一定要是快樂的才是有意義的，可是你仔細想想，有誰不是因為挫折而更加的堅強呢？走過運維的風風雨雨，與大家一起回憶其中的苦樂甘甜，那何嘗不是一段段激情燃燒的歲月呢，記載著你我...