作者 | 少個分號

Bug 對于軟件來說是顯而易見的，程序員犯了一絲毫的錯誤就會帶來 Bug。

需求則不同，不適當的需求往往并不是那么明顯，而且暴露的很晚。錯誤的需求往往不會責備需求的提出方，因為互聯網時代需要快速 “試錯”，而糾正需求所產生的工作卻落到了工程師頭上。

顯然，這似乎不太公平。錯誤的需求難以被質疑，這也帶來了需求的肆意膨脹，是軟件設計不加以克制的原因。

下面是一個檢查清單，用于軟件工程師在接受需求時來評審需求是否合理。

原則

屁股決定腦袋，產品經理和軟件開發者之間的立場不同，則關注點不同，這是需求產品經理和開發之間的矛盾的主要原因。好的產品經理思考的是軟件的市場和背后的生意而不是用戶交互；好的軟件工程師思考的是軟件模型和整體設計，而不是某項技術的偏好。

如果軟件開發和建筑行業一樣，產品經理就是設計院，設計院輸出的圖紙，如果在施工方無法實施時，設計院會承擔巨大的責任。

互聯網時代，軟件和建筑一樣隨處可見。

軟件給人一種容易修改的錯覺。產品經理隨意調整需求被質疑后感到無辜，不就是改一點代碼的事情嗎，為啥說的那么難，這人肯定是技術不行。

簡單的軟件確實容易修改，同理，在農村搭一個窩棚也是，但復雜的軟件和摩天大廈不在此列。

復雜的軟件因為承載了大量的業務模型，以及各種存量的用戶數據，修改運行中的軟件，數據遷移的工作往往比預想要大很多，同時還要考慮已經發布出去的軟件兼容性。

需求變更應該是一個嚴肅和慎重的事情，這是原則。

提前

《一本小小的紅色寫作書》是我最喜歡的一本關于寫作的入門書籍，作者布蘭登·羅伊爾給新手提供了一個寫作建議：當你想到一個絕妙的主題，完成寫作并發布出去等待人們的贊美時，不妨先放一放。當一個好點子蹦出來時，人們往往把所有的美好都寄托在這個點子上，而絲毫看不到不合理之處，其實需要時間讓人冷靜下來。

產品經理往往會蹦出一些“絕妙” idea，自我美妙的 “上頭”。實際上在落地時，會遇到各種問題。

提前準備需求就顯得非常重要，提前三五個星期設計好的需求，隨著時間的推移，實際上每周都能有優化的點，到開始實施時也想的八九不離十了。

軟件工程師應該建議產品經理提前準備需求，如果是 2-3 天內的需求，就需要警覺起來。

雖然互聯網時代變化很快，但不是慌張的理由。

系統性

剛入行的人，多少可能對“系統”這個詞感到奇怪，我們明明只是做了一個軟件、網站或者小程序，但是為什么會被稱作為系統。

我們之所以稱這些軟件為系統，是因為現代軟件不像單機桌面軟件，它們有很多組成部分。Web、APP、管理后臺、開放 API、定時任務等各種組件構成。

系統性，帶來的就是牽一發而動全身。

一次產品經理提出需要收集用戶的公司信息，因此在注冊表單增加了一個字段，但是在管理后臺創建用戶時，并沒有相應的字段，造成數據的混亂。

當產品經理提出一個 Web 端的需求時，參考檢查項：

• 對應的后臺是否有相應管理功能？
• APP、小程序等其他端是否有類似需求？
• 開放出去的 API 是否受到影響？
• 已有數據是否需要遷移？
• 是否和其他功能沖突造成邏輯矛盾？

產品經理或 BA 需要知道當前系統的運行狀態，一個將軟件系統視為黑盒的產品經理，不太能提出嚴密的需求來，只能用創新作為托詞。

遵守慣例

不遵守業界操作慣例的軟件使用起來讓人非常難受，索尼微單的軟件操作方式比主流相機顯得怪異，即使很多人認可它的拍攝性能，也不愿意買單。

不遵守業界操作慣例，而美其名曰創新的需求，往往都會經歷來回改的結果。

按照慣例，信息系統的列表頁都會有分頁、搜索、篩選、排序等組成部分。如果設計上列表頁沒有分頁，在可以預見的情況之下，性能會非常差。

對于表單組件來說，每一種組件元素都有它背后的交互邏輯，刻意改變用途，不僅不能帶來創意效果，反而會讓用戶感到困惑。表單有四種基本元素，缺少了說明需求不合理，需要調整：

• 標簽
• 表單域
• 提示信息
• 操作按鈕

另外表單設計還需要考慮數據回填視圖，這種視圖下可能交互和 UI 有所不同。

一致性

需求的一致性體現一個軟件是否專業，影響用戶的主觀感受。

一致性有幾個維度：

• 操作邏輯上的一致性
• 組件 UI 一致性
• 文案的一致性

同類的交互使用同一個組件，避免出現多種組件。比如上傳文件的邏輯，文件大小、交互方式、允許的文件類型，都應該保持一致。

在之前一個產品中，領導要求 UI 的設計稿還原接近 100%，我們采用將設計稿疊加在瀏覽器中實現的。然而，中途設計師離職，新的設計師無法做到和原來的設計師保持完全一樣的設計尺寸、顏色。

這種情況繼續堅持 100% 的還原度，后果是前端代碼中所有的頁面都有自己的樣式文件，組件幾乎無法復用。

大的團隊往往有自己的設計規范、設計系統等，這樣也減少了高保真的輸出，使用設計系統，不必輸出高保真。開發人員使用原型圖 + 設計系統中的組件即可做出統一美觀的軟件界面來。

使用原型圖表達整個系統的交互邏輯，不用關系 UI 細節，UI 細節交給設計系統來完成。

文案的一致性，要求系統所有的地方使用同樣的名詞概念、表述方式，避免給用戶帶來困惑。

非功能性需求

評審需求時，非功能需求是最容易遺漏的需求，也是需求的冰山。下圖是一個添加文章的需求，背后有交互、性能、UI等多方面的非功能性需求。

有大量的文章敘述非功能需求，這里簡單給出一個清單：

(1)交互體驗相關

• Loading
• 表單的二次提交
• 輸出格式化
• 請求用戶確認和提示

(2)安全相關

• 身份校驗和權限
• 表單驗證

(3)性能相關

• 響應時間
• 生效時間（比如，權限相關允許重新登錄生效）

(4)可用性相關

• 兼容性
• 特殊設備適用性
• 本地化和國際化
• 升級策略

性價比

最后一項是性價比。

有一些需求不符合當前的軟件模型，改動成本極其高昂。但是如果產品經理做出一些取舍，根據當前的技術模型和架構進行調整，可以維持現在技術模型的一致性，降低開發成本。

比如，用戶的會員信息是存放在 Session 中，這樣每一次請求的權限檢查可以非常高效地完成。但是，代價是用戶的會員過期后，需要重新登錄才會生效，大多數系統都這樣處理，因為會員過期是一個極其低頻的事件。

如果產品經理要求，會員過期及時的告訴用戶，并進行續費，而不是在重新登錄時觸發這個行為。即使在技術上能完成，但是付出的代價非常大，也應該在評審時對此類需求進行質疑。