個人做一個帳單還款記帳的產品好實現嗎？我們可以嘗試一下。每個人都可以當一次產品經理，藉此實戰，和大家分享一下產品實現的一些方法論。
1. 前言
現在我們基本上大多數人每個月都有各種需要還款的帳單，要麼是房貸，要麼是信用卡。對於我自己，信用卡也比較多，每個月要還房貸，還信用卡，為了防止漏還，還專門做了一個Excel進行記錄。之前和幾個朋友吃飯聊天，發現有朋友也在用Excel記錄每個月的還款。
像我這樣的用Excel記錄每月還款，應該也有不少。使用Excel記錄，在PC上操作比較方便，顯示屏幕大，信息顯示直觀，操作比較方便。不過在移動端上操作，就不是很便捷。心裡就想，要不要自己也做一個在移動端使用的帳單還款助手。可以方便大家在移動端記錄每個月帳單的還款，防止漏還款逾期造成的逾期風險。市面上有這種功能的產品有很多，都是好幾個團隊協作完成的。
個人做一個帳單還款記帳的產品好實現嗎？我們可以嘗試一下。每個人都可以當一次產品經理，藉此實戰，和大家分享一下產品實現的一些方法論。
2. BRD之競品分析
我們都知道，產品經理涉及的三大產品文檔，分別是BRD（Business Requirement Document，商業需求文檔）、MRD（Market Requirement Document，市場需求文檔）和PRD（Product Requirement Document，產品需求文檔）。
一般而言，BRD是基於商業目標或價值所描述的產品需求內容文檔。類似於我們軟體工程中所提到的可行性分析。你計劃設計的產品在投入研發之前，為企業高層提供決策評估的依據。如果大家要做創業計劃書，BRD也是很重要的一個部分，一般會涉及市場分析，銷售策略，盈利預測。BRD通常是供決策層們討論的演示文檔，一般比較短小精煉，沒有太多的產品細節。說的直白一點，就是這款產品值不值的做。
產品經理在進行產品設計前，最重要的就是進行競品分析。通過競品分析，你可以更清晰的理解自己產品的價值主張，對方的產品優勢與劣勢有哪些，自己將要做的產品同競品的差異點有哪些？自己產品的定位與賣點。用戶或是消費者，使用我們的產品而不使用競品的理由是什麼？
如果我們分析完成，自己都說服不了自己，那產品也就沒有再繼續設計下去的必要。俗語說，知己知彼，百戰不殆。如果產品經理沒有去做產品調研，競品分析，投入了很多時間和金錢，結果產品投向了市場才發現沒用戶，那就為時已晚。
我們選取市面上比較主流產品的帳單還款產品。分別是銀聯雲閃付中的信用卡功能、支付寶中的信用卡功能和業界主打信用卡帳單管理的「51信用卡管家」。
2.1 銀聯雲閃付-信用卡還款
銀聯雲閃付中的「信用卡還款」是銀聯雲閃付中比較重要的一個功能。依託銀聯本身的優勢，銀行也為銀聯提供了各種數據API，銀聯可以把綁定的各家銀行信用卡的帳單日、最後還款日、帳單金額、最小還款金額，實時為用戶展示。這是銀聯信用卡還款產品的一大特點。
還信用卡免手續費，用戶在還款時不會有額外支付其他費用的顧慮，由於是實時到帳，給用戶的還款體驗不錯。添加信用卡的功能也比較方便，提供了OCR（Optical Character Recognition，光學字符識別）支持，免去了用戶添加信用卡輸入卡號的繁瑣。
另外，還提供了在線申卡的功能，可以很方便申請各家銀行的信用卡，為各家銀行導流。銀行為銀聯提供API（Application Programming Interface，應用程式接口），銀聯幫助銀行獲客，也算是互惠互利，合作共贏。銀聯信用卡還款產品定位明確，信用卡帳單顯示與還款整個流程非常流暢，但缺少對非信用卡還款的支持，比如消費貸款、房貸、交房租等帳單的記帳還款功能。
2.2 支付寶-信用卡還款
支付寶也為用戶提供了信用卡還款產品。可以將用戶綁定在支付寶的信用卡在信用卡還款列表中進行展示。但部分銀行不提供帳單應還金額的實時查詢功能，在信用卡實時查詢的範圍上，不如銀聯雲閃付所覆蓋的銀行全面。
對於信用卡的還款，需要自行設置還款時間。而且還信用卡需要支付一定的費用，也沒有標明實時到帳，只是提示「預計今天到帳」，和銀聯相比在到帳時效上，缺少些自信。不知道對於信用卡還款有多少用戶願意為此付費。
支付寶信用卡還款產品提供了「添加還款類型」功能，不僅可以添加信用卡，也可以添加房貸、車貸、房租的還款信息，這點比較人性化。為用戶提供了更多的記帳類別，便於用戶查看自己不同的還款項目，這個很不錯。
2.3 51信用卡管家
51信用卡算是在網際網路行業主打以信用卡還款產品為核心的企業了。支持用戶添加信用卡帳單和生活帳單，統計比較全面。帳單匯總功能，可以查看名下各帳單的還款情況，並為用戶提供了信用卡消費分析。為客戶提供了除帳單管理的額外增值服務。對於51信用卡而言，其Slogan是「讓有信用的人過得更好」，可見信用卡帳單管理對用戶來說功能是免費的，不是51信用卡營收的直接來源，但通過引流，最終通過發放貸款進行賺錢。
不過，對於用戶而言，核心訴求還是想記帳，其他功能，例如提供還款功能，是加分項。用戶還款，也不是實時到帳，產品提示是「預計1h到帳，次日入帳」，對於還款手續費，當月只有6000元的還款額度，超出額度，要額外支付0.2%的手續費。對於經常還大額的用戶來說，可能更傾向於選擇免手續費的還款方式。
由於51信用卡缺少同銀行API對接，無法為用戶提供實時的帳單信息查詢，只能通過用戶提供自己接收帳單的郵件帳號，51信用卡通過讀取用戶郵箱中的銀行帳單，提取信用卡帳單還款數據。也算是一種折衷的辦法。但對於我自己而言，我是不希望把自己郵件的用戶名和密碼提供給第三方機構，讓其讀取我郵件中的內容。感覺有一些安全上的顧慮。
2.4 小結
結合以上分析，我整理了一個功能表格，如下所示。
可以看出，雖然僅是帳單還款這麼一個小功能，各家產品也有各家產品的基因。不同用戶可以根據自己需要選擇產品。而像我這一類的客戶，不願意提供郵件帳號密碼給第三方，又希望支持其他帳單有還款記錄，也不在意對方提供不提供實時還款的功能，就是希望有一個單純的記帳和查看功能。
產品更加輕量簡潔一些，只想要記帳這個核心功能，相當於要給這些產品做減法。目前上有這樣單純的產品嗎？還沒有，都是流量入口，大家都希望提供更多的功能來增強用戶粘性。而有像我這樣就想單純的記帳用戶嗎？應該也有。
3. MRD之產品設計
MRD可以通俗地理解為準備做某一款產品，市場層面打算想做成什麼樣的說明，其作用是承上啟下。
一方面，對BRD中領導層的的意見和公司戰略方向進行整合，提煉核心功能與核心價值，另一下面，對即將編寫的PRD，為其明確產品範圍、功能定義，防止產品設計與最初的目標不一致的情況出現，可以理解為MRD是一個指導性的框架說明文檔。
有些公司前中後臺產品經理分工比較細，也可以理解為是我們常遇到的一句話需求。比如業務產品經理直接和技術產品經理說，我要實現一個業績查看的功能，可以查看、導出某個時間範圍內的團隊業績。接下來技術產品經理會根據業務產品的這句話，編寫PRD。說的直白一點，就是這款產品打算怎麼做。
3.1 產品定位
如果我也想做一款像銀聯、支付寶、51信用卡功能這麼齊全的帳單管理產品，即便是技術可行性和經濟可行性，都具備，還不具備時間可行性。帳單管理產品，在這幾家公司都是幾個團隊配合，至少投入十幾個人的人力和資源才開發出來的。
而由於其用戶群體的廣泛性，需要圍繞帳單還款這個核心功能擴展出很多衍生功能。而現實中，即便是使用了這些功能的用戶，仍然也在使用Excel記錄自己的帳單還款情況。而我的還款產品的定位，就是希望能為使用Excel記帳的用戶，提供移動便捷的記帳功能。
3.2 產品框架設計
將產品功能做減法後，僅保留幾個必要功能。
用戶相關模塊，用戶註冊和登錄是必不可少的。由於產品設計的初衷是儘量不收集用戶信息，因此用戶註冊中，僅需要輸入用戶名和密碼即可，對於自願的用戶，可以提供電子郵箱地址，認證通過後的用戶，可以用來使用密碼找回功能。
帳單還理模塊，用戶可以自行新建帳單月份，在月份中錄入還款項名稱，帳單日，最後還款日，帳單金額 和已還金額，系統會自動計算剩餘應還金額。月份列表，會匯總當月所有還款項的帳單總金額，已還總金額和剩餘應還總金額，方便用戶直觀查看自己的還款情況。
考慮到用戶新增月份後，每個月都要新增還款項比較繁瑣，為用戶提供了還款項智能模版功能，用戶新增月份後，不需要再錄入還款項，會自動將上個月的已經錄入完成了還款項名稱帶入，用戶只需要填寫本月的帳單金額即可。
還款趨勢分析是一個額外的附加功能，便於用戶直觀查看每個月總的帳單情況和還款情況。
3.3 產品流程設計
既然我們的產品是定位一款極簡的還款記帳產品，我們就要先明確核心流程。對於產品流程設計，我們可以採用自底向上或是自頂向下的設計方法。自底向上，就是我們先明確最基礎的功能流程，將一個個基礎功能流程整合起來，形成最終總流程，向頂向下的設計方法，則是先明確總流程，然後再將總流程中涉及的每個子流程進行細化。
我們這款產品採用自頂向下的流程設計方法，經過分析，我們這款產品流程設計如下所示。
用戶註冊登錄、用戶信息管理、密碼修改、郵箱管理這些產品的基礎功能太基礎了，就不在這裡特別介紹了。接下來主要介紹還款記帳的核心功能。在準備做這款產品前，我自己覺得非常簡單，但在實現的過程中卻發現有很多值得考慮的細節。在這裡分享給大家。
4. PRD之產品功能設計
PRD就是將產品理念進行落地的文檔，主要面向團隊開發人員，設計（UI、UE）、測試、運營等，需要更加詳細的去闡述所有功能。就產品流程而言，其實PRD也不是產品的最終文檔，還可以繼續分拆為需求說明書、設計說明書、測試說明說、運營說明書等。PRD中主要會描述詳細的功能說明和業務流程。說的直白一點，就是這款產品如何落地推向市場面向用戶。
4.1 產品主頁面
產品功能設計採用產品MVP（Minimum Viable Product，最小可行性產品）理念，先滿足核心功能。用戶希望有一輛車解決出行痛點，我們就先造一輛車讓用戶先開起來，至於裡面有沒有空調，座椅是不是真皮，暫時不重要。
本次的產品功能設計也是如此，為了方便用戶直觀體驗產品功能，用戶不需要註冊，就可以先體驗。因為好的產品不應該綁架用戶。有些產品設計，用戶不註冊，就不讓用戶體驗產品是不對的。
主頁中，突出了「開始記帳」的按鈕，方便用戶可以第一時間找到記帳入口。如果用戶還沒有登錄，則會先為用戶展示登錄頁面。用戶登錄完成，進入到每月的還款匯總列表頁面。
4.2 還款月匯總頁面
還款項都是以每個月份進行承載，所以我們的視圖設計，也是基本還款記帳月份列表進行展示。用戶查看自己的還款帳單，一般都是看這個月份總共需要還多少錢，已經還了多少錢，還剩下多少錢未還。
按照流程設計，用戶從列表頁面可以查看月還款項細節，不過首次使用的用戶，在新增完成記帳月份之後，不能第一時間知道從哪開始新增還款項。因此細節上，在每個月還款的卡片上，將」查看」，改為記帳。
4.3 還款項新增與編輯
用戶選擇記帳年和記帳月份，點擊 「新增記帳月份」會為用戶新增一條記帳月份卡片。
用戶點擊月份卡片中的「查看」，會為用戶顯示月份下的還款項明細信息，用戶也可以進行還款項的新增、編輯、刪除操作。
新增完成記帳項後，會實時顯示新增的還款項卡片。為了用戶方便了解還款項數量，在每個還款項名稱前進行自動編號。同時，為了便於用戶關注自己的還款情況，將剩餘還款金大於0的金額標紅。考慮到刪除是個相對比較謹慎，因此功能放置在編輯的下一級，而沒有同編輯平級。
4.4 安全設計
而每次我們修改每一還款項的還款金額時，當月的總還款情況都需要同步更新，這就需要在產品設計的內部，定義一個觸發器，以確保各數據都可以實時更新。以確保數據準確。
防注入設計，因為我們在使用ID錄入還款項時，要對傳入的ID進行認證，對於不合法的ID要進行過濾。否則會有注入風險。後續如果為了保證數據傳輸安全，還可以通過配置權威機構認證的數字證書，採用https的方式進行數據傳輸。
5. 總結
最後，我們通過KANO 模型進行我們產品的功能分析，看看我們是否遺漏優先級比較高的功能。KANO 模型原本是用於對用戶需求進行分類和優先排序的工具，通過分析用戶需求對用戶滿意的影響，從而了解產品性能和用戶滿意之間的關係。
很明顯，優先級比較高的幾個核心功能，都已經實現了。接下來就是我們要考慮如何能給用戶提供能令用戶「尖叫」的功能了。因為我們這款產品為用戶提供的還款記帳基礎功能，只是解決了用戶還款記帳的痛點，如果想要用戶體驗更好，我們還要做一些錦上添花的功能，滿足用戶的爽點，同時藉助於口碑，進一步為其他用戶群體提供癢點。但不論怎樣，我們都要圍繞我們產品的定位，一款極簡的還款記帳工具。
這樣一個基本的帳單記帳小助手的產品就完成了。當然產品細節還有需要打磨的空間，比如一些操作過程中的異常處理和提示。整個流程是不是還有進一步提升用戶體驗的空間。既然是談到實戰， 就要看實際的效果。
其實使用MVP理念，可以先用最小成本將產品投入市場，根據用戶和市場反應，不斷升級迭代。這樣用戶的學習成本也相對較低。這次的產品採用H5和PC自適應技術，用戶通過手機瀏覽或是PC瀏覽，會自行適配。接下來，可以進一步開發帳單記帳小助手的小程序版本和APP版本。
有溫度的產品源於有溫度的員工和企業文化。做為產品經理，我們首先站在用戶的角度去看待問題，規劃產品。希望我們彼此，都能做有溫度的人，設計有溫度的產品。
作者：王佳亮，中國計算機學會（CCF）會員。
本文原創@王佳亮 發布於人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議