本文作者將以幾十年的從業經驗來告訴廣大的汪們：當你跟程序猿提需求時，程序猿到底在想什么？

普通人跟程序猿的交流，往往會產生一些意想不到的結果：

程序猿之妻：「老公，下班回來買六個蘋果，如果有賣西瓜的，買一個?！?/p>

程序猿：「好的，老婆大人?！?/p>

程序猿下班后，在超市里看到了賣西瓜的，然后買了一個蘋果回家了。

這類奚落程序猿的小故事大家應該都看過，雖說有點夸張，但也反應了程序猿怕老婆思維嚴謹的本質。

然而，在現實生活中，由于程序猿「喜愛加班」的天性，導致與程序猿交流最多的并不是程序猿之妻，而是產品汪！而交流最多的主題，就是「產品需求」。

下面，果果就以幾十年的從業經驗來告訴廣大的汪們：當你跟程序猿提需求時，程序猿到底在想什么？

是否違背邏輯？

這里說的邏輯并不是產品邏輯，而是「程序猿邏輯」。產品的邏輯往往是從用戶的角度出發，提供高效便捷的使用體驗，有時候也難免天馬行空。但程序猿的邏輯則以「嚴謹」著稱，一絲不茍。思維方式的不同，對同一個問題就難以達成共識。例如原來的產品中有根據搜索詞的動植物屬性作為類別展示結果的功能，現在如果你有一個需求，想在用戶搜索「竹子」的同時也能把熊貓展示出來，在你提需求前，先做好跟程序猿大戰三百回合的準備吧。

能實現嗎？

當討論需求點時，程序猿的腦子就會像翻字典一樣快速遍歷自己了解的所有技術，并逐一匹配需求中的對應功能。當需求中的所有關鍵功能都一一映射為技術點后，技術可行性基本上就沒問題了。然而，如果有個別技術點超出程序猿的「技術字典」收納范圍，合格的程序猿會說「我先調查下這幾個功能點」，但也有的程序猿會以「這幾個功能點無法實現」為由而直接拒絕需求。針對這樣的程序猿，一般的產品汪往往只能祭出競品的對應功能予以反擊，但長期關注果果公眾號的產品汪則能提出完整的技術方案，給程序猿造成暴擊傷害。

需求拆分和模塊化

對于哪些可以在之前的功能上稍作調整就可以實現的新功能，往往都是程序猿喜聞樂見的，這種需求一般都會很容易落地。因為這種需求不會引入太大的工作量，維護的工作量也較低。產品汪在設計需求時，如果每個版本的需求都循序漸進，或者新需求是基于其他功能實現，則更容易營造這種開發體驗。當然，這種需求「可遇而不可求」。所以，程序猿為了讓自己在后面的開發過程中更輕松，往往會將需求按功能點進行拆解，并形成邏輯上相互獨立的小功能模塊。這些小模塊就像「積木」，后期可以通過不同的復用和組合拼裝成不同的形狀。

性能是否可以接受？

程序猿在評估技術可行性的同時，還會對需求帶來的性能損耗做評估。針對后臺來說，可能會重點考慮網絡請求的峰值、同時最大并發連接數、帶寬和數據處理耗時等；針對終端來說，則考慮的是對CPU、內存等硬件資源的消耗，移動終端則還要考慮耗電等問題。如果你剛想到一個24小時用GPS監控用戶位置的需求，我勸你還是只想想就好。

這肯定不是需求的真面目！

作為一個程序猿，這點覺悟還是要有的。面對產品汪的朝三暮四，程序猿在完成需求功能點的同時，在代碼中如何設計良好可擴展性來應對需求變更，也是需要重點考慮的問題?？偛荒苷娴呐艿教炫_上讓你們立字據吧？！

#專欄作家#

給產品經理講技術，微信公眾號（pm_teacher），人人都是產品經理專欄作家。資深程序猿，專注客戶端開發若干年，對前端、后臺技術略懂，熱衷于對新的科技領域的探索。

本文原創發布于人人都是產品經理。未經許可，禁止轉載。