本文假設(shè)的讀者對(duì)象是程序員。

按他們說的做，真的沒問題嗎？

請(qǐng)問以下是一個(gè)真實(shí)需求嗎？

按鈕背景為灰色。

有時(shí)候，程序員接到需求，往往都是這樣的只言片語，作為開發(fā)人員，我們必須保持警惕和懷疑：
灰色是UI設(shè)計(jì)還是客戶公司的標(biāo)準(zhǔn)？它會(huì)變化嗎，可能有其它顏色嗎？
事實(shí)上，以上需求正確的描述是這樣：

APP的所有可視元素（顏色、字體）都可由用戶配置

看似一個(gè)不經(jīng)意的顏色改動(dòng)，背后隱藏的是這樣寬泛的功能性需求，如果不加以挖掘明確，開發(fā)過程將不停的在一個(gè)“小”功能上打轉(zhuǎn)：比如發(fā)布新版時(shí)，客戶要求所有按鈕背景改為粉紅色。

如何對(duì)付“我沒說過”的需求？

有時(shí)辛苦完成一個(gè)功能，領(lǐng)導(dǎo)過來讓你修改，你明明記得上次他的要求不是這樣，當(dāng)你指出這點(diǎn)時(shí)，領(lǐng)導(dǎo)丟來一句“我沒說過”，這時(shí)你是不是感到百口莫辯？
其實(shí)有時(shí)候也不是領(lǐng)導(dǎo)為難你，一個(gè)產(chǎn)品，隨著時(shí)間推移，戰(zhàn)略、想法、優(yōu)先級(jí)都會(huì)變化，當(dāng)然，也有可能是領(lǐng)導(dǎo)真的忘記了；但程序開發(fā)畢竟是有周期的，因此為避免對(duì)功能需求產(chǎn)生誤解，杜絕“翻盤式修改”，推薦使用【需求卡片】。

簡(jiǎn)化版的需求卡片

可能有的開發(fā)一線的童鞋不樂意了：這不是需求人員的活嗎？是的，收集需求確實(shí)是需求分析工作的一部分，但需求人員可能并不了解實(shí)現(xiàn)細(xì)節(jié)，這個(gè)表格就是一份檢查清單，確認(rèn)用戶描述的需求轉(zhuǎn)化成了可以具體執(zhí)行的【用戶用例】，可以用于進(jìn)度追蹤和測(cè)試標(biāo)準(zhǔn)。
當(dāng)然，即使我們完成了需求卡片，也不是默默地自我欣賞遵循就好了，請(qǐng)把這些卡片發(fā)給產(chǎn)品需求或項(xiàng)目經(jīng)理、測(cè)試人員確認(rèn)，如果能直接發(fā)給“問題提出人”，也是最好不過。

在開始寫下第一行代碼前，花點(diǎn)時(shí)間，填寫需求卡片。

確認(rèn)雙方在說同一件事

