再牛逼的產(chǎn)品經(jīng)理也無法一個人完成一款產(chǎn)品

24 評論 4426 瀏覽 78 收藏 10 分鐘

如果我是一個技術(shù)大牛,極具產(chǎn)品sense,還湊巧精通Origami、AI、PS,我完全可以一個人做款A(yù)PP,并持續(xù)迭代!我做過技術(shù),是建筑行業(yè)的技術(shù);我會畫圖,都是用CAD和SkechUp;我很認真的做產(chǎn)品,但剛滿一年而已。答案顯而易見,我一個人是無法做產(chǎn)品的!

老大,我缺開發(fā)。

找外包。

老大,我缺測試。

自己頂上。

老大,我缺視覺。

協(xié)調(diào)資源。

老大,我缺項管。

一陣可怕的安靜之后,老大笑著對我說“產(chǎn)品經(jīng)理是什么?產(chǎn)品經(jīng)理就是發(fā)現(xiàn)問題,解決問題。優(yōu)秀的產(chǎn)品經(jīng)理必須在缺少測試、設(shè)計、項管情況下自己承擔起來?!?/p>

我眨了眨眼,對老大說“那我是不是還要學編程?”然后在老大還沒來得及發(fā)火之前逃離了辦公室。

一個字形容我的項目——真的很缺人。說是一個人做有些夸張,但是在技術(shù)外包,交互、視覺、測試、項管全都兼職的情況下,我真的有些無力,項目也曾經(jīng)歷了上線延期,崩潰率過高,用戶差評無數(shù)的情況,好在這些都成為過去?,F(xiàn)在跟大家分享一下外包項目的注意事項,希望對同行們有所幫助。

一、需求層面

需求不明確,這是產(chǎn)品經(jīng)理的大忌,在這種情況下即便外包把下載做成上傳你都沒什么好說的,誰叫你需求不明確呢。

產(chǎn)品需求文檔是指導開發(fā)、測試的基本文檔,越明確越好。這里說的明確而不是詳細,因為無論是開發(fā)、交互,還是測試,都不愿意看大片的文字,在外包項目的第一個迭代中,我的PRD寫了23頁,封面、目錄、修訂記錄、產(chǎn)品介紹、功能性需求、非功能性需求外,還加上了其他和特別說明,一個需求評審走下來要一兩個小時,當我講完后看到開發(fā)經(jīng)理滿臉茫然的表情,我知道這是一次失敗的評審會。

為了讓開發(fā)更好的理解產(chǎn)品需求,為了讓交互更好進行設(shè)計,為了讓測試的test case更加完整,我司逐漸推廣“story+線框圖+標注”模式的PRD,story務(wù)必條理清晰,線框圖和標注務(wù)必簡單明了,幾個迭代走下來,明顯感覺到外包對需求的理解準確了不少。

二、進度層面

沒有deadline是萬萬不行的,項目可能無限制延期。而我的第一個版本就吃了這樣的虧,由于我司一個模塊在開發(fā)中,release版本事件待定,就將產(chǎn)品交付事件擬定在8月中,可是最后延期了兩周,期間還有各種撕逼,好不難受。

可是僅有deadline也是不夠的,畢竟功能的開發(fā)存在不確定性,聯(lián)調(diào)時間、測試時間、debug時間無法保障,如果僅有deadline,很容易將全部風險往后堆積,最后的結(jié)果只能是項目延期,產(chǎn)品經(jīng)理被批!

你需要設(shè)置項目節(jié)點,階段性交付、階段性提測,把風險分散并提前。當前在進行的迭代我們設(shè)置了四個節(jié)點,兩個模塊化提測節(jié)點,兩個全功能提測節(jié)點,一個上線節(jié)點;雖然目前只進行到首次全功能提測,但是按照節(jié)點走的感覺真的不賴。

三、質(zhì)量層面

外包項目開發(fā)中最怕的不是進度,而是質(zhì)量。因為他們可能會早早的打包給你,可是你能測出100個bug。

要想在把控這一塊,必須加強開發(fā)自測和代碼review。在上一個版本出現(xiàn)過“冒煙測試不通過”的情況,你知道那種外包如期把包給你,你開心的測試,可是居然無法下手的痛苦和無奈嗎?那一刻簡直想把剛買的iPhone 6砸在他們臉上,這也提測,讓我怎么測!

要保證質(zhì)量,首先是開發(fā)的自測。當然如果你是技術(shù)大牛,對自己寫的代碼極其有自信,不自測也罷??墒谴蠖鄶?shù)外包人員水平其實并沒有那么高,那么自測是必要的,自測階段可以發(fā)現(xiàn)不少問題,至少避免出現(xiàn)功能未實現(xiàn)便提測的情況。

