品牌行銷策略，產品行銷與設計，各類型行銷推廣案例分享-品牌行銷點點讚
編輯導讀：數字化是許多企業未來的發展趨勢，但是如何實現數字化，這是產品經理需要解決的問題。本文作者根據自己主導的一個實體企業全鏈路數字化開發項目，總結了方案設計、團隊、項目管理三部分的經驗，與你分享。
今年年中，筆者主導一個實體企業全鏈路數字化開發項目。項目功能涵蓋了9大模塊，140+功能項，需求文檔將近4萬字，共150頁。作為整個項目的負責人，針對項目中業務需求溝通，產品設計方案，團隊配合和整體項目管理，總結了些許實戰實踐經驗，分享給大家。
如果你是B端產品經理或項目經理，歡迎一起討論交流；如果你是傳統行業CIO或老板，有計劃或者也在做數字化升級項目，多了解數字化項目，或許對您也是有幫助的。
項目背景：
我們為國內知名家居品牌提供用戶全鏈路業務數字化業務定制開發。目的是將用戶的所有觸點，從接觸，銷售跟進，踢單成交以及交付后全部的服務和業務流程實現數字化，以此提升用戶體驗，提升全鏈路業務效率。
一、關于方案設計
1. 窮盡拆解低耦合：復雜邏輯的處理原則
對于復雜的產品項目，從業務流程梳理-抽象設計方案-邏輯流程梳理-交互細節設計-部分底層框架的設計，對產品經理來說是非常考驗大腦的思考力，(當然邏輯能力是基礎)。
尤其是鏈路較長，涉及條件較多的邏輯，在梳理方案時候，需要做到”持續思考力“（雖然這聽上去像是一句廢話）。但是我相信有很多產品經理都會遇到有方案瓶頸但是中斷的情況。
中斷思考等于前面做的思考全部作廢，還需要再重新梳理邏輯，低效率且低效果。如何減少這種情況呢？可以試試窮盡拆解法（有點類似金字塔模型的MECY分析法）。
在做復雜邏輯梳理+需要做設計方案決策時，有時候困住你的可能是設計決策，或者是邏輯本身。可能你想直接找到答案，但是此時效率最高的方案是將所有的情況全部可視化梳理出來，將所有有關聯的維度因素梳理出來，交叉確定每個邏輯，或許解決方案會自然出現。
舉個例子，我們有一個業務流程有9個關鍵業務節點；每個節點有多個條件判斷并且有正負邏輯的流轉；同時這9個業務節點有三種不同類型的業務主體。
在處理這種方案時，如果不獨立拆解到最小顆粒度，很容易遺漏邏輯或設計出耦合的方案。對方案的靈活性帶來很大的影響。高內聚低耦合，是系統設計的基本原則。
我們的方案是，把全部的邏輯（哪怕有重復的流程）用流程圖的形式全部可視化展示出來，整個邏輯一下明朗起來。
2. 設計工具：服務藍圖
服務藍圖是服務設計師常用的工具，在數字化項目，涉及到多端交互且有關聯的流程時，非常適合確定主業務的服務流程；確定服務流程后，再深入到交互，邏輯，以及架構設計。
用戶旅程地圖是用戶體驗設計經常用到的設計工具，服務藍圖是服務設計領域常用的設計工具。我將二者做了簡單的合并，以用戶和一線人員的交互為主線，找到服務流程中的設計關鍵的點，針對關鍵觸點，圍繞”用戶體驗和”銷售效率提供解決方案。
3. 設計陷阱：客戶提供解決方案還是需求？
警惕方案設計陷阱：用戶調研獲取需求過程中，始終理性分辨：客戶提供的到底是解決方案還是需求？（很多客戶都喜歡給解決方案😎）同時設計師要警惕大腦中的“第一自然方案”，而是通過用戶的表達了解他的需求場景是什么？他的核心訴求是什么？如何能滿足？不斷深入分析尋求最合適的方案。
B端產品經理和c端產品的工作流和能力要求有些差別，但是對業務調研和需求了解的過程中，我認為都是一致的。充分的了解客戶的最終訴求，用專業的解決方案滿足。
我們的整個項目圍繞銷售數字化，用戶體驗數字化，用戶服務數字化“來進行。在銷售數字化過程中，我們為銷售提供了一個專門服務客戶的小程序。當時在探討提升銷售效率的方案時，銷售提到了一個場景，希望我們做一個微商城小程序，這樣每個商品都可以直接購買。
這個客戶的用戶購買模型屬于購買客單價較高（平均2萬元），購買決策周期較久（大概在2周-3個月不等），在和銷售人員溝通的過程中，他們提到，前過用戶的產品購買路徑可視化的功能很好，但是希望在最后踢單和成交階段也可以在小程序內完成，所以希望可以把這個小程序做成一個微商城小程序。
其實這個方案和我的第一直覺方案很契合，在考慮解決方案的時候，也自然的順著這個思路在深入設計方案。但是在深入設計場景時，隱隱感覺哪里不對。
首先我意識到，如果我按照客戶的建議做成一個簡單粗暴的微商城小程序，那么針對購買需要做很多完整的鏈路功能才能形成閉環，因為社區零售等行業的購買模型和運營模型與他們完全不同；另外我突然意識到，用戶提出的并不是需求，而是解決方案，我們需要繼續深挖，了解用戶本后的需求本質到底是什么。
方案卡殼，可以進行用戶訪談，尋找購買的關鍵決策因素；與一線使用人員進行訪談，尋找業務流程痛點；
此時可以通過調研后，梳理出服務藍圖， 用戶服務藍圖，以用戶為中心，將服務業務全鏈路可視化展示，有助于設計方案。（關于用戶服務體驗藍圖有多好用以及如何使用，后面會專門找一篇文章來寫。）
通過用戶服務旅程圖+服務藍圖工具，和銷售人員一起，將用戶接觸后的流程梳理出來，解決方案豁然開朗。
因為客戶成交的特殊性，用戶的購買決策影響因素有兩個，一個是花色（客戶是家居產品），另一個是價格。而在家居行業 ，一般踢單的形式有兩種，一種的膨脹優惠券，一種是膨脹定金。
在導購的銷售流程中，如何和用戶發起溝通，如何推動抓到了這兩個關鍵點，我們一起確定了功能簡單，閉環鏈路短，以及靈活滿足需求的功能。
我們并沒有簡單做一個連鎖微商城的小程序，而是為銷售在智能導購功能的基礎上，提供了收訂金，以及一對一推送優惠券的功能。并且提供了商品卡片，可以靈活的配置商品卡片，以及用戶的操作路徑可視化，并實時給銷售發通知，收取的訂金還能直接轉化為后續訂單中的預售款。收取訂金的金額由銷售主導，并且支持設置付款后實際抵扣的金額。
用這種形式，最大自由度的滿足了銷售踢單和鎖客的最后一步。而這種解決方案也非常滿意。
整個方案的開發成本很低，滿足的場景足夠靈活。而如果一開始根據銷售的建議，或者根據直覺方案做一個商城小程序，需要做很多額外的功能才能滿足自由靈活的銷售流程。
4. 利其器：好用的工具和表格
我們提供給技術人員的文檔是PRD+交互圖，PRD文檔中很好用的工具有幾種：
- 關于角色權限表格 針對特定身份的人擁有不同的操作權限。用表格的形式，開發同學在實現時候，可以很清晰記錄技術方案；
- 列表狀態-操作表格 后臺系統列表的管理頁面非常多；對于復雜的列表，狀態對應操作最好的表述方式也是以表格的形式展示。針對每一個操作需要再逐一說明流程；
- 業務流程圖 業務流程圖是幫助開發同學整體了解工作流，處理好判斷條件和對應條件的處理方式，可以更好的理解項目業務，提高開發效率。
5. 細節至上：需求管理中需要注意的TIPS
1）冗余還是關聯？
B端產品設計時，很多數據庫字段是技術同學設計數據庫時非常關心的部分。多個數據庫表存在時，有時候技術會直接利用關聯表進行數據查詢。但是對一些記錄型的功能頁面內。數據需要冗余記錄，不能實時連表查詢。這個細節需要標清楚。
常見的冗余數據，例如訂單信息，用戶改了手機號，或者商品后續改了名稱，訂單內的信息不會實時更新；結算信息，不會因為商品改了價格而實時更改結算數據等。
關聯數據例如用戶的頭像，如果用戶更換了頭像我們在會員的微信卡上的頭像也會隨時的更換。工作人員的手機號進行了更改，會員聯系導購時也需要最新的數據等。
2）隱形的數據處理規則
很多時候技術很容易根據需求和交互中的字段來設計數據庫，但是有一些關鍵的數據可能并不會直接填寫在頁面上，但是是非常重要的數據。
常見的比如創建時間，創建人，更新時間，更新操作人等，若不標志清楚，經驗少的技術人員很有可能會出現后續需要找數據時，數據庫沒有記錄某些關鍵數據的情況。數據庫關鍵字段和頁面字段之間的gap，需要產品經理提前梳理好并標清楚。
3）復用組件的UI一致性提前確認
大型項目開發時，前端在多個功能模塊中會涉及到相同的框架和組件的使用，框架僅提供了功能層面的復用性，但是在UI層面如果未約定，則后期會出現頁面不一致的情況。所以花時間梳理好復用的組件，例如表單，列表，彈窗，浮層等，在多功能并行完成后，會實現一致的交互，磨刀不誤砍柴工。
二、關于團隊
1. 效率為王：和技術同學的溝通方法
產品和技術溝通時，了解前后端不同技術人員的關注重點，溝通起來會更高效。
后端同學負責主要的業務邏輯實現，他們關心主業務流程，功能邏輯和流程，數據流轉，以及數據庫設計時的字段和數據；
前端同學關注的是頁面交互和跳轉，UI的實現，以及和后端配合的技術實現。了解這些，在做需求溝通時候，可以有重點的和不同端同學溝通。抓住不同段同學最關注的點，幫助他了解需求本質，效率會提升很多。
2. 避免技術思維的“邏輯陷阱”，產品經理要大膽做決策！
B端復雜的業務邏輯，需要和技術頻繁溝通。技術思維有時可以提供解決思路，但是所有的B端產品經理需要注意一點：避免被技術的極端邏輯思維把討論重點和產品思路帶偏。
技術在考慮問題時，第一直覺是從純邏輯層面考慮，極端情況是非常重要的一個環節，但有時提出的極端情況在實際的業務場景中出現的很少甚至不會出現，但是如果技術方案實現，可能會耗費大量的時長。
此時產品經理需要大膽的做決策，通過人為確定極端情況的確定處理方式，降低項目成本，同時可以很好地支持業務流程。
舉個例子：有一次在討論一個用戶預約安裝地板的情況時，如果有用戶未安裝完成，需要有一個特殊的安裝工邏輯處理，如果把這種邏輯全部用技術實現出來，投入的時間會很久。
當時我突然意識到技術又陷入了“邏輯陷阱”，當時立即提出“簡化邏輯”的產品方案。和客戶溝通后完全可行；和技術溝通很快可以實現，以此既不影響業務的流轉，也實現了高效率的實現功能。產品經理適合時的做決策，通過產品優化可以降低技術方案的復雜性。
但是這種功能情況下，產品經理需要明確自己的設計原則。一味的妥協方案會犧牲體驗。做決策的基礎在于對業務場景的理解和熟悉程度上，有不確定的情況時候，可以回歸到一線的訪談和溝通，輔助確認方案。
3. 指揮家：善用團隊的能力
在整個項目的實現過程中感受最大的是，團隊的協作是最大的生產力。個人的能力再突出，沒有團隊的配合，也無法拿到非常好的成果；個別的能力偏弱，通過團隊的配合，也可以實現驚喜的結果。
設計方案時候，善于利用技術同學的邏輯能力和技術思維能力，可以找到高度效率的解決方案。
比如我們在設計一個審批流方案時，因為涉及到全國的門店，不同類型門店例如直營加盟，不同大區的審批流程不一致；并且相同的產品可能在不同的審批流中的價格也不一致，在設計方案時，技術同學提供的存儲數據以單條存儲，將復雜的方案最小顆粒度保存，給交互設計提供了很大的發揮空間；一下就讓方案清晰了很多。
前端同學對技術的熟悉和經驗，在細節交互上可以提供很多細節的提升。
比如一個長表單頁面提交時候，空值的提醒，前端同學可以直接定位到空值位置；有的同學可能說這些不都是應該的嗎?其實這和經驗有關，有的團隊沒有交互團隊，可能產品不會花太多精力在細節交互上，此時前端同學的體驗經驗可以很好的彌補體驗的缺失。
整個產品就是在一點一點的細節體驗中，豐滿起來的。
三、關于項目管理
1. “云”項目啟動會
大型的數字化項目或軟件開發項目，不管是甲乙雙方的合作，或者是公司內部重要項目的啟動，都需要一個“儀式感”的會議，代表項目正式的kickoff。關于項目啟動會的流程，包括ppt內容，網上搜索可以搜到很多。但是我們當時在項目啟動時，還在特殊時期，所以使用的在線的“云項目啟動會。”
項目啟動會是數字化項目非常重要的一個環節。其目的不單單是將項目計劃告訴所有參與項目以及甲方的領導或高管，最重要的是讓大家了解項目的重要程度，對項目過程中需要配合的積極配合，以及讓所有的高管和參與人員統一思想。
云會議的形式，本身會讓溝通的效果打折，那如何做好云項目啟動會，讓這個會議達到應有的效果和價值，這是我們面臨的第一個問題。
我們通過兩種方式達成了比較好的效果。
第一個，在項目啟動會的開頭，比較重要的是總裁和總經理的講話內容，我們為了讓這個環節充滿”儀式感“，在課件上放置了領導者的形象照片，和正在發言的狀態，讓在線參會者直觀感受到總裁和總經理的講話。這種形式后來被公司云啟動會作為標準模板。
可能有同學會問為什么不用視頻會議？此次會議時，對方多數項目成員在家辦公，有部分成員在公司會議室多人一起參會；視頻會議的形式容易分散注意力，而且如果視頻會議對方沒有特別正式的背景，會讓整個會議顯得不正式。不如直接在課件內容上打造出正式的會議氛圍更能提升效果。
第二個在會議前，和項目關鍵人提前溝通，將對項目的期待和問題做了充分的溝通，在項目啟動會時，可以讓關鍵負責人在雙方的項目組成員前，可以針對項目很好的發表自己的想法和看法。
討論和溝通的過程就是認可的過程，這個過程，既有助于關鍵人提升團隊的認可，也能讓對方提升對項目的認可程度，這種方式在事后的溝通過程中也被證實是非常有效的形式。
2. 打怪升級：項目風險
任何項目都存在風險。項目負責人需要做到的是保持對風險的敏感性，并立即推動應對方案。而在項目進行過程中，隨著陷入到項目的細節流程中，很有可能會出現不能第一時間識別風險，或者識別風險后沒有立即的應對策略情況，項目負責人應該有意識時刻保持對風險的嗅覺。一般項目中的風險來源于幾種：
1）需求變更
需求變更不可避免。降低需求變更帶來對項目影響以及控制需變帶來的成本是項目經理需要整體考慮的。若控制需求變更需要保證：
- 底層邏輯足夠靈活；需求調整時可以靈活應對；
- 核心邏輯反復溝通，最核心的關鍵邏輯確認；只要項目的主功能模塊的主線邏輯沒問題；各自功能模塊的主線邏輯沒問題，需求的變更可能是修改數據庫字段或者增加狀態等層級的需求變更；
- 需求的確認到位 和業務方的需求確認，溝通到位，也是降低需求變更風險的方式；我當時有一個功能模塊因為“想當然”，導致業務方對一個需求點的理解不到位；后來需要新增一個模塊才能保證業務流程的完整；這對雙方來說是成本；
- 溝通技巧 項目初期給客戶埋下“需求變更是很嚴重的事情”的預期錨點，讓客戶非常嚴肅的認識到前期需求確認的嚴謹性；并且在需求已經確認后期進行變更時，將變更后的解決方案和對方確認，以及將可能產生的人天成本告知；這種嚴格的控制可以降低需求變更的概率。當然，如果客戶有錢任性，隨意改；或者需求遲遲無法確認；需要將需求延期帶來的影響告知。
2）第三方合作導致不確定性
不管是對內還是對外的項目中，有可能您的項目需要和第三方的開發合作，而和第三方合作的項目不可控性大大增加。前期控制好不可控信息，確保項目推動得心應手。
- 合作周期不放在主合同內約定項目上線時間：和第三方的合作周期有時間風險，建議在確定項目上線時間時，將此部分的上線時間單獨計算。
- 合作過程中，做好定位：若項目推動過程中，第三方的時間無法保證，則需要確認清楚在問題中三個合作方的定位是什么？是主要的推動人還是積極配合即可？如果應該推動的事情不推動；或者不應該自己推動的事情自己來推動，前者會造成項目延期風險；后者會讓自己“吃力不討好”，也有可能無法達到預期的效果。
- 以文檔形式確認三方的方案和溝通內容：我們遇到了一個比較大的坑，對接方承諾可以提供的接口在方案已經確認之后，后期表示無法提供；導致部分業務邏輯的調整和部分對接接口的更改。所以每一步的流程都需要雙方或者三方的簽字確認。控制“技術需變”是對自己團隊的保護。
3. 火眼金睛：小心隱形的時間成本
1）隱藏的開發時間
項目排期過程中，在大型數字化項目初期，由于還沒有進入到深層的細節邏輯，此時有些關聯邏輯可能無法覺察到。隨著業務需求的深入，最后會發現可能有沒被評估的架構需求或模塊需求；作為底層的關鍵基礎，這部分的工作可能會影響開發的進度。
2）對于復雜的項目，需求和技術評審占據了大量的時間；在項目評估排期時，需要考慮此時間。
3）項目整合時間，底層架構接口調用時間，權限等模塊的調試時間。
在多功能模塊功能最后落地時，多功能模塊間的聯合調試需要額外的時間；有些功能還需要調取公共模塊的接口；就像搭積木時，每個積木做好了，合并到一起拼插時，可能會有額外的時間聯調和測試。
這些隱形的時間在項目初期都考慮到，到項目節奏中才不會手忙腳亂。
作者：邊亞南，華秉科技產品負責人
本文由 @邊亞南 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議