長文 | 如何從0到1搭建產品(上篇)

說在前面

IT行業發展數年，其中出現了多種項目開發流程——瀑布式開發、迭代式開發、螺旋式開發、敏捷開發。將這些思想再細分下去還會有Scrum、XP、V模型等等。但很多時候，似乎在自家項目的開發流程中都能看到上述多種開發方式並存？

有這種情況自然是正常的，方法論只是指導工作的思想，上述的方法適用於某種特定場景下，舉例瀑布式開發。

某度詞條給瀑布式開發的定義：瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求分析、設計、編碼、集成、測試、維護的步驟順序進行。但在現實工作中，一般會採用這種開發流程的基本只有傳統IT行業或外包公司。然而，「不會再改需求」這句話是騙人的，你甲方粑粑終歸是你粑粑。(逃

敏捷類開發演變了那麼多形態，也不是完全適用各種場景。整個互聯網行業都小跑前進，而這些方法論的演變速度似乎已經跟不上了。對於這些方法論我的建議就是吸取部分適用於項目實際情況的，放棄那些看上去有用但實際上並沒有什麼軟用的部分，不要做完完全全的「拿來主義」。

就像敏捷開發最核心的思想——擁抱變化。

項目流程

下面筆者將會總結一套可塑性比較強的工作流程。

整體流程

1、前期調研

1.1市場調研

閉門造車總歸是不對的，在決定怎麼做之前先搞清楚為什麼要這麼去做，如果你或者其它決策者覺得自己經驗豐富，比較喜歡通過「拍腦袋」這種方式來決定一件事情，那筆者建議三思後行。關於市場調研，主要考察的是個大環境情況，在整個前期調研階段多和市場和運營人員以及其它業務相關人員溝通(如果有的話)。

WHY TO DO > HOW TO DO

主要介紹兩種分析法——PEST和SWOT。

PEST)

PEST 是一種宏觀環境分析模型，所謂PEST，即 Political（政治）， Economic（經濟）, Social（社會） and Technological（科技），從四個維度分析大環境。

PEST四象限

政治環境

政治環境包括一個國家的社會制度，政府的方針、政策、法令等。不同的國家有著不同的社會性質，不同的社會制度對組織活動有著不同的限制和要求。即使社會制度不變的同一國家，在不同時期，由於執政黨的不同，其政府的方針特點、政策傾向對組織活動的態度和影響也是不斷變化的。

比如近期的如火如荼的，和區塊鏈經濟相關的ICO（Initial Crypto-Token Offerings，首次公開加密代幣發行)。9月4日，央行、網信辦、工信部、工商總局、銀監會、證監會、保監會等七部門聯手叫停ICO融資。

監管部門將ICO定性為「非法公開融資」並且一刀切，根本不留餘地。這次法令出台似乎是猝不及防，但「韭菜們」卻是真的要被一刀割完了，誰都不信自己是接盤的那個。事實上，ICO在發行代幣這個環節使用了部分區塊鏈技術，而這部分連區塊鏈的1%都占不到。

韭菜，是等不到花開的時候。

圖片來自網路

經濟環境

經濟環境主要包括宏觀和微觀兩個方面的內容。

宏觀經濟環境主要指一個國家的人口數量及其增長趨勢，國民收入、國民生產總值及其變化情況以及通過這些指標能夠反映的國民經濟發展水平和發展速度。

微觀經濟環境主要指企業所在地區或所服務地區的消費者的收入水平、消費偏好、儲蓄情況、就業程度等因素。這些因素直接決定著企業目前及未來的市場大小。

「消費升級」一直都不是新鮮概念，這個過程是持續的。舉個老套的例子，從改革開發以來穿衣要保暖，都後邊要時尚，再到現在的個性化搭配和定製，能很明顯感受經濟發展帶來的變化。從x寶、x東到xx有品、xx優品、xx優選，電商越來越垂直，蛋糕分到後面變成了分裱花。

社會環境

社會文化環境包括一個國家或地區的居民教育程度和文化水平、宗教信仰、風俗習慣、審美觀點、價值觀念等。

宗教信仰和風俗習慣會禁止或抵制某些活動的進行。前陣子某團的「清真箱」事件已經達到了一定的影響力，其實在大學城的食堂都會有清真窗口，大家都習以為常，56個名族都是一家人，相互諒解下還是正常的，不要再說「56個名族，55個VIP」這種騷話了，咳~。

也許這次事件的始作俑者可能不太能接受同胞有特殊待遇，想搞事情，又也許是隨口一說引發的輿論熱潮，誰知道呢？不過讓人深思的是某團公關處理危機的效率相較於其它同行是不是有那麼點

慢了？

相似事件，圖片來自網路

科技環境

