什麼樣的產品流程才是好的產品流程?

不考慮客觀條件的情況下,如老闆的要求,團隊的能力……


一些觀點:

1、不同的領域的產品研發流程的最佳實踐不盡相同

互聯網領域、傳統軟體、傳統製造業/快速消費品雖然都有產品研發,但研發流程不盡相同,這與所在行業的產品研發周期密切相關。

總體而言,傳統軟體一般採用諸如CMMI、ISO9001、RUP、IPD(華為、IBM)之類的研發流程。快速消費品的代表是寶潔,汽車製造的代表是豐田;互聯網一般採用敏捷開發過程,例如Scrum等。

2、企業在不同的階段需要不同的產品研發流程

在創業初期,人員較少,此時侯以解決生存、探索業務模式為主,此時侯產品研發流程以「簡單實用」、快速響應市場需求為主要目的。此時侯產品研發流程可以重點關注立項、產品評審、技術評審等幾個關鍵環節,保證流程的可控性,其他的可以自由發揮。另外在創業初期可以通過面對面的溝通、協作來彌補流程上的缺陷。對於初創型公司而言,如果連溝通協作都有問題,指望制定一個完美流程來規範化此過程,那這樣的公司很難走遠。當然並意味著不需要產品研發流程,但不要教條化產品研發流程,讓流程編程創新的桎梏。

企業處於成長期,規模比初創期稍微大點,人相對多了(例如幾十號人),業務也上了規模,此時侯需要相對規範點的研發流程來規範整個研發過程。此時侯可以在原有流程基礎上針對流程執行過程中常見問題來細化並規範化產品研發過程。此時侯流程制度+溝通協作還是主要形式。

企業發展到成熟期後,此時侯大部分公司都陷入了大企業病、官僚體制(不是貶義,泛指到此階段的狀態),各部門間分工也相對細化,此時侯基於組織管理權責明確(或者叫撇清責任的目標),必須依靠完整的流程制度來規範化整個流程,此時侯產品研發流程越來越複雜,最終會演變成類似IPD、RUP、CMMI等業內最佳實踐的變體。

3、每一個企業的產品研發流程都與其企業文化、企業所在領域、企業發展歷史等密切相關,不要指望有一個完美流程能夠原封不動地搬過來就能夠涵蓋自己企業的需求,每一個企業產品研發流程制度的制定可以參考業內最佳的實踐,但取代不了結合企業的實際情況做裁剪。

4、產品研發流程制度最重要的環節不在於制定,而在於執行,而且在於持續不斷地完善,所謂「持續優化」。在完美的產品研發流程制度,如果不執行到位,只是過形式,那這樣的流程制度依然毫無價值;再差的產品研發流程制度,只要結合企業實際情況,持續不斷地完善並落實到位,那對於此企業而言就是好的流程、就是完美流程

5、產品研發流程制度實際上是規範相關人員的行為,因此所有研發流程制度的問題歸根結底還是人員素質、人員意識的問題,在制定流程制度來規範化相關行為時候,怎樣提升這樣人員的素質更為關鍵。


前面很多答案已經談的比較清楚了,就不在系統回答,簡答下一些思考點。

好的產品流程一定是可迭代的流程,特別是在當前互聯網開發中短周期迭代更加重要,因為互聯網產品本身更加難以前期收集用戶需求並整理為產品需求,通過快速的迭代可以使我們更加方面的收集到用戶信息的反饋並指導後續版本開發。

好的產品流程一定需要有專門的產品立項和啟動過程,產品立項不是簡單的走一個流程完事,而是真正分析清楚產品是否該立項,當前競爭分析如何,產品研發和資源投入如何,產品如何推廣和運營,有哪些假設和風險等。這個必須要認真對待,否則一個產品從一開始啟動往往就已經註定失敗,很大的原因就是諸多美好的願景都依賴於無法落地的諸多假設上。

好的產品流程是能隨時終止的流程,明知道已經不可為而為之是愚蠢的做法,但是如何判斷產品是否可繼續卻沒有事先在產品流程中制定標準,導致無法決斷。因此產品流程裡面必須有階段劃分,有到了某個階段的決策標準判斷。

好的產品流程必須分清楚產品和項目的關係,產品是產品,項目是項目,產品有產品和版本規劃,項目本身也有項目版本和計劃,最終的產品規劃驅動了項目的開展。而本身獨立的一個項目版本又有了明確的需求範圍輸入和進度成本要求。產品當作項目做,容易缺失了產品需求的抽象,業務模型的抽象導致無法產品化,項目當成產品做導致缺乏迭代或無目標。

好的產品流程貫徹了市場驅動研發的思路,一個產品即使做的再好,如果最好沒有市場,沒有創造產品應該有的商業價值或社會價值,那麼就談不上一個優秀的產品。市場驅動研發,需要我們能夠隨時將市場第一線的用戶聲音傳遞的產品研發中去。

好的產品流程是真正能和企業當前業務和團隊匹配的流程,不要去簡單的照搬已有的IPD,CMMI,項目管理,SCRUM等各種方法論,而是充分的結合企業研發的產品所處的行業,市場和用戶的特點,團隊當前情況制定的切實可落地的流程。沒有完美的流程,只有最適用和最匹配的流程,也不要期待流程去解決所有業務問題和人的問題。

好的產品流程是能夠真正能夠沉澱為企業知識庫和無形資產的流程,任何一個企業或團隊,人最終都是流動的,但是通過產品流程最終積累下來的內容卻是企業最寶貴的知識庫或資產。好的產品流程不是簡單的規範當前產品的研發,而是為企業知識庫貢獻力量。


原文地址是: http://www.marscn.net/?p=928

在我的認知中,產品製作主要分為三個階段:

1.需求調研:

