自做產(chǎn)品以來，也經(jīng)歷過幾個版本。跟另外一個小伙伴搭檔，每個版本基本跟的需求都有一半一半。而我外加一個CMS后臺。小步快跑，兩個多星期一個版本。工作量大，卻也能快速成長。但每次功能需求想半天沒問題后，到真正開發(fā)時，卻總有缺漏。有些很深、有些很細節(jié)，有些讓人哭笑不得。甚至有些版本兼容問題沒想過，到發(fā)版后才發(fā)現(xiàn)。好在能在有方案可在API上進行修復(fù)，而不需要客戶端重新發(fā)。

還好開發(fā)測試都還好說話，看工作量跟排期能進行規(guī)則補充的商量。但有時信息同步不到位，排期又緊，難免會被批。最近一直在思考，功能設(shè)計上的缺漏，來來回回那么幾種，是否可進行歸納總結(jié)，以便日后設(shè)計功能時進行自檢。由此歸納如下八項功能自檢自查項目，望能避免被手撕。

需求 – 功能 – 交互 – 耦合 – 數(shù)據(jù) – 異常 – 兼容 – 風險

按照如上介紹的八項自查原則，讓我們逐一來看看吧！

一. 需求：

每個功能需求的提出之前，思考比對調(diào)研。這時候的功能自查是冒著推翻現(xiàn)有方案重來的風險。所以建議這一步放到產(chǎn)品需求提出的第一步自查。

需求的本質(zhì)相信大家都有了解。對需求的深挖是有層次的。我們來看那個熟悉的馬與車的故事：

很久之前有個年輕人想要去一個較遠的地方，他會跟你說他想要一匹更快的馬；

但其實際是希望有更快的交通工具，若能給他輛汽車或者發(fā)明個飛機，他是不是更開心；

這就深挖了需求？如果他其實是為接一位名醫(yī)給他父親看病，那他更深的需求是不是希望有更便捷更完善的醫(yī)療體系或私人醫(yī)生？

如果他父親生病是因為吃錯東西、著涼等等，那么24小時的貼身保姆等需求貌似就是更深的需求。。。

然而還有更深的事件耦合與需求

那么問題來了，怎樣的需求層面才足夠深？

需求，是一類場景下的共性訴求的具體呈現(xiàn)

我們知道，事物是普遍聯(lián)系的。每一件事情的發(fā)生都不是獨立的，而是有其前置條件與偶然因素的疊加。因此需求的深挖程度我們要把握好度。

• 是否覆蓋目標人群：若一開始那個騷年，是我們的目標用戶。滿足他更快出行是我們產(chǎn)品的定位的話，就不必細化。出行理由千奇百怪，那么不管每個人出行的原因。把握出行這個場景共性的訴求，就是更快更舒適，那就夠了。再細分下去，就超出目標人群，而涉及更喜歡的個體。
• 是否脫離原有屬性：產(chǎn)品的屬性是做交通工具，如馬車、汽車、飛機。而若如上故事所述，那就去到醫(yī)療領(lǐng)域甚至家政服務(wù)業(yè)，與原有產(chǎn)品屬性是脫節(jié)的。

需求深挖是縱向的，如上深度確定后就需要橫向選擇。比如如上的需求我們挖到更快的交通工具這一層，評估可以了。那么就進行需求方案的選取。

再者，如電商平臺，我們可以為用戶提供搜索功能，但搜索的關(guān)鍵是讓用戶更快更準地找到所需。那么個性化推薦系統(tǒng)、分類功效品牌等維度的商品篩選等，就是衍生的方案，可以一起做搭配做或短期內(nèi)擇優(yōu)來做，就是產(chǎn)品經(jīng)理要做的第一步自查！

二. 功能：

確認具體需求點后，需要分兩步進行功能自查

基本：

