PM成長日記第一話-不要使用郵件解決問題

首先，在學習任何東西前都須要明確學習的目的，咱們爲何要學習電郵溝通技巧呢？由於電郵表明了我的職業形象，好吧，咱們開始。

第一個問題是什麼狀況下咱們應該使用郵件。

在使用郵件前咱們必須清楚郵件只是衆多溝通方式之一，既然是之一，那麼必然就有應用它的合適場景和不合適場景。

郵件溝通場景之一：知會對收件人必要的信息

這類場景包括了會議通知、事件周知、申請批准和信息分享。這類郵件幾乎沒有什麼好說的，重要程度也不會過高。

郵件溝通場景之二：溝通確認結果

正如會議，溝通的功夫永遠在線下，會議和郵件的目的只是確認溝通的結果。事情在發郵件以前必定是被搞定了，不要經過郵件來搞定事情。領導關注的只是結果而不是過程，好的下屬必定要領導省心。這類郵件包括了會議結論、行動計劃、項目總結郵件。重要程度很高。

郵件溝通場景之三：表揚和感謝

對跨部門項目或在項目取得階段成果時必定要多用郵件表示感謝。感謝必定要具體，要有具體事例支撐說明，要抄送收件人領導。

有了應用郵件的合適場景，不合適的場景基本上就對應起來，一句話：不要妄想使用郵件解決問題。任何問題的解決都是在線下，郵件只是確認結果。知道了郵件的使用場景，那麼第二個問題就是如何寫好郵件。

第二個問題是如何寫好郵件呢。

在具體寫以前仍是必須先想明白一件事：咱們爲何要寫這封郵件？咱們的目的是什麼，要達到這個目的郵件內容應該包含哪些信息。想明白這件事，接下來的郵件形式就很是簡單了：

1 郵件收件人必定是具體辦事或須要回覆的人，抄送則爲領導須要知曉郵件內容的人，必定要想明白郵件的發送範圍；

2  郵件標題前使用【】，例如【Anemoi項目】、【請審閱】、【請協助】、【很重要請回復】等；

3  郵件稱呼使用，Dear Michael、Dear all；

4  正文要樸實、明確、簡練，週期性郵件要創建模板，例如會議模板、進度彙報模板，若是使用圖形必定要圖形本身表達出意思不要讓一千我的眼裏有一千個哈姆雷特；

5  必定要有簽名；

6  出差、休假時設定郵件自動告知。

歸根結底，寫好郵件其實就是一句話：必定想清楚寫郵件的目的。

結論：不要妄想使用郵件解決問題，郵件只是確認結果；必定要想清楚寫郵件的目的。

 

PM成長日記第二話-必定要想清楚本身要什麼

標題是必定要想清楚本身要什麼，內容倒是士兵突擊，由於從那麼樣一羣的男人身上，總能扒拉出點本身想要的。

我周圍的朋友大多討厭成才，他們把他從鋼七連的出走和演習中的放棄稱爲「背叛」，他們把他的自我主義稱之爲對許三多的「出賣」，他們說，這我的纔是真正的假到了必定水平的人。

我什麼都沒有說。 

由於說真的，在這羣華麗的男人中間只有成才略顯真實，只有他纔在成長過程當中不斷遇到挫折，哪裏是挫折，那樣完整的一段人生歷程，比之咱們大多數人，那要強上太多了。 

剛到紅四連，沒多久，就被髮配到了草原上的五班，那個讓人絕望的邊緣部門。好容易到了老A，袁朗又將成才作人的根基擊得支離破碎，將成纔信奉了二十年的那些東西打得無影無蹤，他說成才內心沒有七連的「不拋棄不放棄」，但是他本身卻將成才放棄了，他說不敢將全隊人的生命交託在這樣的人手裏。 

雖然理由無可厚非，但成才畢竟萬念俱灰。我有時候想，袁朗難道真的是神？他一眼就看出了成纔是不會被打倒的小強嗎？或者不是，那麼成才的一輩子就今後陷入自卑的陰影再也沒法自拔——誰又曾把對待許三多的執着和寬容原封不動地移到成才身上過？甚至，衆目睽睽下，永遠溫和的班長將酒潑在成才臉上，不留情面。我經常想，若是是我，我會怎麼辦？

PM又未嘗不是這樣，一段時間，我常常陷入到作事仍是作過程的迷茫中。是的，團隊開始迭代了，開發計劃不多延期了，團隊氛圍活躍了、團隊規則確立了，而後呢？團隊方向是產品經理在負責，產品技術是技術leader在負責，PM呢，只是一個作過程的，天天就是制定計劃、追蹤計劃還有那大大小小的會議。PM的價值究竟在什麼地方，PM將來的發展究竟是什麼？每當這個時候，我就會想起五班上的草原，無邊無際，看不清方向。

