初創團隊為何需要做產品核算？

導語：很多人都認為，核算是總結色彩濃厚的概念，不適於快速反應的初創團隊。但對於我們這些雜牌軍游擊隊、沒有什麼成功經驗的初創團隊來說，應該心態上擁抱變化、準備上制定充分的計劃

今天說說最近已經與團隊中不少人都談到的「產品核算」。

一提到核算，很多人都會不自覺的以為，那是總結色彩濃厚的概念，不適於快速反應的初創團隊。其實，如果準備充分，完全可以在產品開發之前展開。又或者說，從我們準備做一款產品之前，就有意識地為產品制定一些標準。雖然大多數產品在後期運營中，都會經歷過重大調整，但也有不少產品，從首個版本起，核心架構與功能，一直沒有發生太多變化，而是不斷穩定與優化。所以我還是建議大家，心態上擁抱變化，但在準備上制定充分的計劃，尤其對於我們這些雜牌軍游擊隊、沒有什麼成功經驗的初創團隊。

切入正題，我理解中的產品核算，包括四部分：UE核算、UI核算、功能核算、體驗核算。（後期還會有運營核算）

一、UE核算能讓標配功能最快定稿，為後續開發降低不確定性

所謂UE核算，就是專門針對產品原型設計的核算。普遍理解中，產品原型設計往往是發揮空間很大的，甚至可以是很粗糙的，拿我們的項目來講，有很長一段時間，在原型設計中，對於不同類型的功能、交互、界面、icon以及對針對的文案，都沒有系統的標準與核算。表面看上去，它最大限度的提高了UE的生產速度，但弊端與隱患很多，尤其會影響後續開發。

階段性回頭看，任何一類產品，無論是閱讀類、遊戲類、電商類、社交類……在原型設計上，都有很多相同之處，我認為，一款好的產品原型，並非是完全新創的，而是要在已有的品類中，找到自己的定位，進行針對性的功能差異化與體驗優化。

拿我們產品來說，個人資料頁面的上傳頭像、完善資料、進行隱私設置等功能，幾乎是社交類產品的必備功能，就好比韓國餐廳的餐前小菜，它是標配的概念。可以進行創新，但對於一個初始版本的產品來說，一定不是重點，創新空間也有限。因此，對於類似標配的功能、標配的交互，就完全可以先進行標配設計，儘早定稿，不輕易修改。

它的好處是什麼？避免在後續環節中，比如UI設計、功能優化等過程中，造成不必要的改動與人力成本的浪費。毛主席早就說過，集中精力辦大事兒，抓主要矛盾。對於做產品來講，原型設計過程中，尤其要抓好主要矛盾，把精力用在最重要的事情上。

UE 核算要做到什麼程度？以我們項目來說，要保證產品結構的確定、核心交互界面的確定，原型設計中，能夠復用的界面，一定要學會復用。一來，這是實現極簡的有效方式；二來，這會大大降低用戶的學習成本；三來，它會讓你的產品，有著系統性與整體性，不會讓用戶在交互的切換中，彷彿完成產品之間的轉換一樣；最後，也是非常重要的，就是節省UI設計師與開發工程師的工作量，最大程度的加快項目的進度，提升項目的可控性。

別小看原型設計，原型設計不僅是一個產品投入生產過程中的起點，原型設計的確定與清晰程度，還直接決定後續工作的穩定與流暢程度。

所以，UE核算，對於一個產品團隊來說，是一種理念，一種對後續工作深度負責的理念。不要它看成是一種包袱，好的UE核算是有主次、有標準、有梯度的，它能夠讓團隊尤其是產品經理，對產品結構、對產品今後的開發工作如指掌。（別笑，現實是產品開發過程中，大多數產品經理，都有被技術或者UI同事問住的時候，最終還得重新翻UE來回答，在我身上就發生過不少，慚愧）。甚至，如果UE核算做得充分，還能為產品的後續拓展與升級，降低開發成本。

二、產品經理要幫助UI設計師提前完成UI核算

所謂UI核算，就是針對產品界面設計的核算。對於有經驗的設計師來說，這都是小兒科的事兒。但現實情況是，產品團隊非常多，而有經驗又懂產品的UI設計師，非常稀缺。怎麼辦？我們在第一版產品開發中，就沒能事先制定UI核算，包括我們的UI設計師也沒有真正的客戶端產品的設計經驗，所以我們走了一些非常不必要的彎路，甚至還發生過一些爭吵。

因此，如果你是團隊負責人，你最好能夠幫助讓你的UI設計師，從一開始就制定一張UI核算單。而不是僅僅依靠設計師的喜好與直覺來設計產品。否則，即便每個界面分別看起來不錯，也掩蓋不了整個產品界面的不系統與不規範。而且，對於移動互聯網產品來說，前端開發的工作量在很大程度上都與UI有關。如果你是一個對UI標準很高的產品經理，那你就要學會利用UI核算，幫助設計師實現最完美的界面，找到最佳的工作節奏，同時控制好工程師的開發量。

