“程序猿”不明白你一定要這么設(shè)計的原因，因為在他看來用另外的方式做也達成了一樣的效果。

一大早聽到群里一個驚恐的消息：

我的需求昨天晚上開會又被開發(fā)砍了，整個產(chǎn)品一共就兩個模塊，再這么砍就什么都沒有了。

什么？！這年頭還有開發(fā)砍產(chǎn)品的需求？表示不能理解。我覺得如果是市場和實施運營人員表示要“砍需求”，還有點說法，但是開發(fā)人員什么時候也能決定需求的生死了？WHY？

但是仔細回憶一下，在筆者的BA生涯中，貌似還真的發(fā)生過“砍需求”的事情。不過是BA“砍”了產(chǎn)品經(jīng)理的需求。

那個時候我是一名小兵，對于產(chǎn)品經(jīng)理說的所有需求，全盤接受，乖乖地去寫需求規(guī)格。有一年，我們謀劃要開發(fā)一個新的模塊。產(chǎn)品經(jīng)理列了一張Backlog，里面大概有100來個需求。然后我的Leader就召集了產(chǎn)品經(jīng)理、研發(fā)經(jīng)理和我這個小兵開會討論。不到兩個小時，砍掉了2/3的需求。重點是產(chǎn)品經(jīng)理沒有表示不滿，大家皆大歡喜。

我們先來分析下，需求為什么會被？特別是被研發(fā)團隊“砍”。原因八成是：

1. 項目時間緊
2. 技術(shù)有難度

筆者之前遇到的那個情況就是項目時間緊。其實也不緊，只是我們的流程要求我們每一個內(nèi)部版本都要保證質(zhì)量可驗證演示。所以，我們的每個版本都基本上是0缺陷的提交。而且還要留給開發(fā)做單元測試，Code Review，定期的重構(gòu)等等。

而現(xiàn)在很多情況下，大家都對工作量評估呈現(xiàn)一種樂觀的態(tài)度，并且對于加班這件事情習(xí)以為常?！俺绦蛟场笨承枨髴{借的應(yīng)該就是覺得自己很理解需求，而且覺得自己能用最小的工作量達成要求吧！畢竟誰都不想加班。

但是今天我想說的是，這里有一部分我們的責(zé)任。

首先，你的需求是否有分優(yōu)先級？

我們在做一個產(chǎn)品，一個模塊，一個功能時，會分析這個對象的BackBone，就是組成的軀干是什么。這些需求的優(yōu)先級肯定是標明“高”。這些需求絕對不能砍，砍了就會影響到用戶使用，影響到產(chǎn)品價值和賣點，影響到產(chǎn)品整體業(yè)務(wù)架構(gòu)。你要知道，全都是“高”優(yōu)先級的需求等同于優(yōu)先級都是“低”。

其次，你是否有自己的一個對計劃進度的判斷？

這個主要是基于經(jīng)驗了。有的時候一句話的需求，開發(fā)要做很長時間；相反，有的需求原型、規(guī)格描述了一大堆，開發(fā)只要半天就搞定了。而你可以根據(jù)你對于這個功能實現(xiàn)所需要用到的控件、接口的復(fù)雜度進行一個判斷。

另外，多和項目經(jīng)理、開發(fā)經(jīng)理溝通。如果你無法做出判斷，就需要先和開發(fā)負責(zé)人以及項目經(jīng)理做好溝通。
讓他們先判斷哪些可能會存在技術(shù)難點，哪些需要進行架構(gòu)統(tǒng)一規(guī)劃的。

最后，要多和團隊成員宣貫產(chǎn)品價值和理念。

這是最重要的一點。很多溝通的點在于，“程序猿”不明白你一定要這么設(shè)計的原因，因為在他看來用另外的方式做也達成了一樣的效果。

因此，你需要在做分析的時候一方面需要考慮全面了，最好是“程序猿”提到的那個方案當(dāng)初就被你否了，而且理由很充分；另外一方面，你需要和大家講清楚了自己為什么這么設(shè)計，會給用戶帶來什么樣的美好體驗和不可替代的價值。

寫在最后：

最可怕的是，有些程序猿GG為了省事，你怎么說他就怎么硬編碼到產(chǎn)品里。你驗收也看不出來，純粹挖了坑給后面改BUG和做增強的人了。這可比當(dāng)著你的面砍你的需求可怕多了。

好的代碼是有設(shè)計感的，所謂代碼之美。代碼是設(shè)計出來的，不是寫出來的。

作者：顏小婧，微信公眾號【xiaojing-jessieyj】，與小婧同行。

來源：http://www.jianshu.com/p/40a1a107eeee

本文由 @顏小婧 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。