三招七式教你搞定產品經理經常加需求、改需求

 

上篇分享了老闆經常加需求改需求的四種情況和應對方法,這篇分享產品經理經常改需求、加需求的情況。

 

產品經理經常加需求、改需求,主要有四種因素決定:

1)老闆的瞎指揮;

2)產品經理本身的能力不足;

3)程序員的能力不足;

4)項目流程不合理和管理方法存在缺陷。

 

這些因素要分開來分析,不同因素引起的問題要用不同的方法來解決,不能一概而論說產品經理經常改需求、加需求是產品經理的問題。

 

這部分我們分成兩篇文章來分享,這篇分析“人”的能力不足而引起的經常改需求、加需求的情況,下篇分析項目流程和管理方法不合理而引起的改需求和加需求的情況。

 

1. 產品設計流程

我們要解決產品經理經常加需求改需求的問題,就要從產品設計的過程上來分析,從根源上找到引起問題的原因,才能從根本上解決這些問題。

 

 

產品經理做產品設計的流程有三個步驟:

1)設計產品框架

2)用思維導圖設計模塊、功能及功能間的關係

3)設計產品原型或用戶故事

 

這個是簡化的流程,實際流程比這個複雜的多,這篇不是講產品設計的文章,我們就不用完整的流程。這3個步驟,每個步驟出問題,都會給項目帶來不同程度的問題,甚至是災難。

 

2. 設計產品框架

這個步驟,主要的工作是做產品的頂層設計,產品針對哪些用戶,解決用戶的什麼問題,商業模式、贏利模式是什麼,產品的規劃是什麼,分多少步驟實現這個規劃,每個步驟核心要解決什麼問題,以及實現計劃是什麼等。

 

一般產品經理,沒有3年以上的經驗,產品框架是設計不完整的。很多中小公司,爲了節省成本,請的產品經理沒有多少經驗,甚至是老闆、技術經理或UI兼職做產品經理,就會出現產品框架設計不完整的情況。這會帶來什麼問題呢?

 

1) 產品經常整個模塊的調整優先級

這步缺失,帶來的第一個問題:在開發過程中,產品會做方向性的、模塊級的大調整。

一個模塊做好了,感覺可以喘口氣了,產品經理突然跑過來跟你說,這個模塊優先級放低,要增加一個新的模塊,這個新模塊更重要,或者本來不重要的模塊要提高優先級。項目時間本來就緊張,這回好了,要用更多的加班來趕這些改動。

 

還有,一個模塊跟你講非常非常重要,團隊加班加點趕進度,勝利在望的時候,突然跟你說這個模塊不做了。

 

2)產品不停的加功能

這步缺失會帶來另一個問題:不停的加功能。

運營型的產品,運營沒有效果;銷售型的產品,銷售人員賣不動。拼命的加新功能,加更“高級”的功能。希望通過更好的功能,來達到運營或銷售的目標。

最後,大家看到自己做的產品,好高級,什麼先進的功能都有,覺得行業第一。結果運營不知道從哪裏下手做推廣,銷售不知道怎麼賣產品。然後公司就糊里糊塗的關門了。

 

中小型公司和創業公司,這種情況很多見吧!遇到這種情況,實際上P8及以下級別的程序員是搞不定的。而很多創業型公司喜歡從一線互聯網公司挖P8級的程序員來當CTO,這種公司死得很快就在這裏。

如果公司沒有能搞定這個問題的人(懂得頂層設計),那這家公司存活時間,跟老闆、員工的努力和夢想沒有關係,只跟能燒的錢的多少有關係。

 

解決辦法:

1)公司有能解決這個問題的人

如果你遇到這種情況,公司有能解決這個問題的人,那就把問題拋給老大,讓老大從頂層去解決。

 

2)沒有能解決這個問題的人

