中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導(dǎo)讀：數(shù)字化是許多企業(yè)未來的發(fā)展趨勢，但是如何實(shí)現(xiàn)數(shù)字化，這是產(chǎn)品經(jīng)理需要解決的問題。本文作者根據(jù)自己主導(dǎo)的一個實(shí)體企業(yè)全鏈路數(shù)字化開發(fā)項目，總結(jié)了方案設(shè)計、團(tuán)隊、項目管理三部分的經(jīng)驗，與你分享。

今年年中，筆者主導(dǎo)一個實(shí)體企業(yè)全鏈路數(shù)字化開發(fā)項目。項目功能涵蓋了9大模塊，140+功能項，需求文檔將近4萬字，共150頁。作為整個項目的負(fù)責(zé)人，針對項目中業(yè)務(wù)需求溝通，產(chǎn)品設(shè)計方案，團(tuán)隊配合和整體項目管理，總結(jié)了些許實(shí)戰(zhàn)實(shí)踐經(jīng)驗，分享給大家。

如果你是B端產(chǎn)品經(jīng)理或項目經(jīng)理，歡迎一起討論交流；如果你是傳統(tǒng)行業(yè)CIO或老板，有計劃或者也在做數(shù)字化升級項目，多了解數(shù)字化項目，或許對您也是有幫助的。

項目背景：

我們?yōu)閲鴥?nèi)知名家居品牌提供用戶全鏈路業(yè)務(wù)數(shù)字化業(yè)務(wù)定制開發(fā)。目的是將用戶的所有觸點(diǎn)，從接觸，銷售跟進(jìn)，踢單成交以及交付后全部的服務(wù)和業(yè)務(wù)流程實(shí)現(xiàn)數(shù)字化，以此提升用戶體驗，提升全鏈路業(yè)務(wù)效率。

一、關(guān)于方案設(shè)計

1. 窮盡拆解低耦合：復(fù)雜邏輯的處理原則

對于復(fù)雜的產(chǎn)品項目，從業(yè)務(wù)流程梳理-抽象設(shè)計方案-邏輯流程梳理-交互細(xì)節(jié)設(shè)計-部分底層框架的設(shè)計，對產(chǎn)品經(jīng)理來說是非常考驗大腦的思考力，(當(dāng)然邏輯能力是基礎(chǔ))。

尤其是鏈路較長，涉及條件較多的邏輯，在梳理方案時候，需要做到”持續(xù)思考力“（雖然這聽上去像是一句廢話）。但是我相信有很多產(chǎn)品經(jīng)理都會遇到有方案瓶頸但是中斷的情況。

中斷思考等于前面做的思考全部作廢，還需要再重新梳理邏輯，低效率且低效果。如何減少這種情況呢？可以試試窮盡拆解法（有點(diǎn)類似金字塔模型的MECY分析法）。

在做復(fù)雜邏輯梳理+需要做設(shè)計方案決策時，有時候困住你的可能是設(shè)計決策，或者是邏輯本身?？赡苣阆胫苯诱业酱鸢?，但是此時效率最高的方案是將所有的情況全部可視化梳理出來，將所有有關(guān)聯(lián)的維度因素梳理出來，交叉確定每個邏輯，或許解決方案會自然出現(xiàn)。

舉個例子，我們有一個業(yè)務(wù)流程有9個關(guān)鍵業(yè)務(wù)節(jié)點(diǎn)；每個節(jié)點(diǎn)有多個條件判斷并且有正負(fù)邏輯的流轉(zhuǎn)；同時這9個業(yè)務(wù)節(jié)點(diǎn)有三種不同類型的業(yè)務(wù)主體。

在處理這種方案時，如果不獨(dú)立拆解到最小顆粒度，很容易遺漏邏輯或設(shè)計出耦合的方案。對方案的靈活性帶來很大的影響。高內(nèi)聚低耦合，是系統(tǒng)設(shè)計的基本原則。

我們的方案是，把全部的邏輯（哪怕有重復(fù)的流程）用流程圖的形式全部可視化展示出來，整個邏輯一下明朗起來。

2. 設(shè)計工具：服務(wù)藍(lán)圖

服務(wù)藍(lán)圖是服務(wù)設(shè)計師常用的工具，在數(shù)字化項目，涉及到多端交互且有關(guān)聯(lián)的流程時，非常適合確定主業(yè)務(wù)的服務(wù)流程；確定服務(wù)流程后，再深入到交互，邏輯，以及架構(gòu)設(shè)計。