通過面對面訪談,收集需求卡片等方式,對某類或者某行業的用戶,進行密集的調研,收集並總結他們在工作或者日常生活中所遇見的一些問題或是建議,找出其中共性的部分,將其總結為某種需求,最終選定其中一個作為核心問題,而解決這個核心問題的功能,將會是日後產品生存的根基。

2.產品立項與研發

依據用戶的核心需求,提出產品設想,並做好相應的市場調查與可行性分析。在通過決策層評審後,將設想細化成產品原型,提交到UED與研發部門,製作出相應的產品並投放市場。

3.產品市場化:

商務部門依據產品設定的目標用戶群體,對產品進行包裝和宣傳,在完成銷售任務的同時,與產品經理一起積極收集用戶反饋意見,協助產品經理校正與迭代產品,保持產品與市場的同步。

其中產品設計與研發,又可以細分為五個階段:

  1. 產品立項:主要包括商業需求文檔(BRD),市場需求文檔(MRD)以及產品需求文檔(PRD)的製作,通過BRD獲得資源支持,MRD驗證產品設想,PRD提交產品模型,確保產品方案的可行性和可操作性。
  2. 產品研發:包括用戶體驗的設計以及具體的功能實現。
  3. 產品測試 :通過一些的測試,確保產品的質量,及時發現產品的BUG,加速產品的迭代。
  4. 產品上線 :在產品通過上線評審後,通告與協調相關部門完成產品的上線工作。
  5. 產品運營:協助產品經理輸出相關的產品文檔,以及和產品經理一起策劃相關的營銷活動。

有人曾經問過我,為什麼這樣來劃分整個流程,好處與壞處是什麼?

其實工程學上來說,這種模式屬於典型的「瀑布模型」:

好處在於:

  1. 各階段劃分的非常清楚,進入下一階段後不會被上一階段的事情所負累。
  2. 很適合利用此流轉對產品進行增量的迭代;

壞處在於:

  1. 需求變動頻繁的話會很痛苦;
  2. 各階段之間屬於串列連接,版本跨度控制不好的話,會經常出現UED忙的要死的時候,研發很閑,研發忙的要死的時候,UED很閑的情況,團隊利用率不高;
  3. 最嚴重的是要是立項沒立好,或者立錯了方向,基本死翹翹。

因為自己做產品做的比較多,需求一般自己把控,而且大多要求快速迭代,所以個人覺得這種研發模型,非常適合互聯網產品的開發,這些年來自己一直都是使用這樣的套路在研發產品,倒也用的順手,對比以前在FounderRd的時,公司用的CMM3標準,個人最大的感受就是:敏捷。

所以如果把控的項目,需求不由自己把控,而且質量要求很高的話(比如銀行或者電信類產品),相信上述流轉將不適合您現在的產品或項目。


如果是互聯網產品研發流程,個人比較贊同採用Scrum或者其他敏捷方法,當然具體採用的時候,也需要根據自身情況進行合理裁剪 http://www.stonenotes.me/archives/scrum%EF%BC%8C%E4%BA%92%E8%81%94%E7%BD%91%E5%85%AC%E5%8F%B8%E7%9A%84%E6%9C%80%E4%BD%B3%E5%BC%80%E5%8F%91%E6%96%B9%E6%B3%95.html


按照谷歌和亞馬遜的做產品方法,可以歸為7個步驟:

1、確定正確的產品方向

2、儘可能清晰的定義產品

3、設計用戶體驗

4、做一些基礎的項目管理工作

5、開始測試

6、建立一套可衡量產品成敗的指標

7、正式發布


流程沒有好不好,只有合不合適。


任何能讓這個產品走的更遠的流程都是好流程,所以可以是從用戶人群分析開始的流程,也可以是一幫geek一拍腦袋就出來的流程,只有最糟糕的公司才會在沒特別大之前就沒事考慮各種流程的東西,那是一種還沒長胖的人先裝出嬌喘來體現富態的心態,從現在這個時代看,各種龐大冗餘的流程除了養一幫蓋圖章的笨蛋實在沒太大意義。產品導向永遠是第一位的。流程在人治的地方完全耍不開。


查看我的專欄文章:產品研發團隊基於Worktile的Scrum敏捷開發協作流程


產品策劃,產品研發,產品運營形成完整的閉環。

產品流程與公司的行業特點,公司的文化有很大關係,沒有放置四海皆準的流程,建議使用scrum來進行裁剪或增加,持續優化,時間出適合本公司的一套產品流程。譬如:先建立產品的價值模型,在這個模型下進行產品的策劃等。


合適最重要,能夠高效的應對用戶的需求即可


能切合您的業務需求,解決企業存在的諸如上通下達,部門溝通障礙,軟體」孤島「等等問題,就算是好流程。業務方面的流程梳理——費用控制、合同各個環節、銷售訂單類、招投標類的流程,有行業客戶經驗,這些都是企業在進行軟體選型時該考慮的。


流程判斷標準有一個結果論的視角——最快且最小bug率的就是最好的。

當然也有面向過程的視角:流程是好的,結果就是好的。


不同的公司和團隊不同 邱凱的回答適合外企或者大公司

如果純粹是想把事情做成的話 沒有流程就是最好的流程

大家有共同的願景和目標 順其自然 順勢而為


推薦閱讀:

如何分析評價 QQ 安裝時默認捆綁軟體的行為?
開放平台的產品經理應該多注意哪方面的東西呢?
在未越獄 iOS 系統下實現特定功能,有哪些 「機智」 的做法?
啟動新產品,是從原有人員抽出一部分合適,還是將新產品任務加到原有隊伍上,哪種方式更合理?
為什麼互聯網巨頭的產品會有一些低級的 bug?

TAG:產品經理 | 產品管理 |