更快的馬對之前那位小騷年是短期能最快最好地實現(xiàn)的。這是其基礎(chǔ)之一。馬能跑完他想要去的距離，也是基礎(chǔ)功能。而且這馬不說拉馬車，至少能載得動這個人吧，不能人一上去馬就萎了。所以這匹馬基本不止是跑得快，還要是活得能載人能長跑。而很多人只想到馬跑得快就行，忽略這個場景下，需要滿足的其他基礎(chǔ)條件。

拓展：

這匹苦命的馬被設(shè)定好基礎(chǔ)功能后，我們還要想以后是否有其他擴展可能，比如馬身上搞個布袋方便以后放東西（即便這次騷年比較急不帶什么東西）。預(yù)留擴展的好處是顯而易見的。比如馬在設(shè)計時一次性把馬鞍麻袋啥的采購好，而下次需要裝東西的時候再修修補補啥的就可以而不用專門再去采購這些材料。擴展預(yù)留主要關(guān)乎成本！

三. 交互：

界面元素、交互是功能呈現(xiàn)給用戶的重要手段。而界面元素由于是偏向固定靜態(tài)的，所以設(shè)計時缺漏的概率不會像交互方面出現(xiàn)的那么高，這里更傾向?qū)换用嫔系淖圆椋缦庐敳粌H限于此：

跳轉(zhuǎn)規(guī)則：

當多個頁面間進行邏輯跳轉(zhuǎn)時，規(guī)則一定要定義好。之前負責一個搜索的功能。搜索頁去到搜索結(jié)果頁，結(jié)果頁重新點擊搜索框會回到搜索頁，而在此時未發(fā)生搜索時點擊返回是回到原有不清空的搜索結(jié)果頁還是直接跳出到搜索入口。一定要用流程圖畫好各種前置條件下的跳轉(zhuǎn)規(guī)則才能保證程序開發(fā)的無二性，就是其確定性。

動作數(shù)據(jù)

逆向：上下前后左右進出，這種具有逆向的交互往往我們在PRD中就申明定義了一種而忽略了另外一種相反情況。如某些頂部tab可左右滑動，且其交互是點擊只顯示一半的tab內(nèi)容，該tab會彈出至某個位置。而我們習慣性地進行右邊tab的描述，而忽略左邊的描述。（有些人可能會說這個左右交互一看就知道要一致的嘛，但實際上，你不說，人家不做。你懂的）

場景：數(shù)量、前置。

先說數(shù)量，一個模塊其中的具體內(nèi)容數(shù)量為1、2、3…各種數(shù)量時的情況。比如一個商品展示模塊，最多顯示四個，那么其獲取的數(shù)據(jù)超出該數(shù)量時如何取數(shù)據(jù)？若小于該數(shù)量，頁面如何展示排版。若干脆沒有數(shù)據(jù)，該模塊是否直接隱藏還是出現(xiàn)不一樣的交互控件去進行引流？

再者是前置：進入當前場景的前提條件不同，其顯示內(nèi)容則不同。從不同維度進入到一個商品列表頁面，可以從搜索、從分類、從品牌等不同維度進入。其前置場景不同，進入后顯示交互的各種樣式數(shù)據(jù)自然不同。

四. 耦合：

耦合是比較重要的自查點。比如在進行電商產(chǎn)品設(shè)計時，可能會對某個商品的展示樣式進行修改；直觀的，我們會對首頁，或者商品列表等進行修改。而若我們還有購物車、設(shè)置是個人中心中支持對商品的收藏，那我們是否要考慮各個耦合場景的樣式及數(shù)據(jù)內(nèi)容同步修改？一個APP中還包括push系統(tǒng)等非直觀場景可聯(lián)想到的，但卻有很多層級的耦合關(guān)系，所以耦合的場景需要遍歷清楚。