用戶旅程地圖是用戶體驗設(shè)計經(jīng)常用到的設(shè)計工具，服務(wù)藍(lán)圖是服務(wù)設(shè)計領(lǐng)域常用的設(shè)計工具。我將二者做了簡單的合并，以用戶和一線人員的交互為主線，找到服務(wù)流程中的設(shè)計關(guān)鍵的點(diǎn)，針對關(guān)鍵觸點(diǎn)，圍繞”用戶體驗和”銷售效率提供解決方案。

3. 設(shè)計陷阱：客戶提供解決方案還是需求？

警惕方案設(shè)計陷阱：用戶調(diào)研獲取需求過程中，始終理性分辨：客戶提供的到底是解決方案還是需求？（很多客戶都喜歡給解決方案?）同時設(shè)計師要警惕大腦中的“第一自然方案”，而是通過用戶的表達(dá)了解他的需求場景是什么？他的核心訴求是什么？如何能滿足？不斷深入分析尋求最合適的方案。

B端產(chǎn)品經(jīng)理和c端產(chǎn)品的工作流和能力要求有些差別，但是對業(yè)務(wù)調(diào)研和需求了解的過程中，我認(rèn)為都是一致的。充分的了解客戶的最終訴求，用專業(yè)的解決方案滿足。

我們的整個項目圍繞銷售數(shù)字化，用戶體驗數(shù)字化，用戶服務(wù)數(shù)字化“來進(jìn)行。在銷售數(shù)字化過程中，我們?yōu)殇N售提供了一個專門服務(wù)客戶的小程序。當(dāng)時在探討提升銷售效率的方案時，銷售提到了一個場景，希望我們做一個微商城小程序，這樣每個商品都可以直接購買。

這個客戶的用戶購買模型屬于購買客單價較高（平均2萬元），購買決策周期較久（大概在2周-3個月不等），在和銷售人員溝通的過程中，他們提到，前過用戶的產(chǎn)品購買路徑可視化的功能很好，但是希望在最后踢單和成交階段也可以在小程序內(nèi)完成，所以希望可以把這個小程序做成一個微商城小程序。

其實(shí)這個方案和我的第一直覺方案很契合，在考慮解決方案的時候，也自然的順著這個思路在深入設(shè)計方案。但是在深入設(shè)計場景時，隱隱感覺哪里不對。

首先我意識到，如果我按照客戶的建議做成一個簡單粗暴的微商城小程序，那么針對購買需要做很多完整的鏈路功能才能形成閉環(huán)，因為社區(qū)零售等行業(yè)的購買模型和運(yùn)營模型與他們完全不同；另外我突然意識到，用戶提出的并不是需求，而是解決方案，我們需要繼續(xù)深挖，了解用戶本后的需求本質(zhì)到底是什么。

方案卡殼，可以進(jìn)行用戶訪談，尋找購買的關(guān)鍵決策因素；與一線使用人員進(jìn)行訪談，尋找業(yè)務(wù)流程痛點(diǎn)；

此時可以通過調(diào)研后，梳理出服務(wù)藍(lán)圖， 用戶服務(wù)藍(lán)圖，以用戶為中心，將服務(wù)業(yè)務(wù)全鏈路可視化展示，有助于設(shè)計方案。（關(guān)于用戶服務(wù)體驗藍(lán)圖有多好用以及如何使用，后面會專門找一篇文章來寫。）

通過用戶服務(wù)旅程圖+服務(wù)藍(lán)圖工具，和銷售人員一起，將用戶接觸后的流程梳理出來，解決方案豁然開朗。

因為客戶成交的特殊性，用戶的購買決策影響因素有兩個，一個是花色（客戶是家居產(chǎn)品），另一個是價格。而在家居行業(yè) ，一般踢單的形式有兩種，一種的膨脹優(yōu)惠券，一種是膨脹定金。

在導(dǎo)購的銷售流程中，如何和用戶發(fā)起溝通，如何推動抓到了這兩個關(guān)鍵點(diǎn)，我們一起確定了功能簡單，閉環(huán)鏈路短，以及靈活滿足需求的功能。

