這是一篇工程師對產品經理的吐槽｜InfoQ

優(yōu)秀的產品負責人擁有塑造產品愿景的天賦，但如果負責人在產品的初始構想階段就沒能與工程師有效溝通，結果只會浪費時間、機會和人才，這樣下去最后可能會毀掉一個項目。

所有成功的軟件公司都有一個共同點，那就是他們能夠開發(fā)出讓客戶為之買單的產品。

但是，構建一款成功的產品需要做大量工作。這些工作包括了解用戶需求、集體討論用戶流程、設計界面和架構，然后是實現、測試，最后推出產品功能。

所有這些環(huán)節(jié)都需要許多擁有不同技能的團隊成員參與。但是，即使在鼓勵協(xié)作的敏捷環(huán)境中也普遍存在一個問題，那就是產品負責人會獨自承擔塑造產品愿景的職責，并且常常無法采納其他團隊成員的意見。

這些產品負責人會獨自提出關于產品功能形態(tài)和實現方式的想法。然后，他們將相關的規(guī)范或故事轉交給開發(fā)人員，讓后者去評估和實現。

在這種情況下，客戶需求在到達開發(fā)人員之前已經經歷了一系列反饋循環(huán)。在前期，開發(fā)人員對一開始出現的問題一無所知；他們只知道產品負責人要他們做出來哪些功能。

在實踐中，一個例子就是用戶故事的接受標準被強加了一個特定的技術實現。

想象一下你正在構建一個電子商務平臺。產品負責人要求你保留產品價格的歷史記錄。他們還不知道如何將其呈現給用戶。但是他們希望有某種價目表，其中包括每次價格更改的日期，以及一個顯示當前值的字段。

當你詢問如何在驗收會議上驗證此類需求時，他們會告訴你質量檢查小組將在數據庫中檢索產品，并檢查產品是否具有價目表和當前值的屬性。

這個用戶故事在很多層面上都是錯誤的：首先，它不會為用戶帶來任何有用的價值，因為它是后端的更改，不會影響用戶體驗。其次，產品負責人強行指定了解決這個問題的方法，但他的方法可能不是最佳解決方案。

其實用不著為當前值和價目表提供屬性，只需保留一個包含價格和日期的數組即可，例如：

const?prices?=?[{price:?16,?date:”12-04-2020”},?{price:?15.99,?date:”20-04-2020”}]

在程序中，我們可以從價格更改的日期推斷出最新的價格就是當前價格。上面的例子描述了一種簡單的情況。對于更復雜的用戶故事而言，強行讓開發(fā)人員使用某種解決方案，不僅會減慢開發(fā)團隊的速度，而且還會引入軟件設計錯誤。

多數人認為某些工程決策會導致軟件質量下降，而實際上這是軟件項目管理不力的表現。

以我的經驗，失敗的軟件項目過程大都類似：產品負責人希望構建一個特定的解決方案，卻沒有明確指出他們要解決的是什么問題。

對于產品的第一次迭代而言，這可能可以理解。但隨著產品逐漸成熟，產品負責人應該對產品要解決的問題有更清晰的認識，并與團隊一起尋找合適的解決方案。

否則，功能和需求的反復橫跳會迫使團隊花費大部分時間來重建各種東西，或者他們得被迫使用某種老式的軟件決策系統(tǒng)，最后拖累新功能發(fā)布的速度。

開發(fā)人員對功能請求的反應可能有所不同。有些人可能會接受這些要求，并完全按照需求描述來執(zhí)行這些要求，而不會提出任何問題，還有人會提出問題并了解需求背景。在開始實現功能之前，他們會首先嘗試找出潛在問題。他們會提出另一種選項，來了解產品負責人都考慮了哪些因素，以及為什么負責人決定走這一條路而不是另一條。

我們將這類開發(fā)人員稱為產品工程師。這些人能夠將自身強大的技術背景與對業(yè)務的透徹理解結合起來運用，他們在完善產品的過程中起到了至關重要的作用。

