互聯網產品的價值流動:價值流、工作流和信息流
價值流、工作流和信息流的現狀,如何優化,以及如何應用三流幫助我們的產品成功?網易資深PM給我們分享了這些經驗。
三流是一個關于我們如何看待我們的工作的說法,在開始寫這篇文章之前,我有過很多關于這方面的思考,但是都不太系統,最近這個思考逐漸明晰起來,于是就有了這篇文章。
一、什么是三流?
在精益的理論中,希望價值能夠流動起來,當我們嘗試著把精益的理論從制造業的背景中映射到互聯網行業中時,會發現要一一映射價值流是有困難的。
互聯網軟件價值流的判斷和制造產品價值流的判斷之間的差別在于:制造出的產品在用戶拿到的時候就獲得了幾乎全部的價值,而互聯網軟件不是。
互聯網軟件是一種服務,它的價值是在用戶每一次使用這個服務的時候分別得到的,并且每一次得到的服務常常是不一樣的。提供服務的不僅僅是生產部門(軟件開發),而是幾乎每一個部門都在提供服務,換句話說就是:用戶體驗是全公司的事情。
那么在這種情況下我們如何識別互聯網企業在提供價值的過程中的“流”?三流就是從這樣的背景下開始思考的。
1. 價值流
首先是價值流——用戶是如何通過價值流持續獲得軟件的價值的?
以網易卡搭為例,網易卡搭是一個提供少兒STEAM教育的產品,產品本身包含了在線的課程、社區、校園、大賽,同時也包含了線下的營地、機構授權等服務。
以一個購買了卡搭Scratch課程的家長用戶為例,用戶的整個價值流是:
- 了解卡搭,通過卡搭發現了自己和孩子所需要的課程,找到了消除知識競爭帶來的焦慮感的方法。
- 購買課程,通過課程的評測功能了解到孩子需要提升的地方,并且第一時間收到了如何學習課程的方法,了解了自身的情況又消除了對于未知事物的些許恐懼,增強了信心。
- 開始上課,通過上課學習到了新的知識和能力,獲得了更多的競爭優勢,并且培養了創造力和邏輯思維能力。
- 開始做作業,在做作業的過程中,重新回顧了所學的知識并且應用于實踐,通過實踐獲得了成就感和滿足感。
- 作業點評,通過點評獲得反饋,從而了解自己的學習情況和對于知識點的理解,通過這樣的反饋來獲得提升。
- 公開課,拓寬了視野,獲得了一些新的工具方法和認知。
- 結業總結,對于整體學習情況的總結,通過總結看到了自己的成長和變化,并且有一個值得炫耀的證書。
從了解卡搭到結業總結,用戶在這個過程中的每一個環節都得到了不同的價值,這個鏈路就是價值流。
這只是一條簡化的價值流的舉例,實際上的價值流比這個例子豐富得多,并且一個產品往往有多種不同類型的客戶,從企業到個人,再到不同的人群,為每種不同的客戶所設計的價值流是不同的。
如何能設計一條價值流,讓用戶能夠更快、更順暢地通過價值流得到軟件的所有價值,如何在現有的價值流中增加或減少環節為用戶提供更多的價值,這些正是我們所需要考慮的。
2. 工作流
在設計好了價值流之后,我們就需要考慮我們如何能夠支撐這樣的價值流?
這就是工作流的作用。
在互聯網企業中的工作流有很多種,最常見的一種就是產品開發工作流:
- 策劃環節:產品策劃人員從BD,運營等內部客戶那里收到到他們的需求,然后再通過自己對于用戶,產品和行業的認知設計產品形態。
- 交互環節:交互設計是收到了從策劃那里來的需求稿開始做產品的交互設計。
- 視覺環節:視覺設計師收到了從交互那里來的交互稿開始做產品的視覺設計。
- 開發環節:開發人員收到了從視覺環節來的視覺稿和交互環節來的交互稿開始做代碼的開發。
- 測試環節:測試人員收到了從開發人員那里來的代碼開始做測試。
- 上線環節:運維人員從開發人員那里收到了上線的申請,開始做代碼的部署。
從策劃開始到上線,就是產品開發的工作流。
這個工作流,讓用戶能夠在每隔一段時間都能夠感受到不同的軟件使用體驗,比如更加美觀帶來的愉悅感,更符合使用習慣的交互設計帶來的舒適感,更高性能的軟件帶來的順暢感,新增加的咨詢功能讓用戶在了解產品的時候更加便利,刪除的資料填寫功能讓用戶更快地就能開始使用產品獲得產品的價值。
3. 信息流
在建立了工作流之后,就需要建立如何管理工作流的信息流。
工作流不可能自己運轉起來,工作流的每個環節之間是需要銜接和信息同步的,工作流的目標、整體的效能提升和持續地優化是需要通信息流進行管理的。
信息流和工作流的關系,就像是FTP協議中的20端口和21端口的關系:一個傳數據,另一個傳遞控制數據的數據。
我們常見的各種會議就是一種信息流,比如站會,我們在站會上同步昨天各項工作的完成情況,同步今天要做的事情,同步遇到的問題等等。工作狀態的信息通過這個會議從一個人這里傳遞到其他人那里。
再舉一個例子:
產品的戰略層決定了方向之后,是如何將信息傳遞給中層管理人員的,中層管理人員又是如何把這些信息繼續向下傳遞到執行人員的,最后的執行結果又是如何通過這些層反饋會戰略層的——這些就是每天在發生的信息流。
信息流是控制工作流所必不可少的,沒有信息流,工作流就會一團混亂,環節和環節之間就會脫節,層和層之間就會出現不一致的理解。
但是由于信息流本身不創造價值,因此信息流是需要考慮成本的,過多的信息流會造成許多不必要的浪費。
作為項目經理,在進入一個新團隊的時候,切入點也常常是信息流,通過掌控信息流來控制工作流,從而影響價值流。
二、幫助產品成功
了解了什么是三流之后,我們要做的就是通過三流來幫助產品成功。
那么問題來了:我們如何通過三流來幫助產品成功?
商業的競爭最后都是如何有效利用資源的競爭,這種競爭體現在如何用現有的資源獲取更多的資源,如何用現有的資源識別價值和創造更多的價值,這些就是我們所需要面對的。
三流中的價值流就是用來設計對用戶有價值的路徑,而三流中的工作流就是用來做資源利用的;我們通過優化價值流來提升用戶得到的價值,通過優化工作流來提升資源的利用率,通過優化信息流來降低管理成本。
三、了解現狀
在開始做優化之前,首先要做的事情就是了解現狀。通過了解和分析現狀,我們找到可以優化的點,然后再選擇要優化的點做好優化的計劃,接著按照優化計劃實現整體的提升。
1. 價值流的現狀
通過了解價值流的現狀,找到可以優化的點,從而提升用戶的價值。
了解價值流的現狀可以分成三個步驟:
- 整理現有的價值流環節
- 選擇和收集現有價值流的數據
- 收集現有價值流的感性認知
整理現有價值流環節
首先要收集和整理現有的價值流和價值流的每個環節,盡可能地細化:
- 客戶購買卡搭線上課程的價值流。
- STEAM教師使用卡搭校園的價值流。
- 授權機構購買卡搭授權的價值流。
- ……
通過這些價值流的收集整理,我們可以
選擇和收集現有價值流的數據
以前面的客戶購買卡搭課程的價值流為例子,我們需要分析每一個環節的數據,通過數據來發現其中需要優化的點:
1.了解卡搭,數據的目的是了解用戶在了解卡搭的環節是否獲取了足夠多的價值?用戶都是通過什么渠道知道我們的?哪些渠道來的用戶比較符合我們的預期?我們對于原有用戶畫像的設定是否符合實際?用戶是怎么了解卡搭的?是否看到了我們希望用戶看到的內容?我們原計劃希望用戶操作的路徑是否用戶是這么做的?我們設計的那些功能用戶是否都用到了?頁面的上信息用戶看到了哪些? 等等。
- 用戶是通過哪些渠道知道卡搭的?朋友推薦?廣告?搜索引擎?公眾號?還是其他渠道?
- 每個渠道卡搭投入了多少資金?每個渠道帶來的用戶量是多少?每個渠道的投入產出比是多少?
- 相同文案和設計的場景下,哪些渠道ROI更高?哪種文案的ROI更高?
- 用戶瀏覽了哪些頁面?每個頁面的停留時長是多久?跳出率是多少?
- 用戶瀏覽頁面的路徑是怎樣的?
- 單個頁面的熱力圖是怎樣的?哪些功能是用戶較為常用的?
- 滾動條滾到哪里了?哪些地方是用戶會閱讀的?
2. 購買課程,通過課程的評測功能了解到孩子需要提升的地方,并且第一時間收到了如何學習課程的方法,了解了自身的情況又消除了對于未知事物的些許恐懼,增強了信心。
- 訪問卡搭的用戶中有多少用戶購買了課程,轉化率是多少?
- 在購買課程的過程中,每個頁面的跳出率是多少?(實際上,在購買課程的過程中有許多的頁面,包括登陸,填寫個人信息,下訂單,支付等等),每個頁面的停留時長。
- 購買課程的用戶中進行評測的用戶的比例?
- 進行過評測的用戶完成所有課程學習的比例和沒有進行過評測的用戶完成所有課程學習的比例?
3. 開始上課,略。
4. 開始做作業,略
5. 作業點評,略。
6. 公開課,略。
7. 結業總結,略。
在筆者經歷過的團隊里面,數據分析的需求,優先級都是不太高,雖然我本人不太認同,并且也努力推動數據分析的相關功能的建立。
在我的觀念中,數據收集和分析的相關功能屬于功能的一部分,否則,新功能上線新服務推出,如何能知道效果咋樣?不能知道效果咋樣那怎么知道新功能或者服務起到了正向還是負向的效果?怎么知道下一步該做什么?
但實際在工作中,要有這么全的數據打點或者收集是比較難的,成本也是比較高的,因此我們就要根據當下的情況做出一些取舍,對于那些想要知道效果的功能實現數據收集和分析的功能,而對于不那么緊急的,自然也可以往后放放。
收集現有價值流的感性認知
這個就是用戶研究的領域了,我們需要向用研部門提出需求,描述清楚我們所需要達成的目標,我們想要驗證的現有軟件的使用情況,和為未來設計的新功能點的用戶接受程度等等。
2. 工作流的現狀
通過了解工作流的現狀,找到可以優化的點,從而提升團隊整體效能。
了解價值流的現狀可以分成四個步驟:
- 了解價值流的需求,整理工作流所要支撐的價值流
- 整理現有的工作流,列出主要的環節
- 選擇過程數據指標
- 收集各個數據指標的情況
了解價值流的需求
價值流的需求是工作流的目標,因此了解價值流的需求很重要。
以卡搭在線課程為例,課程用戶的價值流的目標是讓用戶在購買和使用卡搭產品的每一個環節都能夠獲得一定的價值,因此,對于工作流的需求就是:
- 能夠持續地盡可能多地提供新的價值;
- 能夠持續找到價值流的優化點,并且可以在2周左右的時間優化掉;
- 價值流的每一個環節不能出現錯誤讓用戶有價值的損失;
- 在用戶上課環節能通過最好的課程和最優質的軟件體驗和班主任的服務讓用戶體會到盡可能多的收益和成就
- ……
這些就是價值流對于工作流的需求。價值流定義了What,工作流就需要定義出How了。
整理現有的工作流
整理現有的工作流會對團隊現有的工作方式有一個更全面的了解,這個工作流分成不同的環節或者步驟,工作流通過這些環節來支撐價值流。
以網易卡搭的課程線為例,為了支持價值流的需求:
- 能夠持續地盡可能多地提供新的價值;
- 能夠持續找到價值流的優化點,并且可以在2周左右的時間優化掉;
- 價值流的每一個環節不能出現錯誤讓用戶有價值的損失
產品開發團隊的現有的常規工作流:
- 策劃
- 交互
- 視覺
- 開發
- 測試
- 預發
- 上線
這個工作流常見得不能再常見了,但我們正是周期性地通過這樣的工作流,持續地為價值流添加新的價值,持續地優化價值流的每一個環節,并且通過測試,預發這樣的環節來保證質量。
當然,Scrum是反對把測試和開發區分得這么明顯的,在Scrum團隊中不應該有專門的測試人員,也不應該有一個專門的測試環節,這個問題我同意也不同意:
從生產力發展的角度來說,社會分工一定是越來越細致的,因此開發和測試兩種不同思維方式的工作是會逐漸區分開的,只是測試人員的角色和定位可能會發生變化,不只是發現問題而是變成成果驗收,并且從測試專家和測試工具提供者的角度為團隊提供支持。
關于測試環節,并不是每一個團隊都能一蹴而就立刻取消測試環節,從組織構架也好,軟件架構也好,測試工具的完備程度,自動化測試用例的覆蓋率,團隊的成熟度,等等多個維度上來看才能判斷測試環節是否在當下可以不要。
選擇過程數據指標
常見可選的數據指標有以下這些:
- 過程時間 = 完成一個工序或者活動所需要的時間
- 交付周期 = 過程時間 + 等待時間
- 增值時間 = 實際花在增值活動上的時間
- 轉換時間 = 從一個活動切換到另外一個工作的過程中所耗費的時間
- 需求速率 = 每次迭代開始的時候團隊承諾的需求數量
- 可靠性 = 開發或者設計等工作依賴的環境的穩定性
- 可用時間 = 有效工作時間,換句話說就是真的是在工作的時間
- 錯誤率 = 也就是Bug率和需求評審,視覺評審,交互評審中的錯誤率,這些會影響返工的時間和延遲交付。
實際在選擇指標的時候,并不是隨心所欲的,往往受到條件的限制,比如增值時間是很難統計的,除非能夠一直跟在相關人員身邊記錄。轉換時間和可用時間也是比較難統計的,常常需要通過和不同的人進行交流后,根據他們的回答進行統計。
收集各個數據指標的情況
由于團隊已經才有了固定迭代周期的方式,所以需求速率理論上應該是穩定的,因此對于需求大小的可以通過Story Point做一個簡單的估計。
過程時間也是相對固定:策劃,交互,是覺得時間為了配合開發測試的迭代時間,也是需要固定迭代的。
上圖顯示了每一個環節所需要花費的時間,可以簡單的判斷策劃,交互,視覺花費的時間比較長。實際上筆者在收集時間的時候是用了更加細致的圖,把開發團隊的時間做了更細致的拆分和記錄,然后把每一個環節都標上時間。
3. 信息流的現狀
信息流是為對工作流進行管理的,為了能夠讓信息在不同環節和不同角色之間同步,讓工作流更順暢地工作起來的。因此了解了工作流的現狀之后我們也需要了解信息流的現狀:
- 整理現有的信息流
- 現有信息流花費的時間
- 現有信息流的覆蓋范圍
整理現有的信息流
理出所有的會議,郵件,IM群等等每個會進行信息傳遞的方式,并且列出每一個方式存在的目的。
會議
- 全員XXX會議:目的是和全員同步業務進展情況和重大成果和重大問題等,對全體員工有正向激勵的效果。
- XXXX雙周會:同步策略執行結果,依據結果討論方案,并且最后形成新的決策和下一步方案。
- XXXXX周會:同步相關信息和問題,暴露問題,推進各項事情的進展。
- 交互評審:略。
- 視覺評審:略。
- 需求評審:略。
- 技術評審:略。
- 開發周會:略。
- 策劃周會:略。
- 測試用例評審:略。
- ……
郵件
- 部門郵件通知:重要事項的通知和同步。
- 上線郵件通知:告知所有人上線的內容,版本,注意事項,方便相關人員開展工作。
- XXXX郵件通知:略
- ……
IM群
- 客服群:及時響應和解決客服人員收到的客戶的重要問題
- 全員群:通知XXXXX
- 開發群:略
- 測試群:略
- ……
現有信息流的覆蓋范圍
還需要整理出現有信息流的覆蓋范圍,因為可能會發現有部分信息流有遺漏關鍵人員,或者會發現相同目的的群重復覆蓋了相同的人群。
現有信息流花費的時間
然后就是記錄每個信息流所需要花費的時間,通過這些時間來判斷信息流的投入產出比。和對于人員時間的占用。
四、分析優化
了解了三流的現狀之后,我們急需要對現狀進行分析,找到其中的問題或者優化點,然后針對性地提出解決方案。
1. 價值流分析優化
通過數據發現:課程用戶購買課程的轉化率不盡如人意,瀏覽課程頁面的用戶只有1%選擇了購買,沒有選擇購買的用戶幾乎所有人根本就沒有進入購買流程,也就是說用戶瀏覽了購買頁面之后就走了。
并且我們發現:大多數用戶其實看完了頁面上的信息。那么問題來了,為什么99%的用戶連購買流程都沒有進入?滾動條百分比顯示大多數用戶看完了,那是因為文案不好看?還是因為信息不充分?還是因為價格太高?是什么讓用戶沒有獲得充分的價值感?
根據這些分析,我們可以做一下嘗試:調整價格,修改文案,增加更多的信息。
經過討論,我們決定增加更多的信息,于是增加了試看課,讓用戶在這個環節得到更多的價值,這個價值幫助用戶降低決策的風險。
在放出了試看課之后,我們也需要收集相關的數據:打開了試看課的用戶比例是多少?看完試看課的用戶比例是多少?增加了試看課之后,購課轉化率是否有提升?根據這些結果來決定我們還需進一步做哪些優化。
2. 工作流分析優化
根據課程的產品開發流和每一各環節的數據,可以看到:前期的策劃和和交互視覺時間是比較長的,占據了整個流程2/3的時間,需要能夠縮短時間;同時,開發時間過短,測試上線預發的時間也過長。
對于策劃交互視覺策劃時間過長的問題,第一步就是要讓這些覺得工作量可見,才能判斷他們是否需要長么長的時間來完成相應的步驟,因此讓所有的工作內容上JIRA就變得很重要,然后下一步才是根據JIRA上的數據來分析是否有可能對這部分的工作內容進行縮短。
當然,也需要和對應的負責人進行溝通,了解他對于這個問題的看法,是否能夠達成共識并且推動實踐的縮短。
對于測試聯調預發上線時間過長的問題,我們進一步分析發現:在Bug上所花費的時間占到整體開發時間的1/3,而聯調時間又比較長,測試環境也經常不穩定,由于質量不好導致測試等待時間也很長,上線過程,因此可以得出第一個結論:質量不好導致在代碼提交測試之后花費的時間過長,因此第一步就是需要提升代碼提交的質量。分析原因,是因為現在的新功能開發壓力比較大,同時又因為插入的臨時需求比較多,開發能用于設計和自己測試的時間不夠導致的。因此解決方法就是:每個迭代給開發留出20%的時間,少做一點需求,少制造一點Bug,并且當有臨時需求插入的時候也可以用這個20%的時間來做緩沖,不至于占用設計和測試的時間;如果沒有用完這部分時間,那就把時間用于技術債的清理。
可用時間的延長要謹慎:并不是所有的時間都可以用于工作,高強度工作8個小時是非常累的,因此每個人都會選擇其中一段時間休息一下——可能是去抽支煙,可能是喝咖啡,或者是站起來走走,或者和別人聊幾句。
這些看起來都是不必要的事情,但是如果剝奪了這部分的時間,那么只會帶來工作效率的下降。并且,每個人所需要的休息時間是不一樣的,不能簡單地一刀切規定每個人的休息時間不得多于多少時間。因此我們在考慮可用時間的目的是看我們實際可以用的時間是多少,而不是簡單考慮增加可用時間。
從另外一個方面來看,我們也可以通過增加工作時長來達到增加可用時間的目的,這也是我們常用的方法。
實際上,這個方法有點類似于飲鴆止渴:剛開始的時候,可用工作時間可能會隨著工作時間的增加而增加;但是由于疲勞的增加,可用時間的增加和工作時間的增加并不會成正比,會隨著加班次數的增加,可用時間會漸漸減少到一個穩定水平;這個水平會比加班之前的可用時間多,但是會比期望的少。
如果加班是有成本的化,這個投入產出比顯然是比較低的。
3. 信息流分析優化
通過信息流的數據可以發現,接收XXX郵件的人數是全員,但其實并不需要通知到全員——這封郵件只需要在郵件列表里面需要回復的人收到就可以了,否則所有的郵件和相關的回復都是全員收到,會造成大量的垃圾郵件,剩下的人只需要在上線的時候收到郵件即可。
通過信息流的數據可以發現:之前XXX會議的時間常常需要開3個小時,在會上大家會討論許多問題;并且是所有核心成員都會參加的會會議,這樣的化就偏離的會議的目的,并且花費的時間過多,導致了許多浪費。
4. 分析和優化的挑戰
雖然我們通過分析得出了許多優化方案,但是要落地方案并不是那么容易的——有一些方案會受限于你所處的環境,受限于團隊當下的狀態而短期內無法實現,這些也都是你所需要面對的挑戰,如何找支持,持續不斷地努力來改變周圍的環境,大概也是互聯網項目經理常常在做的事情。
五、總結
通過了解三流的現狀,然后分析和優化三流,我們用這樣的手段來提升業務線的效能,從而能夠在商業競爭中通過效能的優勢勝出。
通過分析價值流,我們發現在各個環節的數據收集和分析是不夠做決策的,因此我們把盡快提升數據覆蓋作為了我們下一個階段的目標。
通過分析工作流,我們看到了工作流中的問題,把提升可用工作時間作為我們研發團隊的工作目標,從而能夠盡快地完成產品的需求。
通過分析信息流,我們減少了會議的頻率,取消了部分沒有必要的會議,依據目標和組織架構調整了各個會議的參與人員,重新梳理了郵件列表,減少了郵件的打擾,合并了一些群,保證信息能夠發送給所有需要的人,從而保證工作的每個環節的同步花費更少的時間,并且信息能夠被傳達到位。
作者:曹靚,網易資深項目經理,9年SCRUM多角色經驗,6年大規模分布式系統經驗,3年LTE系統經驗,致力于提升用戶需求轉化為價值的速度。
來源:網易杭研項目管理(微信公眾號:NetEasePM)
本文由 @網易杭研項目管理? 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Unsplash,基于 CC0 協議
信息流內容服務 個性化信息推薦 廣告變現 整體提高10%到15%的收益 微信:kwf268
歡迎微信討論?。簄eutyz,我也有很多想說的啊
三流的圖要是能都給出來就完美了
為什么不能說重點,中間總要穿插很多可以省略的話,難道產品經理不該換位思考,以用戶為中心嗎?這么長且實用性并不高的的文章真的觀看起來很累
已鑒定,推廣網易卡塔的軟文