產(chǎn)品經(jīng)理工作概述:談?wù)勎已壑械?個產(chǎn)品工作環(huán)節(jié)(二)

4 評論 20189 瀏覽 279 收藏 19 分鐘

前文已經(jīng)和大家提及到了產(chǎn)品經(jīng)理工作的前三個階段,名為接受任務(wù),分析,產(chǎn)品設(shè)計,這篇文章則和大家聊聊我們工作中的后四個階段,即交付產(chǎn)物,跟進進度,驗收發(fā)布,結(jié)果分析。

交付產(chǎn)物

我一直信奉團隊至上的觀點,個人的力量無論多么強大,也需要團隊的支撐。

我們在工作中,常常感嘆,有一位助理多好,那就能幫我們分擔(dān)許多工作了。

我們希望有位助理,或者有人協(xié)助,本質(zhì)上是對個人能力的一種危險預(yù)警,潛意識在告訴我們,你不行了,你需要團隊

正確處理團隊關(guān)系,高質(zhì)量提供交付產(chǎn)物,是我們獲得團隊幫助所必須要付出的代價。

與不同角色合作,需要交付不同的產(chǎn)物,需要記住的是,沒有誰是誰肚子里的蛔蟲,也不要寄希望和誰心意相通,正如我們無法揣測BOSS的想法,放之他人,也是相同的。

在我們與團隊合作的過程中,90%以上的分歧,不愉快都是因為產(chǎn)品經(jīng)理沒有嚴(yán)謹?shù)膶Υ约航桓兜漠a(chǎn)物。

原型圖和需求文檔是我們最基礎(chǔ)的兩份輸出產(chǎn)物,可直到現(xiàn)在,仍然有許多產(chǎn)品經(jīng)理以思維,思考的名譽,剝削產(chǎn)物的意義。產(chǎn)品經(jīng)理確實是一個強思考的行業(yè),但這不代表我們不需要執(zhí)行,不需要輸出。不需要將我們的思考過程交付給團隊。

我把我應(yīng)該做的做完,我就成功了,置于對方有沒有做完,抱歉,這不是我的責(zé)任,可我們真的知道自己應(yīng)該做哪些事情嗎?

絕大部分的時候,我們是不知道自己要做哪些事情的,這是這類角色的一個特性,似乎沒有人為我們安排明確的任務(wù),于是,我們出現(xiàn)了各種問題,各種花式秀矛盾,如果我們是開發(fā)人員,我大概會這么說。

你不是來寫代碼的,你是來寫bug的。

我們來簡單羅列一下要交付的產(chǎn)物

  • 原型圖
  • 原型全景圖
  • 需求文檔
  • 變更記錄
  • 業(yè)務(wù)流程圖
  • 數(shù)據(jù)流向圖
  • 迭代故事
  • 材料準(zhǔn)備
  • 溝通,調(diào)整

并沒有完全列舉完,我并不想去堆砌交付產(chǎn)物,這似乎沒有價值。

交付產(chǎn)物并不是越多越好,而是越有效越好。

以需求文檔舉例,我們可以看看自己寫的需求文檔,是否方便研發(fā)閱讀,是否有歧義,是否已經(jīng)將功能大部分都覆蓋了,一份好的需求文檔可以極大的增加團隊效率,減少低效時間的耗損。

我曾關(guān)注過一個現(xiàn)象,相同的團隊,相同量級的需求,實際開發(fā)中所消耗時間的差異高達 60% 期間,發(fā)生變化的只是需求文檔更為精致,交付產(chǎn)物質(zhì)量更高。仔細想想,平時耽誤團隊時間的,不恰恰是因為需求描述不清晰產(chǎn)生的溝通成本,調(diào)整成本,以及由于需求顆粒度不夠?qū)е碌淖兏杀締幔?/p>

而這些問題,只是需要提高我們交付產(chǎn)物的質(zhì)量,就能有效解決。

所謂的交付產(chǎn)物是指接力的介質(zhì),產(chǎn)品經(jīng)理所需要做的事情做好了,然后慎重的將我們的努力交給我們的團隊。這是一個很莊重的儀式,很嚴(yán)肅,是對團隊的尊重,也是對自己的尊重。

在野外,我們獵殺了一頭野豬,大概有100kg,我們嫌棄搬運太重了,就只切了一條豬腿,帶回部落,大概只有10kg

當(dāng)我們再回到狩獵地時,被獵殺的野豬已經(jīng)被其他野獸吃完了。

