這是一篇工程師對(duì)產(chǎn)品經(jīng)理的吐槽｜InfoQ

優(yōu)秀的產(chǎn)品負(fù)責(zé)人擁有塑造產(chǎn)品愿景的天賦，但如果負(fù)責(zé)人在產(chǎn)品的初始構(gòu)想階段就沒能與工程師有效溝通，結(jié)果只會(huì)浪費(fèi)時(shí)間、機(jī)會(huì)和人才，這樣下去最后可能會(huì)毀掉一個(gè)項(xiàng)目。

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

但是，構(gòu)建一款成功的產(chǎn)品需要做大量工作。這些工作包括了解用戶需求、集體討論用戶流程、設(shè)計(jì)界面和架構(gòu)，然后是實(shí)現(xiàn)、測(cè)試，最后推出產(chǎn)品功能。

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

這些產(chǎn)品負(fù)責(zé)人會(huì)獨(dú)自提出關(guān)于產(chǎn)品功能形態(tài)和實(shí)現(xiàn)方式的想法。然后，他們將相關(guān)的規(guī)范或故事轉(zhuǎn)交給開發(fā)人員，讓后者去評(píng)估和實(shí)現(xiàn)。

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

在實(shí)踐中，一個(gè)例子就是用戶故事的接受標(biāo)準(zhǔn)被強(qiáng)加了一個(gè)特定的技術(shù)實(shí)現(xiàn)。

想象一下你正在構(gòu)建一個(gè)電子商務(wù)平臺(tái)。產(chǎn)品負(fù)責(zé)人要求你保留產(chǎn)品價(jià)格的歷史記錄。他們還不知道如何將其呈現(xiàn)給用戶。但是他們希望有某種價(jià)目表，其中包括每次價(jià)格更改的日期，以及一個(gè)顯示當(dāng)前值的字段。

當(dāng)你詢問如何在驗(yàn)收會(huì)議上驗(yàn)證此類需求時(shí)，他們會(huì)告訴你質(zhì)量檢查小組將在數(shù)據(jù)庫中檢索產(chǎn)品，并檢查產(chǎn)品是否具有價(jià)目表和當(dāng)前值的屬性。

這個(gè)用戶故事在很多層面上都是錯(cuò)誤的：首先，它不會(huì)為用戶帶來任何有用的價(jià)值，因?yàn)樗呛蠖说母?，不?huì)影響用戶體驗(yàn)。其次，產(chǎn)品負(fù)責(zé)人強(qiáng)行指定了解決這個(gè)問題的方法，但他的方法可能不是最佳解決方案。

其實(shí)用不著為當(dāng)前值和價(jià)目表提供屬性，只需保留一個(gè)包含價(jià)格和日期的數(shù)組即可，例如：

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

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

多數(shù)人認(rèn)為某些工程決策會(huì)導(dǎo)致軟件質(zhì)量下降，而實(shí)際上這是軟件項(xiàng)目管理不力的表現(xiàn)。

以我的經(jīng)驗(yàn)，失敗的軟件項(xiàng)目過程大都類似：產(chǎn)品負(fù)責(zé)人希望構(gòu)建一個(gè)特定的解決方案，卻沒有明確指出他們要解決的是什么問題。

對(duì)于產(chǎn)品的第一次迭代而言，這可能可以理解。但隨著產(chǎn)品逐漸成熟，產(chǎn)品負(fù)責(zé)人應(yīng)該對(duì)產(chǎn)品要解決的問題有更清晰的認(rèn)識(shí)，并與團(tuán)隊(duì)一起尋找合適的解決方案。

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

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

我們將這類開發(fā)人員稱為產(chǎn)品工程師。這些人能夠?qū)⒆陨韽?qiáng)大的技術(shù)背景與對(duì)業(yè)務(wù)的透徹理解結(jié)合起來運(yùn)用，他們?cè)谕晟飘a(chǎn)品的過程中起到了至關(guān)重要的作用。

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

產(chǎn)品工程師提出了不同的解決方案，但他們也能夠快速估算出各種方案的可行性。產(chǎn)品工程師通常會(huì)對(duì)潛在實(shí)現(xiàn)所需的工作量有更準(zhǔn)確的判斷。這樣他們就可以迅速評(píng)估多種解決方案。

也許產(chǎn)品工程師提出的解決方案是產(chǎn)品負(fù)責(zé)人一開始就放棄的，因?yàn)楹笳邠?dān)心這種方案需要的投入太大，也許產(chǎn)品負(fù)責(zé)人甚至都不知道有這么一種可行的方案選項(xiàng)。

在為開發(fā)人員開發(fā)產(chǎn)品的公司中，產(chǎn)品工程師是必備的角色。我之前在 Crate.io 的一個(gè)團(tuán)隊(duì)中任職，我們負(fù)責(zé)的產(chǎn)品是一個(gè)分布式 SQL 數(shù)據(jù)庫。那時(shí)我得以同許多有能力的產(chǎn)品工程師共事。我們的產(chǎn)品負(fù)責(zé)人知道如何在產(chǎn)品構(gòu)想階段就調(diào)動(dòng)起這些產(chǎn)品工程師對(duì)問題解決方案的熱情。

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

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

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

賦予產(chǎn)品工程師權(quán)力，并不只是讓他們自由選擇代碼基礎(chǔ)和架構(gòu)就夠了：

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

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

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

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

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

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

首席增長官CGO薦讀：

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

更多精彩，關(guān)注：增長黑客（GrowthHK.cn）

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