其次是內(nèi)部技術(shù)人員的代碼review,我們的iOS開發(fā)主管跟我說“代碼review必須階段性進行,放在功能性測試之前,我們通過代碼就能review能找到很多問題,減輕測試工作量”,直到那一刻我才知道原來這么重要,代碼review不僅僅是看代碼是否合乎規(guī)范,更重要是看代碼的分層、封裝、碎片化是否足夠,是否有隱藏的bug,是否需要重構(gòu)等。

我對自己產(chǎn)品的期望是在功能性提測之前完成代碼review給到的建議,將功能性bug壓縮至10個以內(nèi)。

四、規(guī)范層面

前面提到了進度,提到了質(zhì)量,但是這些都需要相應(yīng)的規(guī)范來保障,不然還是水中月夢里花。下面是我在項目迭代中整理了部分規(guī)范,雖然不是很完善,但項目相對于之前確順了很多。

內(nèi)部方面:

1、規(guī)范測試準入標準

(1)階段性功能提測:確保基本業(yè)務(wù)流程走通才能提測;

(2)bugfix:

  • a、開發(fā)根據(jù)jira中的優(yōu)先級修改bug。
  • b、開發(fā)打包提測前必須充分自測,驗證所有bug,確保老bug改完、無衍生出的新bug。如測試人員驗證下來bugfix失敗率>=30%可直接打回。
  • c、開發(fā)打包節(jié)奏,常規(guī):一天打包一次,如一天內(nèi)所有bug都改完,改完就打包體測;如有特殊情況,由測試決定開發(fā)的打包節(jié)奏。

2、外包合同中規(guī)定測試輪數(shù)

根據(jù)1的打回機制,從測試輪數(shù)(5輪)和時間(規(guī)定的項目總時間)上制約外包。

3、規(guī)范代碼review機制

階段性的review外包代碼,如果老代碼不符合要求,預(yù)估時間和優(yōu)先級,根據(jù)緊急程度在開發(fā)中或后期維護期里修改掉。

4、規(guī)范產(chǎn)品需求

在PRD的story下面添加功能邏輯關(guān)系圖,以便其他人員更好理解需求

外包方面:

1、加強自測(配合我司的測試準入標準)

根據(jù)測試用例,加強自測減少打回和項目延期的風險。

2、規(guī)范外包響應(yīng)機制

  1. 迭代開始,外包側(cè)需要讓兩端的實際開發(fā)人員到場;
  2. 代碼審核、緊急bug修復(fù)等關(guān)鍵時間節(jié)點,需要開發(fā)人員到場。(預(yù)計:2-3天)

3.加強溝通

避免出現(xiàn)安卓、iOS兩端對需求理解不一致的情況

五、溝通真的很重要

無論是PRD,還是項目節(jié)點;無論是代碼review,還是功能測試;都只是保障項目順利開展,如期上線的手段。最重要的還是項目人員的相互協(xié)作,溝通在這里至關(guān)重要。

我的項目曾出現(xiàn)過同一個需求和交互視覺,安卓和iOS做出了完全不同的功能。當時有好幾個疑問飄在腦海里:

  1. 需求是否不夠明確,以致開發(fā)同學理解有偏差;
  2. 需求評審會是不是不夠細致,遺漏了這塊;
  3. 開發(fā)同學是不是過于內(nèi)向,有疑問時不敢找我溝通;
  4. 開發(fā)同學之間是不是也缺少交流,兩端各做各的。

幾個疑問都直指一個方向——缺少溝通,開發(fā)之間缺少溝通,開發(fā)和產(chǎn)品之間缺少溝通,開發(fā)和交互之間缺少溝通!

如果對需求有疑問,過程中應(yīng)該及時提出,需求評審時應(yīng)提出,兩端同學交流時更應(yīng)該提出,可是他們都沒有來找我,而我也理所應(yīng)該的以為他們理解了,會嚴格按照需求和交互實現(xiàn)。如果我在過程中主動對容易產(chǎn)生疑問的點進行溝通確認,也能避免這個問題??墒俏覀兌紱]有!

上面僅是缺乏溝通導致的一個案例,類似的問題還有太多太多。各位同仁,關(guān)于產(chǎn)品經(jīng)理最核心競爭力有太多討論,我這里也不妄下結(jié)論,但是溝通一定是非常重要的!

愿大家都成為一個能溝通,會溝通,善溝通的產(chǎn)品經(jīng)理!

 