野獸就是我們所接受的任務(wù),由于嫌棄麻煩,我們很粗暴的對待自己的原型圖,很粗暴的對待需求文檔,對待我們的交付產(chǎn)物。似乎是沒有時間,實際上只是因為我們偷懶,而且還是很不聰明的一種偷懶。

如果用正確的方法畫原型圖,寫需求文檔,你會發(fā)現(xiàn),這樣才是最大限度的偷懶。

現(xiàn)在你知道如何面對交付產(chǎn)物了嗎? 他并不難,只是需要我們額外的細心,額外的認真,同時,也需要我們尊重團隊,尊重自己。切忌將產(chǎn)品經(jīng)理等同于思考者,我們除了強思考以外,也是團隊中的一份子,思維固然重要,團隊力量卻遠勝于個人的思維。

想的再多,做不出來,有什么作用呢?

跟進進度

產(chǎn)品經(jīng)理需要跟進版本進度,毫無疑問,我需要再強調(diào)一下,只有思想,只有想法,是無法做好產(chǎn)品經(jīng)理的,我們不缺少想法,每一天我們都有許多想法,成出不窮。

2011年,在我第一次創(chuàng)業(yè)時,認識了一位灰色產(chǎn)業(yè)的朋友,他告訴了我一個很棒的想法,他想要消滅錢包,消滅現(xiàn)金。

人們每天買東西要帶錢包,多么麻煩,還要找零,現(xiàn)在手機那么方便,做個軟件出來,直接掃一下就能付錢,多方便。

光是手機付費還不夠,金額太高,用手機也不方便,我們還得帶個手機,最好還是刷身份證,刷臉,這樣什么都不用帶,要付錢的時候,掃一下臉就好了。

很遺憾,他不是馬云,也不是馬化騰,他只是一位不那么普通的普通人,現(xiàn)在,人們手機支付已經(jīng)非常方便了,平時的生活中,我也很少再用現(xiàn)金了。移動支付產(chǎn)品經(jīng)理的想法與我這位朋友的想法并沒有什么不同,但將想法實現(xiàn)出來卻是截然不同的兩個概念。

想法固然重要,但也只是重要,真正起到?jīng)Q定因素的,還看我們的做法。

當(dāng)我們把產(chǎn)物交付給團隊以后,我們的事情并沒有結(jié)束,你需要留意一下,此時你的身份已經(jīng)變化了。

你的產(chǎn)品從交付的時候開始,出現(xiàn)了變化, 此時,團隊就是你的產(chǎn)品,團隊效率就是你的產(chǎn)品質(zhì)量。

如果一個團隊中沒有更高的角色,那產(chǎn)品經(jīng)理就是這個團隊的leader,產(chǎn)品負責(zé)人就要對這個產(chǎn)品負起責(zé)任,還要對這個團隊負起責(zé)任。

早會,需求卡片,周會,進度跟蹤,風(fēng)險報警,日報,周報,需求調(diào)整,需求管理,資源協(xié)調(diào)。

這些是我們最常看見的在交付后的任務(wù),盡管我們在交付產(chǎn)物之前,有做技術(shù)調(diào)研和需求評審,但這并不能保證在開發(fā)過程中出現(xiàn)需求障礙。

實際上,無論我們的技術(shù)調(diào)研和需求評審做的多么細致,總會出現(xiàn)意料之外的問題,這是因為我們的開發(fā)同學(xué),在技術(shù)調(diào)研和評審時,只能根據(jù)大概情況進行預(yù)測,而在執(zhí)行時,卻會考慮的更深更全面。

在研發(fā)階段,開發(fā)會遇到一些較為復(fù)雜的需求,會消耗較多的時間,此時,我們就需要根據(jù)開發(fā)的反饋進行再評估。

慎用技術(shù)強攻關(guān),大部分的產(chǎn)品并不是以技術(shù)決定勝負的,超過80%的團隊,并不需要過于強硬的技術(shù),尤其是小團隊,初創(chuàng)團隊。(技術(shù)性項目例外)。

在我接觸的許多項目中,再也沒有任何一個方法比修改產(chǎn)品方案更快捷了,當(dāng)出現(xiàn)研發(fā)障礙時,修改需求方案,能夠節(jié)省 1 天至 1 個月以上的時間,這需要我們每天跟進跟進研發(fā)進度

仔細想想,我們真的有必要花費這么大的成本去實現(xiàn)某個功能嗎?

當(dāng)我們參與到進度跟進時,會收獲許多的調(diào)整,為了避免出現(xiàn)需求不統(tǒng)一,也是為了提高交付給測試同學(xué)的產(chǎn)物,我們還需要對需求進行有效管理。