我們并沒有簡單做一個連鎖微商城的小程序，而是為銷售在智能導(dǎo)購功能的基礎(chǔ)上，提供了收訂金，以及一對一推送優(yōu)惠券的功能。并且提供了商品卡片，可以靈活的配置商品卡片，以及用戶的操作路徑可視化，并實(shí)時給銷售發(fā)通知，收取的訂金還能直接轉(zhuǎn)化為后續(xù)訂單中的預(yù)售款。收取訂金的金額由銷售主導(dǎo)，并且支持設(shè)置付款后實(shí)際抵扣的金額。

用這種形式，最大自由度的滿足了銷售踢單和鎖客的最后一步。而這種解決方案也非常滿意。

整個方案的開發(fā)成本很低，滿足的場景足夠靈活。而如果一開始根據(jù)銷售的建議，或者根據(jù)直覺方案做一個商城小程序，需要做很多額外的功能才能滿足自由靈活的銷售流程。

4. 利其器：好用的工具和表格

我們提供給技術(shù)人員的文檔是PRD+交互圖，PRD文檔中很好用的工具有幾種：

• 關(guān)于角色權(quán)限表格?針對特定身份的人擁有不同的操作權(quán)限。用表格的形式，開發(fā)同學(xué)在實(shí)現(xiàn)時候，可以很清晰記錄技術(shù)方案；
• 列表狀態(tài)-操作表格?后臺系統(tǒng)列表的管理頁面非常多；對于復(fù)雜的列表，狀態(tài)對應(yīng)操作最好的表述方式也是以表格的形式展示。針對每一個操作需要再逐一說明流程；
• 業(yè)務(wù)流程圖?業(yè)務(wù)流程圖是幫助開發(fā)同學(xué)整體了解工作流，處理好判斷條件和對應(yīng)條件的處理方式，可以更好的理解項目業(yè)務(wù)，提高開發(fā)效率。

5. 細(xì)節(jié)至上：需求管理中需要注意的TIPS

1）冗余還是關(guān)聯(lián)？

B端產(chǎn)品設(shè)計時，很多數(shù)據(jù)庫字段是技術(shù)同學(xué)設(shè)計數(shù)據(jù)庫時非常關(guān)心的部分。多個數(shù)據(jù)庫表存在時，有時候技術(shù)會直接利用關(guān)聯(lián)表進(jìn)行數(shù)據(jù)查詢。但是對一些記錄型的功能頁面內(nèi)。數(shù)據(jù)需要冗余記錄，不能實(shí)時連表查詢。這個細(xì)節(jié)需要標(biāo)清楚。

常見的冗余數(shù)據(jù)，例如訂單信息，用戶改了手機(jī)號，或者商品后續(xù)改了名稱，訂單內(nèi)的信息不會實(shí)時更新；結(jié)算信息，不會因為商品改了價格而實(shí)時更改結(jié)算數(shù)據(jù)等。

關(guān)聯(lián)數(shù)據(jù)例如用戶的頭像，如果用戶更換了頭像我們在會員的微信卡上的頭像也會隨時的更換。工作人員的手機(jī)號進(jìn)行了更改，會員聯(lián)系導(dǎo)購時也需要最新的數(shù)據(jù)等。

2）隱形的數(shù)據(jù)處理規(guī)則

很多時候技術(shù)很容易根據(jù)需求和交互中的字段來設(shè)計數(shù)據(jù)庫，但是有一些關(guān)鍵的數(shù)據(jù)可能并不會直接填寫在頁面上，但是是非常重要的數(shù)據(jù)。

常見的比如創(chuàng)建時間，創(chuàng)建人，更新時間，更新操作人等，若不標(biāo)志清楚，經(jīng)驗少的技術(shù)人員很有可能會出現(xiàn)后續(xù)需要找數(shù)據(jù)時，數(shù)據(jù)庫沒有記錄某些關(guān)鍵數(shù)據(jù)的情況。數(shù)據(jù)庫關(guān)鍵字段和頁面字段之間的gap，需要產(chǎn)品經(jīng)理提前梳理好并標(biāo)清楚。

3）復(fù)用組件的UI一致性提前確認(rèn)

大型項目開發(fā)時，前端在多個功能模塊中會涉及到相同的框架和組件的使用，框架僅提供了功能層面的復(fù)用性，但是在UI層面如果未約定，則后期會出現(xiàn)頁面不一致的情況。所以花時間梳理好復(fù)用的組件，例如表單，列表，彈窗，浮層等，在多功能并行完成后，會實(shí)現(xiàn)一致的交互，磨刀不誤砍柴工。

