原文作者：Jeff Lash
原文鏈接：Take a cautious approach to problem-solving
翻譯：遠(yuǎn)騁
如果你希望成為一個(gè)失敗的產(chǎn)品經(jīng)理，在遇到bug時(shí)，請(qǐng)立即動(dòng)手修復(fù)它。
如果bug可以立即被修復(fù)，為何要一拖再拖？PM應(yīng)該是一位“執(zhí)行者”，而非總是紙上談兵的“思考者”。當(dāng)問(wèn)題出現(xiàn)后，必須在第一時(shí)間搞定它。當(dāng)然，這樣做可能浪費(fèi)大量的時(shí)間，也可能分散精力，不過(guò)這是一位PM的最佳時(shí)間分配方式，不是嗎？
如果你希望成為一個(gè)成功的產(chǎn)品經(jīng)理，在遇到bug時(shí)，請(qǐng)不要總是立即著急的修復(fù)它。
不可否認(rèn)，我們?cè)谟龅絾?wèn)題時(shí)，總是迫不及待的想改正。然而事實(shí)上，其實(shí)根本不用那么的十萬(wàn)火急，理由如下：
-
如果迅速解決了問(wèn)題，你可能會(huì)忽略問(wèn)題的根本原因。
在大多數(shù)時(shí)候，每個(gè)問(wèn)題都有其根本誘因。在問(wèn)題剛暴露的時(shí)候，誘因一般深藏不露，有很多的可能性。
筆者認(rèn)為，根本誘因最可能來(lái)自于需求確認(rèn)階段。多篇文章都探討了這方面的問(wèn)題，比如： Stop Gathering Requirements, Follow up on requests to learn more, Find solutions that address multiple problems.
同樣，在產(chǎn)品管理的其他階段，這個(gè)理論也適用。有些問(wèn)題可以很容易就找到根本誘因，但產(chǎn)品開(kāi)發(fā)的真正挑戰(zhàn)來(lái)自各種不穩(wěn)定的因素。
例如，有時(shí)候一款漏 洞百出的產(chǎn)品在上線之初，只暴露了冰山一角：一個(gè)很小的Bug，似乎十分容易解決。
另一個(gè)例子，開(kāi)發(fā)過(guò)程中，團(tuán)隊(duì)成員對(duì)各項(xiàng)功能的優(yōu)先級(jí)有爭(zhēng)議時(shí)，靠“民主投票”來(lái)做決策，而忘了引發(fā)爭(zhēng)議的源頭：對(duì)產(chǎn)品遠(yuǎn)景、戰(zhàn)略及計(jì)劃缺乏共識(shí)。
醫(yī)生的任務(wù)不是治標(biāo)，而是治本。對(duì)于PM而言，道理一模一樣。
-
讓問(wèn)題暴露一段時(shí)間，或許是讓大家認(rèn)識(shí)到其嚴(yán)重性的唯一方法。
很多父母都會(huì)說(shuō)，他們的小孩吃一塹才長(zhǎng)一智--例如，不去摸滾燙的炭爐--若小孩自己被炭爐燙傷一次后，他們自然會(huì)明白那東西是摸不得的。在產(chǎn)品開(kāi)發(fā)過(guò)程 中，存在著同樣的道理。當(dāng)你試圖請(qǐng)同事修改或改進(jìn)某功能時(shí)，你需要解釋這是為了什么。如果大家不明白改進(jìn)的意義，自然會(huì)無(wú)動(dòng)于衷。
舉 個(gè)例子，假設(shè)你發(fā)現(xiàn)團(tuán)隊(duì)使用的需求管理軟件存在著很大的問(wèn)題，假如你希望馬上修改它，或許得花大量精力去告訴大家修改的意義，還得制作demo進(jìn)行說(shuō)明。 但如果讓這個(gè)需求管理軟件繼續(xù)運(yùn)轉(zhuǎn)一段時(shí)間，讓它自己暴露出弱點(diǎn)，可能是一種更好的辦法。因?yàn)樾枨蠊芾碥浖膯?wèn)題，在新產(chǎn)品上線前，你會(huì)發(fā)現(xiàn)有些 最初制定的需求并沒(méi)有實(shí)現(xiàn)。此時(shí)，你可以告知大家這些遺漏的需求，但是不需要為之耽誤了上線時(shí)間。如果你是正確的，要不了多久，大家就會(huì)意識(shí)到，因?yàn)槭褂?了那個(gè)糟糕的需求管理軟件，才導(dǎo)致產(chǎn)品出現(xiàn)一些無(wú)法挽救的Bug。
提醒，本方法需十分小心的使用。作為PM，就算你本意是為了讓同事們更透徹的看清問(wèn)題，也不能忘了你是該產(chǎn)品最終成敗的負(fù)責(zé)人。所以多數(shù)情況下，使用本方法時(shí)，最好選擇小項(xiàng)目來(lái)作為案例。
-
問(wèn)題可能沒(méi)有你想象中那么嚴(yán)重。
每次問(wèn)題出現(xiàn)的時(shí)候--產(chǎn)品暴露了Bug，用戶發(fā)出抱怨，會(huì)議上的爭(zhēng)論--看上去總是迫切得非解決不可。于是，PM不得不暫時(shí)暫停正在進(jìn)行的真正關(guān)鍵工作--戰(zhàn)略、計(jì)劃、用戶調(diào)研--而把精力用在四處“滅火”上。
-
然而，必須立即解決的Bug其實(shí)很少。
同時(shí)，與PM應(yīng)該著重思考的產(chǎn)品方向等問(wèn)題比起來(lái)，這些Bug的重要性實(shí) 在很低。每個(gè)Bug都 有看上去萬(wàn)分關(guān)鍵的時(shí)刻，但過(guò)段時(shí)間后，它們似乎都變得無(wú)關(guān)緊要了。事實(shí)上，真正嚴(yán)重的Bug會(huì)迅速暴露出來(lái)。牢記這一點(diǎn)，會(huì)讓PM把時(shí)間用在刀刃上，而 不是每天都在處理危機(jī)。
-
花更多的時(shí)間可以找到更完美的解決方案。
若 在全面了解Bug之前，就急著去為Bug尋找答案，我們通常會(huì)選擇腦 海中冒出來(lái)的第一個(gè)解決方案。這可能也算是一個(gè)過(guò)得去的方案，不過(guò)若我們花更多時(shí)間來(lái)分析此Bug，找到其根本誘因，甚至來(lái)一場(chǎng)頭腦風(fēng)暴，或許我們能發(fā)現(xiàn) 更完美的解決方案。當(dāng)然了，花更多時(shí)間也不一定就找得到更棒的方案，但至少，花了時(shí)間之后，得到的不會(huì)是更少的備選方案或更差的解決方案。
下 一次遭遇Bug時(shí)，請(qǐng)別十萬(wàn)火急。PM需要有戰(zhàn)略眼光（不是戰(zhàn)術(shù)），請(qǐng)先分析Bug，找到根本誘因，并衡量全局重要性，再對(duì)Bug進(jìn)行 解決。若不是每一次都著急解決每一個(gè)Bug，PM可以花更少的時(shí)間四處“滅火”，從而擁有更多的時(shí)間去思考產(chǎn)品戰(zhàn)略--如何給用戶帶去更多的價(jià)值。