遇到不合理的業(yè)務(wù)需求，項目流程和走向不如愿，你是如何應(yīng)對的？作者復(fù)盤了自己的這次項目，針對兩個版本進(jìn)行了分析，總結(jié)了相關(guān)經(jīng)驗和教訓(xùn)，希望對你有所啟發(fā)。

大家在做項目的過程中會不會碰到以下問題？

• 業(yè)務(wù)總是提出不合理需求，產(chǎn)研部門苦不堪言；
• 業(yè)務(wù)人員總是不按照定好的流程操作系統(tǒng)，自己搞“野路子”，功能不是落地不下來，就是要按照他們的要求重新設(shè)計；
• 項目上線前信誓旦旦的承諾，上線后立刻又變了個樣子，導(dǎo)致需求反復(fù)修補；

而正好最近，我也遇到了這些問題，但最后還是將項目成功上線，并順利跑通。

雖然項目本身是需要增加公司內(nèi)部的「訂單審批」的功能，看起來并不大，但由于我司商品機(jī)制復(fù)雜、且牽涉到了底層訂單模塊，導(dǎo)致這個功能并不像市面上一般審批功能好做。

這個項目有兩個大的版本，版本1上線時出現(xiàn)了諸多問題，版本2卻十分絲滑地嵌入了業(yè)務(wù)流程。

為什么兩個版本會出現(xiàn)如此大的差別，我在版本2的設(shè)計中究竟做對了什么？

我對這次項目復(fù)盤了一下，總結(jié)出了十分重要的經(jīng)驗分享給大家。

話不多說，讓我們正式開始吧。（老規(guī)矩：加粗字能幫你快速閱讀）

背景說明：我負(fù)責(zé)在線教育公司的自研系統(tǒng)，本次舉例的功能是訂單錄入+審批的功能。

一、版本1-設(shè)計階段

這個需求最先開始于業(yè)務(wù)希望新增錄入訂單。

于是這個項目最一開始的版本，是先簡單做了一個錄入訂單的功能。

它十分簡單：銷售人員在后臺操作錄入訂單→訂單生效，客戶使用，就完成了。

不久之后需求發(fā)生了改變：除了錄入，還需要新增審批功能，理由是財務(wù)需要風(fēng)險控制。

我當(dāng)時心想：哎呀，這還不簡單嗎？審批功能是市面上已經(jīng)成熟的常見功能模塊，并不是很難才對。

完成了初期的調(diào)研工作后，很快，我與相關(guān)部門進(jìn)行了第一次會議，定下了本次項目目標(biāo)：

• 從財務(wù)層面減少風(fēng)險；
• 將這個流程順利地嵌入現(xiàn)有業(yè)務(wù)流程中；

順著這兩個目標(biāo)，我開始了產(chǎn)品設(shè)計。

這個過程也并不復(fù)雜，我參考了市面上已有的審批功能設(shè)計，刷啦啦就完成了第一版的產(chǎn)品設(shè)計，簡版示意圖大概如下。

省略了一些環(huán)節(jié)，大家可以簡單理解。

拿著初版，我們開始了第二次對齊會議。

問題從這里開始出現(xiàn)：

會議上業(yè)務(wù)人員提出特殊要求，出于各種業(yè)務(wù)原因，希望能讓訂單先生效，審批后置。簡版示意圖如下：

這個要求在我看來十分“不合理”：如果訂單先生效，那審批只是擺設(shè)。本身審批就是為了控制風(fēng)險，這么一來是為了什么？

經(jīng)過協(xié)商，業(yè)務(wù)人員用充分的理由打敗了我們：需要立刻使用訂單的客戶占比不少。

于是，我只能硬著頭皮去設(shè)計這一個功能。很快我就發(fā)現(xiàn)了問題：這么設(shè)計會讓損害客戶體驗。

簡單地描述一下就是：我們存在關(guān)聯(lián)商品。當(dāng)某個商品訂單被駁回后，連帶著所有的關(guān)聯(lián)商品都會出問題?？蛻魟t會在某一時刻看到自己的所有訂單都無法使用。

這期間我覺得十分奇怪。拉起了第三次會議，但業(yè)務(wù)和財務(wù)人員仍然沒有表示什么。認(rèn)為如果有駁回的情況，客戶體驗感差也是沒關(guān)系的。