科技環境除了要考察與企業所處領域的活動直接相關的技術手段的發展變化外，還應及時了解國家或者地方對該領域的扶持情況。雖然有技術專利這麼一說，但產品同質化的現象依舊阻擋不住，互聯網史上「百團大戰」的情況不只是歷史，現在依舊在發生，未來也規避不了。上面講到的也是政策對科技環境的影響。

外部大環境看起來容易分析，但要想深入研究，怕是有點難度，影響大環境的因素太多，需要一個專業的市場分析團隊來分析，尤其是數據來源的不確定性，數據被污染等干擾的情況。

比如下面TalkingData2016年移動遊戲行業白皮書顯示，雲貴疆(川)地區用戶付費情況相對較高。

TalkingData2016移動遊戲行業白皮書

Exm？是不是很不科學，為什麼APA(ActivePayment Account 活躍付費用戶數)反而是西北內陸地區高於江浙滬等沿海城市？講道理，不是黑，拋開經濟狀況不談，沿海地區人口數都要遠高於內陸地區，難不成是這個數據源被污染了？

圖片來自網路

嘿嘿~，如果你經歷過二十一世紀初「斯凱王朝」的崛起，或者對那個時期的故事略有耳聞，那你可能會知道其中的緣由。這是題外話，也不能亂寫，不然會被利益相關者吊起來點天燈的。

大環境的因素大多屬於不可抗力，除非你的項目帶來的影響力已經能達到一定規模，這是後話不展開。而下面的SWOT分析法則主要切入企業內部，分析自家企業內部狀況，做到揚長避短。

SWOT)

SWOT即S（strengths）是優勢、W（weaknesses）是劣勢，O（opportunities）是機會、T（threats）是威脅。清晰地把握全局，分析自己在資源方面的優勢與劣勢，把握環境提供的機會，防範可能存在的風險與威脅。這是SWOT分析法的目標所在

SWOT四象限

談及自家產品的優勢，很多產品負責人會說出一長串引以為豪的論點，但對於一個從0到1的產品，似乎優勢就很有限。沒有數據來支撐好看的dashboard，也沒有什麼產品壁壘一說，核心競爭力似乎只能是團隊或企業的背景、人脈、渠道以及其他隱性的資源優勢。

而劣勢就相對更可見一點。團隊人力資源短缺，團隊沒有相關經驗，資金預算短缺，數據孤島現象嚴重等等。所以一個創業團隊，或者企業內部孵化新項目所要經歷的都是重重困難，一個產品從demo到release也許靠著開發團隊可以正常上線，但在上線之後想要發展起來，外界條件是非常重要的。

這時候就要把握好機會(opportunities)，應對各種威脅(threats)。

機會這種東西可遇不可求。馬雲認為，生意難做的時候才能誕生了不起的企業和企業家。話是這麼說，但馬雲只有這麼一個。大家在日常工作中將各種細節親歷躬行，努力將所有事情做到最好，不就是為了減少運氣在創業成功中所佔的比例么？

關於威脅(threats)這點可能用詞言重了，正確的解讀應該是外界的不利因素，或者挑戰。VR/AR在前幾年被炒作的要上天了，但行業冷靜下來後不還是一地雞毛，歸納下，大致原因有如下幾點：

1.VR/AR成本較高，還沒有達到消費級產品的價值(谷歌Cardboard那樣的紙板真的不能叫VR...)

2.行業生態還很雛形，下游的相關服務性質的產業還不能撐起客觀的市場規模

3.相關從業者藉助媒體炒作風口，妄想把產品從to c到to vc。關於這點各領域的都有這種現象，典型的就是互金。

分析完這大環境和企業內部的情況，該來分析下友商的產品了。

1.2競品分析

部分產品按照服務受眾分to C和to B，兩種產品的側重點全然不同。前者注重用戶需求和體驗，出發點就是解決用戶的需求，實現商業價值，所以用戶才是爸爸。而後者基本都是工具型產品，為了解決業務需求，提高工作效率，出發點就是商業價值。

to B的產品如果沒有相關從業經歷，可能會無從下手，因為to B類產品的業務邏輯錯綜複雜，沒有經歷過一個成熟產品的搭建設計，想要開始規劃會有些難度。這時候，你可以嘗試下搜索市面上是否已經有此類to B的產品服務，一些ERP、CRM或其它SaaS，都會有Demo可以體驗試用。也可以找這類產品的客服或者商務要求體驗下產品，甚至索取使用說明書。如果這類產品服務掌握在少數企業手裡，而你所在公司有這個業務，那筆者的認知也沒法幫助到你了。

而to C的產品基本都是可以接觸到的，可以從用戶體驗五要素來分析，即

戰略層 --> 範圍層 --> 結構層 --> 框架層 --> 視覺層

