導(dǎo)讀：要基于現(xiàn)有基礎(chǔ)邏輯功能進(jìn)行優(yōu)化或改造，我們必須先要知道他原始設(shè)計(jì)的初衷，才能盡可能得避免動(dòng)到其潛在的關(guān)聯(lián)邏輯以及功能點(diǎn)優(yōu)化時(shí)的合理性，在原始方案上進(jìn)行推翻、優(yōu)化、回退或消亡。那么，如何了解現(xiàn)有功能背后的需求點(diǎn)呢？一起來文中看看吧~

昨夜北風(fēng)吹盡寒，執(zhí)筆不見深思來。

又到了新的季節(jié)點(diǎn)，最近腦袋中總是出現(xiàn)一團(tuán)黑黑的亂麻，就像似在白紙上用黑色鉛筆不斷攪動(dòng)的涂鴉，理不清剪不明的感覺，這種感覺在處理需求時(shí)尤為強(qiáng)烈。

經(jīng)常遇到一些功能，在換了一個(gè)又一個(gè)接手的人時(shí)，曾經(jīng)的邏輯與需求追溯已不可見，只留下一個(gè)軀殼平靜的躺在軟件里，在產(chǎn)品長河中也會(huì)時(shí)不時(shí)有人拿出來又將其繼續(xù)優(yōu)化，然后變成如今的模樣，多次優(yōu)化下來，初始的需求已經(jīng)不可見。

基于現(xiàn)有基礎(chǔ)邏輯功能進(jìn)行優(yōu)化或改造，我們必須先要知道他原始設(shè)計(jì)的初衷，才能盡可能得避免動(dòng)到其潛在的關(guān)聯(lián)邏輯以及功能點(diǎn)優(yōu)化時(shí)的合理性，在原始方案上進(jìn)行推翻、優(yōu)化、回退或消亡。

那么如何找到曾經(jīng)的需求場景呢，歷史追溯通過文檔總是可以從現(xiàn)有零星的記錄中追溯到70~80%的內(nèi)容，可見文檔信息保存與共享的重要性。

一、從需求工具中追溯功能點(diǎn)和提出對(duì)象

在需求處理工具中，我們常常使用5W1H描述我們的需求，一對(duì)一的需求里都盡可能詳細(xì)的描述了需求的來源、使用者、場景及期望實(shí)現(xiàn)的內(nèi)容，一個(gè)需求不見得特別的有說服力，所以我們會(huì)橫向?qū)Ρ?，從通用化場景中獲取對(duì)應(yīng)的需求并證明其有效性，故我們?cè)谶M(jìn)行修改時(shí)需要考慮到之前的需求存在的設(shè)計(jì)邏輯及其衍生內(nèi)容，能根據(jù)類別搜索對(duì)應(yīng)的模塊及功能點(diǎn)最好。

但是并非每一個(gè)需求都會(huì)被采納，關(guān)閉時(shí)的原因也是可以作為一個(gè)可參見的意見，判斷當(dāng)時(shí)未做以及推斷出現(xiàn)在又被提出的原因。如果一個(gè)需求被多次提出且非同一客戶提出的，那么他的場景在一定情況下是可信的。如果在現(xiàn)有方案無法滿足的情況下，技術(shù)方案即使較大改動(dòng)，也是應(yīng)該參考入內(nèi)的。

此外，非常個(gè)性化的定制如果也能從它指定行業(yè)中剝離出標(biāo)準(zhǔn)的一方面，那么其實(shí)也可以做到復(fù)用。

比如生鮮、冷飲、食品等運(yùn)輸?shù)拇鎯?chǔ)要求和服裝、圖書等類目區(qū)別較大，但是依舊可以從多家生鮮中獲取共同點(diǎn)取名為該行業(yè)的軟件特性作為通用性功能，當(dāng)后續(xù)有類似項(xiàng)目進(jìn)來之后，也能大致滿足他的基本需求，這樣便能大大節(jié)省了重復(fù)梳理的時(shí)間，提高效率。

然而，也是因?yàn)檫@樣的做法，后來者接手時(shí)，就需要整理之前的需求與場景，才能嘗試著是否能改動(dòng)到。需求處理工具較為實(shí)在，能夠清晰的描述出功能點(diǎn)的前置條件、后置條件、邏輯限制、業(yè)務(wù)流程等，比較適合1：N迭代的（在0到1的時(shí)候，需求點(diǎn)可能較為粗糙），但是這樣卻也有可能打破了整體的數(shù)據(jù)流轉(zhuǎn)，僅限于局部內(nèi)容，且不同產(chǎn)品經(jīng)理風(fēng)格不一，在描述時(shí)未必能那么詳盡。

