在初次進行數據系統搭建時，產品經理可能會遇到哪些困難？也許你需要結合需求的全流程進行系統搭建。本篇文章里，作者結合實戰經驗，對其從0到1搭建數據系統的過程進行了復盤總結，一起來看看吧。

從產品團隊運作的工作方法和程序，結合實踐結果來談談第一次做數據產品時常見的坑，

這個項目是為一家食品公司制作的數據看板，從用戶心聲和賠付2個模塊幫助其企業進行成本分析，找到對應的責任方來共同分擔售后賠付壓力。

一、產研團隊的搭建

因為項目的周期非常短，需要一個月的時間實現從0到1的上線，涉及的數據及判斷規則較多。對于從來沒有做過數據產品設計的團隊來講都是摸石頭過河，但還是需要繼續往前走。

確定需要的資源，臨時搭建一個數據小分隊，包含了產品、設計師、后端研發、BI數據師。沒有測試和項目經理的充足的資源，這部分工作由產品兼任。具體的人員從各個職能組中抽選出，然后搭建數據項目組，矩陣型的團隊組成方式能夠非?？焖俚仨憫o急的任務。

二、產品策略的制定

這是一個KA-S級的客戶，公司非常重視大客戶的交付和服務。所以在整個項目的啟動開始，整個流程都備受公司的關注。由于項目前期遇到了不可避免的原因，客戶的業務進行了提前，所以要求我們提前完成系統的交付使用。雙重的壓力讓整個團隊都非常忙碌，一個月內處于24小時待命的狀態。

每個項目都應該有個交付清單和功能范圍邊界。在進入需求的調研前期，我們是需要銷售、客成、產研與客戶方進行明確的信息同頻。這不僅讓整個項目有目標，也避免交付階段的矛盾。

三、獲得用戶反饋及需求

確定了范圍后，我們就進入到需求的討論階段。并不是每個客戶都對自己業務非常熟悉，所以幫助客戶慢慢梳理清楚自己業務流程也是一個必要的過程。

最開始，我們與客戶的信息和重要程度是沒有對齊的。我們緊急時，客戶松弛。在全局的產品策略當中，雙邊拉扯的時間和周期非常長。

如何讓客戶不要無限地修改需求呢？以下2點很實用：

1. 確定需求的階段最好拉上最后以公司名義拍板的負責人；
2. 最后的需求內容及方案在口頭交流后以郵件的形式做二次的確認。

四、需求管理

當然，肯定是存在一些需求是在前期沒有覆蓋和想到的。因為數據類項目無法考慮到完全的方方面面，可能會存在很多的意外，比如技術上的無法實現、平臺的數據不全、或者第三方公司不進行技術配合等等。

所以，為了保證信息的及時溝通，需要搭建一個公開的產研溝通群，遇到具體的問題隨時溝通。無論是產研團隊還是客戶方面。

所以，我們需要進行好需求的管理，包含以下幾個方面：

1. 對產品需求進行必要的分類

比如哪些是客戶提出的？哪些是產品的規劃？對于B端的需求來講，產品規劃不一定滿足客戶的業務需求，還是需要根據實際情況來決定?？蛻舻男枨笠膊徊⒉皇菍嶋H的業務需要。

2. 記錄產品需求的重要屬性和背景信息

任何事情多問自己幾個為什么？直到問到明確的答案。我的老板經常會問我為什么很重要？解決什么問題？背景是什么？一定要這么做嗎？不做會有什么影響？如果自己沒有辦法想的很清楚或者很有條理，可以用筆寫下來。在日常的生活中不斷地聯系，深度思考是非常重要的！

3. 評估產品需求的預估價值和投入

是不是所有重要的產品需求都要馬上做？對于數據類的項目而言，客戶覺得每個需求都是非常緊急和重要的，有很多自己的實現想法。怎么更高效地和客戶達成方案的價值共識呢？

• 可以先安撫客戶的情緒，讓她認真地講遇到的問題，耐心傾聽就可以，最后告知我們會進行調研然后我們再溝通下具體的方案；
• 保證方案不止一個，多想可實現的方案，然后與技術團隊進行內部思想爆炸；
• 將每個方案的實現過程、利弊以及投入列舉出Excel表，讓客戶做選擇題；
• 從業務的角度為客戶思考，為他推薦一種最友好的方式。

4. 確定產品需求的優先級

一下子把全部的需求做完？肯定不是的。因為是一個數據項目，所以我們考慮的角度是這個需求如果不做，這個系統可不可以用？如果不行，那么就必須完成。

然后對需求進行重要程度的打標，產品方案評審后與技術團隊共同進行拆任務和確定時間，給到交付時間給客戶。盡可能任務細致，把時間排的更合理，有充裕的時間進行周轉。

5. 對產品需求的狀態進行跟蹤

因為項目經理的缺失，產品需要兼任對應的工作。其實，在很多公司，大型的項目會有專門的項目經理 。但是對于比較小或者急的項目，大概率是沒有專門的項目經理來推動。所以，掌握一定的項目管理能力是非常有必要的！

