為了保持專案的透明度，pm一般都會定期傳送專案週報，而且一般是乙份週報模板貫穿專案始終。
其實專案在不同階段，專案管理的側重點也會相應發生變化，此時專案報告模板也應做相應調整。
今天我們聊聊專案在準備進入轉運維階段時的專案週報該如何呈現？
不一樣的專案週報
專案報告真的僅僅是為了告訴干係人我們做了什麼嗎？這樣的話，報告能發揮的力量就明顯大打折扣了（注意：好的報告是驅動專案成功的關鍵因素）。
經過大量專案的豐富實踐，針對轉運維階段的專案週報，我梳理出一套「報告四原則」：
原則一.驅動專案成員的成長，使其由「需求驅動」思維轉換為「價值驅動」思維。
it人員在做專案的時候，很容易掉入「只問需求，不問價值，若有問題，幹就完事」的陷阱中，這是目前國內絕大部分專案實施成員的通病。
這種專案心態表面來看對提公升專案交付效率很有幫助，但深層次思考下，其實是百害無一利。
1. 需求是做不完的。
如果需求本身找不到落腳點，那就是無根之萍，一是散亂不堪，二是無窮無盡造成專案範圍蔓延。
在專案啟動之初的需求落腳點是公司戰略規劃，而在專案實施過程中需將落腳點再次分解，並用一根主線串起來，串起來的這根主線，我們叫它「價值鏈」。
因此本質上來講，凡是不在價值鏈上的需求均可以不做或者擱置，否則做了也難得到專案sponsor的認可。
到時候很可能一頓操作猛如虎，一看價值在低谷。
2. 要做有價值的事。
我們要積極引導他們將所做的工作價值最大化，忙忙碌碌一場空是我們必須要擯棄的狀態。
我們得讓他們知道為什麼要做，做了有什麼用，用處在**。這樣才能讓他們看透需求的本質，並從中找到成就感。
如果每個需求的價值本質他們都能把握到，他們對這個行業的理解就會到乙個全新的高度，對他們的成長幫助是不可衡量的。
原則二. 保持專案的透明度，站在使用者的立場告訴他們我們做了什麼，計畫做什麼。
專案能否保持始終透明，是專案成功的核心因素之一。專案sponsor出了錢並組織了乙個龐大的業務群體支援我們的專案工作，於情於理我們都需要對他們有所交代。
交代的原則應該是「事事有迴響」，需要定期告訴他們我們做了什麼，計畫做什麼。以此提公升大家對專案實施工作的信心，也能側面提公升專案團隊成員的執行力。
原則三. 提公升業務領導的參與度，以便後面能獲取更多的業務支援。
it人員一般比較低調、內斂，因此在專案管理過程中很多it專案容易陷入一種狀態：和關鍵使用者打的火熱，卻把業務領導冷落在了一邊（因為他們認為關鍵使用者會和他們的業務領導匯報），進而導致業務領導對專案情況了解很少，一旦pm想獲取更多業務支援的時候非常容易陷入業務領導不支援的困境。
故大膽起來吧，如果你可能需要誰的支援，就要提前鋪路。
在平時的報告中「指名道姓」，以既有現象去驅動他們的關注。關注的多了，他們對專案的理解就會越來越深，才能更精準地了解自己在專案中應承擔的職責。
這樣後面你爭取資源的時候，才容易水到渠成。
原則四. 賦能業務團隊，平滑完成能力/角色從專案組到業務職能團隊的切換。
專案在試執行期間，為了快速上線，專案組往往會大包大攬。這樣導致專案在進入運維階段後，業務使用者既沒能力也沒意願去接手運維工作。
這樣就導致，運維的工作一直掛在專案組身上，從而造成很多困擾。
因此得想辦法謀求運維角色的轉變，這樣就需要在報告裡做一定的策略。
報告中可以積累一些平時容易遇到且通過培訓業務部門能自我解決的問題，做成運維tips。
光明正大地給業務部門賦能，為後面定崗定責鋪路。
基於以上4項原則，模板如下，以饗讀者。
運維報告模板 轉入運維階段的專案週報該怎麼做？
為了保持專案的透明度，pm一般都會定期傳送專案週報，而且一般是乙份週報模板貫穿專案始終。其實專案在不同階段，專案管理的側重點也會相應發生變化，此時專案報告模板也應做相應調整。今天我們聊聊專案在準備進入轉運維階段時的專案週報該如何呈現？不一樣的專案週報專案報告真的僅僅是為了告 訴干係人我們做了什麼嗎？...
Mysql的密碼忘記了該怎麼做？
1.關閉正在執行的mysql服務 必須關閉，不然會出錯的 2.開啟dos視窗，轉到mysql bin目錄 3.輸入mysqld skip grant tables 回車 skip grant tables 的意思是啟動mysql服務的時候跳過許可權表認證 4.再開乙個dos視窗 因為剛才那個dos視...
效能測試的專案應該怎麼做
很多小夥伴兒會問，效能測試是不是會乙個工具就算會效能測試了呢？效能測試不是這樣的，首先要明確的是，不是說你會了工具就會了效能測試。效能測試是乙個行業，而工具只是它的乙個組成部分。效能測試需要了解的東西很多 業界俗稱 打雜的 就是說會對各種的知識點都有涉獵，linux 語言 工具以及一些框架的東西。1...