二、關(guān)于團(tuán)隊

1. 效率為王：和技術(shù)同學(xué)的溝通方法

產(chǎn)品和技術(shù)溝通時，了解前后端不同技術(shù)人員的關(guān)注重點(diǎn)，溝通起來會更高效。

后端同學(xué)負(fù)責(zé)主要的業(yè)務(wù)邏輯實(shí)現(xiàn)，他們關(guān)心主業(yè)務(wù)流程，功能邏輯和流程，數(shù)據(jù)流轉(zhuǎn)，以及數(shù)據(jù)庫設(shè)計時的字段和數(shù)據(jù)；

前端同學(xué)關(guān)注的是頁面交互和跳轉(zhuǎn)，UI的實(shí)現(xiàn)，以及和后端配合的技術(shù)實(shí)現(xiàn)。了解這些，在做需求溝通時候，可以有重點(diǎn)的和不同端同學(xué)溝通。抓住不同段同學(xué)最關(guān)注的點(diǎn)，幫助他了解需求本質(zhì)，效率會提升很多。

2. 避免技術(shù)思維的“邏輯陷阱”，產(chǎn)品經(jīng)理要大膽做決策！

B端復(fù)雜的業(yè)務(wù)邏輯，需要和技術(shù)頻繁溝通。技術(shù)思維有時可以提供解決思路，但是所有的B端產(chǎn)品經(jīng)理需要注意一點(diǎn)：避免被技術(shù)的極端邏輯思維把討論重點(diǎn)和產(chǎn)品思路帶偏。

技術(shù)在考慮問題時，第一直覺是從純邏輯層面考慮，極端情況是非常重要的一個環(huán)節(jié)，但有時提出的極端情況在實(shí)際的業(yè)務(wù)場景中出現(xiàn)的很少甚至不會出現(xiàn)，但是如果技術(shù)方案實(shí)現(xiàn)，可能會耗費(fèi)大量的時長。

此時產(chǎn)品經(jīng)理需要大膽的做決策，通過人為確定極端情況的確定處理方式，降低項目成本，同時可以很好地支持業(yè)務(wù)流程。

舉個例子：有一次在討論一個用戶預(yù)約安裝地板的情況時，如果有用戶未安裝完成，需要有一個特殊的安裝工邏輯處理，如果把這種邏輯全部用技術(shù)實(shí)現(xiàn)出來，投入的時間會很久。

當(dāng)時我突然意識到技術(shù)又陷入了“邏輯陷阱”，當(dāng)時立即提出“簡化邏輯”的產(chǎn)品方案。和客戶溝通后完全可行；和技術(shù)溝通很快可以實(shí)現(xiàn)，以此既不影響業(yè)務(wù)的流轉(zhuǎn)，也實(shí)現(xiàn)了高效率的實(shí)現(xiàn)功能。產(chǎn)品經(jīng)理適合時的做決策，通過產(chǎn)品優(yōu)化可以降低技術(shù)方案的復(fù)雜性。

但是這種功能情況下，產(chǎn)品經(jīng)理需要明確自己的設(shè)計原則。一味的妥協(xié)方案會犧牲體驗。做決策的基礎(chǔ)在于對業(yè)務(wù)場景的理解和熟悉程度上，有不確定的情況時候，可以回歸到一線的訪談和溝通，輔助確認(rèn)方案。

3. 指揮家：善用團(tuán)隊的能力

在整個項目的實(shí)現(xiàn)過程中感受最大的是，團(tuán)隊的協(xié)作是最大的生產(chǎn)力。個人的能力再突出，沒有團(tuán)隊的配合，也無法拿到非常好的成果；個別的能力偏弱，通過團(tuán)隊的配合，也可以實(shí)現(xiàn)驚喜的結(jié)果。

設(shè)計方案時候，善于利用技術(shù)同學(xué)的邏輯能力和技術(shù)思維能力，可以找到高度效率的解決方案。

比如我們在設(shè)計一個審批流方案時，因為涉及到全國的門店，不同類型門店例如直營加盟，不同大區(qū)的審批流程不一致；并且相同的產(chǎn)品可能在不同的審批流中的價格也不一致，在設(shè)計方案時，技術(shù)同學(xué)提供的存儲數(shù)據(jù)以單條存儲，將復(fù)雜的方案最小顆粒度保存，給交互設(shè)計提供了很大的發(fā)揮空間；一下就讓方案清晰了很多。

