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

在職場上，如果有一些工具能讓我們順手使用，工作效率會高很多。本文作者匯總整理了一份B端產品的工具包，并以案例穿插其中，可以幫助大家更好掌握文中列舉的這些工具。

這篇文章僅包含6、7、8、9、10節哦，由于單篇文章不宜過長，已分為上、中、下三篇，前序章節請查看本賬號，歡迎收藏、評論或轉發給有需求的小伙伴~

六、產品實施工具

6.1 實施規劃工具：行事歷

為什么已經有了項目計劃，我們在實施環節還要另外創建行事歷？

項目計劃規劃了關鍵任務的起止時間，行事歷細化了關鍵任務，追溯到一個個子項的籌備及完成情況。

行事歷是項目計劃的補充，在最終項目文檔匯總時，行事歷可以以附件的形式附在項目計劃。

那么如何撰寫行事歷?

以某倉庫管理系統（WMS）項目的行事歷為例：

STEP1：根據項目計劃，提取與實施相關的關鍵任務。

• 確認硬件情況（2024/10/08-2024/10/12）。
• 軟件功能確認（2024/10/08-2024/10/12）。
• 基礎信息整理（正式&測試環境）（2024/10/08-2024/10/12）。
• 基礎信息錄入（測試）環境（2024/10/14-2024/10/20）。
• 基礎信息錄入（正式）環境（2024/10/20-2024/10/20）。
• 關鍵用戶培訓（2024/10/14-2024/10/20）。
• 用戶UAT測試（2024/10/14-2024/10/20）。
• 現場準備（2024/10/21-2024/11/01）。

STEP2：根據提取到的與實施相關的關鍵任務，進一步細化子任務，寫明責任方、責任人、支持人員（系統人員）、開始日期完成日期、狀態、備注。

以確認硬件情況（2024/10/08-2024/10/12）為例，它的子任務有確認網絡設備、確認掃描投入、確認網絡連通性，以此類推。

STEP3：重復步驟，匯總所有與實施相關的子任務，即可得到下述行事歷：

表格 20某倉庫管理系統WMS實施階段行事歷

6.2 實施落地工具：基礎數據收集表

為什么B端產品經理需要熟悉制作基礎數據收集表？

因為它可以有效幫助提升和用戶/客戶地溝通效率。基礎數據收集表，可以在下述節點幫助我們推進工作：

• 在測試階段獲取基礎數據，幫助系統測試進行回歸測試
• 在實施階段快速完成基礎數據收集與驗證

那么怎么制作基礎數據收集表？

以某倉庫管理系統（WMS）項目的數據收集表為例：

STEP1：根據系統情況，列明所有需要收集的基礎信息

表格 21某倉庫管理系統WMS基礎信息清單

STEP2：將上述信息粘貼到Excel中,作為目錄頁，增加具體的基礎信息明細sheet。

圖片 67增加具體的基礎信息明細sheet

STEP3：然后就目錄頁的“信息類型”列的字段增補超鏈接，關聯到“本文檔中的位置”。

圖片 68增補超鏈接

重復STEP3的操作，我們就完成了基礎信息收集表的創建。

在與客戶/用戶的溝通中，可以以EXCEL作為基礎數據討論的依據，提升溝通效率。此外，通過對這個數據的分析，便于我們發現項目字段超長、特殊字符等情況。

6.3 實施培訓工具：操作手冊

B端產品經理為什么要重視操作手冊？

操作手冊橋接著開發測試階段和實施階段，是實施培訓的基礎。

此外，根據對9個WMS、OMS項目為期一年的追蹤復盤，40%的運維問題最終會被歸類為培訓問題。物流作為一個人員流動性高的行業，需要頻繁的新員工的培訓，如果物流系統操作手冊不夠細致清晰，將顯著增加運維人員的工作壓力。

那么操作手冊應該如何撰寫?

STEP1：首先需要明確培訓手冊的受眾

以WMS為例，不是所有的用戶，都有WMS的全部權限；也不是所有的用戶，都需要知曉WMS的具體操作。所以在撰寫培訓手冊之前，要考慮好是面向誰寫的操作手冊。

在常規地劃分中，我們可以按照項目劃分版本，例如：XX系統操作手冊_XX項目版_V1_20241203；我們也可以按照受眾劃分，例如：XX系統操作手冊_Vendor版_V1_20241203；我們還有可能按照最終用途劃分，例如：XX系統操作手冊_售前版_V1_20241203。