UI核算之於UE相對簡單，我認為首要任務是確定產品的設計風格。（不是直覺上的設計風格，一旦以核算作為標準，將沒有「我覺得，我認為」這些模稜兩可的概念）

再拿我們項目來說，我首先和設計師提出的要求是扁平風格，盡情擁抱iOS7，然後就是主色系、視覺氛圍等方面的要求。這幾點也是很多產品同仁最通用的常識。不過UI核算真的不只是這些，有了上文UE核算的基礎，UI核算要在間隔線、頭像、字體字型大小顏色（高亮）、按鈕、消息類型等分類通用設計上做足功夫，有特色又不過度設計。這就能在最大程度上，確保高保真的質量與切圖的規範，避免開發過程中，因為UI的不規範與調整，對進度造成影響。同樣，對於設計師本身的成長也有非常大的幫助。除此以來，還包括UI設計與開發同事，在配上流程上的核算，什麼時間提供什麼，提供到何種程度，這都是可以通過核算來規範的。

實際上，如果你用心看看現有的app產品，在UI設計上不規範，有明顯「BUG」的不在少數。雖然不會影響功能體驗，但好的產品體驗，既包括功能也包括視覺。所謂極致，二者缺一不可。何況，我一直以為，好的UI設計，一定是為產品加分且不影響項目進度的。在這一點上，我們真應該多向國外的同行學習。他們在細節的把握上，比我們到位，比我們用心，比我們有方法。

三、功能核算能夠促進工程師更多關注體驗

接下來是功能核算，包括前端功能，也包括後台功能。對於功能核算，我沒有太多發言權，因為我不是技術出身，但我一直有一個理念：僅僅把功能做完是遠遠不夠的。功能和體驗一定是連在一起的。最近幾個月，我花了很多時間和技術團隊溝通，就是希望技術團隊在進行功能開發的評估之前，就把體驗考慮到。

比如同樣的feed發布功能，目前市場上，就有多種現成的體驗可供選擇，有微博的發布體驗，有微信朋友圈的發布體驗，還有很多其他產品的發布體驗。工程師最容易陷入的思維是：最快並且穩定的（沒有BUG）的實現，而產品經理想要的卻是：實現的同時，能有著最好的體驗。但在工程師的標準中，體驗上的差別往往不那麼明顯，這種反差完全是由於分工不同造成的，並不是工程師不在乎體驗，畢竟誰都想做好產品，而且工程師往往是更加好勝的。

因此我建議那些經驗不太豐富的團隊，在功能評估時，最好能向工程師多問一句實現方式，順便把體驗兼顧了，多提醒這些技術天才們。否則，一旦開發結束，你跟工程師說，我想要的不是微博的體驗，而是朋友圈的體驗，這對於工程師的傷害是非常大的，改動的工作量往往也超出初創團隊的接受程度，畢竟，我們活下去的關鍵是快速迭代。如果不快，等你體驗好了，對手已經二次迭代了。

所以，我最近一直在和工程師溝通，在今後的工作中，確保每個功能在開發之前，都能把實現後的體驗兼顧到。評估的過程中，要對市場上同類產品中口碑好的功能點，做出調研。激勵工程師關注目前市場上同類功能中最佳的實現方式。否則，你做出來的，只是功能，遠遠不是市場上能夠生存的產品。

功能核算的另外一種好處，就是能夠促進工程師在功能點上的合理分工，讓每個工程師，在每個階段，都負責相同模塊的開發，持續深入下去，換來的結果自然是體驗上的不斷提升。

四、體驗核算應該融化到團隊每個人的心中

最後是體驗核算。其實在我心中，體驗核算是貫穿著產品工作的始終，我從來不覺得體驗是產品經理一個人的工作。它更應該融化到團隊每個人的心中，好的體驗應該是一種工作方式，一種生活方式，一種思維方式。當然，這非常難，對於初創團隊也很少奢望，但我想告訴大家，一旦你把對更好體驗的追求，講給團隊的每個人，總有一天，你會得到超乎想像的結果。體驗的升級，就好比龜兔賽跑中的烏龜，持之以恆，潛移默化，假以時日，天翻地覆。

在這裡，我舉一個與後台工程師的溝通的例子。之前的文章中，我提到過體驗很重要的一方面就是產品的性能。而這一點，後台工程師起到決定性的作用。比如載入速度上的0.1秒之差，都應該是後台工程師應該極力追求的。作為產品經理，團隊負責人，要想盡辦法，調動資源，鼓勵後台工程師，為類似的點滴細節，拼盡全力。

以我為例，對後台工程師提出了一個要求：把影響產品性能體驗的關鍵節點、關鍵指標數據化，然後做出不同階段的優化目標，我們不需要激進，不需要一步到位，但什麼時候能夠到什麼程度，要心裡有數，單單嘴上說說是無法達成的。

好了，作為一個新轉型的產品人，以上是我在最近半年工作中的一切感受，產品核算不是什麼新鮮概念，也不是什麼救命的奇葯，它更多是團隊工作的一種方法，一種思維，一種習慣。希望對正準備或剛剛轉型的產品人，有所幫助。寫得不對的地方，歡迎資深從業者指正。