采用敏捷迭代開發(fā)的互聯(lián)網(wǎng)公司，往往在每一個迭代開始前，產(chǎn)品、開發(fā)、測試會通過需求會、沖刺會，評估該迭代的需求和工時，保證在該迭代內(nèi)把所有明確的需求完成開發(fā)和測試。然而，相信很多產(chǎn)品都經(jīng)歷過在迭代進(jìn)行中加需求的情況，那么如何可以保證向開發(fā)、測試加需求時不被打呢？
一、為什么會在迭代中加需求
從緊急重要四象限需求分析方法來看，在迭代中需要加的需求，一定是緊急重要（也許并非真的“重要緊急”）的需求，那么這類需求大致可分為以下兩個維度：
1. 老板的需求
在迭代中的某一天，老板找到你說，某某功能體驗不好、改一改啊。你心想，老板好不容易加一次需求，雖然這個需求看起來并不靠譜，但是也不好拒絕呀，就說好。然而老板的下一句話讓你瞬間崩潰，“我覺得這個功能需要趕緊改，兩天后上吧”。
“What the f*”，相信你的內(nèi)心一定是這樣的，但是你又無法拒絕，只能加班設(shè)計解決方案，然后膽戰(zhàn)心驚的去找開發(fā)、測試哥哥姐姐們聊聊“家常”。
其實(shí)上面這種場景很常見，至少我就遇到過很多次，老板提的需求有的很靠譜，有的卻很扯，當(dāng)然最關(guān)鍵的是老板的需求都很急。如果老板的需求是在迭代周期剛開始提出來還比較好解決，但是如果老板的需求在迭代的中后期提出來并且要求緊急上線的這種，對產(chǎn)品來說才是最難受的。
但是請記住一句話，老板的需求，再不合理，還是要做?。▽τ诓缓侠淼男枨螅绾卧谧鐾暝俸屠习鍦贤?，在本文最后會通過一個案例進(jìn)行復(fù)盤）
2. 對用戶體驗，對公司收益造成重大損失
這類緊急需求更容易讓團(tuán)隊成員接受，在線上運(yùn)行的產(chǎn)品，突然出現(xiàn)了某一個對用戶體驗造成重大傷害或?qū)臼找嬖斐芍卮髶p失的問題，那么設(shè)計解決方案并緊急安排開發(fā)上線，這種場景對于大多數(shù)人來說都是比較容易接受的。
二、如何保證加需求不被打
1. 以理服人
首先，需求的解決方案一定是可實(shí)現(xiàn)的，比如：前兩天某安的產(chǎn)品與開發(fā)大打出手，就是因為需求的不可實(shí)現(xiàn)性。先不去看需求是否合理（畢竟老板提的不合理需求你也是要滿足的），要保證的是給開發(fā)的解決方案是可以實(shí)現(xiàn)的。
其次，從5W2H的角度與開發(fā)、測試溝通需求，需求的背景，即誰提出了一個什么樣的問題，這個問題在某個端（PC、小程序、APP等）對用戶或公司造成了什么樣的影響，影響有多大。再提出你的解決方案，即通過什么方案去解決這個問題，能達(dá)到什么樣的效果，希望什么時間上線。
最后，就是與開發(fā)和測試確認(rèn)時間點(diǎn)，對于用戶體驗和公司損失的問題，團(tuán)隊成員都容易理解，通過加班等方式也會盡力去保證及時上線。對于老板的需求，多多少少都會有些抵觸心理，那么產(chǎn)品在這中間就要做到協(xié)調(diào)，盡可能讓老板和團(tuán)隊開發(fā)、測試都滿意，如何做到就是下面要說的學(xué)會向上溝通。
2. 學(xué)會向上溝通
對于老板提的不合理或者不靠譜的需求，前面說了，一定要做。那么接下來就是具體的方案和時間點(diǎn)，通過與開發(fā)、測試溝通好方案后，也許這個方案與老板要求的上線時間點(diǎn)不一致。
這個時候就要去和老板溝通，擺事實(shí)、講道理，和老板溝通為什么不能在有限的時間點(diǎn)內(nèi)完成并上線。羅列解決方案的復(fù)雜性，開發(fā)、測試資源的不足等等，老板也是從普通員工做起的，我相信只要你說的有道理，老板不會蠻不講理的。
向上溝通，就是要保證團(tuán)隊成員和老板都盡可能的滿意，不能完全壓榨團(tuán)隊的積極性去一味的拿老板的需求當(dāng)尚方寶劍，這樣起到的作用也許適得其反。
三、案例復(fù)盤
最后通過一個案例來聊一聊，面對老板提的不靠譜需求，你應(yīng)該如何合理的處理。
這個案例是這樣的：
用戶在購買服務(wù)后并沒有立即支付，對于未支付的訂單會在30分鐘后自動取消，那么為了做到對用戶的提醒，提高支付成功率。系統(tǒng)會對下單后未支付超過10分鐘的用戶進(jìn)行短信提醒，短信中會加入訂單詳情頁鏈接，引導(dǎo)用戶點(diǎn)擊繼續(xù)支付。
某一天老板用了一下這個功能，發(fā)現(xiàn)通過點(diǎn)擊鏈接進(jìn)入訂單詳情頁時要先登錄，再點(diǎn)擊去支付跳轉(zhuǎn)收銀臺才能支付。于是老板提了一個需求說，鏈接直接跳收銀臺讓用戶支付就好了，為什么要加那么多繁瑣的步驟，影響用戶的繼續(xù)支付意愿。
本質(zhì)上來說，這樣一個優(yōu)化點(diǎn)是有些不合理的，在電信詐騙猖獗的今天，用戶通過短信鏈接直接支付而不做任何提醒，對用戶來說是有疑問的，用戶可能不會輕易去支付。但是老板提了需求，就要做，3天時間開發(fā)、測試、上線。
為了保證老板能看到上線后的效果，以及想讓老板了解，這個需求也許并不是那么合理。通過在頁面埋點(diǎn)以及從后臺提取數(shù)據(jù)，分析對比了一下功能優(yōu)化上線前后的數(shù)據(jù)效果，從繼續(xù)支付的數(shù)據(jù)上看，效果并沒有明顯提升。
通過頁面打點(diǎn)來看，用戶通過短信鏈接進(jìn)行繼續(xù)支付的幾乎沒有，通過分析和猜測，可能更多的用戶還是在看到短信后繼續(xù)登錄了app進(jìn)行繼續(xù)支付，短信鏈接直接跳收銀臺的優(yōu)化理論上沒有起到任何正向的效果。
通過這樣一個案例可以看出，老板也許只從個人的角度去看待功能的優(yōu)化，并未考慮用戶以及環(huán)境的因素，那么提出了這樣一個不算合理的需求，作為產(chǎn)品經(jīng)理，不僅要對老板負(fù)責(zé)，還要對更廣大的用戶負(fù)責(zé)。
在滿足了老板的需求后，也要通過上線后效果去提醒老板，也許還有更好的方案去提升用戶繼續(xù)支付成功率的指標(biāo)，而不是通過現(xiàn)有的方案。