STEP2：在每次更新前，先維護好更新版本號，方便溯源

表格 22 操作手冊版本更新示例

STEP3：在具體模塊的操作指引前，需要列明每個功能的應用場景及限制。

舉例：在此項目中，所有的物料主數據都從SAP同步，SKU管理中的編輯及新增權限需要在權限控制中移除。

STEP4：列明訪問路徑及變更方式，如果是基礎數據，則需要為用戶列明哪些字段是必填字段，哪些是非必填字段。

以某WMS的貨主信息維護操作指引為例：

• 訪問路徑：全局基礎數據-貨主
• 新增方式：WEB界面新增

貨主數據字典：

表格 23某項目貨主數據填寫指引

STEP4：插入合適的功能頁面配圖，圈出需要操作的按鈕，以STEP1、STEP2……的次序引導用戶一步步完成操作。

STEP5：如果是面向操作工/司機/供應商的培訓，建議可以將上述內容視頻化，方便上述同事從移動端查看。

以上，重復上述操作，我們就能完成操作手冊的撰寫。

6.4 實施培訓工具：培訓計劃

B端產品經理為什么要重視培訓計劃？

首先，需要強調的是，“培訓計劃”是軟件實施流程合規的重要歸檔信息，在審計環節，會由審計人員查驗，如果我們的系統想要獲得認證，同樣有可能被抽檢到培訓計劃（含培訓記錄）。

其次，“培訓計劃”幫助產品經理有序的規劃培訓內容、明確培訓對象、確定培訓時間，提升培訓事宜的溝通效率。

最后，“培訓計劃”中囊括的培訓記錄，結合培訓后上報的運維問題，能夠幫助我們復盤培訓效果。

那么培訓計劃應該如何撰寫?

STEP1：列明培訓計劃需要包含的內容標題。

常見的培訓計劃，需要包含序號、所屬業務流程、相關資料、培訓日期、培訓人/答疑人、培訓對象、培訓/答疑目標。

表格24 B端產品培訓計劃模板建議

STEP2：按照不同的業務流程，完善培訓計劃描述。

表格25 某項目培訓部分計劃

STEP3：重復STEP2的操作，直至完成培訓計劃初稿。

表格 26 某WMS項目培訓計劃

STEP4：與業務溝通敲定培訓日期、培訓對象。

STEP5：在進行培訓時，做好培訓簽到記錄，附在培訓計劃，做好歸檔，在項目審計時會用到。

表格27 培訓簽到表模板樣例

STEP6：在培訓完成后，可以由業務側管理人員籌備UAT（用戶參與測試）。

產品經理此時需要就業務在UAT中提到的問題進行答疑，可以用“UAT問題追溯表”承接此階段的系統問題及發版情況。

表格28 UAT問題追溯表

6.5 實施培訓驗收工具：培訓驗收考試

B端產品經理為什么要重視培訓驗收考試？

培訓驗收考試，能幫助我們及時發現用戶對系統的理解不當之處，提高用戶對培訓的重視程度，減少實施環節的問題。

怎么設計培訓驗收考試？

在培訓驗收考試里可以設置主觀題和客觀題兩類題目。

主觀題可以重點考察用戶的實操、用戶對運維流程的理解：

表格29 培訓驗收考試主觀題舉例

客觀題可以重點考察用戶對系統流程的理解：

表格30 培訓要收考試客觀題舉例

七、產品交付階段工具

7.1 上線管理工具：版本記錄

為什么B端產品經理要重視版本記錄？

首先，需要強調的是，版本記錄是發版流程合規的歸檔信息，在審計環節，會由審計人員查驗，如果我們的系統想要獲得認證，同樣有可能被抽檢到版本記錄。

其次，版本記錄了產品的發展歷程，是可以與團隊提升溝通效率的工具。

最后，版本記錄能夠幫我們追溯版本變化，在遇到運維問題時，可以幫助我們及時確定影響范圍，做好應對準備。

那么怎么進行版本記錄呢？

STEP1：列明版本記錄需要包含的內容標題。

表格31 版本記錄包含的內容舉例

STEP2：在前序文檔的基礎上，在發版完成后更新新版本信息。