本文由 @edgar1990 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?,未經(jīng)許可,禁止轉(zhuǎn)載。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 測試用例,不用回復(fù)

    來自河北 回復(fù)
  2. 寫的很好。作者我已經(jīng)成為你鐵粉了。

    來自廣東 回復(fù)
  3. 我覺得是分階段的,最原始階段 一個人來做 反而容易出精品 比如 linux。 但是一直一個人 比較難發(fā)展下去

    來自北京 回復(fù)
  4. 好熟悉的感覺

    來自廣東 回復(fù)
    1. 你也做外包項目?

      來自上海 回復(fù)
  5. 產(chǎn)品經(jīng)理和項目經(jīng)理在國內(nèi)大多數(shù)是同一個人。

    來自北京 回復(fù)
    1. 很多小公司都不分。項目型的公司就有分。項目經(jīng)理級別高于產(chǎn)品。呵呵,我前東家就這樣。一家技術(shù)型外包大公司。

      來自廣東 回復(fù)
    2. 產(chǎn)品經(jīng)理對技術(shù)沒有管轄的權(quán)利,所以有新功能需求或者需求變動的時候,很容易變成一種技術(shù)部門與產(chǎn)品部門之間的博弈。

      來自北京 回復(fù)
    3. 是啊,每次有變更都不是跟技術(shù)對接,是跟他老大對接 ?

      來自上海 回復(fù)
    4. 我司有項管,不過我也兼著部分項管工作

      來自上海 回復(fù)
    5. 你們是外包企業(yè)嗎? ??

      來自北京 回復(fù)
  6. 產(chǎn)品的溝通能力確實很重要!舉個例子,運營沒法理解開發(fā)的意思,開發(fā)無法理解運營的需求,直接對話往往折騰了半天然并卵,所以需要產(chǎn)品在中間起到”翻譯”的作用~

    來自北京 回復(fù)
    1. 同感??!我經(jīng)常突然插話于旁邊熱火朝天討論的技術(shù)和運營之間,因為他們真不是一個世界的人,永遠不理解彼此的意圖 。

      來自上海 回復(fù)
  7. ??

    來自北京 回復(fù)
  8. 但是好多外行人,就以為請個產(chǎn)品經(jīng)理就能把這些活都給承包了。特別在一些初創(chuàng)公司,自己根本都不知道產(chǎn)品需求量有多大,就急著找一個產(chǎn)品經(jīng)理回來,計劃用一個月的時間,把整個APP由0到1做起來。UI什么都沒到位。只能呵呵了。這樣的崗位,真不敢接??佑卸嗌钸€不知道,不想從一個坑里爬上來,又掉到另外一個坑。

    來自廣東 回復(fù)
    1. 前東家的boss都是銷售出生,策劃了一個超級app,秘密開發(fā)了2個月,然后市場爭取到360首發(fā)。呵呵噠,接口居然沒通,整個app無數(shù)據(jù)。在上架應(yīng)用市場之前,除了CEO和COO,沒有人見過那款app!

      來自上海 回復(fù)
    2. 呵呵,前不久,就見了一家初創(chuàng)公司的負責人。一名非互聯(lián)網(wǎng)的人,但又不停地裝自己是很了解互聯(lián)網(wǎng)的人。后來也跟我說,他是銷售出身的。不斷的游說我入伙,還說給我配股(但前提是把我的工資壓低),十分熱情。其實我是一個很理智的人。跟我說什么情懷,配股有多少分紅,其實我是不信的。跟我吹了一個多小時,其實我知道很多東西是虛的。一個初創(chuàng)公司的領(lǐng)頭人關(guān)系到一家公司能不能做得下去。當有一天,東西做出來了,不那么美好,互聯(lián)網(wǎng)人一般會堅持,迭代優(yōu)化,但外行人,就會懷疑員工的能力,再換一個產(chǎn)品經(jīng)理或者換一個項目做。最怕就是外行領(lǐng)導內(nèi)行,因為不是互聯(lián)網(wǎng)出身的人,根本沒有耐心去做用戶培育。

      來自廣東 回復(fù)
    3. 互聯(lián)網(wǎng)公司一定要有技術(shù)合伙人,不然很難做起來,很難做活了

      來自上海 回復(fù)
    4. 是啊。

      來自廣東 回復(fù)
    5. 非常贊同這個觀點“當有一天,東西做出來了,不那么美好,互聯(lián)網(wǎng)人一般會堅持,迭代優(yōu)化,但外行人,就會懷疑員工的能力,再換一個產(chǎn)品經(jīng)理或者換一個項目做。最怕就是外行領(lǐng)導內(nèi)行,因為不是互聯(lián)網(wǎng)出身的人,根本沒有耐心去做用戶培育。”

      來自北京 回復(fù)
  9. 這個作者應(yīng)該是一個開發(fā)出身的產(chǎn)品

    來自廣東 回復(fù)
    1. 說出來怕嚇著你,我是先搬了幾年磚,又打了一年雜,然后做的產(chǎn)品

      來自上海 回復(fù)
    2. 同行,我和你一樣,也是搬了兩年磚,現(xiàn)在在做產(chǎn)品,我現(xiàn)在也在做外包,方便的話加QQ指點一二?可以否?

      來自新疆 回復(fù)
    3. 微信、QQ都是787224927

      來自上海 回復(fù)