PM與工程師·續

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