我是如何避免制造“產品事故”的

10 評論 6878 瀏覽 43 收藏 9 分鐘

事故并不可怕,可怕的是,事后并不懂得反省。

對于一家互聯網企業來講,服務器并發未處理好導致宕機,那屬于“技術事故”,商城首頁的商品和價格對應不上,那屬于“運營事故”,錯誤的執行了錯誤的產品設計,造成用戶流失,那屬于“產品事故”。

在我不長的產品生涯中,也曾遇到過大大小小的“產品事故”,下面我將分享一段經歷,以及在這件事情上自己的一些思考給大家。

我經歷過的“產品事故”

2015年,我在騰訊旗下某2B軟件的代理公司做CRM,當時是個小研發團隊,加上項目經理18個人。

項目經理是騰訊下來的,高度提倡敏捷開發,一周一個小迭代,兩周一個大迭代,通常是上一個迭代內容剛測試完成,下一個迭代內容就開始宣講了,團隊的研發人員一直處于工作量飽和,節奏快得工作狀態。

正式在這種開發背景下,促成了一次嚴重的事故,當時那個需求的重要性很高,所以是產品總監牽頭負責的。

我們的需求評審通常是各部門Leader一起參加,該需求最初是Boss直接提出的,在評審的時候發現產品功能與期望的需求有偏差,因此產生了嚴重分歧。

進一步導致技術實現上也產生爭論,10個人參加的需求評審,出現了10種不同的聲音。

那段時間開了無數次的碰頭會,搞得大家都很精疲力盡,所以到最后也沒有出現一個“大家一致認可”的方案出現,感覺總有漏洞,但是時間緊迫,沒辦法只能“跟著感覺走”讓開發做了一個心里沒譜的版本上線。

剛上線一天,大量數據涌入,嚴重的缺陷瞬間暴露,造成公司那一天的退款訂單比平時一個月都還多。

Boss大發雷霆,產品總監事后主動辭職。

這次事故讓我明白了什么?

首先要說服自己

我對PRD文檔的理解,其實里面的內容是給自己看的,寫的過程其實是,幫助自己梳理思路的過程。

一個PRD文檔,上午寫完趁熱看,感覺很完美,下午再來看一遍,就會發現問題。

一個點,也許會被自己推翻很多次,只有當自己也推翻不了自己的時候,才說明那個點已經可以曝光給其他人了。

自己還沒想清楚,就別拉著大家開會

開會的目的無非就是向一群人詳細的表達自己的想法,或聯合一群人來頭腦風暴,需求評審會議明顯屬于前者別把評審會開成了”大家來幫你思考的討論會”。

頻繁交流

產品經理是“無冕之王”,我們是沒有實權但是又可以是站在公司最耀眼的地方的人,我們能驅動公司的資源來幫助落地我們腦子里的想法,靠的不光是思考,還有溝通。

“思考再多,不說出來等于不思考?!?/strong>

持續跟蹤

需求交付給設計和開發以后,應該持續跟蹤,以保證實現的方式跟需求是吻合的。

人與人之間交流,內容傳遞是一個衰減的過程,你想的和你說的,以及對方聽到的,可能內容都不一樣。

那么,該如何避免制造事故的?

需求采集階段

需求一定是采集來的,而不是自己憑著主觀意識和想當然的同理心去設想出來的,采集需求一定要客觀,只有客觀才能最貼近真實需求,只有貼近真實需求,才能保證接下來的工作路線是正確的。

運營部反饋了一個問題:“用戶覺得這個地方字太小,內容又多,操作起來很麻煩,看久了眼睛又花又累?!?/p>

如果單純聽取運營部的想法,以及主觀思考來分析,很容易“誤入歧途”的認為,只要“通過優化UI清爽界面,或把一個頁面的功能拆分為兩個頁面來完成” 就能解決用戶這個需求。

其實只有去拜訪用戶,面對面交流,觀察以后,才會發現用戶的真實需求為:在Web端上開發出這個功能,因為能用電腦操作,屏幕大。

如果把產品經理的工作看作是修路,終點是“滿足用戶需求”,那么需求采集階段就是修路的第一段,我們的理解和看法,產生的思考結果,將決定這條路的方向。

思考實現的方法,實現的路徑,實現的難度,資源的分配,就如盤上公路一半,S型的蜿蜒盤旋,繞過一個又一個的“雷區”。

只有思考的越透徹,那后面的雜音才會越小,落地的速度才會最快。

分析與設計階段

需求分析與設計,是產品工作中很重要的一部分,這里產出的內容,將決定公司接下來的營銷、運營、研發等資源的調配與消耗,所以需求分析一定要謹慎,產品設計一定要匹配。

  1. 學會頻繁的梳理自己的PRD文檔,也許每過一遍,就會修復一些邏輯缺陷,或者產生更好的想法來調優方案。
  2. 拿捏不準的和概念模糊的,學會請教相關的人,描述想法給他人,以驗證對方案的設想是否正確,只有得到驗證才好大膽的去實現。
  3. 對自己批判性思考,學會問自己“首先是這是不是真實需求,其次是這樣解決的可行性如何?最后是這種解決方案在邏輯上是否合理”。
  4. 開需求評審會以前,盡量先跟參會的關鍵人員們通通氣,分歧和不統一的意見,盡量放到臺下來解決,減少會議上的雜音。

今年年初,我牽頭負責了我們產品“錢包”功能的重構設計,以下是這期間我的大致工作流程:

如果前期我“聽風就是雨”,做的驗證不夠就拿到臺面上來宣講,那么帶來的結果:

  1. 可能與財務系統有沖突。
  2. 可能技術實現有困難。
  3. 可能不符合公司運營方案的策略。
  4. 產品思路有問題,缺陷明顯。
  5. 上線后問題暴露,傷害用戶,造成損失。

作為產品的第一負責人,只有嚴謹的做事方式去避免出現“產品事故”,才能有機會站在臺上,被眾人所注目,被聚光燈所照亮。

如果只能做螺絲釘,也要做一顆有思想的螺絲釘。

 

本文由 @擁抱變化?原創發布于人人都是產品經理。未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 前輩寫的很好,收獲了

    來自浙江 回復
    1. 非前輩,謝謝支持!

      來自四川 回復
  2. 一周一個小迭代兩周一個大迭代確實騰訊風格,不過這種開發強度對于團隊規模要求很高,不到達一定規模就特別容易出事故…

    回復
    1. 是的,團隊各崗位都是獨當一面 ??

      來自四川 回復
  3. 你好多感想都和我一模一樣…… ??

    來自江蘇 回復
    1. 加微信聊聊? ??

      來自四川 回復
    2. 嗯可以啊,你微信號?

      來自湖南 回復
    3. 348881074

      來自四川 回復