産品設計開發幾個階段?本文作者最近複盤并總結出了：産品從設計到開發上線中的一些基本原則，enjoy~，接下來我們就來聊聊關于産品設計開發幾個階段?以下内容大家不妨參考一二希望能幫到您!

産品設計開發幾個階段

本文作者最近複盤并總結出了：産品從設計到開發上線中的一些基本原則，enjoy~

身在創業團隊中工作，讨論與意見分歧是不可避免的，最近在進行複盤的時候，我發現讨論通常會分為兩種：

一種是針對于模棱兩可的問題進行進一步的明晰與界定，這種讨論往往是有積極意義的，會促使團隊成員深度思考；

另一種是讨論往往是針對于産品細節可A或可B的意見分歧，這種讨論會浪費大量的時間，并且在很多時候是無意義的。

進一步分析第二種讨論，我發現原因是團隊内部對于一些基本的産品原則模糊不清，每個人都會有不同的産品理解與産品原則，這也就不可避免的在很多次要問題上進行了過多的無意義讨論。為此，我專門總結了一下産品從設計到開發上線這個過程中的一些基本原則，然後把這些原則與公司各部門同事進行了溝通，以期就一些基本的産品原則達成共識，從而減少無意義的讨論。

這些原則中，有些是已有廣泛應用的，有些是我自己的經驗總結，歡迎同行們補充糾錯，相互學習。

一. MVP産品原則

1. 該原則的含義

這個概念最早是由《精益創業》的作者Eric Ries提出來的，意思是指開發團隊通過提供最小化可行産品獲取用戶反饋，并在這個最小化可行産品上持續快速疊代，直到産品到達一個相對穩定的階段。MVP産品的重點并不是讓産品如何美觀、交互如何炫酷，而僅僅是為了驗證産品的功能是否被用戶所接受，人們的接受程度如何。

如果團隊成員對這個原則沒有清晰的認知，那麼産品經理就會接到大量關于優化與細節體驗上的需求，而且産品也會經常被内部成員吐槽。所以這個最基本的觀念需要在團隊内部達成充分的共識。

2. 該原則的意義

（1）MVP原則可以使創業團隊在擁有較少資源的情況下，對用戶的需求進行快速試錯；

（2）MVP産品可以使團隊大量減少因為開發錯誤功能而産生的成本與開支（時間成本、人員成本等）。

3. 注意的點：

（1）MVP産品是一個持續優化的過程，初期不要将眼光過多着眼于UI與體驗層面；

（2）MVP需要産品團隊将更多的精力花費用戶意見反饋搜集及數據分析上，并以此為依據進行版本的持續更疊。

二. 需求凍結原則

1. 該原則的含義

這個原則是我自己總結的，是因為在創業團隊裡雖然也有開發節奏把控和版本控制，但是經常性的會被上級或者老闆以一些有理或者無理的需求所強行打亂，逼得我變更需求，而開發團隊又是敢怒不敢言。所以這個“需求凍結原則”就是針對于公司内部喜歡頻繁變更需求所制定的。

需求凍結是指在需求評審會議結束之後直到産品新版本上線之前，對需求進行暫時性的凍結，不在此期間内接受新的需求。新提出的需求都需要統一延期到後續版本中去。

2. 該原則的意義

（1）對開發進行保護，避免因産品經理或其他人頻繁變更需求而導緻開發進度延期；

（2）提升團隊開發效率、對需求提出方進行約束、避免過多的需求擾亂開發節奏。

3. 注意的點：

需求凍結在實際中很難做到百分之百，你總會有那麼個别上級或老闆喜歡在上線前強行插需求，但凍結率至少應控制在90%以上，否則會擾亂開發節奏、而且讓開發感你的需求控制能力很差。

以下是提需求的過程中，可能需要注意的原則：

三. 數據導向原則

1. 該原則的含義

創業團隊内的每個成員都有提需求的權力，但是很多人會根據個人的主觀感覺提一些不重要或當前階段并不需要的需求。而每當這時，我都還需要花費一定的時間解釋這個需求為什麼不重要、為什麼不适合在當前版本做等等問題，時間長了還挺浪費我時間的。

所以我覺得團隊内部在提需求的時候，應當有一個數據導向的原則，提需求并不是憑空構想的過程，而是需要有具體的數據分析依據，根據數據分析出來的需求、才有可能是核心需求。在各種需求依據當中、總體的排序如下：

數據分析>用戶反饋>競品情況>先前經驗>個人構想

2. 該原則的意義

（1）這樣做的核心目的是為了降低開發錯誤需求的概率；

（2）讓全體成員都擁有數據意識，養成從數據角度看産品的習慣。

四. 需求統一管理原則

1. 該原則的含義

需求的管理其實并不是一件容易的事，因為需求的管理需要綜合考慮需求的來源、優先級、影響的範圍、帶來的收益、可能帶來的風險以及産品當前所處于的階段等等方面。而很多人在提需求的時候（尤其是老闆），總是認為自己的需求就是最重要的，而要求産品經理将自己所提出的需求進行插隊。

需求統一管理原則其實就是讓各個部門以及老闆知道：既然你們現在有産品經理，那麼你們所有人提出的需求都應該讓産品經理進行統一管理，讓他去排序優先級、決定做與不做，在這方面進行充分的授權。而非自以為是的要求産品經理按照你的要求一會做這個、一會做那個。

2. 該原則的意義

（1）給予産品人員更多的自主性與授權，提升産品人員對于産品的責任心與擔當；

（2）隻有維護産品人員的相對獨立性，才有可能做出更好的産品。

3. 注意的點：

産品人員也同時需要承擔需求錯誤、延期等問題以及所帶來的責任。

以下是需求評審中的一些原則：

五. 可行性先行原則

1. 該原則的含義

需求評審過程中，如果技術人員針對于某個産品需求提出了更便捷的實現方式，原則上尊重技術人員的意見，按照可行性先行原則進行。

2. 該原則的意義

可行性先行原則有利于提升開發團隊的效率，并且提升技術團隊的參與感與責任感。這個原則也與MVP原則是内在統一的。

六. 責任人定奪原則

1. 該原則的含義

在産品設計與開發的過程中，經常會出現可A可B的時候，各方也經常會為了證明到底是A對還是B更正确進行非常多的讨論。這個時候如果沒有具體的結論，應當遵循責任人定奪原則，比如宣傳頁面到底是藍色好、還是紅色好，這種問題發生争論的時候，最終應當交由設計師進行定奪。

比如交互方式到底是A好還是B好的時候，最終應當交由交互設計師去定奪。再比如一個需求到底做或者不做，最終也應當是産品經理發話。

2. 該原則的意義

（1）責任人定論的原則其實是對員工的一種授權與信任；

（2）責任人定奪的原則有利于讓專業的人在其專業的領域發揮更大作用。

3. 注意的點：

責任人定奪原則需要責任承認其定奪錯誤帶來的問題與責任，所以責任人定奪并非是亂授權、亂定奪。

以上就是我最近複盤所總結出來的産品從設計到開發上線中的一些基本原則，歡迎同行進行修正或補充。

#專欄作家#

旺仔九号，人人都是産品經理專欄作家。心理學碩士，一名奮鬥中的産品汪，緻力于将心理學與互聯網進行深度整合。

本文原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自 Pexels，基于 CC0 協議