淺談業(yè)務系統(tǒng)的用戶調(diào)研與需求分析
前幾天說了業(yè)務系統(tǒng)的產(chǎn)品設計,今天再來說說業(yè)務系統(tǒng)的用戶調(diào)研與需求分析。業(yè)務系統(tǒng)由于其復雜性,在用戶調(diào)研過程中往往容易被需求方帶到坑里,對業(yè)務系統(tǒng)而言,只講表面需求,對用戶的表述奉行“拿來主義”,都是在耍流氓。
1.用戶調(diào)研與開發(fā)流程優(yōu)化
業(yè)務系統(tǒng)由于其復雜性,往往都是根據(jù)需求方深度定制,這就要對需求方進行調(diào)研。而需求方的想法往往天馬行空、朝秦暮楚,若不能合理規(guī)劃開發(fā)流程,則容易陷入每個階段都在該需求的怪圈:程序員焦頭爛額、怨聲載道,需求方天天催促,產(chǎn)品經(jīng)理里外不是人。
理想的開發(fā)過程大致如下(包含但并不唯一):
但是理想與現(xiàn)實往往是有差距的,很多同學在用戶調(diào)研時沒有占據(jù)主動,那么開發(fā)過程可能是這樣:
1.1癥結(jié)所在
總結(jié)之前的項目經(jīng)驗,造成后期頻繁修改的原因主要有以下幾個:
- 調(diào)研中需求方需求表述不準確;
- 調(diào)研人員對需求分析不徹底,沒有認識到需求本質(zhì);
- 產(chǎn)品方案與實際需求有偏差;
- 項目組內(nèi)部(PM與開發(fā)人員)交流不暢;
- 出現(xiàn)需求變更時不能及時調(diào)整項目計劃;
- 開發(fā)過程管控力度不足;
1.2對癥下藥
兵法有云:知己知彼,百戰(zhàn)不殆。認識到了問題產(chǎn)生的原因,那么就要對癥下藥。要想在用戶調(diào)研過程中避免被用戶帶進坑里,就要從調(diào)研過程、需求分析、需求確認、內(nèi)部溝通、需求變更、開發(fā)過程把控六個方面入手。
調(diào)研過程
在調(diào)研時,用戶所表述的需求未必是正確的需求(可能添加個人主觀因素等),因此需要向盡可能多的用戶了解需求。
在了解需求過程中要引導用戶對需求的表述方式:比如A工作怎么完成,為什么要這樣完成,其中的某個步驟是因為解決了什么實際業(yè)務的難點(痛點),而不是去聽用戶在滔滔不絕地講他們怎么開展工作(此處可參考故事“我想要一匹更快的馬”)。
絕大多數(shù)用戶都不是專業(yè)的互聯(lián)網(wǎng)人士,因此在調(diào)研和溝通時要占據(jù)主動,從專業(yè)角度給予用戶引導和建議,否則很容易被用戶天馬行空的思維帶到溝里。
需求分析
需求分析對產(chǎn)品經(jīng)理而言是大坑,需求調(diào)研與產(chǎn)品方案之間往往不是簡單的因果關系。
這就要求產(chǎn)品經(jīng)理在整理和分析需求時要深入思考,不要執(zhí)著于表象,具體在下面的章節(jié)會說到。
需求確認
產(chǎn)出原型和PRD之后,就需要進入需求確認的環(huán)節(jié)。需求確認的意義非常重要。這是后期需求變更或出現(xiàn)撕逼的有力證據(jù)。需求確認的常用打開方式一般是這樣:①向需求方講解產(chǎn)品方案;并打印書面的、含有原型截圖的PRD;③由需求方簽字確認,簽字確認應包含簽字日期。
需求確認旨在明確雙方責任,并非借此保證需求一成不變。其作用是在需求出現(xiàn)變更時,明確因此對整個項目帶來影響的責任主體,以避免出現(xiàn)需求方主動提出變更,但對項目工期不滿意的情形。
內(nèi)部溝通
俗話說的好:溝通不誤開發(fā)工。內(nèi)部溝通是避免出現(xiàn)項目組成員對需求理解不一致的重要解決方式。項目組內(nèi)部往往包括產(chǎn)品經(jīng)理、設計師、開發(fā)工程師、測試工程師等多種角色,若對需求的了解不統(tǒng)一,則容易在相應環(huán)節(jié)出現(xiàn)偏差,影響項目的正常進行。
因此,需求確認、需求變更等狀況發(fā)生時,需要與相關人員及時有效溝通,同時要求所有相關人員在出現(xiàn)疑問時主動溝通而不是自我臆造,對于保證開發(fā)過程的順利進行具有重要意義。
需求變更
需求變更在業(yè)務系統(tǒng)中是難以避免的,即使用戶對原型及PRD進行了書面確認,但如果出現(xiàn)確認需求的相關人員對實際需求了解不夠,或者用戶在表達需求時有所遺漏,甚至于在開發(fā)完成后需求方修改了相關規(guī)章等情況,導致最終確實無法滿足需求,那么修改仍然不可避免。
在需求變更時,需及時向各利益相關方告知需求變更事宜,并向需求變更提出方明確由此變更所帶來的影響,包括新需求完成的時間節(jié)點,由此新需求占用的人力和由此需求變動造成的其他相關模塊的變更,對既定開發(fā)計劃的影響等。
開發(fā)過程監(jiān)控
防范勝于救災。對開發(fā)過程的監(jiān)控旨在防止BUG,避免開發(fā)人員對需求理解出現(xiàn)偏差。應對開發(fā)進度進行每日回報,形成明確的疑問反饋機制。
過程監(jiān)控并不意味著產(chǎn)出的完美無缺,但摸索到最大程度減少問題的合作方式,對于提高效率和需求方滿意度是非常重要的。
在用戶調(diào)研的過程中條條大路通羅馬,能夠?qū)⑵毡樾耘c團隊、項目、需求的特殊性相結(jié)合,具體問題具體分析,找到最優(yōu)方案,就是成功的調(diào)研。
2.需求分析
需求分析的難點在于用戶表達出的需求未必是真正的需求,用戶的表面需求往往隱藏著更深的本質(zhì)需求。但是需求分析是工作開展的第一步,若需求理解過程中出現(xiàn)偏差,那么再好的產(chǎn)品設計、再好的原型,也是沒有意義的。
寫這一章其實是心懷忐忑的,作者和無數(shù)前輩大牛相比還是有很大差距,僅僅從業(yè)務系統(tǒng)的需求分析入手,談一談自己的看法,大家應以辯證、批判的角度去讀。
2.1需求概述
需求是指用戶的問題。對于業(yè)務系統(tǒng)而言,需求即業(yè)務的實現(xiàn)過程、原業(yè)務實現(xiàn)中的痛點。與互聯(lián)網(wǎng)產(chǎn)品的區(qū)別是,業(yè)務系統(tǒng)的需求相對穩(wěn)定,一般來說變化較少,而產(chǎn)品的生命周期則更多依賴于業(yè)務實現(xiàn)方式的調(diào)整。
相比于其他產(chǎn)品,業(yè)務系統(tǒng)的需求挖掘方式較少,而需求挖掘過程即調(diào)研過程,主要通過與用戶深入交流、了解用戶業(yè)務相關的規(guī)章制度(或行政業(yè)務的法律法規(guī))、分析用戶此前已經(jīng)存在的業(yè)務系統(tǒng)、分析用戶業(yè)務的發(fā)生場景等,本文對此不做贅述。
2.2需求分析
業(yè)務系統(tǒng)(平臺)之所以稱之為系統(tǒng),是因為其業(yè)務、數(shù)據(jù)之間應該是互為關聯(lián)而不是相互獨立的,因此應該從整體的、全面的角度看待獨立的需求。獨立需求的特殊性共同構(gòu)成系統(tǒng)的普遍性。
從要解決的問題看需求
這個觀點想必對所有產(chǎn)品從業(yè)者而言都不陌生。需求的本質(zhì)是為解決問題,但由于用戶表達需求不明確、用戶主觀因素、或用戶由于此前已經(jīng)存在的系統(tǒng)形成思維定勢,因此對用戶的表述奉行拿來主義是不可取的。
在了解需求時,要通過刨根問底與業(yè)務場景分析,了解到實際的業(yè)務需求。產(chǎn)品設計必須建立在對實際應用場景充分了解的基礎之上。
在與用戶交流時,要根據(jù)實際業(yè)務提出自己更優(yōu)的解決方案。從產(chǎn)品設計、流程優(yōu)化、交互設計、工作協(xié)同、視覺設計、安全、性能等各方面對用戶提出專業(yè)建議。
之前有同學與我交流時說起自己負責的項目,因為之前已有系統(tǒng),用戶的觀點是按照原系統(tǒng)實現(xiàn)即可,其實從用戶習慣的角度考慮并無不可。但一方面業(yè)務系統(tǒng)是往往是自上而下推動,另一方面,業(yè)務系統(tǒng)的出發(fā)點和落腳點是為更好滿足業(yè)務。之前系統(tǒng)的交互方式已經(jīng)融入用戶習慣,可以參考,但若照搬照抄,新系統(tǒng)就很難發(fā)揮其意義了。
從整體的觀點看需求
業(yè)務系統(tǒng)/平臺的出現(xiàn),尤其是對于存在多個分支機構(gòu)、多類用戶的系統(tǒng)而言,即將原來獨立的業(yè)務使用云計算的形式統(tǒng)一起來。
該種情形下,不同獨立的業(yè)務之間可能存在跨部門、跨單位協(xié)作,數(shù)據(jù)之間的互聯(lián)互通。因此,需要從整體的觀點看相對獨立的業(yè)務,整合原本獨立業(yè)務中相同的數(shù)據(jù)來源,刪減冗余流程。
謹小慎微,腳踏實地
業(yè)務流程往往是通過相關規(guī)章制度而來,而規(guī)章制度往往會有明確的規(guī)定,比如業(yè)務發(fā)生的前置條件、業(yè)務流程節(jié)點的限制條件等,在需求分析時一定要梳理清楚,對系統(tǒng)中的條件限制是保障業(yè)務制度的重要方式。
但部分業(yè)務規(guī)章和實際執(zhí)行過程中,往往由于實際業(yè)務發(fā)生時的復雜狀況,不能完全按照制度開展業(yè)務,此時則需深入了解業(yè)務場景,保證業(yè)務的正常開展。
3.總結(jié)
業(yè)務系統(tǒng)相比于其他產(chǎn)品,有諸多特殊性。只有把握其特點,才能知己知彼,百戰(zhàn)不殆。在任何時候,需求挖掘、需求分析、需求管理是進行產(chǎn)品設計的必要前提條件,對業(yè)務系統(tǒng)需求深刻認識的基礎上,建立明確的需求池,按照優(yōu)先級進行劃分,才能為產(chǎn)品規(guī)劃、設計打下堅實的基礎。
作者:張騫(微信號zhangqian9208),開創(chuàng)集團產(chǎn)品經(jīng)理。一年產(chǎn)品工作經(jīng)驗。
本文由 @張騫 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
一直有個問題,在和需求方進行需求確認時是否需要和技術先確認原型方案的可實現(xiàn)性? 總會碰到需求確認完畢后技術再開發(fā)過程中碰到了問題,以至于不得不更改方式,此時又是否需要再度與需求方確認?
1.這要求產(chǎn)品經(jīng)理必須有基礎的技術認知,技術上難以實現(xiàn)的需求應該在采集階段就放棄掉;2.變更產(chǎn)品方案必須要重新確認需求
這就同時要求產(chǎn)品經(jīng)理對技術也有了解,如果要做的很好,那你產(chǎn)品經(jīng)理的技術分析能力也需要很強,但是這種人除非以前就是做開發(fā)出身的。。。否則真的不太現(xiàn)實
一直從事業(yè)務系統(tǒng)產(chǎn)品建設,感覺需求深度挖掘最難做到,頗有感觸
對,給到技術的需求應該無懈可擊才好往下推
需求分析要防止各種坑,認識到本質(zhì)需求才是根本