產品辦理流程思考互聯網產品流程的碎片化

　　【無流程】是一個現實問題，或者說是一種趨勢。請記住：在那之前，你還有團隊、公司…

　　什么使得一款產品從0到1？

　　差別人而言，有紛歧樣的理解和篤定。如是說來，興致萬分，十分有趣。人們通常是先相信某種東西，而后再去找證據來證實本身的不雅觀點。

　　有人覺得，技術水平是一款產品的基礎條件；

　　有人相信，資金能力是一款產品的須要前提；

　　有人堅持，溝通技巧是一款產品的實現助力；

　　有人認為，人是一款產品的核心要素；

　　很多人，很多認為…

　　顯然，我是無法辯駁上訴的任何一條不雅觀點的，難道說技術、資金、溝通、人對軟件毫無裨益？然而，是否有維系全部產品要素的紐帶存在？

　　我相信，必然是存在的而且為大多數人所知。做產品以來，一直有人問我，你覺得對產品而言，很重要的是什么？坦白講，我的內心是抗拒的，產品自己就是一個復雜的綜合體不但得益于源于一個復雜的過程，豈論如何回答都無法達到一個平衡。

　　一、定義產品流程

　　產品辦理流程（Product Design Process）簡稱PDP，尤其不喜歡使用【項目辦理】這個詞，平時的工作中我很少提及，因為我覺得項目辦理傾向于專注項目自己，過分強調要害節點，輪廓很清楚。愚認為產品辦理是完全覆蓋項目的辦理的，而且用于項目辦理所不具備的優良特質，產品辦理是一個價值導向、有溫度的過程，不是錙銖必較，不是須臾推諉，不是憑空捏造…

　　1、瀑布模型

　　經典的軟件工程提倡采用線性的工作流方式，應用范圍很廣、很有名氣的莫過于——瀑布模型（waterfall model ），又被成為經典生命周期（classic life cycle）。

　　瀑布模型提出的是一個系統的、挨天線貓SEO軟件的的軟件開發方法，從用戶的需求規格說明開始，通過計劃、建模、構建和安排的過程，很終提供一個完整的軟件并提供持續的技術支持。

　　是不是是曾相識？似乎在哪見過？是的，該方法到目前未知，還有很多公司在遵循，暫且忽略一些毛病，該模型真的是經典之很，沒有之一。

　　由于現實的壓迫，實際的項目很少嚴格遵循瀑布模型的挨天線貓SEO軟件，因而后期對該模型做了不少改變，好比V模型、增量模型、原型開發模型。一些比較前衛的互聯網公司，大多采用了【增量過程模型】持續交付，各個公司依據本身公司的實際情況可能存在細節上的差異，但總體的思想是別無二致的。

　　2、SCRUM

　　現代軟件又提出了一個用于開發和維持復雜產品的框架 ——SCRUM，是一個增量的、迭代的開發過程。SCRUM的五個價值不雅觀：

　　承諾 – 愿意對目標做出承諾專注– 把你的心思和能力都用到你承諾的工作上去開放– Scrum 把項目中的一切開放給每個人看尊重– 每個人都有他獨特的配景和經驗勇氣– 有勇氣做出承諾，履行承諾，接受別人的尊重

　　假如你對SCRUM有所了解，其實就能知道SCRUM的兩個重要不雅觀點：靈敏開發、XP編程，讓其看起來更像是一個偏向于軟件開發的概念。

　　我認為，事實上確實是如此的，將開發人員前置需求、過程化是一個很有先見的做法。

　　當然，現實究竟是相對比較骨感的，對人員本質和團隊結構的要求都近乎嚴苛，而現在公司的人員簡直就是流水般順滑，因而采用SCRUM的產品辦理理念的團隊知之甚少。

　　二、回顧經典產品流程

　　古語有云：不以規矩，不可方圓。假如說沒有一個相對范式的產品流程，那么0到1的產品過程一定是不成言喻的，而其中的關系人更是苦不堪言、無意言表。或許這正是大多數產品死在路上的重要原因，大多數技術人員對產品人員印象很差的很初來源。

　　下述流程是一個經典的【瀑布模型+增量模型】的復合流程，其有兩個要害要點：一是流程的線性，二是執行的交叉。之前我已經在《產品經理必修課之產品設計流程[完整版]》一文中做了具體說明，下面將概述要害要點，不再贅述：

　　1、頂層設計需求分析：溝通、理解情境研究：需求調研的過程，包孕：用戶研究、調研，競品分析等；需求辦理：項目辦理技巧；2、概要設計需求建模功能建模流程設計原型設計：很多產品經理只對這個感愛好，而且占據了TA們的大多數工作時間；信息架構：信息架構（IA）是設計信息的組織結構；視覺設計：UI協同完成；3、技術追蹤項目追蹤：產品實現進程的管控，確保產品的定時按量上線；產品驗收：豈論理念還是業務邏輯設計上都是需要產品去把控的；4、回歸迭代實現偏差：技術實施過程中，一定有些需求因為現實的局限性被耽擱或者簡化實現，，那么上線后第一時間需要給出小幅優化的迭代完成之前研發階段的歷史遺留問題；反饋迭代：問題反饋通道建設對于一款新產品迭代優化初期顯得尤為重要，對產品快速增量式迭代及改善用戶體驗的重要都是不成估量的；