轉自：https://blog.csdn.net/u012562943/article/details/53482864
前言
如果沒有做過開發,研發過產品的人,很難體會做產品的艱難,剛進公司的人,一般充當的是程序開發,我這里說的是開發,它與研發是有區別的.
一個需求下來,如果不能很好地理解產品需求，如果不能很好的駕馭需求實現的邏輯,肆意的根據理解去做技術方面的架構和編碼，等到后來發現了不對了再去修改就特別麻煩。
所以我們在實現產品需求時,每一個功能需求,不管是大還是小,都要想商量清楚了,我們在采取編碼.
言歸正轉,那么整個過程一款產品從想法-開發-上線-產品都經歷了哪些?
希望能給大家一個好的借鑒作用,總結的不好的,希望給予指正,大家可以暢所欲言.
主要分為以下幾步
第一步：需求梳理、分析
第二步：產品原型圖繪制
第三步：UI設計
第四步：項目經理&技術負責人對接需求
第五步：技術方案 & 架構設計
第六步：項目排期 & 任務分解
第七步：產品研發階段
第八步：交付測試階段
第九步:產品發布上線
第十步:迭代
下面我們來看看具體操作:
第一步：需求梳理、分析
在此假設用戶需求分析已經確定 , 接下來根據提煉的真實用戶需求來確定產品需求。
產品經理將會根據溝通中的相關資料的word、ppt、jpg等等東西翻譯成邏輯語言，最簡單的就是產出一張產品功能腦圖或者一份功能列表。 
▲產品功能腦圖 
▲一份功能列表
初步產品功能需求梳理清楚之后，產品經理持續跟進，反復溝通確定產品原型圖。
▲產品原型圖
同時根據具體的項目需求，會搭配一套產品業務流程圖 
▲產品業務流程的圖
簡單點，用墨刀做一份帶交互的原型。這個很重要,只有交互原型圖上的邏輯跑通了,代碼的邏輯差不多也通了,這樣能節省很多時間,需求上說的跟實際上做的還是有很大區別的,有時間,需求聽起來是很有道理,但是用技術幾乎實現不了. 
▲墨刀帶交互的原型
第三步：UI設計
UI設計，包含風格稿和內頁設計。
風格稿會根據產品需求提供的目標用戶類型、客戶傾向、LOGO等信息，以及確定做風格稿的2-3個頁面的原型圖，來進行風格稿設計。
待風格稿確認后進行內頁設計，包括設計效果、頁面元素、彈出頁面等等 
▲風格稿
▲風格稿
所有頁面設計完后會統一發給客戶做進一步溝通，然后統一修改優化。
▲Zeplin
Zeplin能夠幫助前端更好地理解設計師意圖，而設計師又能快速得到前端反饋的協作，從而減少設計師與前端的溝通錯位，使得兩者在“界面元素”和“交互動作”上形成一致。 
▲Zeplin
invision用於設計先行能減少后端技術工程問題，設計的迭代越快，軟件開發就越能在時間點的把控上做到極簡。 
▲invision
設計定稿后並不是設計師的工作結束了，之后還有一段周期的切圖、標注工作 。 
▲標注 
▲切圖
第四步：項目經理&技術負責人對接需求
項目經理對接上這些需求，第一個工作是細化需求，將這些翻譯成技術能更好理解地語言，搭配着原型圖或設計稿來召開技術會議，統一講解新項目的需求。 
▲細化需求
第五步：技術方案 & 架構設計
技術負責人在清楚了解整個項目的需求之后會開始構思整個項目的技術方案，根據產品需求，提供易擴展、可持續迭代的技術框架方案。 
▲整個項目的技術方案(需求文檔) 
▲可持續迭代的技術框架方案
第六步：項目排期 & 任務分解
同時，項目經理在和研發團隊溝通確認后對項目進行分解以及排期，以此來保證項目進度和質量。
▲項目管理
第七步：產品研發階段
這個階段就是各端技術按照排期規划開始編碼，期間各種對接、調試以及撕逼。我不是程序猿，這塊就不多寫了，貼幾張他們技術wiki的截圖吧。
▲Wiki對接
Paw 讓測試 API 變得輕松愉悅，可以構建內部和外部的資源。它可以在不同的環境下進行測試，也可以引用來自其他請求響應的數據。 
▲PAW
它可以定義不同的環境，於是可以輕松地在開發、臨時和生產環境中進行切換，而無需重新配置任何端點（endpoint）。並且還可以在一個請求的消息體中引用另一個請求中返回的值，這能夠節省大量時間。
第八步：交付測試階段
測試工程師基本全程跟進，從最早期對接完詳細產品需求之后就開始編寫測試用例 
▲測試用例
然后配合項目各個里程碑節點進行功能測試和性能測試，將問題按優先級划分統一反饋 
▲測試過程
第九步:上線
以上均是理想情況下，一個App必經的幾個階段的簡潔步驟說明，具體執行依然會根據需求穿插進行。
不同的項目管理模式或許會有完全不同的流程步驟。但是專業性幾乎是保證產品質量的唯一准則。
第十步:產品迭代
每次要根據用戶反應的問題和增加的功能需求進行產品迭代 