遇到不合理的業務需求，項目流程和走向不如愿，你是如何應對的？作者復盤了自己的這次項目，針對兩個版本進行了分析，總結了相關經驗和教訓，希望對你有所啟發。

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

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

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

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

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

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

我對這次項目復盤了一下，總結出了十分重要的經驗分享給大家。

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

背景說明：我負責在線教育公司的自研系統，本次舉例的功能是訂單錄入+審批的功能。

一、版本1-設計階段

這個需求最先開始于業務希望新增錄入訂單。

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

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

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

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

完成了初期的調研工作后，很快，我與相關部門進行了第一次會議，定下了本次項目目標：

• 從財務層面減少風險；
• 將這個流程順利地嵌入現有業務流程中；

順著這兩個目標，我開始了產品設計。

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

省略了一些環節，大家可以簡單理解。

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

問題從這里開始出現：

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

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

經過協商，業務人員用充分的理由打敗了我們：需要立刻使用訂單的客戶占比不少。

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

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

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

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

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

財務人員沒有對該需求表示異議，我仍然按照這個版本的設計正常推進了。

二、版本1 – 使用階段

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

但上線后——問題爆發了。

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

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

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

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

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

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

我回答：“是財務人員駁回了訂單呀?！?/p>

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

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

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

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

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

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

經過幾位大佬們的商討，我們仍然同意了銷售的“新訴求”，就這樣運行了1年多的時間。

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

經過這次的項目，我總結出了2點經驗教訓：

1. 流程未試跑，便直接接入系統

這次的項目是建設一條新流程，此前我們從未試跑過。所以真正系統上線后，出現了許多我們未能預料的情況。

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

如果業務沒條件去試跑的話，那么系統在這時候的介入應該保持最小介入，簡單開發，不能做太個性化的設計。

簡單開發的思路，我會在下文繼續跟大家詳細分享。

2. 不能過分聽信業務或任何其他部門給給予的保證

屁股是決定腦袋的：所有人都是根據他的指標去行動的。

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

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

也許他認為監督很重要，但是時間精力已經不允許他完成監督工作。

所以對方給予了保證，我們應該都持懷疑態度，準備好一些備用方案。

三、版本2 – 設計階段

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

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

業務人員則一直強調立即生效的必要性，也拿出了數據證明。并且認為保證客戶體感應該是產品需要考慮的問題。

這段時間陸陸續續拉了幾次會議，我們一直達不到共同的結論。

最后事情遲遲沒有推進，領導喊上了業務最大的負責人一起商討。

業務總負責人則認同應該審批后再生效訂單，可能是位置的原因，他也更愿意為公司利益考量。但屬下反饋的問題他也不得不管。

最后在總負責人的協調下，我們采取了折中方案：

• 存在關聯關系的商品，不允許先生效，必須等待財務審批通過。
• 簡單商品的訂單需要先對客戶生效。

拿到會議結果的時候不由得喜從心中生，產品設計的時候多快了許多。

不過我們仍然面臨著「簡單商品的訂單，需要先生效」的問題。

這次我也學會了不再埋頭苦干，和其他團隊伙伴、領導進行了一番商討后，我們發現這個功能也許并不需要很復雜。

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

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

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

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

同時我也吸取之前的一些教訓：功能流程太長、復雜導致的問題，在這一版設計中我都盡力規避，去做到「高內聚、低耦合」。

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

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

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

四、版本2-使用階段

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

并且在培訓環節中，我們改變了過往的培訓流程。

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

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

新的培訓流程只跟管理層培訓，由管理層下發到一線執行人員，他們的問題由管理層解答。

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

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

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

五、經驗教訓&方法論提取

下面，我想根據上文提到的幾點經驗教訓，給大家分享下這中間可復用的方法論。

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

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

1.1 公司戰略上

做版本1時的公司戰略，現在回想起來是做出比去年翻2倍的營收，那么當時公司的重心一定是營收。

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

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

做版本2時的公司戰略，發生了重大改變。從營收，變為了重點控制成本、保證流程符合要求。

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

總結起來，做版本2時，需求符合公司今年戰略，所以推進起來更絲滑。

1.2 公司流程上

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

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

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

1.3 公司文化上

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

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

這和指標有關，也和他們長期以來的工作習慣有關。

和多幾個銷售溝通，發現他們都有一樣的擔憂?？梢岳斫鉃?，整個部門的風格是這樣的。

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

方法論提?。?/p>

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

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

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

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

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

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

如果我能盡早的觀察到這一點，可能后續的產品設計中，就會十分簡單去設計，并且只重點做一個監控看板供財務部門分析訂單數據。

這樣既完成了項目目標，又避免了復雜設計帶來的風險。

同時，我們也可以反向得出一個結論：花更多時間去做公司戰略相關的項目。

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

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

版本2中，雖然業務負責人松口退讓了一步，但我們仍然需要完成簡單商品的「先生效、后審批」。

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

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

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

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

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

第2個問題，根據之前客戶消費習慣數據來看，業務提出的觀點去確實有道理。

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

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

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

方法論提?。?/p>

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

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

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

結束語

最后給大家總結一下本篇文章的幾個重要經驗教訓：

1. 面對不合理需求，產品應該怎么處理？

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

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

避免功能流程太長、復雜；遵循高內聚、低耦合的設計原理。

2. 業務人員總是不按照定好的流程操作系統，自己搞“野路子”

建設新流程時，謹慎在業務未試跑前，就增加系統接入。

如果有可能，應讓業務先在線下試跑。如無法試跑，則保持系統的最小介入，簡單開發MVP版本。

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

不能過分聽信業務或任何其他部門給給予的保證。準備好自己備用方案。

最后學會從公司戰略、部門規劃的角度理解項目。為什么高層想做這個項目，他們會有多重視這個項目。同時也盡量多去做跟戰略相關的項目，會讓我們協調其他部門，推進項目都更順利。

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

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