【無流程】是一個現(xiàn)實問題，或者說是一種趨勢。請記?。涸谀侵?，你還有團隊、公司…

什么使得一款產(chǎn)品從0到1？

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

有人覺得，技術(shù)水平是一款產(chǎn)品的基礎(chǔ)條件；

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

有人堅持，溝通技巧是一款產(chǎn)品的實現(xiàn)助力；

有人認為，人是一款產(chǎn)品的核心要素；

很多人，很多認為…

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

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

一、定義產(chǎn)品流程

產(chǎn)品辦理流程（Product Design Process）簡稱PDP，特別不喜歡使用【項目辦理】這個詞，平時的工作中我很少提及，因為我覺得項目辦理傾向于專注項目自己，過分強調(diào)關(guān)鍵節(jié)點，輪廓很清晰。愚認為產(chǎn)品辦理是完全覆蓋項目的辦理的，而且用于項目辦理所不具備的優(yōu)良特質(zhì)，產(chǎn)品辦理是一個價值導(dǎo)向、有溫度的過程，不是錙銖必較，不是須臾推諉，不是憑空捏造…

1、瀑布模型

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

瀑布模型提出的是一個系統(tǒng)的、挨次的的軟件開發(fā)方法，從用戶的需求規(guī)格說明開始，通過計劃、建模、構(gòu)建和安排的過程，最終提供一個完整的軟件并提供持續(xù)的技術(shù)支持。

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

由于現(xiàn)實的壓迫，實際的項目很少嚴格遵循瀑布模型的挨次，因而后期對該模型做了不少改變，好比V模型、增量模型、原型開發(fā)模型。一些比較前衛(wèi)的互聯(lián)網(wǎng)公司，大多采用了【增量過程模型】持續(xù)交付，各個公司依據(jù)本身公司的實際情況可能存在細節(jié)上的差異，但總體的思想是別無二致的。

2、SCRUM

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

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

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

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

當然，現(xiàn)實畢竟是相對比較骨感的，對人員本質(zhì)和團隊結(jié)構(gòu)的要求都近乎嚴苛，而現(xiàn)在公司的人員簡直就是流水般順滑，因而采用SCRUM的產(chǎn)品辦理理念的團隊知之甚少。

二、回顧經(jīng)典產(chǎn)品流程

古語有云：不以規(guī)矩，不可方圓。如果說沒有一個相對范式的產(chǎn)品流程，那么0到1的產(chǎn)品過程一定是不成言喻的，而其中的關(guān)系人更是苦不堪言、無意言表?；蛟S這正是大多數(shù)產(chǎn)品死在路上的重要原因，大多數(shù)技術(shù)人員對產(chǎn)品人員印象很差的最初來源。

下述流程是一個經(jīng)典的【瀑布模型+增量模型】的復(fù)合流程，其有兩個關(guān)鍵要點：一是流程的線性，二是執(zhí)行的交叉。之前我已經(jīng)在《產(chǎn)品經(jīng)理必修課之產(chǎn)品設(shè)計流程[完整版]》一文中做了詳細說明，下面將概述關(guān)鍵要點，不再贅述：

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

標簽：鹽城 九江 烏魯木齊 林芝 東營