銷售主管表示：“保證大部分客戶的體驗才是最重要的。其他的少數(shù)客戶我們會解釋?！?/p>

回想起來，這句話給我埋了個深坑，我應(yīng)該及時注意到指望銷售壓住客戶，是不靠譜的。

財務(wù)人員沒有對該需求表示異議，我仍然按照這個版本的設(shè)計正常推進(jìn)了。

二、版本1 – 使用階段

很快，第一個版本如期上線了。

但上線后——問題爆發(fā)了。

首先是我們對功能預(yù)期使用出現(xiàn)了偏差——比起客戶未打款，銷售人員錯誤錄入信息的情況更多。

原因是這條是新流程，此前我們從未試跑過，自然就沒想到銷售人員錄入訂單能這么不“走心”，有些銷售竟然能把客戶都寫錯。

其次是駁回訂單的修改流程落地使用出現(xiàn)問題，體現(xiàn)在銷售人員總是忘記要修改訂單，一筆錯誤訂單在客戶端正常運行著，盡管財務(wù)一直催促，銷售人員卻屢屢先集中于開單工作，而將修改工作拋之腦后。

于是我們緊急上線了補充版本，為了跑通補充版本，又和各方需要配合的部門人員幾番溝通，連續(xù)加班好幾天，可謂是心力交瘁。

本來以為萬事大吉了，沒什么大問題，但銷售側(cè)卻開始推翻自己在對齊會議上許下的承諾。

一天，銷售人員小B找到我：“小里小里，這個你快幫我看看怎么回事呢？”

我回答：“是財務(wù)人員駁回了訂單呀。”

小B大驚失色，表示駁回訂單后，客戶反應(yīng)很大，情緒很糟糕，希望能將訂單恢復(fù)給客戶。

我表示，這是因為客戶本身的問題沒有打款，自然是不能恢復(fù)。

但小B繼續(xù)說，客戶人在海外，打款有時限，希望我們能通融一下。

我對此事感到不滿：“可明明是他沒打款吧？”

小B則解釋說：“我們還是希望他能打款過來呀，總不能得罪他吧?，F(xiàn)在大家都會上小紅書寫我們壞話了。我可得罪不起。”

至此我是明白了，之前完全是我天真了，銷售怎么可能得罪客戶呢？

經(jīng)過幾位大佬們的商討，我們?nèi)匀煌饬虽N售的“新訴求”，就這樣運行了1年多的時間。

以下大概是這個流程的簡版示意圖：

經(jīng)過這次的項目，我總結(jié)出了2點經(jīng)驗教訓(xùn)：

1. 流程未試跑，便直接接入系統(tǒng)

這次的項目是建設(shè)一條新流程，此前我們從未試跑過。所以真正系統(tǒng)上線后，出現(xiàn)了許多我們未能預(yù)料的情況。

所以當(dāng)我們的項目是建設(shè)一條新流程時，最好讓業(yè)務(wù)先在線下試跑，跑通后再上系統(tǒng)。試跑的方法，這里限于篇幅，我會另開文章說明。

如果業(yè)務(wù)沒條件去試跑的話，那么系統(tǒng)在這時候的介入應(yīng)該保持最小介入，簡單開發(fā)，不能做太個性化的設(shè)計。

簡單開發(fā)的思路，我會在下文繼續(xù)跟大家詳細(xì)分享。

2. 不能過分聽信業(yè)務(wù)或任何其他部門給給予的保證

屁股是決定腦袋的：所有人都是根據(jù)他的指標(biāo)去行動的。

銷售的指標(biāo)是營收，要去得罪客戶其實是很困難的。也許他在跟你做保證的時候心是好的，自己也想往那個方向努力。但是當(dāng)指標(biāo)壓力給下來時，未必如此好操作。

還有一個例證是管理層有時會承諾說自己會從哪一個環(huán)節(jié)中給予監(jiān)督，幫助系統(tǒng)落地。但往往隨著業(yè)務(wù)高峰期的到來，所有人都集中于沖業(yè)績，“監(jiān)督”這個事情慢慢變得無足輕重。