表格32 版本記錄舉例

7.2 上線管理工具：上線通知

B端產品經理為什么要重視上線通知?

上線通知是進行用戶期望管理的主要工具，我們通過上線通知告知關鍵用戶、關聯系統新版本信息，能夠有效降低發版對用戶體驗的影響。

如何進行上線通知?

STEP1：列明需要通知到的人，包含上下游關聯系統和系統關鍵用戶。郵件發送下述用戶，并抄送產研團隊。

表格33 上線通知用戶范圍模板

STEP2：列明本次發版是否影響使用，以及具體的發版時間。

例如：本次發版需要停站，預計在凌晨2：00-3：00完成發版，發版期間用戶將無法登錄系統。

STEP3：列明此發版的內容有哪些，注意，發版內容一定要以動詞開頭，語句簡明（讓業務方能夠理解）。

表格34 發版內容舉例模板

STEP4：添加問候語，留下產品團隊的聯系方式。

例如：Bestorder團隊衷心祝愿各位工作順利，如在發版后有任何疑問，請隨時聯系我們（郵箱：xxxxx@xxx.com）。

以上，我們就完成了一次發版通知。

7.3 上線管理工具：上線檢查清單（Checklist）

B端產品經理為什么要重視上線檢查清單？

正如我在這本書提到的其他清單一樣，上線檢查清單的基礎功能是避免我們遺漏。不同于其他清單，上線檢查清單的還直接作用于產品質量提升，通過上線檢查清單，能夠幫助我們及時發現BUG，減小影響范圍。

需要強調一點，并不是所有的問題都可以在測試環境顯現，不能把生產BUG全部歸因到測試人員沒有認真測試，或單純的Coding問題。作為一個團隊，產品和運維有責任參與到上線后的系統檢查，提升產品質量。

如何進行上線檢查?

STEP1：撰寫上線檢查清單。

如果是從0開始準備檢查清單，可以請測試幫助，拿到測試的測試用例，在此基礎上，區分主業務流程與本次發版內容，整理常態化檢查清單和本次檢查內容。

表格35 上線檢查清單模板

STEP2：如果是24h作業的系統，一定要在發版后立即進行檢查。

按照檢查清單，等待生產環境出現對應場景的單據，如果有異常，則及時向開發進行反饋（具體層級可以參考11.2問題復盤），確認上線檢查清單所有事項都被妥善關閉后，上線檢查才能結束。

八、售后運維階段工具

8.1 問題定位工具：SQL

B端產品經理為什么要重視SQL?

SQL能夠幫助產品通過數據分析和優化產品設計、定位和確認受影響的數據范圍。

使用SQL的注意事項:

1）數據操縱語言（DML）分類如下，常規產品側不需要用到SELECT外的其他語句。為了避免誤操作刪庫跑路，在向數據庫管理員（DBA）申請賬號的時候，可以申請只有查詢權限的賬號

表格36 常規數據操縱語言分類

2）市面上存在多種數據庫管理系統（Mysql、PostgreSQL、Microsoft SQL Server、Oracle Database等），在不同的管理系統中，SQL的語法是有差別的，在學習前，需要先明確學習的SQL類型

3）SQL對大小寫不敏感

4）在寫SQL的時候要注意語句的性能，盡量不要執行慢查詢。在語句執行前，可以用EXPLAIN命令分析SQL查詢的執行計劃，顯示查詢的詳細信息，包括是否使用了索引、表的連接順序等

舉例：EXPLAIN SELECT * FROM table_name WHERE condition;

產品經理常用的SELECT語句如下：

SQL JOIN是我們最常用的聯表查詢語句，如果不熟悉各種JOIN，可以多看下面的圖：

圖片69 不同的JOIN圖解

這本書僅僅列舉了常規需要用的到SELECT相關的語句，如果想精進，推薦可以看看《高性能Mysql》這本書。

8.2 問題分析工具：問題復盤（Postmortem Analysis）

B端產品經理為什么要重視問題復盤？

復盤是一種重要的工具，可以幫助產品經理從故障中總結經驗教訓，為后續思考產品設計提供參考。

如何進行問題復盤？

圖片70 問題復盤流程

STEP1：在故障發生后的兩天內，進行問題回顧。

完整的記錄下故障的發生、發現、原因定位、決策、處理、預案執行、回滾、故障解決等的關鍵人與關鍵時間點。