所以在產(chǎn)品改動(dòng)時(shí)，若是能即時(shí)更新，在整體上增加描述對(duì)應(yīng)的邏輯，那對(duì)后來者會(huì)更為友好。軟件隨著不斷迭代會(huì)更為笨重，前期設(shè)定的功能和技術(shù)框架，如果擴(kuò)展性跟不上的話，那么發(fā)揮的空間也會(huì)極為有限。所以處于中間階段的需求，需要考慮到承上啟下。

二、親自跑完現(xiàn)有軟件的功能流程和細(xì)節(jié)

既然處于迷糊階段，看到需求無法下手，就盡量先將軟件邏輯整明白，親自將現(xiàn)有的軟件功能親自跑一遍，作為文檔描述不夠詳盡的補(bǔ)充。不管歷史如何變化，功能總是以當(dāng)下的功能最為準(zhǔn)確。想象你是你的客戶，作為一位沒接觸過該系統(tǒng)的人員，你在執(zhí)行作業(yè)時(shí)，是否能夠順暢理解該功能，這個(gè)功能是否能夠解決了你的痛點(diǎn)。易用性總是客戶滿意度最高的一個(gè)吸引點(diǎn)，有些軟件功能隱藏的很深，有些配置限定太死，在初次接觸軟件常常會(huì)把自己弄的很痛苦。

后續(xù)軟件的優(yōu)化點(diǎn)，詰取某一部分進(jìn)行研究時(shí)，可以綜合軟件實(shí)操與反饋同步進(jìn)行，明確方案的目的，分別可從總體的功能、產(chǎn)品架構(gòu)列舉，從細(xì)分的流程、使用者畫像進(jìn)行描述，從市場定位和功能比對(duì)中記錄不同，從同個(gè)功能不同方案的枚舉眾比較，才能更好的了解現(xiàn)有軟件的不足，將復(fù)雜的需求轉(zhuǎn)變成簡易的流程，可謂是智者見智了。

三、與人討論，頭腦風(fēng)暴

不管是產(chǎn)品老人還是研發(fā)老人，從討論中都是能窺探出些許設(shè)計(jì)邏輯的，后臺(tái)代碼是最有說服力的工具，代碼注釋挺重要的。另外，測試同事有不斷給軟件試錯(cuò)的用例中對(duì)不同的功能觸點(diǎn)，測試用例也是很不錯(cuò)的一個(gè)參考文件。

四、分析客戶本身及上下游對(duì)接

如果能從所提需求引絡(luò)出其他的痛點(diǎn)，當(dāng)獲得充分信息時(shí)，大概也就能知道該需求是否能夠去滿足了。

經(jīng)常說到要深入需求的核心，不拘于淺層，一般是指客戶提出一個(gè)需求僅僅是針對(duì)當(dāng)下這種情況而提出的問題，深入點(diǎn)就是需要理解出為什么他會(huì)出現(xiàn)這個(gè)問題以及這個(gè)問題的有效性，再深入點(diǎn)就是客戶日常作業(yè)時(shí)所涉及的方方面面，問題出現(xiàn)的頻率以及真實(shí)的、全面的、客觀的場景，分析客戶本身業(yè)務(wù)以及他上下游是如何進(jìn)行對(duì)接和過渡的，以至于我們可以提供多種備選方案。

雖然也有很多需求就是為了滿足某一個(gè)簡單的想法而已，深挖倒也是大可不必了，這種一般是用戶體驗(yàn)型的需求。

五、產(chǎn)品架構(gòu)圖

從整體的視角去看軟件也可能事半功倍，模塊間的數(shù)據(jù)流動(dòng)體現(xiàn)在應(yīng)用層面的具體表示?？粗考夜窘o出的產(chǎn)品架構(gòu)圖都十分相似，看不出“端倪”，這里的架構(gòu)圖不建議看別人畫，而是自己畫的，加深理解，可以加上一點(diǎn)自己的“個(gè)性”，才能將整個(gè)行為進(jìn)行閉合，總-分-總的方式百試百靈。

六、上線跟蹤

跟蹤上線后的使用情況，能證實(shí)該需求是否存?zhèn)?，用的話是否用的順暢，不用的話原因是什么，業(yè)務(wù)調(diào)整還是未達(dá)預(yù)期，若是未達(dá)預(yù)期那么可能開始的方向就錯(cuò)了。

寫在最后，當(dāng)我們處理需求的時(shí)候，常?？紤]到他的開發(fā)量、各種投入產(chǎn)出比、用戶性格、收益率等等，但這些顧慮也有可能固化了我們的思考，從而記不得我們?yōu)橛脩艚鉀Q問題的初衷了。衡量取舍好像已經(jīng)是各大公司產(chǎn)品經(jīng)理取之有道的共識(shí)了，不過還是想說，若可行，先行莫后折，易折為假，繼續(xù)摸索吧。

本文由 @謝星星 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。