圖片來自網路，用戶體驗五要素

其中戰略層基本只能靠揣摩和推測，在上述分析外部環境的時候就一起研究，結合整個大環境來分析。一個企業的戰略方針，保密級別必定是S級的。企業通過各種媒體渠道發布的內容都得經過包裝，如果將老底全盤托出，那競爭對手就會調整戰略，對其進行針對性的打壓。除了上市公司Qn財報的數字相對可信，其它的新聞發布會之類的真的只能聽聽，這種真假參半的訊息如果當真的拿來分析，那勢必會造成分析結果的不準確。

關於用戶需求和商業需求的權衡，這點眾說紛紜。產品崗的面試的時候也總被問到用戶利益和商業利益取捨，這個問題仁者見仁，智者見智了。

範圍層，介紹該產品所包含的功能範圍，簡而言之就是用戶能通過產品能做哪些事情。在項目早期會議中，一個產品的核心功能就被決定了，產品無論日後迭代成什麼樣子，它的核心功能是不會變的。如果產品經過大改動或者乾脆研發了新產品，這可能是產品盈利出現了大問題，要麼乾脆換人接盤了。

從框架-結構-視覺，這三層基本會混在一起拿來分析，像流程進行中的交互體驗，一個頁面上承載的信息量和整體信息架構，是沒法完全拆解開來分析。

舉個栗子。

在移動端做一個用戶信息填寫的表單，一份單頁的長表單可能會造成用戶認知壓力，這時候就會把表單拆解成多個頁面，並且控制每個頁面的信息量。

單頁—>多頁

而這頁表單的切換方式設計貼近自然交互的劃頁效果，相伴而生的是整個界面輕柔的風格。

載入—>劃頁

為了加強多個頁面的相關性，將一些元素在多個頁面復用，並在頁面流轉時體現出來。在底部加上進度條，告知用戶他處在哪個階段，類比web上的麵包屑。

元素關聯

初步眼動測試發現表單文字的位置沒有思考到位，導致視覺移動路徑過於崎嶇，並且發現導航效果過於明顯，干擾了用戶使用，決定弱化導航。

優化調整

最後，還要做一輪「減法」，去掉沒必要存在的元素，減少信息干擾。

圖片來自網路

所以哪怕一個小小的表單，也會有UED團隊的反覆斟酌，從框架到結構再到視覺，都是無法分離的，用研、IxD和GUI設計師還有產品經理需要相互協作，還有需求提出人也需要介入其中的過程，不然到最後可能就變成丁公鑿井了。

丁公原話：吾穿井得一人

翻譯：我要挖井，需要一個人幫忙。

路人版：丁公挖井，挖出一個人。

光靠流水線式工作，交付文檔和設計稿，能對接成功就有鬼了。

1.3用戶用例

用例全寫Use Case，標題是硬湊四個字的，怎麼翻譯就不去深究了，原意是基於多場景的，有目標序列的行為交互。對於新加入項目的同學，看UML用例圖是最快能理解項目業務的方式。在實際工作中，可能有的同學會覺得多泳道的流程圖已經把業務流程講的很詳細了，再多個UC圖會贅述，浪費時間。但實際上，UC在產品需求整理前期可以更清晰的理順思路，尤其是需求還沒有確認下來的時候，一份簡單的UC和項目成員溝通可以節約更多成本。

還有一點要注意的是use case和use story的區別。引用下一位同行的解釋。

從概念上，用例包括了業務用例和系統用例。user story更多的是一種業務用例，而軟需描述的更多的是系統用例。從粒度上，userstory的粒度特別是在敏捷開發的時候往往比用例的粒度更細化。用例中的基本流，擴展流，業務規則都可能是轉換為userstory。從層面上，user story更加關注業務場景和用戶故事，更加偏向於用戶能夠理解或看懂的內容。user story是能夠產生核心業務價值的單位。業務用例能夠達到這目的，但是系統用例就不一定了。從詳細程度看，user story偏用戶需求或業務場景，重點把業務需求和場景說清楚即可，比較簡單。而用例建模比較複雜，涉及業務流程，業務規則，輸入，輸出，界面，交互等各個方面的內容。

如果一個產品的用戶類型過多，或者產品功能過多，則切忌只在一張用例圖上繪製，這時候可以選擇按照幾個維度來劃分：功能，場景，角色。不然用例出來會和蜘蛛網一樣混亂，讓人沒法閱讀。

正確示範，圖片來自網路

上述三點前期調研分析，都是同步進行的，從一各不經意的點子到著手實現一個demo或分析市場，都沒有前後之分。其實在這個時候，整個產品的布局已經躍然紙上了，接下來要做的就是細化細節，這也是大多數產品經理和需求分析師主要工作內容。