也許他認(rèn)為監(jiān)督很重要，但是時間精力已經(jīng)不允許他完成監(jiān)督工作。

所以對方給予了保證，我們應(yīng)該都持懷疑態(tài)度，準(zhǔn)備好一些備用方案。

三、版本2 – 設(shè)計階段

1年后，因為公司內(nèi)部調(diào)整，這個功能再次出現(xiàn)問題。就新版的審批如何調(diào)整，我們半年前開始了各種“掰頭”會議。

我強烈反對了繼續(xù)使用「先生效，后審批」的流程，并舉例說明這個流程中已經(jīng)存在的種種問題和給客戶體感造成的損害。

業(yè)務(wù)人員則一直強調(diào)立即生效的必要性，也拿出了數(shù)據(jù)證明。并且認(rèn)為保證客戶體感應(yīng)該是產(chǎn)品需要考慮的問題。

這段時間陸陸續(xù)續(xù)拉了幾次會議，我們一直達(dá)不到共同的結(jié)論。

最后事情遲遲沒有推進(jìn)，領(lǐng)導(dǎo)喊上了業(yè)務(wù)最大的負(fù)責(zé)人一起商討。

業(yè)務(wù)總負(fù)責(zé)人則認(rèn)同應(yīng)該審批后再生效訂單，可能是位置的原因，他也更愿意為公司利益考量。但屬下反饋的問題他也不得不管。

最后在總負(fù)責(zé)人的協(xié)調(diào)下，我們采取了折中方案：

• 存在關(guān)聯(lián)關(guān)系的商品，不允許先生效，必須等待財務(wù)審批通過。
• 簡單商品的訂單需要先對客戶生效。

拿到會議結(jié)果的時候不由得喜從心中生，產(chǎn)品設(shè)計的時候多快了許多。

不過我們?nèi)匀幻媾R著「簡單商品的訂單，需要先生效」的問題。

這次我也學(xué)會了不再埋頭苦干，和其他團(tuán)隊伙伴、領(lǐng)導(dǎo)進(jìn)行了一番商討后，我們發(fā)現(xiàn)這個功能也許并不需要很復(fù)雜。

過去我們下意識地認(rèn)為錄入訂單就是要生成正式商品（課程），讓客戶使用。

但是只要我們多開一個「臨時商品」，只讓客戶使用，而不產(chǎn)生正式訂單&商品的數(shù)據(jù)，整個開發(fā)量會小非常多。

最后我們確定了這個簡單的實現(xiàn)方法，即把「生效」和「訂單」兩件事分開來。讓功能自行閉環(huán)，與訂單模塊隔離開來，即使出問題了，也能減少影響面。

我們是如何得出這個解法、思路是什么，我會在「方法論提取」部分重點說明，大家可以繼續(xù)往下看。

同時我也吸取之前的一些教訓(xùn)：功能流程太長、復(fù)雜導(dǎo)致的問題，在這一版設(shè)計中我都盡力規(guī)避，去做到「高內(nèi)聚、低耦合」。

例如我將訂單修改功能刪除，僅保留錄入訂單功能。

如信息有誤，則直接在錄入時選擇錯誤訂單，便可由系統(tǒng)快速填充信息提交新審批，無需自己手動重新填寫。

這個功能最后通過我的一番改造，從6個功能模塊，簡化為了3個功能模塊：

四、版本2-使用階段

最后上線后，只做了一場培訓(xùn)，線上意外的比我想象中更順利的跑通了起來。

并且在培訓(xùn)環(huán)節(jié)中，我們改變了過往的培訓(xùn)流程。

過往的培訓(xùn)流程中，由產(chǎn)品向公司所有人宣導(dǎo)，所以不直接操作系統(tǒng)的管理層，往往當(dāng)個”甩手掌柜“，遇到問題了就問我們，一線人員也是直接來問我們。

而一線人員的流動性較高，我們也每隔一段時間就需要回答同樣的問題。

新的培訓(xùn)流程只跟管理層培訓(xùn)，由管理層下發(fā)到一線執(zhí)行人員，他們的問題由管理層解答。

這種模式不僅讓管理層能更清楚系統(tǒng)能做什么，而且一線人員學(xué)習(xí)時，因為由上司直接培訓(xùn)，效果也好了許多。