需求管理

目的:統(tǒng)一需求,提高需求溯源性,也是為了測試時能依據(jù)最新的,正確的需求進行測試,減少我們的溝通成本,也減少需求的不確定性

需求本身首先要能被管理,我并不提倡word版本的需求,也不提倡原型圖上寫需求,兩者皆因為 需求無法被管理

其次,當(dāng)需求評審以后,不再對已評審的需求進行編輯和刪除操作,原則上,我們將以 取消和新增的狀態(tài)進行標(biāo)示。

同時,我們還要維護變更記錄,讓變更原因,變更內(nèi)容清晰可見。

這并不是一件簡單的事情,需要我們掌握一些方法,比如嘗試用excel來編寫需求文檔,并且在需求文檔的撰寫過程中,遵守一些規(guī)范。

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

產(chǎn)品開發(fā)過程中,其實需要用到很多資源,包括內(nèi)部的和外部的。

當(dāng)我們需要使用第三方系統(tǒng)時,需要為開發(fā)同學(xué)準(zhǔn)備好第三方系統(tǒng)的賬號,key或者其他什么,比如第三方統(tǒng)計,第三方圖片處理,第三方登錄,第三方地圖

而內(nèi)部的資源集中體現(xiàn)在接口API 和設(shè)計圖輸出上,許多時候,我們都是由前端驅(qū)動的,我們設(shè)計的多數(shù)是前端的產(chǎn)品,比如APP, H5 ,WEB, PC ,但前端的功能需要依賴后端的接口,以及UI的效果圖。

等接口,等設(shè)計圖,這兩種時間的耗損雖然很可惜,但卻是我們經(jīng)常遇見的問題,如何妥善的安排資源,如何取舍,便是我們要做的資源協(xié)調(diào),盡量的減少等待,這需要我們知曉各個功能的優(yōu)先級,復(fù)雜度,盡快進入并行軌道,避免等待。

驗收發(fā)布

我?guī)Мa(chǎn)品團隊時,會經(jīng)歷兩次驗收,這里提到的驗收是整體驗收,我并不是很提倡在開發(fā)過程中頻繁打包,但我也很理解許多團隊,都會頻繁的打包驗收。

當(dāng)開發(fā)階段結(jié)束后,測試介入前,產(chǎn)品經(jīng)理有義務(wù)進行一次驗收,目的是確保主要功能邏輯與需求符合,沒有遺漏需求功能,可以稱之為需求驗收

當(dāng)測試結(jié)束后,產(chǎn)品經(jīng)理還需要再進行一次驗收,目的是確保產(chǎn)品無明顯Bug,能夠正常使用,此時,才是真的產(chǎn)品驗收

需求驗收

有時,我們需要做好心理準(zhǔn)備,也許開發(fā)實現(xiàn)的功能與我們的想象的有所區(qū)別,甚至南轅北轍。

我們首先需要確認一下,有沒有需求遺漏的,通常情況下,會有開發(fā)漏做了部分功能,此時,我們就要判斷這部分功能是否可放到下個版本迭代,還是當(dāng)前版本非常重要的功能。

面對一些實現(xiàn)效果與預(yù)期效果不一致的功能,我們還要冷靜的分析判斷,開發(fā)這樣的調(diào)整,能否接受,如果能接受,那就要根據(jù)調(diào)整結(jié)果,來修訂我們的交付產(chǎn)物。

原則上,我們希望盡快的切換軌道,需求驗收是一個階段,更多的卻是一個節(jié)點,我們要把關(guān),但也要靈活,盡量避免過多時間的反復(fù)調(diào)整

如何判斷哪些需求調(diào)整是可被允許的,哪些需求遺漏是可悲允許的,便是我們在這個階段所需要鍛煉提升的技能,MVP原則在這個環(huán)節(jié)也是適用的。

產(chǎn)品驗收

確保產(chǎn)品上線沒有明顯BUG,不只是測試同學(xué)的職責(zé),也是產(chǎn)品經(jīng)理的職責(zé),當(dāng)然,我們無法像測試同學(xué)一樣細致,成體系,成規(guī)范的進行模擬操作。

但我們卻可以從自己的角色出發(fā),確保主要路徑不出明顯bug,我們需要保證業(yè)務(wù)是正常的,核心功能是能被使用的,大部分使用場景是沒有明顯Bug的。

同時,產(chǎn)品驗收階段也是我們對需求邏輯的最后審核階段,我們的業(yè)務(wù)邏輯,功能邏輯這樣做是否正確。

