我是如何避免制造“產品事故”的
事故并不可怕,可怕的是,事后并不懂得反省。
對于一家互聯網企業來講,服務器并發未處理好導致宕機,那屬于“技術事故”,商城首頁的商品和價格對應不上,那屬于“運營事故”,錯誤的執行了錯誤的產品設計,造成用戶流失,那屬于“產品事故”。
在我不長的產品生涯中,也曾遇到過大大小小的“產品事故”,下面我將分享一段經歷,以及在這件事情上自己的一些思考給大家。
我經歷過的“產品事故”
2015年,我在騰訊旗下某2B軟件的代理公司做CRM,當時是個小研發團隊,加上項目經理18個人。
項目經理是騰訊下來的,高度提倡敏捷開發,一周一個小迭代,兩周一個大迭代,通常是上一個迭代內容剛測試完成,下一個迭代內容就開始宣講了,團隊的研發人員一直處于工作量飽和,節奏快得工作狀態。
正式在這種開發背景下,促成了一次嚴重的事故,當時那個需求的重要性很高,所以是產品總監牽頭負責的。
我們的需求評審通常是各部門Leader一起參加,該需求最初是Boss直接提出的,在評審的時候發現產品功能與期望的需求有偏差,因此產生了嚴重分歧。
進一步導致技術實現上也產生爭論,10個人參加的需求評審,出現了10種不同的聲音。
那段時間開了無數次的碰頭會,搞得大家都很精疲力盡,所以到最后也沒有出現一個“大家一致認可”的方案出現,感覺總有漏洞,但是時間緊迫,沒辦法只能“跟著感覺走”讓開發做了一個心里沒譜的版本上線。
剛上線一天,大量數據涌入,嚴重的缺陷瞬間暴露,造成公司那一天的退款訂單比平時一個月都還多。
Boss大發雷霆,產品總監事后主動辭職。
這次事故讓我明白了什么?
首先要說服自己
我對PRD文檔的理解,其實里面的內容是給自己看的,寫的過程其實是,幫助自己梳理思路的過程。
一個PRD文檔,上午寫完趁熱看,感覺很完美,下午再來看一遍,就會發現問題。
一個點,也許會被自己推翻很多次,只有當自己也推翻不了自己的時候,才說明那個點已經可以曝光給其他人了。
自己還沒想清楚,就別拉著大家開會
開會的目的無非就是向一群人詳細的表達自己的想法,或聯合一群人來頭腦風暴,需求評審會議明顯屬于前者,別把評審會開成了”大家來幫你思考的討論會”。
頻繁交流
產品經理是“無冕之王”,我們是沒有實權但是又可以是站在公司最耀眼的地方的人,我們能驅動公司的資源來幫助落地我們腦子里的想法,靠的不光是思考,還有溝通。
“思考再多,不說出來等于不思考?!?/strong>
持續跟蹤
需求交付給設計和開發以后,應該持續跟蹤,以保證實現的方式跟需求是吻合的。
人與人之間交流,內容傳遞是一個衰減的過程,你想的和你說的,以及對方聽到的,可能內容都不一樣。
那么,該如何避免制造事故的?
需求采集階段
需求一定是采集來的,而不是自己憑著主觀意識和想當然的同理心去設想出來的,采集需求一定要客觀,只有客觀才能最貼近真實需求,只有貼近真實需求,才能保證接下來的工作路線是正確的。
運營部反饋了一個問題:“用戶覺得這個地方字太小,內容又多,操作起來很麻煩,看久了眼睛又花又累?!?/p>
如果單純聽取運營部的想法,以及主觀思考來分析,很容易“誤入歧途”的認為,只要“通過優化UI清爽界面,或把一個頁面的功能拆分為兩個頁面來完成” 就能解決用戶這個需求。
其實只有去拜訪用戶,面對面交流,觀察以后,才會發現用戶的真實需求為:在Web端上開發出這個功能,因為能用電腦操作,屏幕大。
如果把產品經理的工作看作是修路,終點是“滿足用戶需求”,那么需求采集階段就是修路的第一段,我們的理解和看法,產生的思考結果,將決定這條路的方向。
思考實現的方法,實現的路徑,實現的難度,資源的分配,就如盤上公路一半,S型的蜿蜒盤旋,繞過一個又一個的“雷區”。
只有思考的越透徹,那后面的雜音才會越小,落地的速度才會最快。
分析與設計階段
需求分析與設計,是產品工作中很重要的一部分,這里產出的內容,將決定公司接下來的營銷、運營、研發等資源的調配與消耗,所以需求分析一定要謹慎,產品設計一定要匹配。
- 學會頻繁的梳理自己的PRD文檔,也許每過一遍,就會修復一些邏輯缺陷,或者產生更好的想法來調優方案。
- 拿捏不準的和概念模糊的,學會請教相關的人,描述想法給他人,以驗證對方案的設想是否正確,只有得到驗證才好大膽的去實現。
- 對自己批判性思考,學會問自己“首先是這是不是真實需求,其次是這樣解決的可行性如何?最后是這種解決方案在邏輯上是否合理”。
- 開需求評審會以前,盡量先跟參會的關鍵人員們通通氣,分歧和不統一的意見,盡量放到臺下來解決,減少會議上的雜音。
今年年初,我牽頭負責了我們產品“錢包”功能的重構設計,以下是這期間我的大致工作流程:
如果前期我“聽風就是雨”,做的驗證不夠就拿到臺面上來宣講,那么帶來的結果:
- 可能與財務系統有沖突。
- 可能技術實現有困難。
- 可能不符合公司運營方案的策略。
- 產品思路有問題,缺陷明顯。
- 上線后問題暴露,傷害用戶,造成損失。
作為產品的第一負責人,只有嚴謹的做事方式去避免出現“產品事故”,才能有機會站在臺上,被眾人所注目,被聚光燈所照亮。
如果只能做螺絲釘,也要做一顆有思想的螺絲釘。
本文由 @擁抱變化?原創發布于人人都是產品經理。未經許可,禁止轉載。
前輩寫的很好,收獲了
非前輩,謝謝支持!
一周一個小迭代兩周一個大迭代確實騰訊風格,不過這種開發強度對于團隊規模要求很高,不到達一定規模就特別容易出事故…
是的,團隊各崗位都是獨當一面 ??
你好多感想都和我一模一樣…… ??
加微信聊聊? ??
嗯可以啊,你微信號?
348881074