直到飛躍培訓，聽廖凱講他的故事，講他的堅守，我才明白，唔，之因此迷茫，是由於我根本沒有想清楚本身想要什麼啊！

誰說咱們在作過程？咱們原本就是在作事。團隊計劃老是延期，這是否是問題，是的，是問題，咱們創建起有規律的開發節奏，在開發和產品之間創建起清晰的規則，保證了開發的效率和進度，這算不算是作事呢，是的，是作事；團隊屬於技術支持部門，儘管很是努力但用戶滿意度不高，這是否是問題，是的，是問題，咱們對需求排定優先級將團隊的開發向外可視化得到更多的理解，這算不算是作事呢，是的，是作事；中心有多個開發小組，一個面向用戶的交付每每要跨越多個小組，交付時間長，這是否是問題，是的，是問題，咱們協調各個小組的開發計劃創建項目集的視圖在總體上達成一致，這算不算是作事呢，是的，是作事；部門發展很快，一個產品的開發人員由最初十幾人發展到幾十人，協調愈來愈困難，這是否是問題，是的，是問題，咱們將開發團隊按照特性和產品架構進行拆分，將溝通儘可能限定在一個組內，減小溝通的範圍和成本，每一個小組都能獨立交付特性，這算不算是作事呢，是的，是作事；部門產品線上老是出事，這是否是問題，是的，是問題，咱們創建起發佈流程和自動化的打包發佈機制，產品發佈前必須通過自動化的集成測試，這算不算是作事呢，是的，是作事。

因此，PM是什麼？PM是解決實際問題的人。在一個一個問題的解決過程當中，PM就成長了，由於問題老是相似，對研發部門來講，需求、開發、測試、運維就是這些事，對溝通協調來講，小組、中心、部門、跨部門溝通就是這些事，對產品形態來講，客戶端、前端、後端、搜索、廣告、app就是這些事。當碰到一個棘手的問題時，應該對本身說，嗯，成長的機會又來了，而且，越是讓本身痛苦的問題，過後必定是收穫最大的問題。當有一天，你來到一個新部門，全部的問題都是那麼的相似，本身都曾經解決過或知道解決方法，那麼，恭喜，你就成長了。

我本身想要什麼？我想要的正是解決問題的思路，在一個一個實際解決問題中積累的經驗和思考，當對大多數問題你都能遊刃有餘的時候，這時缺乏的就只是一個機會了。

回到士兵突擊。

這一切，成才都熬過來了，一我的，從最初就有本身堅決的目標，知道本身想要什麼，而且爲着本身不管如何都要作到的事情不斷地捨棄和放開，這纔有可能成功。我討厭成功這個詞，我更願意用成才最後享受到的一句話：「你的路，比許三多還長。」 

想清楚本身要什麼，路，纔會長。

PM成長日記第三話-那些年咱們一塊兒作過的項目

第三話按照原計劃是要寫寫日常心的，由於飛躍計劃要交做業，因此就改成寫本身對項目管理的一些經驗總結，恰好前一段時間那些年咱們一塊兒追過的女孩非常流行，這一話的名字就叫作那些年咱們一塊兒作過的項目。

個人第一個項目是在2005年，那是一家市場佔有率前三的本地化翻譯公司，公司的信息部門只有兩我的：老大和我，咱們一塊兒開發公司內部的協同辦公系統。要解決的問題很簡單：因爲公司發展迅速，之前單純依靠紙質單據和郵件分派和追蹤任務已經愈來愈讓項目經理和財務不堪重負，迫切須要將這些工做給自動化。系統的技術架構也很簡單： jsp+javabean+mysql。沒有專門的開發計劃，基本開發流程是這樣的：每週一咱們訪談一個業務部門經理，瞭解他的需求，週中開發，開發中有任何問題均可以直接找業務經理，週五的時候系統上測試環境，再和業務經理坐到一塊兒看一下是否知足了他的需求。系統就一直這樣不緊不慢的開發着，老闆辦公室就在咱們身後，一有時間老闆就會和咱們一塊兒使用該系統。整個開發過程只有一個細節讓我印象深入，就是對任務估算工做量時，無論我估算多少，老大都會給我乘以3，一次要給業務表單增長一個字段，老大問我須要多長時間，我說不就是增長數據庫字段嗎10分鐘，結果老大給了我半天時間，老大說，增長字段確實只須要幾分鐘，但打開編輯器須要時間吧，集中注意力須要時間吧，改完了啓動系統測試須要時間吧，測試完了和業務經理確認需求須要時間吧，咱們估算的是完成整個事情的時間而不只僅是編碼的時間。