STEP2：利用5W1H分析問題產生的Rootcause。

圖片71 根因分析

• WHO：確定受到影響的客戶是誰？受影響的系統使用者是誰？
• WHEN：確定用戶何時會遇到這個問題？
• WHERE：確定在什么業務流程中產生這個問題？
• WHAT：確定產生了什么樣的問題？是什么原因導致的？
• HOW：確定怎么樣才能解決這個問題？如何決策？如何實施?

STEP3：通過總結，進行故障定性、故障定責及總結本次故障帶來的經驗教訓。

在進行故障定性時，要評估對業務帶來的影響（可以用SQL提取影響單據的范圍），確認損失及范圍。

這樣做的好處有：

• 1.通過故障定性，我們可以劃分不同的問題的等級（如P0/P1/P2/P3/P4等級），可以更加有序、科學的進行運維資源的分派。
• 2.通過故障定性，我們可以跳出故障本身，抽象的看待同級別或者不同級別的故障差異與共性，可以更加系統性的規劃解決普世問題。
• 3.通過故障定性，我們可以識別故障處理中是否有可以優化的點，例如通過同級別故障處理手冊規范故障通知、解決流程，以縮短問題處理時間。

STEP4：通過行動，落實故障的處理。

通過SMART法則，提出改進項目：

• Specific（具體）：目標需要明確具體，清晰地指出我們需要改進、優化的單項、指標是什么。
• Measurable（可衡量）：目標應該是可以量化的，明確的制定驗收標準是什么？
• Achievable（可達成）：目標應該是現實的，考慮到資源和能力，避免出現一些假大空、無法落地的改進。
• Relevant（相關性）：目標應與個人或組織的長遠愿景和目標保持一致，盡可能避免出現孤立的改進。
• Time-bound（時限性）：目標應該有明確的截止日期或時間框架，這個時間建議最長不要超過三個月，避免改進流于形式。

僅僅提出改進項目是不夠的，接著我們要追溯改進項目：

1.首先，要明確相關改進項的負責人。

負責人可以有多個，但主要負責人有且只能有一個。即這個人需要對這個改進項的落地全權負責。當然，這個負責人的指定也需要在權責對等的基礎之上。

2.定期回顧改進狀態，規定好回顧時間，回顧后續改進項的狀態如何？是在準備？進行中？還是完成？

在完成了改進項后，需要進行改項的關閉。

以上，我們就完成了問題的復盤。

8.3 運維需求工具：用戶俱樂部（USER CLUB）

B端產品經理為什么要重視用戶俱樂部（USER CLUB）？

USER CLUB提供了一個窗口，讓用戶可以直接反饋用戶體驗。

不同于分散的提出問題，USER CLUB同時邀請了所有的產品相關業務，可以就某些爭議性的問題，進行跨部門的直接確認及業務優先級反饋，產品經理可以根據用戶反饋進行產品優化。

怎么組織USER CLUB？

STEP1：確定系統的關鍵用戶。

和業務部門確認，由業務部門指定對接系統的人員。

STEP2：會前收集關鍵用戶的所有需求。

可以套用4.1的需求清單，請關鍵用戶提前維護其需求，必填字段如下：

表格37 關鍵用戶需求填寫表

STEP3：會中組織關鍵用戶反饋其需求。

為了避免占用所有人太長時間，可以先講需要跨部門的需求，在業務講解需要后，及時的反饋此需求對于其他業務職能的影響，并引導業務給出需求的優先級，避免會后扯皮。

STEP4：會后及時將需求進度更新反饋給提出的用戶。

會后及時與開發測試評估，反饋業務需求的預計完成日期及預計發版版本，在發版前組織用戶UAT，在發版后通知業務進行驗收。

術語表:

參考文獻：

[1] 國際物流與貨運代理從入門到精通 物流管理[M]. 國際物流與貨運代理從入門到精通 物流管理, 2020.

[2] 王偉. 電商產品經理：基于人,貨,場,內容的產品設計攻略[M]. 電商產品經理：基于人、貨、場、內容的產品設計攻略, 2019.

[3] 梅芊, 黃丹, 盧藝. 基于MBSE的民用飛機功能架構設計方法[J]. 北京航空航天大學學報, 2019, 045(005): 1042-1051.