需求是什么泥兰？需求本質(zhì)上就是問題庄涡，問題是什么量承？問題本質(zhì)就是現(xiàn)狀和預(yù)期的差距，產(chǎn)品經(jīng)理終其一生要做的事就是發(fā)現(xiàn)問題并提出問題的解決方案啼染，同時讓這個解決方案在商業(yè)上獲得成功宴合，這個解決方案就是我們所說的產(chǎn)品。
要想做出好的產(chǎn)品迹鹅，前提就是要深刻的理解需求卦洽，需求不止是個問題，它貫穿了產(chǎn)品的全生命周期斜棚，它的形態(tài)不斷發(fā)生變化阀蒂，需求的變化過程也是從產(chǎn)品從一個初步構(gòu)想的點子、到形成解決方案弟蚀、完成功能設(shè)計到最后形成產(chǎn)品的過程蚤霞。
1、用戶需求
隨著產(chǎn)品的推進义钉，需求形態(tài)也會發(fā)生變化昧绣，最開始的時候，當(dāng)這個需求被發(fā)現(xiàn)時捶闸，我們管它叫用戶需求夜畴，也許這個需求是運維或者市場人員傳達過來的二手需求，也許是產(chǎn)品經(jīng)理和用戶調(diào)研后獲取的一手需求删壮，也可能是通過系統(tǒng)的數(shù)據(jù)分析得到的優(yōu)化需求贪绘，本質(zhì)上都是用戶需求。
用戶需求是最原始的需求央碟，有以下4個特點：
（1）煙囪需求
這是一個特立獨行的需求税灌，類似的用戶都沒有這個訴求，完全是一個個性化的需求，用戶的意圖是追求滿足個人的需求菱涤，而非滿足帶有集體人格的角色需求苞也，這類需求被稱為煙囪需求，在需求采集階段發(fā)現(xiàn)了這類需求要果斷拋棄掉 粘秆。
曾經(jīng)我們做PMS系統(tǒng)墩朦，需要管項目的流程，一個項目可能涉及很多個流程環(huán)節(jié)翻擒，這些環(huán)節(jié)有嚴(yán)格的前后關(guān)系，有個別的項目經(jīng)理提需求牛哺，希望能有項目信息補錄功能陋气，可以在項目執(zhí)行完畢后統(tǒng)一補錄，或者可以跳過某些環(huán)節(jié)引润。
顯然這個需求不符合企業(yè)管理上對項目經(jīng)理這個角色要求的定義巩趁，管理就是要固流程，規(guī)范項目經(jīng)理的操作淳附，領(lǐng)導(dǎo)可以實時看到項目的進展议慰，如果按照某個項目經(jīng)理要求開個后門，管理目標(biāo)就達不到了奴曙，這個需求就是煙囪需求别凹。
（2）重復(fù)需求
在需求調(diào)研時，從不同渠道洽糟、不同用戶收集來的需求炉菲，可能存在很多相似或者重復(fù)的需求，這類需求在下一階段需要進行合并處理坤溃，有時這些重復(fù)的需求帶有一定的隱蔽性拍霜，只從用戶的需求描述上感覺完全是兩個不同的用戶需求，但實際上是相同的需求薪介。
這個時候就需要了解需求的層次祠饺，不能只看表面的需求，需要理解用戶更深層次的需求汁政，比如一個用戶說希望把某個功能菜單改為一級道偷，另一個用戶希望把這個功的菜單改為特殊顏色標(biāo)志，只看表面確實是兩個不同的需求烂完，我們的解決方案可能最終按照用戶的想法把菜單提升到一級并且修改了顏色试疙，這么做是典型用戶說什么，我們就做什么抠蚣，最后的結(jié)果就是把系統(tǒng)做爛掉祝旷。
往深層次分析一下用戶的動機，這兩個用戶的動機其實是一致的，都是為了快速找到自己常用的功能怀跛，只是分別提出了不同的解決方案距贷。
分析到這個層次機會發(fā)現(xiàn)，要解決用戶的這個問題吻谋，比較好的解決方案忠蝗，不是改變現(xiàn)有的菜單體系，而是在個人首頁單獨增加一個快速菜單的入口漓拾，這是個通用的功能阁最，用戶可以定制自己經(jīng)常訪問的功能。
（3）矛盾需求
用戶需求很多都是矛盾的骇两，不同人提的需求有矛盾速种，比如一個功能按鈕的顏色，有的用戶希望是灰色的低千，這樣整體色調(diào)顯得更協(xié)調(diào)配阵，有的用戶希望按鈕顏色更深一些，可以更顯眼示血。
還有就是一個人提的需求棋傍，前后存在矛盾的地方，針對這類問題一定要及時和用戶溝通难审，有時候可能是表述上的失誤瘫拣，也有可能是我們理解上問題，一定和用戶確認(rèn)清楚剔宪。
（4）不可實現(xiàn)需求
用戶一般不會考慮技術(shù)的可行性或者開發(fā)的成本拂铡，大部分用戶都是不懂技術(shù)的，他們提出這些需求很多時候是被互聯(lián)網(wǎng)產(chǎn)品教化的結(jié)果葱绒，用戶接觸太多互聯(lián)網(wǎng)產(chǎn)品感帅，總覺得實現(xiàn)起來都很簡單，人家能做你們也應(yīng)該能做地淀。
比如原來我們做訂單管理模塊失球，用戶就說你們按照淘寶做就行了，有現(xiàn)成的可以借鑒帮毁，不用你們單獨造輪子实苞，這就是典型的不計成本，大公司互聯(lián)網(wǎng)產(chǎn)品背后的研發(fā)團隊豈能和一個項目組同日而語烈疚，遇到這這種情況也就只能呵呵了黔牵。
2、業(yè)務(wù)需求
業(yè)務(wù)需求是對用戶需求第一次過濾爷肝、分析后形成的需求猾浦，? 業(yè)務(wù)需求本身并沒有很抽象的功能設(shè)計陆错，用戶很容易看得懂，研發(fā)也能清晰的知道要做什么金赦，所以業(yè)務(wù)需求更像一個用戶思維和系統(tǒng)思維的轉(zhuǎn)換器音瓷。
用戶需求和業(yè)務(wù)需求之間的關(guān)系是多對多，也就是說不同的用戶需求可以合并為一個業(yè)務(wù)需求夹抗，一個用戶需求也可能拆分成多個業(yè)務(wù)需求绳慎，最終產(chǎn)出業(yè)務(wù)需求需要經(jīng)過需求識別、場景分析漠烧、流程分析杏愤、數(shù)據(jù)分析4個步驟.
(1)需求識別
這個步驟就是對用戶需求的重新篩選、整合的過程已脓，去除技術(shù)上無法實現(xiàn)和煙囪需求声邦、整合重復(fù)需求，明確矛盾需求摆舟，初步產(chǎn)出一個需求列表，這個需求列表還不是最終的業(yè)務(wù)需求邓了，而是明確要做恨诱、能做、無歧義的用戶需求骗炉。
(2)場景分析
對這些明確的用戶需求通過具體的場景分析照宝，明確產(chǎn)品的喚起點和喚起人，這個人就是角色句葵，角色對B端產(chǎn)品而言非常重要厕鹃，往往B端的產(chǎn)品涉及的角色更復(fù)雜。
場景的喚起存在主動喚起和被動喚起乍丈，主動喚起就是在某個場景下需要使用產(chǎn)品剂碴，比如移動OA的主動喚起場景是用戶在出差的火車上、被動喚起場景是系統(tǒng)的一條待辦審批的短信通知轻专。
另外做場景分析一定不要忘記例外場景分析忆矛，比如我們設(shè)計一個工程現(xiàn)場管理的APP，要在現(xiàn)場采集一些施工檢查的圖片请垛，很多時候施工都是在大山里催训，網(wǎng)絡(luò)環(huán)境不好，如果連不上移動網(wǎng)絡(luò)怎么辦宗收， 這個是時候就要考慮在網(wǎng)絡(luò)不好情況下的緩存機制漫拭，后面可以直接將緩存數(shù)據(jù)導(dǎo)入PC服務(wù)端答倡。
(3)流程分析
流程分析是對場景的細化帅容，需要分析清楚具體的業(yè)務(wù)流程崔兴，這個流程不一定完全是系統(tǒng)流程，而是完整的業(yè)務(wù)流佩谣，有些需要在線下完成，有些需要通過系統(tǒng)完成均驶，通過完整的業(yè)務(wù)流程分析郑口，能夠基本明確不同的用戶通過系統(tǒng)需要完成哪些事。
流程也是分級的各淀，管理級的流程看到的是端到端的業(yè)務(wù)線條懒鉴，操作級的流程就是全流程中的一環(huán)。比如采購過程從提出請購碎浇、采購方案立項到招標(biāo)临谱、是一個端到端的長流程，發(fā)出招標(biāo)公告就是一個操作級的流程奴璃，由項目經(jīng)理負(fù)責(zé)起草悉默，相關(guān)領(lǐng)導(dǎo)審批后發(fā)出。
(4)數(shù)據(jù)分析
數(shù)據(jù)分析是在流程分析的基礎(chǔ)上建立業(yè)務(wù)數(shù)據(jù)模型苟穆，明確每個流程的輸入和輸出數(shù)據(jù)抄课，然后在此基礎(chǔ)上梳理出整體數(shù)據(jù)模型，明確業(yè)務(wù)實體之間的關(guān)系雳旅，這個時候針對每個實體的屬性可能并不全跟磨，沒關(guān)系這是下個階段的事，現(xiàn)在關(guān)鍵是要出一張完整的業(yè)務(wù)數(shù)據(jù)模型圖攒盈。
是不是一定要用UML工具抵拘，我覺得也未必，UML是比較通用的語言型豁，研發(fā)做設(shè)計是一定要用僵蛛，描述需求只要能表達清楚，工具顯得不那么重要迎变。
3充尉、系統(tǒng)需求（項目需求）
系統(tǒng)需求一般是指針對某個項目的定制開發(fā)需求，所以系統(tǒng)需求也叫項目需求衣形，這個時候完全是根據(jù)用戶需求進行定制喉酌，不會考慮過多的靈活性、通用性泵喘、多版本泪电。
業(yè)務(wù)需求要轉(zhuǎn)化為系統(tǒng)需求還要經(jīng)過功能設(shè)計、交互設(shè)計和數(shù)據(jù)割接設(shè)計3個步驟纪铺。
（1）功能設(shè)計
通過業(yè)務(wù)需求的整理相速，輸出的是業(yè)務(wù)功能，而通過功能設(shè)計產(chǎn)出的是系統(tǒng)功能鲜锚，業(yè)務(wù)功能和系統(tǒng)功能存在映射關(guān)系突诬，一般也是多對多的關(guān)系苫拍。
舉例說明，業(yè)務(wù)需求是一個報表需求旺隙，但是要在系統(tǒng)上完全實現(xiàn)這個報表需求可能需要很多個系統(tǒng)功能去實現(xiàn)绒极。
首先分析這個報表需要展示的字段，目前系統(tǒng)數(shù)據(jù)不全蔬捷，需要增加一個單獨的采集功能采集更多的數(shù)據(jù)才能展示垄提。
其次這個報表中的某些字段需要從現(xiàn)有的流程模塊中提取，而目前流程模塊記錄形式不滿足要求周拐，需要對現(xiàn)有的流程模塊進行功能優(yōu)化铡俐。
最后這個報表的數(shù)據(jù)量非常大，可能是百萬妥粟、千萬級別的审丘，目前的技術(shù)架構(gòu)在性能上無法滿足快速采集并生成數(shù)據(jù)報表，這個時候可能需要在技術(shù)架構(gòu)層面進行優(yōu)化勾给，引入solr和es滩报，可以實現(xiàn)數(shù)據(jù)的快速檢索。
如果不在技術(shù)架構(gòu)層面改造播急，也需要針對這種大數(shù)據(jù)量的報表增加定時處理功能露泊，比如每天定時生成報表推送給用戶，這在一定程度上也能規(guī)避性能問題旅择。
經(jīng)過分析發(fā)現(xiàn)要滿足一個報表生成的業(yè)務(wù)功能需求，需要新增1個采集功能侣姆，1個定時報表生成功能生真、1個報表展示功能，優(yōu)化1個流程表單捺宗，甚至還要優(yōu)化技術(shù)架構(gòu)柱蟀。
（2）交互設(shè)計
交互設(shè)計這一步就是要根據(jù)具體的系統(tǒng)功能，由產(chǎn)品經(jīng)理和交互設(shè)計師配合完成蚜厉，通過交互設(shè)計輸出原型长已，原型是系統(tǒng)需求的一部分，系統(tǒng)需求文檔和原型設(shè)計才是一份完整的需求說書昼牛。
產(chǎn)出高保真原型的成本很低术瓮，針對B端產(chǎn)品我個人建議盡量產(chǎn)出高保真原型，很多時候需要和用戶領(lǐng)導(dǎo)匯報贰健，高保證原型是需求確認(rèn)的最好方式胞四，可以最大限度的避免需求理解的差異，減少后續(xù)的需求變更伶椿。
高保證原型大部分時候是由專職的交互設(shè)計師完成辜伟，產(chǎn)品經(jīng)理和交互設(shè)計師對接的方式氓侧，根據(jù)不同的管理模式有差異。
如果設(shè)計師屬于自己的產(chǎn)品團隊导狡，為了更高效的產(chǎn)出原型约巷，產(chǎn)品經(jīng)理可以通過白板畫些草圖就可以交付設(shè)計了，如果設(shè)計師是資源池共享資源旱捧，建議由產(chǎn)品經(jīng)理先畫一版線框圖原型交付設(shè)計独郎，當(dāng)然作為產(chǎn)品經(jīng)理具備交互設(shè)計師的能力，完全自己搞定也是可以的廊佩。
關(guān)于交互設(shè)計囚聚，相關(guān)的文章很多，我先前也寫過一些類似文章标锄，這里不再多說顽铸。
（3）數(shù)據(jù)割接設(shè)計案
這個步驟常常是容易被產(chǎn)品經(jīng)理忽略的，總感覺這個是研發(fā)的事料皇，實際在B端項目實施時谓松，每次大的迭代都可能涉及到數(shù)據(jù)割接。
比如本次迭代設(shè)計流程變更践剂，在原來基礎(chǔ)上取消了幾個流程環(huán)節(jié)鬼譬，這些取消的環(huán)節(jié)可能在系統(tǒng)上線時候有很多正在處理的待辦，這些待辦如何處理逊脯？
一種方法是通知大家优质，在系統(tǒng)上線前人工把全部待辦處理掉，還有一種方法就是把流程退回上一環(huán)節(jié)军洼，取消當(dāng)前待辦巩螃，這就需要研發(fā)寫個腳本在系統(tǒng)上線時統(tǒng)一處理，數(shù)據(jù)割接的業(yè)務(wù)規(guī)則匕争，需要產(chǎn)品經(jīng)理來定避乏，研發(fā)給出割接的技術(shù)方案，最后由工程人員實施甘桑。
4拍皮、產(chǎn)品需求
最后談?wù)劗a(chǎn)品需求，產(chǎn)品需求是對多個項目需求的抽象總結(jié)跑杭，項目需求要干的事铆帽，產(chǎn)品需求都要做，功能設(shè)計德谅、原型設(shè)計一個都不能少锄贼，除此之外有兩個關(guān)鍵點，是產(chǎn)品需求有別于項目需求的部分女阀，第一是需求抽象宅荤、第二是產(chǎn)品版本管理屑迂。
（1）需求抽象
產(chǎn)品抽象的初步目標(biāo)是讓系統(tǒng)的通用性更高，最直接的實現(xiàn)方式就是增加各種各樣的配置功能冯键，滿足各種各樣的需求惹盼，整個產(chǎn)品的靈活性更好，需求的響應(yīng)速度更快惫确。
產(chǎn)品需求抽象的最終目標(biāo)是不斷進行業(yè)務(wù)積累手报，逐漸形成自己產(chǎn)品線的業(yè)務(wù)中臺。
比如一個采購管理的產(chǎn)品改化，web門戶掩蛤、 采購訂單、業(yè)務(wù)告警都是這個產(chǎn)品的功能模塊陈肛，在這個產(chǎn)品里這些功能模塊抽象程度很高揍鸟，但是如果現(xiàn)在要做一個PMS系統(tǒng)，也會用到web門戶句旱，也需要對業(yè)務(wù)用戶進行進度告警阳藻，直接把采購系統(tǒng)的功能拿過來沒法直接用，還要進行大量的改造谈撒。
這時的辦法就是把門戶腥泥、告警單獨提出來做成共享的產(chǎn)品模塊，預(yù)留接口啃匿，不同的產(chǎn)品或者項目可以直接使用蛔外，可以快速完成不同項目的交付，所以做產(chǎn)品需求的目標(biāo)是做中臺需求甚至是后臺需求溯乒。
（2）多版本
產(chǎn)品需求要考慮多版本夹厌，一個是按照市場定價，會有免費版橙数、基本版、高級版等相關(guān)的版本帅戒，另外一個就是根據(jù)不同的行業(yè)劃分不同的版本灯帮。