某周五距離下班前半小時(shí)，產(chǎn)品汪在群里大喊：“@XXX，某某功能做完了嗎？測(cè)試那邊等著要?！?br> 程序猿：“做完了，周三的測(cè)試包里就有。”
（...大約10分鐘后）
產(chǎn)品汪：“測(cè)試那邊說沒看見，我也安裝試過了，沒有發(fā)現(xiàn)某某功能模塊！”
程序猿：“等等，我檢查下”
（...大約20分鐘后）
程序猿：“明明在安裝包里啊，你確定安裝了0.2.8版嗎？”
產(chǎn)品汪：“我看下”
（...大約15分鐘后）
產(chǎn)品汪：“確認(rèn)過了，版本號(hào)是0.2.8，測(cè)試那邊也確認(rèn)過了，你打個(gè)新包出來?！?br> 程序猿：“好吧|||”
（...大約20分鐘后）
程序猿：“新包打好了，你們看一下?！?br> （...大約10分鐘后）
產(chǎn)品汪：“還是沒有?。?！”
程序猿：“怎么沒有，（截圖）”
產(chǎn)品汪：“！不是這個(gè)呀，是某某功能?！?br> 程序猿：“這就是某某功能！”
產(chǎn)品汪：“某某功能是這樣的（另一幅截圖）?。?！”
程序猿：“這個(gè)功能?。。?！這個(gè)不是某某某功能嗎？某某功能還在開發(fā)”
產(chǎn)品汪：“...”
（此時(shí)，距離下班時(shí)間已過去一個(gè)小時(shí)，產(chǎn)品汪、程序猿的對(duì)話還在繼續(xù)，苦逼的測(cè)試鼠默默地拿起手機(jī)向女友道歉：晚上估計(jì)要加班...）
這樣一幕是不是感到似曾相識(shí)？問題在于對(duì)于“某某功能”，產(chǎn)品汪、程序猿沒有統(tǒng)一，如果測(cè)試鼠對(duì)“某某功能”的定義與產(chǎn)品汪也不一致，這個(gè)反復(fù)確認(rèn)的時(shí)間會(huì)指數(shù)級(jí)增長(zhǎng)，各種產(chǎn)品參與者對(duì)具體功能定義產(chǎn)生了<u>理解誤差</u>，或許我們不停加班原因就在于此。
同樣是表格，在iOS系統(tǒng)（左圖）和Excel（右圖）中分別指：

【表格】的不同含義

因此，在開發(fā)前，產(chǎn)品參與者們一同約定一個(gè)【詞匯表】，并用“有道云協(xié)作”這樣的云工具共同編輯，確保大家在后面的溝通沒有誤差，是非常必要的。

IBM產(chǎn)品詞匯表

詞匯表是一組為項(xiàng)目構(gòu)建一致性的常規(guī)術(shù)語而創(chuàng)建的詞匯。

區(qū)分無形的腳鐐還是大氣層

經(jīng)常聽到，APP端的童鞋抱怨服務(wù)端的接口改了，導(dǎo)致一套界面無法使用。很多時(shí)候我們覺得程序無法修改了，甚至無法開始寫代碼，這時(shí)候不如問下自己下面這些問題：

1. 這是需求問題還是技術(shù)問題？
2. 商量好的方法確實(shí)能解決這個(gè)問題嗎？
3. 這個(gè)問題必須要解決嗎？不解決會(huì)怎么樣？
4. 作為開發(fā)者，我能自由發(fā)揮的范圍有多大？

NLP心理學(xué)說就假設(shè)

凡事有三個(gè)以上解決方案。

有時(shí)候重新解釋問題，問題會(huì)自己消失。
比如現(xiàn)在APP開發(fā)對(duì)過場(chǎng)動(dòng)畫越來越重視，很多開發(fā)童鞋一開始實(shí)現(xiàn)功能時(shí)就糾纏于加動(dòng)效，可有時(shí)候，領(lǐng)導(dǎo)可能只是要個(gè)演示功能的安裝包而已，正式開發(fā)時(shí)，可能很多頁面都不要了，如果不加以區(qū)分，一律加動(dòng)效，自己做了無用功不說，還耽誤了軟件發(fā)布的時(shí)間，自然雙方都不滿意。

小結(jié)：

本篇介紹了在實(shí)際編程前，必須要做的工作：

1. 對(duì)需求保持警惕，主動(dòng)了解真實(shí)需求。
2. 用需求卡片記錄需求，挖掘領(lǐng)導(dǎo)或客戶的真實(shí)意圖。
3. 使用詞匯表，保持大家對(duì)某具體問題的描述一致。
4. 重新解釋問題，避免糾纏于不必要的問題。

不要收集需求，而要挖掘需求！

畢竟我們程序員是最終為程序負(fù)責(zé)的人，祝各位編程快樂！

本文為溪石iOS原創(chuàng)
轉(zhuǎn)載務(wù)經(jīng)授權(quán)