實戰復盤:從0到1如何構建定制化的數據系統?
在初次進行數據系統搭建時,產品經理可能會遇到哪些困難?也許你需要結合需求的全流程進行系統搭建。本篇文章里,作者結合實戰經驗,對其從0到1搭建數據系統的過程進行了復盤總結,一起來看看吧。
從產品團隊運作的工作方法和程序,結合實踐結果來談談第一次做數據產品時常見的坑,
這個項目是為一家食品公司制作的數據看板,從用戶心聲和賠付2個模塊幫助其企業進行成本分析,找到對應的責任方來共同分擔售后賠付壓力。
一、產研團隊的搭建
因為項目的周期非常短,需要一個月的時間實現從0到1的上線,涉及的數據及判斷規則較多。對于從來沒有做過數據產品設計的團隊來講都是摸石頭過河,但還是需要繼續往前走。
確定需要的資源,臨時搭建一個數據小分隊,包含了產品、設計師、后端研發、BI數據師。沒有測試和項目經理的充足的資源,這部分工作由產品兼任。具體的人員從各個職能組中抽選出,然后搭建數據項目組,矩陣型的團隊組成方式能夠非??焖俚仨憫o急的任務。
二、產品策略的制定
這是一個KA-S級的客戶,公司非常重視大客戶的交付和服務。所以在整個項目的啟動開始,整個流程都備受公司的關注。由于項目前期遇到了不可避免的原因,客戶的業務進行了提前,所以要求我們提前完成系統的交付使用。雙重的壓力讓整個團隊都非常忙碌,一個月內處于24小時待命的狀態。
每個項目都應該有個交付清單和功能范圍邊界。在進入需求的調研前期,我們是需要銷售、客成、產研與客戶方進行明確的信息同頻。這不僅讓整個項目有目標,也避免交付階段的矛盾。
三、獲得用戶反饋及需求
確定了范圍后,我們就進入到需求的討論階段。并不是每個客戶都對自己業務非常熟悉,所以幫助客戶慢慢梳理清楚自己業務流程也是一個必要的過程。
最開始,我們與客戶的信息和重要程度是沒有對齊的。我們緊急時,客戶松弛。在全局的產品策略當中,雙邊拉扯的時間和周期非常長。
如何讓客戶不要無限地修改需求呢?以下2點很實用:
- 確定需求的階段最好拉上最后以公司名義拍板的負責人;
- 最后的需求內容及方案在口頭交流后以郵件的形式做二次的確認。
四、需求管理
當然,肯定是存在一些需求是在前期沒有覆蓋和想到的。因為數據類項目無法考慮到完全的方方面面,可能會存在很多的意外,比如技術上的無法實現、平臺的數據不全、或者第三方公司不進行技術配合等等。
所以,為了保證信息的及時溝通,需要搭建一個公開的產研溝通群,遇到具體的問題隨時溝通。無論是產研團隊還是客戶方面。
所以,我們需要進行好需求的管理,包含以下幾個方面:
1. 對產品需求進行必要的分類
比如哪些是客戶提出的?哪些是產品的規劃?對于B端的需求來講,產品規劃不一定滿足客戶的業務需求,還是需要根據實際情況來決定??蛻舻男枨笠膊徊⒉皇菍嶋H的業務需要。
2. 記錄產品需求的重要屬性和背景信息
任何事情多問自己幾個為什么?直到問到明確的答案。我的老板經常會問我為什么很重要?解決什么問題?背景是什么?一定要這么做嗎?不做會有什么影響?如果自己沒有辦法想的很清楚或者很有條理,可以用筆寫下來。在日常的生活中不斷地聯系,深度思考是非常重要的!
3. 評估產品需求的預估價值和投入
是不是所有重要的產品需求都要馬上做?對于數據類的項目而言,客戶覺得每個需求都是非常緊急和重要的,有很多自己的實現想法。怎么更高效地和客戶達成方案的價值共識呢?
- 可以先安撫客戶的情緒,讓她認真地講遇到的問題,耐心傾聽就可以,最后告知我們會進行調研然后我們再溝通下具體的方案;
- 保證方案不止一個,多想可實現的方案,然后與技術團隊進行內部思想爆炸;
- 將每個方案的實現過程、利弊以及投入列舉出Excel表,讓客戶做選擇題;
- 從業務的角度為客戶思考,為他推薦一種最友好的方式。
4. 確定產品需求的優先級
一下子把全部的需求做完?肯定不是的。因為是一個數據項目,所以我們考慮的角度是這個需求如果不做,這個系統可不可以用?如果不行,那么就必須完成。
然后對需求進行重要程度的打標,產品方案評審后與技術團隊共同進行拆任務和確定時間,給到交付時間給客戶。盡可能任務細致,把時間排的更合理,有充裕的時間進行周轉。
5. 對產品需求的狀態進行跟蹤
因為項目經理的缺失,產品需要兼任對應的工作。其實,在很多公司,大型的項目會有專門的項目經理 。但是對于比較小或者急的項目,大概率是沒有專門的項目經理來推動。所以,掌握一定的項目管理能力是非常有必要的!
無論是整個項目的研發管理表,還是細化的小需求,我們都需要有專門的文件進行管理。前期,因為需要和客戶進行每日研發工作的同步,所以采用的是飛書的表格管理,甘特圖形式來跟蹤。便于內部的成本預算等方面的考慮,我們會同步在JIRA上進行需求的記錄。
因為是B端的項目,相較于C端必做的競品調研,我們更關注客戶的業務情況。什么事業務情況?直白來講,他們到底是怎么用的?如果用軟件來代替,那么能夠解決什么問題?有什么更好的效益呢?如果做不到基礎的收益, 那么這個產品是不會被客戶買賬的!
五、產品功能-規劃
確定要做的內容和大概的方案后,那么要考慮地更細,因為數據指標一定要考慮是什么,怎么算以及怎么來的問題。如果前期沒有思考到,那么后續的問題會接踵而至。指標與指標之間是相互制約和聯系的。
所以怎么做好數據項目呢?首先是確定有哪些數據指標及對應的計算規則。從原始數據層、維度數據層、明細數據層、匯總數據層和應用數據層5個層次去考慮??梢杂昧鞒虉D將數據的流轉過程進行記錄。比如從哪些地方獲取數據,如何獲取,增量還是全量?
用流程圖表示的方法需要注意直接易懂、布局清晰及邏輯完整,這可以很大程度較少團隊之間溝通,也是讓客戶更好確定業務是否是這樣的。
接下來是原型的設計,因為現在公司采用數據項目使用前端輕代碼,所以頁面可以直接在一個系統上套用,選擇對應的展現形式,放上SQL語句就可以使用。如果要進行界面或者格式的調整,可以馬上修改后立即進行發布上線。
最后是成型的方案,因為迭代的需求會比較多,更改的細節也會多。所以一定是要寫文檔,并且非常細致。在文檔的開篇要注明版本記錄。這便于后期可以去查詢,代碼回滾等也更好追溯。
六、研發、測試并上線
雖然前期準備地比較充分,但在研發的過程中仍然會忽略一些小的細節。所以團隊內部要保持足夠的信息溝通,不能因為個人的原因被卡住,每日的敏捷站會的幫助非常大。內部固定一個時間,用15分鐘聚在一起,聊下遇到的問題和待解決的事項。
最困難的階段是數據校驗,如果這個模塊不行,相當于前期所有的努力都是白費的。這個項目沒有測試,產品兼測試也是常見的。所以,平時可以多看看數據分析及測試方面的內容。
經歷過一次小白測試后,在數據項目重點看功能使用、數據準確性以及數據壓力三個方面。首先是在視覺上功能能不能用,不可以點擊或者使用失敗的功能就要及時撤掉。然后是數據準確性,因為這個項目涉及到調用內部數據和導入外部數據,所以數據源的準確性和結果的準確性都是非常重要。
測試的過程中很容易忽略數據壓力,單天的幾萬條可能是好的。如果是查詢一個月的量是否響應足夠快?如果是下載,是不是可以下載的?可以邀請公司的小白用戶來體驗項目,他不用看業務,可以體驗使用的感受。
七、項目管理
聽下來,是不是覺得項目很順利完成的?其實,并沒有,中間產研團隊幾乎每個人都有做到崩潰。熬夜加班,連續3個周末無休是正常的。有時候,周末經常會接到客戶的消息,他們很著急分享觀點。遇到很多的問題,我們提前告知給客戶,但是他認為產研總是會有問題。
不被理解,質疑和老板的施壓像家常便飯。但是產品經理哪有那么容易被打倒,所以做項目考驗能力的同時也是在錘煉自己冷靜從容的心態。
項目管理也是我做這個項目遇到的困難,因為項目緊急,我臨時被老板拉進來做產品方案的設計。產品和研發同時被告知1個月做項目,項目經理安排好進度表(前期本來是打算有的,因為被投訴所以取消了)。產品和研發的時間非常少,我以為所有的需求溝通好,但是一切為0。
1個月的時間完全不夠,且前期承諾給客戶的內容太多,導致實際無法支持到。并且客戶投入的錢與實際的價值太大,公司不愿意投入過多的資源做。雖然是知道賠本的生意,為什么要做?一是公司的形象,二是需要該行業的口碑。
所以,前期沒有具體的方案時,不要拿空大的話去承諾。如果不能交付就是會被打臉。前期我們的壓力非常大,客戶無數次說如果你們不能按照這個時間給我們,就算違約收傳票。
不做這單生意挺簡單,但是這個行業的單子可能都沒有了。做好客戶的前期預期和項目管理也是非常重要的是。這個項目管理并不是說產研的進度,包含了人力資源、產品范圍、成本預估、里程碑計劃、風險管理及整體溝通機制。
積極、主動和認真,即使再困難的項目也會有結果。最后,我們終于做完了這個數據項目。過程很痛苦,結果還是存在的。我也是既會做業務也會做數據的小產品啦!bingo~
總結
理論永遠要和實踐結合起來,或許書里的方式與自己非常契合,或許完全不適用。多聽、多看和多做才有可能變得更好,期待我們一起努力~
本文由 @萌沐 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!