版本2的順利上線和使用讓我終于松了口氣，回想起來，我在版本2中做對了這幾點：

• 學(xué)會拆分問題，不將所有問題整合起來處理。就像訂單生效和訂單使用，未必是一回事。
• 產(chǎn)品設(shè)計時，一定要遵循「高內(nèi)聚、低耦合」的原則。不僅開發(fā)起來更簡單，對業(yè)務(wù)人員的使用也更方便，無需記憶太多的使用方法。

五、經(jīng)驗教訓(xùn)&方法論提取

下面，我想根據(jù)上文提到的幾點經(jīng)驗教訓(xùn)，給大家分享下這中間可復(fù)用的方法論。

1. 拔高一些角度看，為什么版本1各種問題，版本2卻如此絲滑順暢？

這里是我自己嘗試從全局的角度思考這個項目，不一定對，歡迎大家和我一起交流。

1.1 公司戰(zhàn)略上

做版本1時的公司戰(zhàn)略，現(xiàn)在回想起來是做出比去年翻2倍的營收，那么當(dāng)時公司的重心一定是營收。

而審批的需求，更多是出于風(fēng)險控制，與營收無關(guān)。所以審批需求，它牽涉范圍很廣，需要各部門支持以外，卻又得不到公司的戰(zhàn)略支持。

意思就是實際落地時，其他部門人員覺得：我可以配合你，但你可別擋著我搞營收，壓力可大呢。

做版本2時的公司戰(zhàn)略，發(fā)生了重大改變。從營收，變?yōu)榱酥攸c控制成本、保證流程符合要求。

所以在版本2的需求會議上，很明顯地感覺到財務(wù)部門的人說話都更有底氣了。

總結(jié)起來，做版本2時，需求符合公司今年戰(zhàn)略，所以推進(jìn)起來更絲滑。

1.2 公司流程上

版本1時，公司未建立審批流程，所有的一切都是0-1。

版本2時，公司已經(jīng)跑了1年多的審批流程，有些曲折，但終究是能跑通的。

所以這兩點的差異，又導(dǎo)致了版本2注定比版本1好跑。而我在設(shè)計流程時，更是注意這一點，未增加新流程，而是把舊流程中不必要的細(xì)節(jié)剪裁掉，業(yè)務(wù)人員非常容易熟悉，不需要額外的學(xué)習(xí)、溝通成本。

1.3 公司文化上

這是一個非常有趣的視角，意思是窺探其他部門的做事風(fēng)格。

從我這次項目中，可以感受到銷售部門是非常擔(dān)心得罪客戶的，即使可能公司利益有損失，他們也不愿意得罪客戶。

這和指標(biāo)有關(guān)，也和他們長期以來的工作習(xí)慣有關(guān)。

和多幾個銷售溝通，發(fā)現(xiàn)他們都有一樣的擔(dān)憂?？梢岳斫鉃?，整個部門的風(fēng)格是這樣的。

所以如果事先窺探到這一點，就很容易理解為什么后來銷售側(cè)會推翻自己在會議中的保證。

方法論提?。?/p>

之前讀《金錢博弈》時，得到了一個洞察：當(dāng)項目進(jìn)行到一定時間后，成和不成很可能已經(jīng)不是談判人員的問題了，是這背后勢力的較量。

所以從這個角度去理解版本1為什么出問題，版本2為什么不出問題，就更容易明白一些。

在需要多個部門協(xié)作配合的項目中，如果沒有公司戰(zhàn)略支持，那么想要實行起來是十分困難的。

在開始一個項目前，可以先了解一下公司今年戰(zhàn)略是什么，各個部門的規(guī)劃又是怎么樣的。

作為一個個體，我們要盡全力做好。

但是也要學(xué)會觀察整個環(huán)境中，我們究竟受到哪些限制，這樣才能更好地定位接下來該如何行動。

如果我能盡早的觀察到這一點，可能后續(xù)的產(chǎn)品設(shè)計中，就會十分簡單去設(shè)計，并且只重點做一個監(jiān)控看板供財務(wù)部門分析訂單數(shù)據(jù)。

這樣既完成了項目目標(biāo)，又避免了復(fù)雜設(shè)計帶來的風(fēng)險。