2、需求分析

2.1業務邏輯

在一個小團隊或創業公司，需求可能直接來自老闆或項目經理，這類需求都是二次需求，需要你在聽取需求後思考背後的目的。就如本文開頭所說一樣，在決定怎麼做之前先搞清楚為什麼要這麼去做，不然跟著一起遭罪的還有團隊成員，需求總是改動對士氣影響很大。

WHY TO DO > HOW TO DO

用戶用例簡述了參與業務的角色，以及發生這些業務的場景，接下來就要細化各個業務的流程了。C端產品的早期，業務邏輯梳理起來不會過於複雜，但用戶的需求，需要不停地去揣摩和研究；而B端產品的需求則會很明確，產品所需要的功能都很清晰，其業務邏輯相對C端產品會來的複雜。一般創業團隊在測試市場對產品的接受程度或者驗證商業模式的時候，會設計開發一個MVP版本的產品投放市場，或者其它非產品化手段。

舉例滴滴打人

滴滴打人業務邏輯

滴滴打人app作為平台其核心功能就是連接打手和用戶，收取中介費盈利。產品經理需要考慮這個訂單需要提供哪些信息才能讓打手找到目標，打手競標的機制該怎麼設計，什麼樣的情況打手才算完成任務，用戶是先付款還是後付款。每個功能節點的業務需要細化，設計不同場景下的邏輯處理。

2.2商業&用戶需求

這兩點是大多數C端產品糾結的地方，權衡商業需求和用戶需求。舉個栗子，還是滴滴打人

從需求源頭上來分析，用戶因為個人情感經濟糾紛，或者別的情況需要「教育」下對方，因為自己身體素質不行或者沒有時間，也可能因為找不到對方，所以需要求助專業人士來處理。這裡的需求是接到提案時初步分析的，再用馬斯洛需求金字塔來分析需求的層次。

這裡假設用戶小明因為小白欠債不還，決定使用滴滴打人來要回這筆錢。

從底層需求來開始講，小白欠了小明錢不還，小明打電話催促了好多次但無果，於是很憤怒，智商瞬間為負數，決定報復對方，獲得快感；但小明因為自己塊頭太小，琢磨下不是人高馬大的小白的對手，處於保護自己，他決定思考別的方法；欠債還錢是社會基本規則，小白不還錢似乎顯得自己很窩囊，好欺負；再往上走，對自我價值的實現，似乎解釋不通了。

馬斯洛需求金字塔

各位觀眾老爺看到這裡一定覺得拿筆者拿滴滴打人作為例子顯得很蠢，但現實生活中相關產業已經發展的不錯了，甚至有的還能拿的上檯面。頭幾年互聯網金融中的P2P相較於傳統的金融企業像銀行和其它小額借貸機構，它的放貸要求的很寬鬆，比如你向某互金A公司借錢，A公司的業務員只要是你拿出其它同行的借貸證明就能放貸，如此不謹慎的風控機製造成了居高不下的壞賬率，也催生了下游催債的行業的發展，某些討債公司甚至已經掛牌新三板了，也算是「上市」公司了。

繼續回到這個假設。

產品解決了用戶的需求，還得讓自己活下去，這就是商業需求。作為中介平台，幫助小明追回債務，讓打手賺到了錢，自然是要收取手續費了。在這之後，向打手推薦專業的培訓服務、通過大數據定位目標位置、分析目標用戶畫像等等面向打手的增值服務，也是需要思考的。一個產品可實現的商業模式還得視產品形態而定，有些產品想要商業化頗有難度，工具類產品如何變現自古以來就是個痛點，行業內有兩個典型的例子——墨跡天氣和美圖。天氣似乎一項高頻且剛性的需求，據去年招股書顯示，墨跡天氣坐擁4.7億裝機量和3000萬+的日活，年營收還不到兩億，這凈利潤更是少得可憐。而美圖，雖然一直都在虧損狀態，但整體一直處於上升期，財報顯示，美圖公司2016年總收益15.786億人民幣，同比增長112.8%，2017年1月美圖月活總數約5.2億，同比增長約32%。雖然美圖致力於硬體製造，但這其中的差距也有很大一部分來自軟體產品本身。

關於兩家公司的比對，網路上不乏出色的文章講解，各位觀眾老爺可以自行搜索。

強忍著掏出原型設計工具的衝動，冷靜的分析一波需求，這時候你會發現，一開始接到這個提案所迸發出的那些「靈感」，似乎有些那麼不成熟。

上半篇文章到這裡就結束了，下半篇將會講述如何向團隊輸出需求，推動項目落地，以及如何應對一些小小的「突發情況」。

我們下次再見

搜索公眾號：老楊陪你來說事兒