前端同學(xué)對技術(shù)的熟悉和經(jīng)驗，在細(xì)節(jié)交互上可以提供很多細(xì)節(jié)的提升。

比如一個長表單頁面提交時候，空值的提醒，前端同學(xué)可以直接定位到空值位置；有的同學(xué)可能說這些不都是應(yīng)該的嗎?其實(shí)這和經(jīng)驗有關(guān)，有的團(tuán)隊沒有交互團(tuán)隊，可能產(chǎn)品不會花太多精力在細(xì)節(jié)交互上，此時前端同學(xué)的體驗經(jīng)驗可以很好的彌補(bǔ)體驗的缺失。

整個產(chǎn)品就是在一點(diǎn)一點(diǎn)的細(xì)節(jié)體驗中，豐滿起來的。

三、關(guān)于項目管理

1. “云”項目啟動會

大型的數(shù)字化項目或軟件開發(fā)項目，不管是甲乙雙方的合作，或者是公司內(nèi)部重要項目的啟動，都需要一個“儀式感”的會議，代表項目正式的kickoff。關(guān)于項目啟動會的流程，包括ppt內(nèi)容，網(wǎng)上搜索可以搜到很多。但是我們當(dāng)時在項目啟動時，還在特殊時期，所以使用的在線的“云項目啟動會。”

項目啟動會是數(shù)字化項目非常重要的一個環(huán)節(jié)。其目的不單單是將項目計劃告訴所有參與項目以及甲方的領(lǐng)導(dǎo)或高管，最重要的是讓大家了解項目的重要程度，對項目過程中需要配合的積極配合，以及讓所有的高管和參與人員統(tǒng)一思想。

云會議的形式，本身會讓溝通的效果打折，那如何做好云項目啟動會，讓這個會議達(dá)到應(yīng)有的效果和價值，這是我們面臨的第一個問題。

我們通過兩種方式達(dá)成了比較好的效果。

第一個，在項目啟動會的開頭，比較重要的是總裁和總經(jīng)理的講話內(nèi)容，我們?yōu)榱俗屵@個環(huán)節(jié)充滿”儀式感“，在課件上放置了領(lǐng)導(dǎo)者的形象照片，和正在發(fā)言的狀態(tài)，讓在線參會者直觀感受到總裁和總經(jīng)理的講話。這種形式后來被公司云啟動會作為標(biāo)準(zhǔn)模板。

可能有同學(xué)會問為什么不用視頻會議？此次會議時，對方多數(shù)項目成員在家辦公，有部分成員在公司會議室多人一起參會；視頻會議的形式容易分散注意力，而且如果視頻會議對方?jīng)]有特別正式的背景，會讓整個會議顯得不正式。不如直接在課件內(nèi)容上打造出正式的會議氛圍更能提升效果。

第二個在會議前，和項目關(guān)鍵人提前溝通，將對項目的期待和問題做了充分的溝通，在項目啟動會時，可以讓關(guān)鍵負(fù)責(zé)人在雙方的項目組成員前，可以針對項目很好的發(fā)表自己的想法和看法。

討論和溝通的過程就是認(rèn)可的過程，這個過程，既有助于關(guān)鍵人提升團(tuán)隊的認(rèn)可，也能讓對方提升對項目的認(rèn)可程度，這種方式在事后的溝通過程中也被證實(shí)是非常有效的形式。

2. 打怪升級：項目風(fēng)險

任何項目都存在風(fēng)險。項目負(fù)責(zé)人需要做到的是保持對風(fēng)險的敏感性，并立即推動應(yīng)對方案。而在項目進(jìn)行過程中，隨著陷入到項目的細(xì)節(jié)流程中，很有可能會出現(xiàn)不能第一時間識別風(fēng)險，或者識別風(fēng)險后沒有立即的應(yīng)對策略情況，項目負(fù)責(zé)人應(yīng)該有意識時刻保持對風(fēng)險的嗅覺。一般項目中的風(fēng)險來源于幾種：

1）需求變更

需求變更不可避免。降低需求變更帶來對項目影響以及控制需變帶來的成本是項目經(jīng)理需要整體考慮的。若控制需求變更需要保證：

