庖丁開發：專注于互聯網項目開發
前面我發過產品從發現需求到上線整個開發流程的文章，由于激烈額競爭和市場迅速的變化，幾乎所有的團隊在開發這塊都采用了敏捷開發模式，今天就來跟大家詳細聊聊這種開發模式到底是什么樣的。
什么是敏捷開發？
在這之前，簡單說說另一種常見模式：瀑布流模式。它是以文檔為驅動，在整個開發過程中，開發人員根據需求文檔進行開發，一切以文檔為依據。
而敏捷開發則是一種以人為核心、迭代、循序漸進的開發方法。它不是一門技術，它是一種開發方法，也就是一種軟件開發的流程，它會指導我們用規定的環節去一步一步完成項目的開發；而這種開發方式的主要驅動核心是人，注重的是人與人之間，面對面的交流，它只寫有必要的文檔，或盡量少寫文檔，采用的是迭代式開發，適用于以下情況：
適用于軟件，因為軟件是軟的，可以改。要是硬件，改起來就沒那么方便了；
適用于客戶不知道自己要啥的情況，這樣的客戶占絕大多數。因為客戶不知道要啥，所以你需要不斷幫客戶弄明白他到底想要啥。換句話說，你需要和客戶溝通，合作，傾聽反饋，持續改進；
適用于競爭激烈的市場，這樣的情況下，趕在競爭對手前交付一個不完美但至少能用的產品非常重要；
適用于快速變化的市場，你在埋頭造一輛汽車的時候，客戶已經想開飛機滿天飛了，這就需要你能一步步的把汽車改成飛機，還能按時交付；
適用于在一個地方辦公的小團隊，一般 10 個人以內。這樣能使敏捷中主要的溝通方式「Face to Face」是可行的。
敏捷開發的過程與分工
敏捷開發的過程主要通過產品范圍內迭代內容和周期的確認，規劃合理的迭代范圍，安排各崗位人員分步驟協同工作，通過開發過程中的任務項的快速跟進和漸進明細原則，保證資源的平衡和工作效率的最大化。
丨前期（前1/4時間）
由產品經理驅動，訂制公司產品戰略，從而進行需求的采集與確定，根據競品分析以及用戶調研，進行產品原型的制作以及產品需求文檔的撰寫，在這個過程中，需要與項目經理進行評審，了解產品的開發難度以及可行性，從而對產品需求以及原型圖進行合適地調整。
丨中期（1/4時間）
由 UE 完善產品原型的交互細節，有關頁面的跳轉等用戶體驗做到極致，然后由 UI 設計師進行界面的設計美化，及時與產品經理進行溝通，設計出與產品經理所想要的效果出來，結合自身的設計理念和技術，將界面設計得人性化、扁平化。
丨后期（1/2時間）
由開發人員進行產品具體的功能設計開發，根據項目進度安排時間，做好工作安排，認真查看設計圖以及原型圖、產品需求不懂，不清楚的地方及時與產品經理進行溝通，以免辛苦做出的功能與產品的意思不符，造成浪費時間精力的后果，產品進行開發完成后，由測試人員根據測試用例進行測試，將出現的問題進行反饋，及時修復產品的 bug，確保產品在規定的時間進行上線。
了解了這個流程，就容易解釋為什么一旦產品出現問題，產品就成為當之無愧的背鍋俠，事實上，這怨不得其他人，好比造房子，產品的工作類似打地基，地基不好，房子會塌，房子塌了怪誰，地基打得不好，當然是產品。
所以在工作中產品經理特別需要注意以下三個要點：
丨全程參與
前期的產品戰略以及需求，產品經理都是參與其中的。特別是大的產品方向突出的功能點，你都必須全局進行了解。對公司的戰略方向是否匹配，之后在產品的開發以及以后產品的迭代是否難度太大；這些問題一定要想清楚，不懂的就問，不斷地進行評審深入下去。因為一旦進入開發階段，突然變更需求，那么這段時間的精力以及時間就浪費了，這對于公司的損傷是巨大的。
丨勤寫文檔
一個人的記憶不可能會記住所有的東西，所以你必須記錄下來，這樣能更好地開展工作，在寫需求文檔的時候，我們需要要對每個用詞定義緊摳，少用差不多、不確定等用詞來模糊定義，千萬不要以為需求文檔開發不看，只看設計圖，起碼測試是需要根據你的需求文檔寫測試用例的，所以需要慎重對待。
丨做好評審記錄
在評審的過程中，與項目經理進行評審后，記得做記錄。哪些功能要做，哪些功能不錯；什么時間開始，什么時間結束，這些都做好記錄。
在互聯網時代，使用敏捷開發模式可以讓產品在市場上快速試錯，根據數據的反饋進行及時的戰略調整，讓產品在市場立于不敗之地，而在這個模式中，產品經理無疑是最重要的一個角色。最后用敏捷開發的 slogan 來總結它的幾個特點吧：
「個體與交互」勝過「過程與工具」
「可以工作的軟件」勝過「面面俱到的文擋」
「客戶協作」勝過「合同談判」
「響應變化」勝過「遵循計劃」