另一點就是數(shù)據(jù)的耦合，這更為普遍。前端展示的數(shù)據(jù)內(nèi)容有些是具有邏輯依賴的。如某個價格是通過原價跟折扣進行計算得出的。若要使用該最終價格，進行其他數(shù)據(jù)計算。而當一段時間后，我們忘記原有的數(shù)據(jù)邏輯，對原始數(shù)據(jù)邏輯進行修改，最后就會牽連有耦合的數(shù)據(jù)。

五. 數(shù)據(jù)：

數(shù)據(jù)能演變的玩法最多，也就有更多的狀況。特別是運營后臺進行錄入，前端進行展示的數(shù)據(jù)需要反復(fù)考慮。

默認：

如在后臺進行某項數(shù)據(jù)的插入錄入時，是否有給定默認值？一方面若默認值設(shè)置合適，可以減少運營人員的操作成本。另若運營忽略了該值的輸入時，該數(shù)值會為空。若給出必填提示，其實質(zhì)也增加操作成本。而這種情況，設(shè)置默認值是更為保險的方式。

邊界：

正常數(shù)據(jù)的錄入，也同時需要進行判斷。特別是邊界檢查。該數(shù)值超出合法區(qū)間如何處理？該數(shù)值填寫正確保存成功是否給出提醒。輸入超出邊界后是情況原有內(nèi)容還是只給個彈窗提示？

異常：

若數(shù)據(jù)輸入要求是數(shù)字，而此時進行文字的輸入會如何？數(shù)據(jù)在錄入時，發(fā)生斷網(wǎng)、瀏覽器異常關(guān)閉時，數(shù)據(jù)進行本地草稿保存？不同的異常情況也要根據(jù)不同需求程度去進行考量設(shè)計！

六. 異常：

異常的情況不止出現(xiàn)在數(shù)據(jù)上，在客戶端可能發(fā)生的情況更為多樣。如網(wǎng)絡(luò)異常導致數(shù)據(jù)加載失敗，用戶賬號異常導致功能限制，GPS定位失敗導致獲取地理位置失敗等情況。每個功能不僅要考慮順利的情況，還要考慮各種異常分支，并進行相應(yīng)的提示說明或跳轉(zhuǎn)等操作。

七. 兼容：

兼容性問題是優(yōu)化的重要限制點。有句話說得好“船大難掉頭”，一個產(chǎn)品功能多了后，各個功能間的耦合更多。一個改動會涉及方方面面。如前端展示的樣式發(fā)生改變，那么上線版本需要如何兼容。新版本中一個數(shù)據(jù)或樣式增加，老版本不支持，如何通過接口或其他方式對老版本的新增數(shù)據(jù)樣式進行過濾？或者老版本保留原有規(guī)則而新版本使用新規(guī)則與接口？

八. 風險：落地細節(jié)

風險評估是保證項目順利推進避免出現(xiàn)意外的情況的保障預(yù)警。如開發(fā)能力無法落實需求？開發(fā)時間無法掌控？客戶端對后臺數(shù)據(jù)的依賴導致客戶端先行而數(shù)據(jù)跟不上？特別是大公司平臺較多，相互依賴也多?？绮块T的需求排期若跟進不到位，容易出現(xiàn)需求一直被晾著無法按計劃實現(xiàn)。

以上幾點是近來對工作的一點小總結(jié)?？偨Y(jié)點是有優(yōu)化空間，但真正關(guān)鍵的是如何將上述自查項在具體功能需求中進行自我排查思考。
越來越發(fā)現(xiàn)產(chǎn)品經(jīng)理新手更多需要在執(zhí)行層面上下工夫。當然不是說在產(chǎn)品戰(zhàn)略或規(guī)劃方面要少思考。而是作為一個新人，其快速融入職場及職業(yè)角色的方向應(yīng)跟偏向落地。需求思考，功能落地，項目跟進，溝通掌控。對于項目來說，都是極為重要的。新手上路，產(chǎn)品不易，且行且總結(jié)！

作者：way菜畦（簡書作者）

原文鏈接：http://www.jianshu.com/p/5a59ecef471d

本文由 @way菜畦 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。