無論是整個項目的研發管理表，還是細化的小需求，我們都需要有專門的文件進行管理。前期，因為需要和客戶進行每日研發工作的同步，所以采用的是飛書的表格管理，甘特圖形式來跟蹤。便于內部的成本預算等方面的考慮，我們會同步在JIRA上進行需求的記錄。

因為是B端的項目，相較于C端必做的競品調研，我們更關注客戶的業務情況。什么事業務情況？直白來講，他們到底是怎么用的？如果用軟件來代替，那么能夠解決什么問題？有什么更好的效益呢？如果做不到基礎的收益， 那么這個產品是不會被客戶買賬的！

五、產品功能-規劃

確定要做的內容和大概的方案后，那么要考慮地更細，因為數據指標一定要考慮是什么，怎么算以及怎么來的問題。如果前期沒有思考到，那么后續的問題會接踵而至。指標與指標之間是相互制約和聯系的。

所以怎么做好數據項目呢？首先是確定有哪些數據指標及對應的計算規則。從原始數據層、維度數據層、明細數據層、匯總數據層和應用數據層5個層次去考慮?？梢杂昧鞒虉D將數據的流轉過程進行記錄。比如從哪些地方獲取數據，如何獲取，增量還是全量？

用流程圖表示的方法需要注意直接易懂、布局清晰及邏輯完整，這可以很大程度較少團隊之間溝通，也是讓客戶更好確定業務是否是這樣的。

接下來是原型的設計，因為現在公司采用數據項目使用前端輕代碼，所以頁面可以直接在一個系統上套用，選擇對應的展現形式，放上SQL語句就可以使用。如果要進行界面或者格式的調整，可以馬上修改后立即進行發布上線。

最后是成型的方案，因為迭代的需求會比較多，更改的細節也會多。所以一定是要寫文檔，并且非常細致。在文檔的開篇要注明版本記錄。這便于后期可以去查詢，代碼回滾等也更好追溯。

六、研發、測試并上線

雖然前期準備地比較充分，但在研發的過程中仍然會忽略一些小的細節。所以團隊內部要保持足夠的信息溝通，不能因為個人的原因被卡住，每日的敏捷站會的幫助非常大。內部固定一個時間，用15分鐘聚在一起，聊下遇到的問題和待解決的事項。

最困難的階段是數據校驗，如果這個模塊不行，相當于前期所有的努力都是白費的。這個項目沒有測試，產品兼測試也是常見的。所以，平時可以多看看數據分析及測試方面的內容。

經歷過一次小白測試后，在數據項目重點看功能使用、數據準確性以及數據壓力三個方面。首先是在視覺上功能能不能用，不可以點擊或者使用失敗的功能就要及時撤掉。然后是數據準確性，因為這個項目涉及到調用內部數據和導入外部數據，所以數據源的準確性和結果的準確性都是非常重要。

測試的過程中很容易忽略數據壓力，單天的幾萬條可能是好的。如果是查詢一個月的量是否響應足夠快？如果是下載，是不是可以下載的？可以邀請公司的小白用戶來體驗項目，他不用看業務，可以體驗使用的感受。

七、項目管理

聽下來，是不是覺得項目很順利完成的？其實，并沒有，中間產研團隊幾乎每個人都有做到崩潰。熬夜加班，連續3個周末無休是正常的。有時候，周末經常會接到客戶的消息，他們很著急分享觀點。遇到很多的問題，我們提前告知給客戶，但是他認為產研總是會有問題。

不被理解，質疑和老板的施壓像家常便飯。但是產品經理哪有那么容易被打倒，所以做項目考驗能力的同時也是在錘煉自己冷靜從容的心態。

項目管理也是我做這個項目遇到的困難，因為項目緊急，我臨時被老板拉進來做產品方案的設計。產品和研發同時被告知1個月做項目，項目經理安排好進度表（前期本來是打算有的，因為被投訴所以取消了）。產品和研發的時間非常少，我以為所有的需求溝通好，但是一切為0。

1個月的時間完全不夠，且前期承諾給客戶的內容太多，導致實際無法支持到。并且客戶投入的錢與實際的價值太大，公司不愿意投入過多的資源做。雖然是知道賠本的生意，為什么要做？一是公司的形象，二是需要該行業的口碑。

所以，前期沒有具體的方案時，不要拿空大的話去承諾。如果不能交付就是會被打臉。前期我們的壓力非常大，客戶無數次說如果你們不能按照這個時間給我們，就算違約收傳票。

不做這單生意挺簡單，但是這個行業的單子可能都沒有了。做好客戶的前期預期和項目管理也是非常重要的是。這個項目管理并不是說產研的進度，包含了人力資源、產品范圍、成本預估、里程碑計劃、風險管理及整體溝通機制。

積極、主動和認真，即使再困難的項目也會有結果。最后，我們終于做完了這個數據項目。過程很痛苦，結果還是存在的。我也是既會做業務也會做數據的小產品啦！bingo~

總結

理論永遠要和實踐結合起來，或許書里的方式與自己非常契合，或許完全不適用。多聽、多看和多做才有可能變得更好，期待我們一起努力~