不久前我寫了篇日誌， 講我的一點經驗，PM如何與工程師協作。但是知易行難啊，最近我們的工程師也有點小抱怨，認爲需求變動較多，太折騰了。我聽到以後很警惕，查了一遍，發現 變動的需求大部分還算合理。半年多來一直強調敏捷，敏捷，有什麼想法就快速發佈出來，再根據上線效果進行調整。因此“一步到位”的方案是不可能的，而快速 調整是必須的。
這時工程師就有意見了，覺得後續的修補太多，浪費時間，希望發佈第一個版本的時候能夠謹慎一些，周全一些。但這其實和“敏捷風格”是相悖的。
我想了想，問題並不在於工程師不認可這個敏捷風格，而是不理解爲什麼要做這個，爲什麼要調整那個。我們的PM把設計案寫得清晰完整，這是“提交任務”的環節，可是還漏了另一個環節，即“解釋說服”的部分。
去年看一篇介紹Facebook的文章，講他們的PM權力很小，PM必須用自己的方案吸引住工程師，才能換得他們的投入，而工程師又必須去說動交互與視覺設計師，爲這項開發提供支持。總之，如果不能說服配合你的人，在Facebook寸步難行。
初看這篇文章時，覺得簡直是PM的噩夢，後來細細一想，又大有道理。如果某個方案都不能說服自己的同伴，是否隱患多多呢？換個角度，即便方案最後被證實是錯誤的，當初支持過它的所有人都會共同承擔責任——主要是精神上的自責，而不會互相埋怨造成內耗。
只不過，Facebook這個管理文化還有兩項大前提，輕易照搬不動。
1、只聘請最優秀的工程師，有較高的產品素養
2、每個員工都是自家產品的用戶，感同身受，有不錯的用研基礎
所 以其他公司盲目學習Facebook這一套，必死無疑，但其中的道理是共通的。怎樣讓團隊齊心協力呢？必要條件是對自己的任務有認同感。這個認同感不是靠 升職加薪換來的，也不是靠請吃飯拉關係換來的，而是你必須說服他，做這個事情是有價值的，值得你花時間去弄。大到產品方向，小到交互優化，都不例外。
每 個月的月初，我會開一小時部門例會，滔滔不絕地講近期的版本路線。每次花兩三個小時來準備PPT。在我看來，在座的每一個人都是我的客戶，我希望靠說服力 （而不是權力）來打動他們，接受我的產品計劃。在每週的策劃運營例會上，在我跟策劃組與運營組的單獨溝通中，這種演說不斷持續——雖然有點囉嗦，但可以保 證溝通充分，不存在對任務的牴觸情緒。
PM與工程師的協作，也應該學習我這個態度。PM既不是請求工程師去做這個，更不是安排工程師去做那個，而是通過繪聲繪色的說明，與工程師達成共識，我們下階段就應該做這個做那個。
因 此，我在每週四下午安排了一場30-60分鐘的會議，PM與工程師參加。PM這邊有一份龐大的需求總表，大約涵蓋了2-3個月的開發需求，隨時增補修訂。 然後在會議上根據優先級，對工程師講解與討論接下來的開發計劃，並確定下週的發佈內容（緊急需求除外）。對這種討論之前其實是有要求的，但如果不予以流程 化，制度化，就容易荒廢掉，口號永遠只是一灘糖稀屎。“提單-接單”的傳統協作形式必須被“講解-傾聽-討論”所替代。
上週我在新浪發了 條微博，說產品協作的根本出路是讓工程師加入設計討論，共同確認方案，共同對結果負責。這條微博的回覆很多。不少人提出，工程師哪裏有這麼多時間參與產品 設計？又有人說，所有人都負責，相當於所有人不負責。這些都是誤解。工程師只在幾個關鍵節點（架構提出/方案確認/進度安排）參與進來，佔用時間有限；而 所謂“共同負責”，意思是當初你不出聲反對，事後就得同甘共苦；當初你接受了這份開發計劃，便不會指責PM拍腦袋瞎折騰。對產品負責到底的必然是PM，他 同時還需要說服所有同伴接受自己的方案。
在我這裏，這個做法是可以被執行下去的。又有人留言說，第一，溝通能力足夠強的PM比較少，沒有 能力說服別人；第二，對產品有感覺的工程師比較少，固執的工程師卻很多。他說的也是常見情況。這屬於團隊建設的問題，團隊經驗與內部磨合都支撐不了協作上 的民主，但換個角度來看，這樣的團隊是否也很難做好產品呢？與其獨裁管理，不如多花心思在招聘與培訓上。
另外還有一種情況，在創業階段， 打算做點創新的事情。由於用戶反饋很少，多半憑主觀感覺去摸索，說服力有限，容易發生分歧。而創業最怕的就是內耗，一爭執，一慢下來就完了。這時PM與工 程師的合力很難形成，更不適合搞一言堂——摸索中的試錯成本加重了內部矛盾。腫麼辦？所以牛逼的創業團隊都是技術主導，帶頭大哥兼具工程師與PM的雙重屬 性，自己想清楚了，挽起袖子就寫代碼，雌雄合體知行合一，非此不足以殺出血路。
PM與工程師要相親相愛。
這時工程師就有意見了，覺得後續的修補太多，浪費時間，希望發佈第一個版本的時候能夠謹慎一些，周全一些。但這其實和“敏捷風格”是相悖的。
我想了想，問題並不在於工程師不認可這個敏捷風格，而是不理解爲什麼要做這個，爲什麼要調整那個。我們的PM把設計案寫得清晰完整，這是“提交任務”的環節，可是還漏了另一個環節，即“解釋說服”的部分。
去年看一篇介紹Facebook的文章，講他們的PM權力很小，PM必須用自己的方案吸引住工程師，才能換得他們的投入，而工程師又必須去說動交互與視覺設計師，爲這項開發提供支持。總之，如果不能說服配合你的人，在Facebook寸步難行。
初看這篇文章時，覺得簡直是PM的噩夢，後來細細一想，又大有道理。如果某個方案都不能說服自己的同伴，是否隱患多多呢？換個角度，即便方案最後被證實是錯誤的，當初支持過它的所有人都會共同承擔責任——主要是精神上的自責，而不會互相埋怨造成內耗。
只不過，Facebook這個管理文化還有兩項大前提，輕易照搬不動。
1、只聘請最優秀的工程師，有較高的產品素養
2、每個員工都是自家產品的用戶，感同身受，有不錯的用研基礎
所 以其他公司盲目學習Facebook這一套，必死無疑，但其中的道理是共通的。怎樣讓團隊齊心協力呢？必要條件是對自己的任務有認同感。這個認同感不是靠 升職加薪換來的，也不是靠請吃飯拉關係換來的，而是你必須說服他，做這個事情是有價值的，值得你花時間去弄。大到產品方向，小到交互優化，都不例外。
每 個月的月初，我會開一小時部門例會，滔滔不絕地講近期的版本路線。每次花兩三個小時來準備PPT。在我看來，在座的每一個人都是我的客戶，我希望靠說服力 （而不是權力）來打動他們，接受我的產品計劃。在每週的策劃運營例會上，在我跟策劃組與運營組的單獨溝通中，這種演說不斷持續——雖然有點囉嗦，但可以保 證溝通充分，不存在對任務的牴觸情緒。
PM與工程師的協作，也應該學習我這個態度。PM既不是請求工程師去做這個，更不是安排工程師去做那個，而是通過繪聲繪色的說明，與工程師達成共識，我們下階段就應該做這個做那個。
因 此，我在每週四下午安排了一場30-60分鐘的會議，PM與工程師參加。PM這邊有一份龐大的需求總表，大約涵蓋了2-3個月的開發需求，隨時增補修訂。 然後在會議上根據優先級，對工程師講解與討論接下來的開發計劃，並確定下週的發佈內容（緊急需求除外）。對這種討論之前其實是有要求的，但如果不予以流程 化，制度化，就容易荒廢掉，口號永遠只是一灘糖稀屎。“提單-接單”的傳統協作形式必須被“講解-傾聽-討論”所替代。
上週我在新浪發了 條微博，說產品協作的根本出路是讓工程師加入設計討論，共同確認方案，共同對結果負責。這條微博的回覆很多。不少人提出，工程師哪裏有這麼多時間參與產品 設計？又有人說，所有人都負責，相當於所有人不負責。這些都是誤解。工程師只在幾個關鍵節點（架構提出/方案確認/進度安排）參與進來，佔用時間有限；而 所謂“共同負責”，意思是當初你不出聲反對，事後就得同甘共苦；當初你接受了這份開發計劃，便不會指責PM拍腦袋瞎折騰。對產品負責到底的必然是PM，他 同時還需要說服所有同伴接受自己的方案。
在我這裏，這個做法是可以被執行下去的。又有人留言說，第一，溝通能力足夠強的PM比較少，沒有 能力說服別人；第二，對產品有感覺的工程師比較少，固執的工程師卻很多。他說的也是常見情況。這屬於團隊建設的問題，團隊經驗與內部磨合都支撐不了協作上 的民主，但換個角度來看，這樣的團隊是否也很難做好產品呢？與其獨裁管理，不如多花心思在招聘與培訓上。
另外還有一種情況，在創業階段， 打算做點創新的事情。由於用戶反饋很少，多半憑主觀感覺去摸索，說服力有限，容易發生分歧。而創業最怕的就是內耗，一爭執，一慢下來就完了。這時PM與工 程師的合力很難形成，更不適合搞一言堂——摸索中的試錯成本加重了內部矛盾。腫麼辦？所以牛逼的創業團隊都是技術主導，帶頭大哥兼具工程師與PM的雙重屬 性，自己想清楚了，挽起袖子就寫代碼，雌雄合體知行合一，非此不足以殺出血路。
PM與工程師要相親相愛。