像前面說的,根本解決這種問題,級別要求是比較高的。如果沒有能解決這個問題的人,可以開始考慮換地方了。不過,我在《程序員爲什麼技術這麼厲害,賺得錢卻不多?》這篇中,跟大家分享如何選擇職業跑道,如果你選擇了這種類型公司,你可能以後的職業生涯都會在這一級別的公司上換,所以要想辦法換更好的跑道

而這種類型的公司,工作實際上很累。經常要加班,身體很累;而且,你發現自己做的很多是無用功,心也很累。如果想過得輕鬆一點,還是有辦法的。

 

3)治標不治本,死得舒服一點

和項目負責人(正常是產品經理)溝通版本的發佈節奏,把這個節奏調快,比如2個月的版本時間,調到1個月左右。然後和負責人達成共識,這個版本要發佈哪些模塊和功能,評估工作量和做好計劃。因爲版本的發佈時間很短,模塊和功能不多,正常負責人不會打亂節奏。

如果還是出現要強加模塊或功能的情況呢?這樣肯定會影響這個版本的進度,那怎麼辦?比如這個版本做了一半,要強給你加一堆有的沒的功能。這個時候可以和負責人談,給一兩天時間,把做好的功能產品化,提前把做好的功能上線。再重新起一個版本,新功能在新的版本開發,重新排進度。

如果負責人不同意,前面做的工作量評估和計劃就派上用場了,給負責人二選一,要麼用新功能替換原來安排的功能,要麼延長項目時間。

 

這個方法有兩個好處:一、快速出成果,老闆或產品經理等可以快速的驗證他們的想法,精力就不會放在猜加哪些功能,才能讓產品更有殺傷力,然後給產品加一堆的功能。二、我們都有經驗,版本與版本之間,會有空檔時間,程序員可以得到休息和調整,而不是沒有盡頭的加班趕進度。

這個方法是很有效的,只是和負責人溝通的時候,自己的方案是要可行的。還有這個方法,只能給程序員的工作帶來好處,解決不了產品核心的問題,要根本解決這個問題,是要有頂層設計能力的人來解決的。

 

3. 用思維導圖設計模塊、功能及功能間的關係

產品經理設計產品的步驟中,是沒有這個步驟的。很多產品經理的習慣,設計完產品的框架之後,做產品原型的產品經理,就會開始設計產品原型;做用戶故事的產品經理,就會開始設計用戶故事。這樣會帶來什麼問題呢?

 

1)實現某項業務的功能缺失

2)功能的完整性不夠

3)功能間的關係不正確。

 

而這些問題,在項目中的表現,就是在開發的過程中,產品經理會時不時的添加小功能,或者是給功能添加步驟,還有就是調整功能關係。

 

 

不知大家對用例(Use Case)熟不熟悉,實際上這步做的就是用例分析。我們做用例分析,簡單的講就是分析用戶與功能的關係,功能間的關係,功能與存儲之間的關係。而產品經理在設計產品原型之前,通過思維導圖,從容易就找出用戶需要哪些功能,功能間有什麼關係。不會造成功能的缺失和功能間的關係遺漏。

 

如果是用用戶故事,在做故事路線圖的時候,有點類似在做這件事,它也是在找功能間的關係,及優先級。但是用戶故事已經有它自己的內容描述了,就像產品原型一樣,已經不能單純的去看功能和關係。效果沒有像這樣單獨拉出來做好。

 

而且,這步做的好,程序員的需求分析都可以不做,而且評估工時,可以直接用這張圖來評估。可以簡化很多的工作,效率也會大有提升。

 

如果遇到項目過程中,產品經理經常添加功能,給功能添加步驟和調整功能關係,要怎麼解決?

 

解決方法:

1)吊產品經理,讓他把業務考慮清楚

如果你自己工作年限不長,產品經理年限長,就可以直接吊他,他沒有把業務考慮清楚。雖然,團隊合作精神很重要,但是,我們該表達自己不爽的時候還是要表達,不然這個問題不會引起重視,就沒辦法解決。

如果你有四五年的工作經驗,就不能吊產品經理了,是自己的能力沒有達到,也就是第二點,要學會做需求分析。

 

