PM與工程師

來源:互聯網
上載者:User

原文連結:http://firecacada.blog.163.com/blog/static/70743762011117114451722/

 

過節前看到一篇文章,講產品項目就應該由工程師來主導,但國內讓PM去驅動項目,搞得亂七八糟,很惱火,怎麼可能做出一款好產品來呢?

很顯然,寫這篇文章的是一位憤怒的工程師,Angry Engineer!我跟他至少有兩點共鳴:

1、國內的PM確實常常折騰工程師,甚至不乏“把工程師當工具對待”的情況。
2、如果工程師有開闊的產品視野與全面的設計素養,知行合一,由工程師來驅動項目是一個完美的選擇。

可惜由於教育環境的問題,國內通才太少。一個優秀的工程師,同時又是一個優秀的PM,鳳毛麟角,只能人任其長,各自做自己拿手的活兒。這時候更擅長需求分析與產品設計的PM來驅動項目,也是不得已的選擇。

說來慚愧。需求不靠譜,或是來來回回修改,折騰工程師的事兒我也做過不少,直到最近一年多才算是大有好轉。我應該懺悔……雖然能做好PM的工程師極少,靠譜的PM其實也不算多,最後大家都得寫周報對不對?

在產品行業遠遠不夠成熟的現階段,痛苦的來回折騰難以避免。但最起碼,PM應該把工程師作為夥伴而不是工具,想法設法地站到一條戰壕裡去,爭取他們的理解。因此拋開難以評鑑的需求的對錯,僅僅從協作流程的改進上,我積累了以下的經驗。

首先要得到工程師對整個項目的認同。每個月都有一場一小時的部門月會,對著PPT,我來講下個月乃至下個階段,我們的任務規劃是什麼,目標設定又是什麼,詳細解釋制定規劃與目標的原因,近景與遠景分析,為咩做這件事情為咩這樣去設計等等。希望工程師能認可他即將做的事情是有價值的,值得為之而努力的。為接下來PM與工程師的溝通做好鋪墊。

月會上還有一個環節,詳細分析本月發生的所有資料,尤其是最近發布的新功能的資料。這個環節也是為工程師準備的,使他們瞭解自己的工作能產生多少實際效果。

至於月會上送出的新功能禮品(以前講過許多次),最開始是為工程師專設的彩蛋,再後來才將PM與運營包括了進來。我得承認自己對工程師偏心眼,因為有信心能激勵PM與運營,卻出於溝通深度不足,需要藉助更多的手段來激勵工程師投入項目。

專案工作分兩種,大版本與小模組。對於大版本,在基本架構定下來之後,PM提前向工程師講解,聽取技術視角對設計方向的建議。整個設計過程中還會反覆討論三五次,為技術上的合理性徵求意見。小模組則在策劃案基本敲定之後,與工程師共同確認一次,視覺稿出來後再通報一次。(所以PM與工程師坐得近是很有必要的)

我曾經在部門月會上公開承諾說,任何一個需求,只要工程師認為是不合理的,都可以停下來不做。直到PM能說服工程師為止。如果死活談不下來,才由我和技術經理出面來協調。強硬要求服從的情況在我這裡基本上沒有,被工程師說服倒是時有發生,按工程師提出的意見來改方案。我也常常跟PM講,小分歧你們都聽工程師的,沒有必要堅持己見。你讓他爽一點,開發速度就快一點,大家都獲益。再說你多聽聽技術夥伴的意見有什麼不好呢?協助你轉換思考的角度,共同找到提高開發效率的方法。

最後方案定下來了,PM說OK,工程師也覺得方向大致沒錯,細節基本合理;進度方面則由工程師進行評估。PM覺得時間太長接受不了,再找到我和技術經理一起商量,看是分階段砍需求呢,還是加把力加點班。除了極少數緊急修複任務外,不會由PM單方面確定開發時間安排。包括一系列任務的優先順序安排,也由PM先提草案,工程師根據開發情況來調整順序,再共同確認。

在PM提出需求的整個流程裡,始終在進行不斷的協商,保證工程師對任務是理解並且接受的,不會出現抗拒,或者是麻木的心態。如果遇到突發性的需求變更,更加會向工程師反覆解釋,請求諒解,因為浪費了他們的工作成果而心存歉意。為此而花費的時間對比更高的開發效率,穩賺不賠。雖說具體協作時還有一些不到位的地方,但態度總歸是好的,基本的效果也是有的。

當然,這套流程的實施得具備兩個前提。第一是有穩定的團隊,如果變成提單協作,這個月一起幹下個月分道揚鑣,那就不可能實現共同的項目歸屬感。第二是工程師的個人素質基本靠譜,溝通順暢;尤其是技術經理可以服眾,協調好分歧而不護短。比如說一個功能能不能做,至少開發多久,我和PM都搞不掂,主要靠技術經理來做最終判斷;如果出現開發過程中的失誤,或是不按照約定好的方案進行開發,則由技術經理進行處罰。我對開發組更多作行政管理,全靠這位技術核心夥伴來負責業務管理,他也會更深入地參與到產品的結構設計,任務規劃裡來。

這樣做,也就撇開了把工程師當工具對待的嫌疑。我覺得把任何同事當工具都挺可恥。怎樣才算是夥伴呢?比如交流必要的資訊,理解對方;比如能站在對方立場去換位思考;比如多一點點鼓勵與協助。

換個角度看,我這邊曾經出現過由工程師來提出大致構思,PM認可並負責細節設計,再由這位工程師來實現的情況。結果皆大歡喜。我後來多次在月會或別的場合徵求工程師的創意,換一換視角,引入新鮮的想法與靈感。即便想法不一致,也會非常溫和地解釋反對原因,絕不可能一口否決。唯恐工程師們默不出聲悶頭幹活——聽不到技術夥伴的意見是多大的損失啊。

今上有敕云:“科學發展觀的核心是和諧發展。”

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.