這個項目完成時得到了公司上下的一致好評，從公司老闆到業務經理，每一個人都很是滿意，而讓我感到惟一遺憾的倒是身爲IT人員居然歷來都沒有加過班。

回想起來，這個項目之因此成功當然是由於技術簡單和系統不復雜（咱們甚至都不須要 SVN，徹底依靠腳本同步代碼），但最重要的仍是持續交付和持續的用戶反饋，老闆和業務經理每週都能看到新功能的上線，這加強了他們的信心，同時反饋幾乎天天都在進行，而且他們很快都能看到這是不是他們想要的。

第二個項目在2006年，這一年我換工做了，由於當時我認爲不加班的程序員不是好程序員。新公司在上地，是一家作協同辦公業務平臺的公司，最開始去的是項目部，一開始很爲業務平臺這個概念着迷，由於當寫程序時最早不是寫代碼而是用代碼生成器生成代碼，而且生成完的代碼立刻能夠運行！第一個項目是豐田公司的銷售管理系統，咱們創新的使用了當時最熱的Ajax技術，咱們徹底是用技術熱情加上週末時間完成對原有功能的 Ajax加強，這個項目得到了用戶極高的評價，由於當大多數web系統還在使用點擊 /刷新的方式進行交互時，咱們卻能夠直接拖拽完成操做了。若是在當時，我會認爲是技術的創新讓項目得到了成功，可是如今，我會用漸進式加強這個詞，即只有在完成用戶所須要的核心功能（什麼叫核心功能，即缺乏這個功能系統不能工做）後纔開始對系統用戶體驗、性能進行漸進式優化。

第三個項目是在公司的平臺部，這裏部門經理正準備對原有的業務平臺進行重寫，原先業務平臺的技術框架是：jsp+struts+ojb+sqlserver，新的技術框架定義爲： ajax+freemarker+webwork+spring+hibernate。這讓我興奮，由於新的技術框架幾乎是當時最流行的技術。加部門經理共有三個開發人員（因此溝通一直不是問題），老大使用project來管理項目，每一個人負責一個模塊，估算以周爲單位，最初計劃是 5個月交付，功能直接就是老平臺的翻版換的只是技術實現，可是 5個月後進行測試和項目試用時卻發現了大量缺陷，最後幾乎用了半年時間纔將缺陷收斂，產品發佈計劃延期半年。回顧這個項目，需求沒有進行詳細的分解和評審致使實現與需求不一致 彷佛是項目延期最重要的問題，然而更深的思考倒是咱們需不需由於技術緣由開始新產品的開發，在不影響用戶使用的狀況下對原業務平臺進行漸進式加強是否更加合適。即咱們在啓動項目時更多關注的應該是用戶價值（只有有用戶價值用戶纔會買單公司纔有收益）。

第四個項目是我負責的，這個項目幾乎是上一個項目的翻版，重寫公司的工做流產品：支持更多的工做流模式，更易集成的api和管理界面，惟一不一樣的是這個項目採用了不少敏捷裏的實踐：持續集成、單元測試、站會、迭代，但這些實踐均不影響這個項目最終的失敗。一樣是該不應重寫這個項目的問題，在公司資金鍊緊張、時間要求緊、新產品相比競品沒有突出特性的狀況下，這個項目從一開始就決定了失敗。若是沒有特別充足的理由就不要重寫產品，這幾乎成爲我目前最重要的一條原則，尤爲要從公司全局的角度看待產品不能侷限在技術。如今，只要誰一說到要重寫產品，而給出的僅僅是技術緣由，我就會兩股加緊，冷汗直流。在對項目徹底負責的狀況下，我另外一點深入感覺就是人的重要性，對團隊中的每一個人員，做爲leader 你都須要知道他的需求是什麼，沒有人願意作機器人，在一次對某一技術方案簡單粗暴拍板後，一個核心技術人員流失了，這成了壓垮這個項目的最後一根稻草。

08年末去了一家新公司，新公司採用敏捷實踐。第一個項目很成功，幾乎是敏捷項目的一個成功範例，需求分析、迭代、持續集成、結對、客戶 showcase、持續交付，項目甚至提早半個月完成。惟一美中不足的是項目二期時新團隊因爲一期文檔不多帶來了不少困擾。突出的感覺是：團隊人員有了角色、有了分工也就有了流程。如今，到了一個新的部門或中心，第一件事情每每就是梳理項目開發流程，定義出每一個人的角色，職責不清是互相埋怨之源。