2)學習做需求分析

中級程序員有個能力,是對產品有一定的理解能力,能把模塊分解成功能級。要有這個能力,就應該要懂得做需求分析。而到高級程序員,需要有產品有把控能力,能把產品分解成不同的模塊,能根據不同的程序員的能力分配模塊或功能,能做好這件事,本來就是靠需求分析能力。

但是我見過太多工作很多年都不會做需求分析的人,這個跟行業的發展也有關係。現在要找本像樣的項目管理或開發方法的書都很難,能找到的還都是十年前的。所以,現在的程序員只關注框架、技術、工具,是情有可原的。

但是,想在這個行業混的好,需求分析能力是需要的。所以,我們經常在抱怨產品經理改需求、加功能,實際上是自己應該掌握的技能沒有掌握。自己在罵產品經理的時候,是在罵自己。

 

3)從項目流程上來解決這個問題

程序員會需求分析,是要來幫產品經理做這個步驟嗎?

不是的,這個步驟是產品經理的活,程序員在做產品評審和需求分析的時候應用這個能力,這個在下一篇項目流程和管理方法不合理引起的改需求、加需求中分享。

 

 

4. 產品原型設計

很多小公司和創業公司,是不做產品原型設計的,可能只是幾句話,去參考某某應用,就完事了。

 

採用用戶故事的團隊,很多也是不做產品原型設計。

很多敏捷團隊有發現用戶故事不管怎麼做,在開發的時候都會有問題,解決方法往往是招更厲害的程序員,希望高手自帶解決方法,還有就是把用戶故事做的更重型。這些解決方案,問題會有好轉,但不能根本解決。

 

爲什麼會這樣呢?實際上我們從敏捷開發的歷史就能發現問題:

1)敏捷開發是誰提出來的?一羣技術高手。

2)敏捷開發是什麼年代提出來的?90年代。

那個年代的產品,基本上沒有界面上的要求,只要把字段往界面上一鋪就很好了。而現在對界面的交互體驗要求很高,所以出問題是再正常不過了。

 

我來舉個例子:

作爲一名程序員,我想要買一個價格在80元左右、手感好的杯子,以便於我可以用來在辦公室喝水,也可以用來喝茶。

 

這個是按用戶故事三要素來寫的用戶故事,基本滿足3C原則和INVEST原則。

現在,讓你來買這個杯子,你會買什麼杯子?

 

 

 

你看,不同的人,買回來的是不同的。人之間的信息傳遞,過程中會有20%以上的損失,所以一個需求,從用戶到產品經理再到程序員,理解上的偏差就很可觀了,如果沒有一個統一的參考標準,不管程序員的理解能力有多強,最後做出來的和用戶理解的都會相去甚遠。

 

沒有做產品原型設計,或者產品原型設計做的不好,會帶來什麼問題?

我們在做項目過程中,經常遇到改界面、功能微調,基本上就是這種問題引起的。

 

解決辦法:

要有統一的驗收標準。最好是有產品原型,或者有比較完整的UI交互設計。如果是用用戶故事,故事要直觀,理解上有歧義的地方,一定要和產品經理溝通清楚,不然就等着改需求。

 

對於有做產品原型,但是做的不好的團隊,就需要程序員有產品理解能力(需求分析能力),在做產品評審或用戶故事討論的時候,發現產品設計上的問題。這部分的細節,我們在下一篇討論。

 

作者介紹

陳華祥

18年全棧工程師,8年集團公司CTO;

項目管理、職業成長、研發系統建設專家;

《艾米視頻聊天》,裝機量3億,註冊用戶4000萬;

騰訊學院《騰學匯》項目負責人;

銳思克網絡創始人

項目管理、程序員職業成長企業內訓講師和教練;

《程序員職場第1課》、《職業規劃:程序員百萬年薪修煉之道》、《高級程序員進階修煉》、《項目管理從入門到精通》,作者、講師。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章