如何避免被程序員手撕——產品八項自查
自做產品以來，也經歷過幾個版本。跟另外一個小伙伴搭檔，每個版本基本跟的需求都有一半一半。而我外加一個CMS后臺。小步快跑，兩個多星期一個版本。工作量大，卻也能快速成長，但每次功能需求想半天沒問題后，到真正開發時，卻總有缺漏。有些很深、有些很細節，有些讓人哭笑不得。甚至有些版本兼容問題沒想過，到發版后才發現。好在有方案可在API上進行修復，而不需要客戶端重新發。
還好開發測試都還好說話，看工作量跟排期能進行規則補充的商量。但有時信息同步不到位，排期又緊，難免會被批。最近一直在思考，功能設計上的缺漏，來來回回那么幾種，是否可進行歸納總結，以便日后設計功能時進行自檢。由此歸納如下八項功能自檢自查項目，望能避免被手撕。
需求- 功能- 交互- 耦合- 數據- 異常- 兼容- 風險，這八項可用來自查。
按照如上介紹的八項自查原則，讓我們逐一來看看吧！
一、需求
每個功能需求提出之前，思考比對調研。這時候的功能自查是冒著推翻現有方案重來的風險。所以建議這一步放到產品需求提出的第一步自查。
需求的本質相信大家都有了解。對需求的深挖是有層次的。我們來看那個熟悉的馬與車的故事：
很久之前有個年輕人想要去一個較遠的地方，他會跟你說他想要一匹更快的馬。
但其實際是希望有更快的交通工具，若能給他輛汽車或者發明個飛機，他是不是更開心？
這就深挖了需求？如果他其實是為接一位名醫給他父親看病，那他更深的需求是不是希望有更便捷更完善的醫療體系或私人醫生？
如果他父親生病是因為吃錯東西、著涼等等，那么24小時的貼身保姆等需求貌似就是更深的需求。
然而還有更深的事件耦合與需求。
那么問題來了，怎樣的需求層面才足夠深？
需求，是一類場景下的共性訴求的具體呈現。
我們知道，事物是普遍聯系的。每一件事情的發生都不是獨立的，而是有其前置條件與偶然因素疊加的。因此，需求的深挖程度我們要把握好度。
是否覆蓋目標人群：若一開始那個騷年，是我們的目標用戶。滿足他更快出行是我們產品定位的話，就不必細化。
出行理由千奇百怪，那么不管每個人出行的原因。把握出行這個場景共性的訴求，就是更快更舒適，那就夠了。再細分下去，就超出目標人群，而涉及更喜歡的個體。
是否脫離原有屬性：產品的屬性是做交通工具，如馬車、汽車、飛機。而若按如上故事所述，那就去到醫療領域甚至家政服務業，與原有產品屬性是脫節的。
需求深挖是縱向的，如上深度確定后就需要橫向選擇。比如如上的需求我們挖到更快的交通工具這一層，評估可以了。那么就進行需求方案的選取。
再者，如電商平臺，我們可以為用戶提供搜索功能，但搜索的關鍵是讓用戶更快更準地找到所需。那么個性化推薦系統、分類功效品牌等維度的商品篩選等，就是衍生的方案，可以一起做搭配做或短期內擇優來做，就是產品經理要做的第一步自查！
二、功能
確認具體需求點后，需要分兩步進行功能自查。
1、基本
更快的馬對之前那位小騷年是短期能最快最好地實現的，這是其基礎之一。馬能跑完他想要去的距離，也是基礎功能。而且這馬不說拉馬車，至少能載得動這個人吧，不能人一上去馬就萎了。所以這匹馬基本不止是跑得快，還要是活得能載人能長跑。而很多人只想到馬跑得快就行，忽略這個場景下，需要滿足的其它基礎條件。
2、拓展
這匹苦命的馬被設定好基礎功能后，我們還要想以后是否有其他擴展可能，比如馬身上搞個布袋方便以后放東西（即便這次騷年比較急不帶什么東西）。預留擴展的好處是顯而易見的。比如馬在設計時一次性把馬鞍麻袋啥的采購好，而下次需要裝東西的時候再修修補補啥的就不用專門再去采購這些材料。擴展預留主要關乎成本！
三、交互
界面元素、交互是功能呈現給用戶的重要手段。而界面元素由于是偏向固定靜態的，所以設計時缺漏的概率不會像交互方面出現的那么高，這里更傾向對交互層面上的自查，如下當不僅限于此：
1、跳轉規則
當多個頁面間進行邏輯跳轉時，規則一定要定義好。之前負責一個搜索的功能，搜索頁去到搜索結果頁，結果頁重新點擊搜索框會回到搜索頁，而在此時未發生搜索時點擊返回是回到原有不清空的搜索結果頁還是直接跳出到搜索入口。一定要用流程圖畫好各種前置條件下的跳轉規則才能保證程序開發的無二性，就是其確定性。
2、逆向
上下前后左右進出，這種具有逆向的交互往往我們在PRD中就申明定義了一種而忽略了另外一種相反情況。如某些頂部tab可左右滑動，且其交互是點擊只顯示一半的tab內容，該tab會彈出至某個位置。而我們習慣性地進行右邊tab的描述，而忽略左邊的描述。（有些人可能會說這個左右交互一看就知道要一致的嘛，但實際上，你不說，人家不做。你懂的）
3、場景：數量、前置
先說數量，一個模塊其中的具體內容數量為1、2、3...各種數量時的情況。比如一個商品展示模塊，最多顯示四個，那么其獲取的數據超出該數量時如何取數據？若小于該數量，頁面如何展示排版。若干脆沒有數據，該模塊是否直接隱藏還是出現不一樣的交互控件去進行引流？
再者是前置：進入當前場景的前提條件不同，其顯示內容則不同。從不同維度進入到一個商品列表頁面，可以從搜索、從分類、從品牌等不同維度進入。其前置場景不同，進入后顯示交互的各種樣式數據自然不同。
四、耦合
耦合是比較重要的自查點。比如在進行電商產品設計時，可能會對某個商品的展示樣式進行修改，直觀的，我們會對首頁，或者商品列表等進行修改。而若我們還有購物車、設置是個人中心中支持對商品的收藏，那我們是否要考慮各個耦合場景的樣式及數據內容同步修改？一個APP中還包括push系統等非直觀場景可聯想到的，但卻有很多層級的耦合關系，所以耦合的場景需要遍歷清楚。
另一點就是數據的耦合，這更為普遍。前端展示的數據內容有些是具有邏輯依賴的。如某個價格是通過原價跟折扣進行計算得出的。若要使用該最終價格，進行其他數據計算。而當一段時間后，我們忘記原有的數據邏輯，對原始數據邏輯進行修改，最后就會牽連有耦合的數據。
五、數據
數據能演變的玩法最多，也就有更多的狀況。特別是運營后臺進行錄入，前端進行展示的數據需要反復考慮。
1、默認
如在后臺進行某項數據的插入錄入時，是否有給定默認值？一方面若默認值設置合適，可以減少運營人員的操作成本。另若運營忽略了該值的輸入時，該數值會為空。若給出必填提示，其實質也增加操作成本。而這種情況，設置默認值是更為保險的方式。
2、邊界
正常數據的錄入，也同時需要進行判斷。特別是邊界檢查。該數值超出合法區間如何處理？該數值填寫正確保存成功是否給出提醒。輸入超出邊界后是情況原有內容還是只給個彈窗提示？
3、異常
若數據輸入要求是數字，而此時進行文字的輸入會如何？數據在錄入時，發生斷網、瀏覽器異常關閉時，數據進行本地草稿保存？不同的異常情況也要根據不同需求程度去進行考量設計！
六、異常
異常的情況不止出現在數據上，在客戶端可能發生的情況更為多樣。如網絡異常導致數據加載失敗，用戶賬號異常導致功能限制，GPS定位失敗導致獲取地理位置失敗等情況。每個功能不僅要考慮順利的情況，還要考慮各種異常分支，并進行相應的提示說明或跳轉等操作。
七、兼容
兼容性問題是優化的重要限制點。有句話說得好“船大難掉頭”，一個產品功能多了后，各個功能間的耦合更多。一個改動會涉及方方面面。如前端展示的樣式發生改變，那么上線版本需要如何兼容。新版本中一個數據或樣式增加，老版本不支持，如何通過接口或其他方式對老版本的新增數據樣式進行過濾？或者老版本保留原有規則而新版本使用新規則與接口。
八、風險：落地細節
風險評估是保證項目順利推進避免出現意外的情況的保障預警。如開發能力無法落實需求？開發時間無法掌控？客戶端對后臺數據的依賴導致客戶端先行而數據跟不上？特別是大公司平臺較多，相互依賴也多。跨部門的需求排期若跟進不到位，容易出現需求一直被晾著無法按計劃實現。
以上幾點是近來對工作的一點小總結。總結點是有優化空間，但真正關鍵的是如何將上述自查項在具體功能需求中進行自我排查思考。
越來越發現產品經理新手更多需要在執行層面上下工夫。當然不是說在產品戰略或規劃方面要少思考。而是作為一個新人，其快速融入職場及職業角色的方向應跟偏向落地。需求思考，功能落地，項目跟進，溝通掌控。對于項目來說，都是極為重要的。新手上路，產品不易，且行且總結！