同時，我們也可以反向得出一個結(jié)論：花更多時間去做公司戰(zhàn)略相關(guān)的項目。

不僅項目推進(jìn)更順暢，這些工作在年終總結(jié)、或晉升匯報里才能讓我們更亮眼。

2. 面對拒無可拒的不合理需求，如何盡可能做的合理、可復(fù)用性強？

版本2中，雖然業(yè)務(wù)負(fù)責(zé)人松口退讓了一步，但我們?nèi)匀恍枰瓿珊唵紊唐返摹赶壬?、后審批」?/p>

面對一個不合理的需求，我們是如何得出「訂單生效和訂單使用拆分開」的結(jié)論的？這里給大家重點分享一下解題思路，那就是：「拆分問題的思想」。

首先這里的問題看上去是是否要做「先生效，后審批」的功能，其實隱藏著3個問題：

1. 是否應(yīng)該是先生效，后審批？
2. 錄入訂單后，客戶可以等待多久？它應(yīng)該在多久內(nèi)生效？
3. 客戶使用商品，與訂單生效是必定劃等號的嗎？

第1個問題，按照市面上能夠接觸到的競品來看，幾乎所有的審批都是先審批，后生效。

先審批，后生效不僅開發(fā)流程簡單，不易出問題以外，也能避免成本的隱性支出。

第2個問題，根據(jù)之前客戶消費習(xí)慣數(shù)據(jù)來看，業(yè)務(wù)提出的觀點去確實有道理。

第3個問題，與開發(fā)進(jìn)行了一番討論后，使用商品，并不一定等于訂單生效。

這里帶出了解題的第二個重要思路：「盡量不與重要模塊耦合」。

訂單生效后代表著訂單數(shù)據(jù)生成、營收數(shù)據(jù)生成。但我們可以另外做一個「臨時使用權(quán)限」，類似與給內(nèi)部人員使用那種。

方法論提?。?/p>

• 遇到兩邊都是死胡同的問題，先將問題拆解開。不要將多個問題揉雜在一起。
• 拆解后，觀察問題之間是否劃等號？問題1=問題2嗎？
• 如果不劃等號，問題之間的平衡點在哪里？
• 最后設(shè)計時，盡量不與重要模塊耦合設(shè)計。

這里我的平衡點是采用臨時權(quán)限的功能來解決問題。

大家如果在工作中也遇到了類似的困難，可以采用這個方法去思考一下，說不定就有新的思路。

結(jié)束語

最后給大家總結(jié)一下本篇文章的幾個重要經(jīng)驗教訓(xùn)：

1. 面對不合理需求，產(chǎn)品應(yīng)該怎么處理？

學(xué)會拆分問題，不將所有問題整合起來處理。

盡量將“不合理”需求設(shè)計“合理”。具體的方法論也寫在了上面，希望對大家有幫助。

避免功能流程太長、復(fù)雜；遵循高內(nèi)聚、低耦合的設(shè)計原理。

2. 業(yè)務(wù)人員總是不按照定好的流程操作系統(tǒng)，自己搞“野路子”

建設(shè)新流程時，謹(jǐn)慎在業(yè)務(wù)未試跑前，就增加系統(tǒng)接入。

如果有可能，應(yīng)讓業(yè)務(wù)先在線下試跑。如無法試跑，則保持系統(tǒng)的最小介入，簡單開發(fā)MVP版本。

3. 項目上線前信誓旦旦的承諾，上線后立刻又變了個樣子，導(dǎo)致需求反復(fù)修補

不能過分聽信業(yè)務(wù)或任何其他部門給給予的保證。準(zhǔn)備好自己備用方案。

最后學(xué)會從公司戰(zhàn)略、部門規(guī)劃的角度理解項目。為什么高層想做這個項目，他們會有多重視這個項目。同時也盡量多去做跟戰(zhàn)略相關(guān)的項目，會讓我們協(xié)調(diào)其他部門，推進(jìn)項目都更順利。

那么今天的分享就到這里，如果你覺得本篇文章不錯，請幫我點個贊，給予我一些鼓勵吧~

如果你對文章有任何疑問，也歡迎來找我一起交流。