自做產(chǎn)品以來褂萧，產(chǎn)品工作量大押桃，卻也能快速成長。但每次功能需求想半天沒問題后箱玷，到真正開發(fā)時怨规，卻總有缺漏。有些很深锡足、有些很細節(jié)波丰，有些讓人哭笑不得。甚至有些版本兼容問題沒想過舶得，到發(fā)版后才發(fā)現(xiàn)掰烟。
還好開發(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會彈出至某個位置嘲驾。而我們習(xí)慣性地進行右邊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ò)異常導(dǎo)致數(shù)據(jù)加載失敗桌粉，用戶賬號異常導(dǎo)致功能限制授段，GPS定位失敗導(dǎo)致獲取地理位置失敗等情況。每個功能不僅要考慮順利的情況番甩，還要考慮各種異常分支，并進行相應(yīng)的提示說明或跳轉(zhuǎn)等操作届搁。
七. 兼容：
兼容性問題是優(yōu)化的重要限制點缘薛。有句話說得好“船大難掉頭”，一個產(chǎn)品功能多了后卡睦，各個功能間的耦合更多宴胧。一個改動會涉及方方面面。如前端展示的樣式發(fā)生改變表锻，那么上線版本需要如何兼容恕齐。新版本中一個數(shù)據(jù)或樣式增加，老版本不支持瞬逊，如何通過接口或其他方式對老版本的新增數(shù)據(jù)樣式進行過濾显歧？或者老版本保留原有規(guī)則而新版本使用新規(guī)則與接口？
八. 風險：落地細節(jié)
風險評估是保證項目順利推進避免出現(xiàn)意外的情況的保障預(yù)警确镊。如開發(fā)能力無法落實需求士骤？開發(fā)時間無法掌控？客戶端對后臺數(shù)據(jù)的依賴導(dǎo)致客戶端先行而數(shù)據(jù)跟不上蕾域？特別是大公司平臺較多拷肌，相互依賴也多≈枷铮跨部門的需求排期若跟進不到位巨缘，容易出現(xiàn)需求一直被晾著無法按計劃實現(xiàn)。
以上幾點是近來對工作的一點小總結(jié)采呐∪羲總結(jié)點是有優(yōu)化空間，但真正關(guān)鍵的是如何將上述自查項在具體功能需求中進行自我排查思考斧吐。
越來越發(fā)現(xiàn)產(chǎn)品經(jīng)理新人更多需要在執(zhí)行層面上下工夫拴清。當然不是說在產(chǎn)品戰(zhàn)略或規(guī)劃方面要少思考靶病。而是作為一個一兩年內(nèi)的新人，需要快速融入職場及職業(yè)角色的方向應(yīng)跟偏向落地口予。需求思考娄周，功能落地，項目跟進沪停，溝通掌控煤辨。對于項目來說，都是極為重要的木张。產(chǎn)品不易众辨，且行且總結(jié)！
本文發(fā)表收錄情況：
三節(jié)課：如何避免被程序員手撕：產(chǎn)品八項自查
人人都是產(chǎn)品經(jīng)理：如何避免被程序員手撕：產(chǎn)品八項自查
產(chǎn)品100：如何避免被程序員手撕——產(chǎn)品八項自查