這需要我們站在用戶的角色,真實的進行體驗,可以說產(chǎn)品驗收時,我們便是這個新功能的第一位真實用戶。

當(dāng)我們已經(jīng)完成產(chǎn)品驗收了,此時,我們就會通知開發(fā)同學(xué)。

沒有問題,可以打包了。

打包的意思是將已經(jīng)驗收的程序獨立生成安裝包,在android 平臺,我們往往需要打多個渠道包,每個渠道一個唯一的標(biāo)示,這樣我們就能知道我們的用戶都是從哪里下載的。

當(dāng)然,發(fā)布一個版本可不是這么簡單的。

產(chǎn)品發(fā)布

從硬性角度來講,我們要為產(chǎn)品發(fā)布準(zhǔn)備一些材料,比如更新文案,上傳安裝包以供審核,特別是IOS平臺,要預(yù)算3-7天的時間進行審核,且可能審核被拒絕。

從軟性角度來講,當(dāng)我們發(fā)布一些特殊的版本時,還需要配合運營的規(guī)劃擬定發(fā)布策略,必要時,可以封包待發(fā)布。

即,我們將可發(fā)布的版本準(zhǔn)備好,但卻不真的發(fā)布,等待機會成熟,再進行發(fā)布。

為什么在一些重要節(jié)慶日,成熟的產(chǎn)品都能準(zhǔn)時準(zhǔn)點的上線特殊版本呢?比如圣誕節(jié)版本,如果延期一兩天,是否表示這個版本的時間完全浪費了,畢竟圣誕節(jié)可不會等你兩天。

特殊的版本,我們往往會提前將安裝包準(zhǔn)備好,進入封包待發(fā)布的狀態(tài),只要等待某個特定的時間,便可以直接發(fā)布版本。

結(jié)果分析

這是最后一個環(huán)節(jié)了,也是最容易被大家忽視的環(huán)節(jié),我們習(xí)慣性的將希望寄托在下個版本,寄托在下個功能,卻很少對結(jié)果進行分析。

當(dāng)我們產(chǎn)品已經(jīng)發(fā)布了,此時要注意觀察相應(yīng),觀察數(shù)據(jù),通過實際市場結(jié)果,我們再來思考和評估。

這個功能是否被用戶所喜歡,用戶使用情況怎么樣?有沒有提高的方法?

我們知道一個頁面,不同的位置,人們的點擊欲望是不一樣的,相同的發(fā)布功能,以點擊次數(shù)來判斷,右上角的發(fā)布只占底部菜單的發(fā)布的1/10。

我們需要通過產(chǎn)品發(fā)布后的結(jié)果來持續(xù)的去改進,去分析,為下一個版本提供總結(jié)性材料。

作為產(chǎn)品經(jīng)理而言,我們所設(shè)計的功能,應(yīng)該是越來越有效的,而不是越來越多的,我至今仍然記得一個案例。

某網(wǎng)站,進行了一次改版,改動內(nèi)容是將注冊 的按鈕做的比以前更突出了一些,新版本的網(wǎng)站,注冊率比老版本的提高了30%。

這里提升的是注冊率而不是絕對值,因此我們可以忽略運營或者市場情況帶來的影響。

如果我們每次發(fā)布后,不對結(jié)果進行分析,我想一年經(jīng)驗和兩年經(jīng)驗,區(qū)別真的不大,甚至再做到第三年,第四年也是相同的。

我們在入門的時候,是以能做出產(chǎn)品為目的的,但當(dāng)我們能做出來以后,就要學(xué)會去分析,去改進,而不是一層不變。

相關(guān)閱讀

產(chǎn)品經(jīng)理工作概述:談?wù)勎已壑械?個產(chǎn)品工作環(huán)節(jié)(一)

#專欄作家#

枯葉,近6年經(jīng)驗的產(chǎn)品經(jīng)理,人人都是產(chǎn)品經(jīng)理專欄作家。擅長社交,社區(qū),細分群體挖掘。微信公眾號:枯葉咖啡館。

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

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 這篇文章對我們要從事產(chǎn)品這條路的人來說很好,比較容易理解

    回復(fù)
  2. 有所感悟

    回復(fù)
  3. 謝謝樓主的總結(jié)分享,說出了很多產(chǎn)品人很容易的細節(jié) :mrgreen:

    來自福建 回復(fù)
    1. 容易忽略的細節(jié)….手抖打錯….

      來自福建 回復(fù)