正如 Atlassian 的產品經理 Sherif Mansour 在他關于產品工程師的文章中所述：作為一門年輕的學科，我們花費了大量時間來研究“如何”構建軟件，而這依舊是學校教育的重點所在。但是一旦有了基礎，我們就需要那些積極探索“為什么”這樣做的開發(fā)人員。這類開發(fā)人員是渴望使用技術解決人類 / 用戶問題的工程師。他們富有同理心，渴望探索奇妙的旅程。這就是我在書中定義的產品工程師?！退降漠a品工程師會繞很多遠路，但偉大的工程師知道，團隊在構建 MVP 產品的階段就需要有足夠的思考深度。

產品工程師提出了不同的解決方案，但他們也能夠快速估算出各種方案的可行性。產品工程師通常會對潛在實現所需的工作量有更準確的判斷。這樣他們就可以迅速評估多種解決方案。

也許產品工程師提出的解決方案是產品負責人一開始就放棄的，因為后者擔心這種方案需要的投入太大，也許產品負責人甚至都不知道有這么一種可行的方案選項。

在為開發(fā)人員開發(fā)產品的公司中，產品工程師是必備的角色。我之前在 Crate.io 的一個團隊中任職，我們負責的產品是一個分布式 SQL 數據庫。那時我得以同許多有能力的產品工程師共事。我們的產品負責人知道如何在產品構想階段就調動起這些產品工程師對問題解決方案的熱情。

那些工程師擁有豐富的知識和影響力：每個人都向他們提出各種問題。當然，他們沒有那么高大上的頭銜；他們只被稱為軟件工程師而已。

我要講的重點并不是要為他們的職位換上好聽的頭銜和描述（盡管這可能會有所幫助）。熱情的產品工程師確實存在，而且他們的專業(yè)知識非常寶貴。優(yōu)秀的產品負責人具有塑造產品愿景的天賦，但若負責人無法利用產品工程師的獨特經驗和見解，就是對機會和人才的浪費。

跨職能協(xié)作會帶來最佳結果。產品工程師可以提供有關解決方案可行性、可用性和安全性問題的見解；產品負責人可以提出產品愿景：管道中有哪些功能，為什么？

賦予產品工程師權力，并不只是讓他們自由選擇代碼基礎和架構就夠了：

賦予工程師權力，意味著你可以讓工程師了解你要解決怎樣的問題，了解業(yè)務的戰(zhàn)略背景，這樣他們就能夠利用技術來找出解決問題的最佳方法。判斷你是否已賦予工程師權力的一種簡單方法是，如果你的工程師第一次看到產品創(chuàng)意是在 Sprint 計劃會上，那么你們顯然就只是一支功能團隊，而你的工程師在任何層面上都沒有得到充分的權限。我一直在說，如果你只是讓自己的工程師寫代碼，那么你所獲得的價值就只是他們潛力的一半而已。

這樣可以確保工程師與產品團隊保持一致，并幫助他們了解產品決策背后的意圖。要打造成功的產品，團隊合作是必不可少的：擁有不同技能的人們需要團結起來。應當鼓勵工程師盡早參與討論。如果將他們排斥在外，那么代價就會體現在產品之中。

文：eriam Kharbat 是 Field Intelligence Inc. 的高級軟件工程師

特別提示：關注本專欄，別錯過行業(yè)干貨！

PS：本司承接 小紅書推廣/抖音推廣/百度系推廣/知乎/微博等平臺推廣：關鍵詞排名，筆記種草，數據優(yōu)化等；

咨詢微信：139 1053 2512 (同電話) 

首席增長官CGO薦讀：

• 《小紅書推廣：筆記排名，KOC種草，達人筆記，數據優(yōu)化》
• 《王思聰站臺，兩個月融資兩輪《吐槽大會》爆火后牽扯的商業(yè)邏輯》
• 《抖音推廣：抖音關鍵詞排名，抖音種草，抖音數據監(jiān)測》

更多精彩，關注：增長黑客（GrowthHK.cn）

增長黑客（Growth Hacker）是依靠技術和數據來達成各種營銷目標的新型團隊角色。從單線思維者時常忽略的角度和高度，梳理整合產品發(fā)展的因素，實現低成本甚至零成本帶來的有效增長…