在整個項目過程中，項目經理需要與業務方進行頻繁的溝通。那么，每次溝通的重點是什么？要達成哪些目的？本文作者從自己的實踐出發，分立項和實施兩個階段，給大家說明溝通的重點。

To B的數字化項目因其與業務的關聯非常緊密，特別在非標業務場景下（如私募、投資行業等），不同公司對于業務的理解、流程、關注點、數據要求等都不相同，項目團隊的人員往往很難做到對各種情況都有知識儲備或相關經驗，需要與業務方保持深度互動，才能使設計和開發的功能滿足用戶的需求。

筆者作為項目經理，經歷了一個為私募股權投資企業定制化開發的投融資業務綜合服務系統的完整周期（項目金額270萬，周期一年）。因為上一輪的數字化建設成效比較明顯，目前正在推動項目二期建設（項目金額281萬，周期預計一年）。

基于該項目的實踐經驗，筆者認為可以從以下幾方面著重開展與業務方的溝通。

一、立項階段

立項階段主要是收集業務方的需求，簡單來說就是挖掘業務方現在有哪些實際問題可以通過數字化的手段解決，比如哪些流程可以線上流轉、哪些報表可以自動出具、哪些文件可以自動生成、哪些信息能夠自動獲取等等（同時要考慮如何把這些需求有機的嵌入在系統的整體結構中），通過此階段才能明確項目范圍，所以這個步驟非常重要，溝通重點在以下三點：

1. 明確牽頭部門和牽頭人員

項目組在初期，對公司的架構、業務和人員都不熟悉，必須有業務方的牽頭人員進行總體協助，且該人員的作用在整個項目期間都非常重要，所以務必從一開始就使其對項目建設充滿責任心。

我們的經驗是不斷向其灌輸這個理念“這個數字化項目將成為他重要的工作成績”，同時需要在項目建設周期中，不斷提供各類成果供其進行內部匯報以體現工作成效。

2. 廣泛開展需求調研

在條件允許的前提下（沒有條件也最好能創造條件），廣泛與各個部門開展面對面的需求溝通會議，建議最好每個部門都聊一遍。

在會議上需要通過一些案例進行引導，讓業務方明白系統可以幫助他們解決實際問題，從而打開他們的思路和熱情。

3. 需求二次確認

把調研收集回來的需求進行加工、匯總之后，請牽頭部門協調，組織一場由各個部門負責人參加的需求確認會議。

這樣做的好處有兩點：

1. 部門負責人往往有更廣闊的視野和更豐富的信息，能對需求提出很多實質性的建議；
2. 通過這場會議提高項目在公司的“知名度”，為后續工作做好鋪墊。

二、實施階段

在實施階段，重點是定期做好以下事項：

1. 需求框架會議

我們這個項目采取的是敏捷迭代的方式，固定每個月發一個新版本，需要在每月下旬確認下個月版本的具體需求范圍。

最初項目組采取的是根據年初制定的計劃進行每個版本的開發，但是發現業務方總會在中途插入各種臨時性的緊急需求或者調整需求的優先級，打亂開發計劃。

為盡量解決這個問題，我們和業務方協商確立了需求框架會議機制，即在進行下個版本詳細需求設計之前，由項目組提出擬安排開發的需求清單，再由業務牽頭部門的領導進行調整和確認。

通過實踐，發現這一模式確實能大幅降低各類需求插隊的情形，因為業務方領導一般不會輕易推翻自己的決策，在碰到需求變更或者插隊的情形時會更加謹慎，同時也能更加體諒項目組在面對這些情況時的困難。

2. 需求評審會議

在產品經理完成詳細的需求文檔和原型設計之后，組織開展由需求提出人員參加的需求評審會議，以明確系統功能與其前期口述的需求相匹配，部分業務人員在看到原型之后往往會迸發出許多新的有價值的意見和建議，能有效指導需求設計工作，避免后續返工。

3. UAT集中測試會議

在項目建設實際過程中，我們發現以通知的方式告知業務人員進行UAT測試，往往效果都不太好，因為一是業務人員比較忙，對于UAT測試工作重視程度不夠；二是在沒人指導的情況下，業務人員進行UAT測試的效率也比較低，最終導致UAT測試流于形式。

為解決這個問題，項目組通過牽頭部門的協助，在每個版本上線前會組織一場集中的UAT測試會議，由擬上線功能的需求提出人參加，項目組測試人員現場演示相關功能，業務同事當場實操體驗并提出問題和建議。

實踐證明，該方案能有效解決版本上線前缺少UAT測試的問題。

4. 項目周例會

這個會議主要是向業務牽頭部門匯報上周的工作完成情況、本周的工作計劃和需要協調解決的問題，重點是匯報需要業務牽頭部門協調解決的問題，盡量把問題提早暴露出來，做到以周為維度推動相關問題的解決，避免問題堆積。

5. 版本上線匯報

在每個版本上線后，主動去需求提出人員及其領導處進行匯報，告知功能已上線，邀請其進行體驗。這樣一方面可以盡快進行生產驗證，一方面可以展示項目組的工作成果。

6. 成果匯報

每個月定期給業務牽頭人提供一些可供匯報的工作成果（比如系統重點功能的使用數據、本月上線的功能為業務辦理和公司管理提供了哪些便利等），讓該項目成為業務牽頭人的重要工作成績，從而不斷提高其對于項目工作的積極性。