• 底層邏輯足夠靈活；需求調(diào)整時可以靈活應(yīng)對；
• 核心邏輯反復(fù)溝通，最核心的關(guān)鍵邏輯確認(rèn)；只要項目的主功能模塊的主線邏輯沒問題；各自功能模塊的主線邏輯沒問題，需求的變更可能是修改數(shù)據(jù)庫字段或者增加狀態(tài)等層級的需求變更；
• 需求的確認(rèn)到位 和業(yè)務(wù)方的需求確認(rèn)，溝通到位，也是降低需求變更風(fēng)險的方式；我當(dāng)時有一個功能模塊因為“想當(dāng)然”，導(dǎo)致業(yè)務(wù)方對一個需求點(diǎn)的理解不到位；后來需要新增一個模塊才能保證業(yè)務(wù)流程的完整；這對雙方來說是成本；
• 溝通技巧?項目初期給客戶埋下“需求變更是很嚴(yán)重的事情”的預(yù)期錨點(diǎn)，讓客戶非常嚴(yán)肅的認(rèn)識到前期需求確認(rèn)的嚴(yán)謹(jǐn)性；并且在需求已經(jīng)確認(rèn)后期進(jìn)行變更時，將變更后的解決方案和對方確認(rèn)，以及將可能產(chǎn)生的人天成本告知；這種嚴(yán)格的控制可以降低需求變更的概率。當(dāng)然，如果客戶有錢任性，隨意改；或者需求遲遲無法確認(rèn)；需要將需求延期帶來的影響告知。

2）第三方合作導(dǎo)致不確定性

不管是對內(nèi)還是對外的項目中，有可能您的項目需要和第三方的開發(fā)合作，而和第三方合作的項目不可控性大大增加。前期控制好不可控信息，確保項目推動得心應(yīng)手。

• 合作周期不放在主合同內(nèi)約定項目上線時間：和第三方的合作周期有時間風(fēng)險，建議在確定項目上線時間時，將此部分的上線時間單獨(dú)計算。
• 合作過程中，做好定位：若項目推動過程中，第三方的時間無法保證，則需要確認(rèn)清楚在問題中三個合作方的定位是什么？是主要的推動人還是積極配合即可？如果應(yīng)該推動的事情不推動；或者不應(yīng)該自己推動的事情自己來推動，前者會造成項目延期風(fēng)險；后者會讓自己“吃力不討好”，也有可能無法達(dá)到預(yù)期的效果。
• 以文檔形式確認(rèn)三方的方案和溝通內(nèi)容：我們遇到了一個比較大的坑，對接方承諾可以提供的接口在方案已經(jīng)確認(rèn)之后，后期表示無法提供；導(dǎo)致部分業(yè)務(wù)邏輯的調(diào)整和部分對接接口的更改。所以每一步的流程都需要雙方或者三方的簽字確認(rèn)。控制“技術(shù)需變”是對自己團(tuán)隊的保護(hù)。

3. 火眼金睛：小心隱形的時間成本

1）隱藏的開發(fā)時間

項目排期過程中，在大型數(shù)字化項目初期，由于還沒有進(jìn)入到深層的細(xì)節(jié)邏輯，此時有些關(guān)聯(lián)邏輯可能無法覺察到。隨著業(yè)務(wù)需求的深入，最后會發(fā)現(xiàn)可能有沒被評估的架構(gòu)需求或模塊需求；作為底層的關(guān)鍵基礎(chǔ)，這部分的工作可能會影響開發(fā)的進(jìn)度。

2）對于復(fù)雜的項目，需求和技術(shù)評審占據(jù)了大量的時間；在項目評估排期時，需要考慮此時間。

3）項目整合時間，底層架構(gòu)接口調(diào)用時間，權(quán)限等模塊的調(diào)試時間。

在多功能模塊功能最后落地時，多功能模塊間的聯(lián)合調(diào)試需要額外的時間；有些功能還需要調(diào)取公共模塊的接口；就像搭積木時，每個積木做好了，合并到一起拼插時，可能會有額外的時間聯(lián)調(diào)和測試。

這些隱形的時間在項目初期都考慮到，到項目節(jié)奏中才不會手忙腳亂。

作者：邊亞南，華秉科技產(chǎn)品負(fù)責(zé)人

本文由 @邊亞南 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議