第二個項目是諮詢項目，略去不表。第三個項目是分佈式團隊，一部分團隊在國外，一部分團隊在國內，最開始一切順利，但在上線前一個月遇到了嚴重的性能問題，陷入了一片混亂當中，全部人都不知道咱們離上線還有多遠，還有哪些工做須要完成，優先級都是什麼，項目經理甚至本身都失去對整個項目的把控，她不知道項目上線究竟須要知足什麼條件，因而一次次在等待國外團隊優化後的測試結果，因而一次次的測試結果不滿意，因而項目在一次次的下週二上線的空頭承諾中成了整個公司的笑柄。這個項目回顧起來就是團隊遇到挫折時放棄了計劃，迭代沒有了，故事牆沒有了，全部人都在等待，而項目經理爲了避免讓開發人員被公司收回還不得不想一些優先級不高的任務給團隊完成裝着咱們很忙。教訓就是，任何狀況下都不能放棄計劃，計劃是項目之本。其餘包括團隊能不分佈式就不要分佈式，若是必須分佈式那麼必定要從架構開發任務上進行隔離，儘可能減小兩個團隊之間的交互（不少項目經理進入到部門以後推動項目制，其實也是一樣的原則，團隊大了就要拆解，產品代碼多了也要模塊化，儘可能減小團隊之間、模塊之間的交互，作到可以各自獨立演進和發佈）。儘早進行實際環境的測試，越早越好。測試越早進行越好，測試環境越貼近產品環境越好，這一原則何時強調都不過度（咱們上線前的測試才發現嚴重的性能問題）。

第三個項目是幸運的，由於他們有錢，可以等待，在多等待了大半年後系統終於上線。而第四個項目就沒有這麼走運了，這個項目是一個在線 saas CRM系統的重寫，並且有着強時間約束（若是半年不能交付，將錯過該系統客戶每一年作預算的窗口期），看吧，又是重寫，又是時間約束，這幾乎總預示着它厄運難逃。表面上看項目是在一次中期的架構重寫中崩潰了，重寫耗去了團隊太多的時間，而因爲對未知領域知識的不正確估算（須要學習）再次令項目雪上加霜，項目目標又不能變化，要在六個月後上線，但更深層的緣由仍是項目開始以前沒有決策正確，真的要重寫產品嗎？老產品確實界面很醜、一些功能沒有，但這些不能漸進式加強進行嗎，必定要從新開始嗎？重寫使用新團隊，他們對該業務領域並無經驗，過去系統遇到的坑他們不清楚，他們的計劃由於少考慮了一些狀況是否顯得過於樂觀？這個項目的其餘問題包括項目計劃一直沒有發生變化，儘管全部人都認爲在規定日期到來以前不可能交付，但這個日期卻沒有發生變化。最後不得不說這是一個技術強大的團隊，一切都作到了自動化，甚至部署產品環境也是一鍵完成，可是這些在項目目標失敗的狀況下顯得黯然失色。而客戶貸款作這個項目則讓不少團隊成員良心不安。

來到騰訊，來到soso，最重要的收穫是對運維有了新的認識，之前曾經認爲devops就是自動化部署，全功能團隊，如今發現它關乎架構：一條搜索的badcase是否可以很快找出錯誤的緣由？是抓取失敗，是索引時丟失，仍是相關性排序很差？關乎監控和報警，咱們可否很快從監控中定位出緣由？關乎組織結構，前臺開發，後臺架構，基礎架構，運維測試團隊都是分離的，如何協做才能使團隊合做的成本最低而總體利益最大化？

回顧往事，保爾柯察金說：如何才能不虛度光陰，只有爲共產主義奮鬥終身；柯景騰說：惟有沈佳宜讓我懷念；而我想說的是：

• 作任何項目以前必定要想清楚爲何要作這個項目，必定要想清楚這個項目的價值是對用戶和公司的（尤爲須要跳出站到一個比較高的層次看項目），必定要想清楚項目的約束（時間約束、人員約束）,不只是項目開始以前要想，過程當中要不斷回顧；；
• 項目任什麼時候候都必須有計劃，對全部干係人透明；
• 項目必定是持續交付和持續反饋的，不容許黑盒出現；
• 測試和運維必定要儘早介入；
• 從每一個團隊成員的角度出發關注全部人的利益實現雙贏