本文假设的读者对象是程序员。
按他们说的做，真的没问题吗？
请问以下是一个真实需求吗？
按钮背景为灰色。
有时候，程序员接到需求，往往都是这样的只言片语，作为开发人员，我们必须保持警惕和怀疑：
灰色是UI设计还是客户公司的标准？它会变化吗，可能有其它颜色吗？
事实上，以上需求正确的描述是这样：
APP的所有可视元素（颜色、字体）都可由用户配置
看似一个不经意的颜色改动，背后隐藏的是这样宽泛的功能性需求，如果不加以挖掘明确，开发过程将不停的在一个“小”功能上打转：比如发布新版时，客户要求所有按钮背景改为粉红色。
如何对付“我没说过”的需求？
有时辛苦完成一个功能，领导过来让你修改，你明明记得上次他的要求不是这样，当你指出这点时，领导丢来一句“我没说过”，这时你是不是感到百口莫辩？
其实有时候也不是领导为难你，一个产品，随着时间推移，战略、想法、优先级都会变化，当然，也有可能是领导真的忘记了；但程序开发毕竟是有周期的，因此为避免对功能需求产生误解，杜绝“翻盘式修改”，推荐使用【需求卡片】。
可能有的开发一线的童鞋不乐意了：这不是需求人员的活吗？是的，收集需求确实是需求分析工作的一部分，但需求人员可能并不了解实现细节，这个表格就是一份检查清单，确认用户描述的需求转化成了可以具体执行的【用户用例】，可以用于进度追踪和测试标准。
当然，即使我们完成了需求卡片，也不是默默地自我欣赏遵循就好了，请把这些卡片发给产品需求或项目经理、测试人员确认，如果能直接发给“问题提出人”，也是最好不过。
在开始写下第一行代码前，花点时间，填写需求卡片。
确认双方在说同一件事
某周五距离下班前半小时，产品汪在群里大喊：“@XXX，某某功能做完了吗？测试那边等着要。”
程序猿：“做完了，周三的测试包里就有。”
（...大约10分钟后）
产品汪：“测试那边说没看见，我也安装试过了，没有发现某某功能模块！”
程序猿：“等等，我检查下”
（...大约20分钟后）
程序猿：“明明在安装包里啊，你确定安装了0.2.8版吗？”
产品汪：“我看下”
（...大约15分钟后）
产品汪：“确认过了，版本号是0.2.8，测试那边也确认过了，你打个新包出来。”
程序猿：“好吧|||”
（...大约20分钟后）
程序猿：“新包打好了，你们看一下。”
（...大约10分钟后）
产品汪：“还是没有！！！”
程序猿：“怎么没有，（截图）”
产品汪：“！不是这个呀，是某某功能。”
程序猿：“这就是某某功能！”
产品汪：“某某功能是这样的（另一幅截图）！！！”
程序猿：“这个功能啊！！！这个不是某某某功能吗？某某功能还在开发”
产品汪：“...”
（此时，距离下班时间已过去一个小时，产品汪、程序猿的对话还在继续，苦逼的测试鼠默默地拿起手机向女友道歉：晚上估计要加班...）
这样一幕是不是感到似曾相识？问题在于对于“某某功能”，产品汪、程序猿没有统一，如果测试鼠对“某某功能”的定义与产品汪也不一致，这个反复确认的时间会指数级增长，各种产品参与者对具体功能定义产生了<u>理解误差</u>，或许我们不停加班原因就在于此。
同样是表格，在iOS系统（左图）和Excel（右图）中分别指：
因此，在开发前，产品参与者们一同约定一个【词汇表】，并用“有道云协作”这样的云工具共同编辑，确保大家在后面的沟通没有误差，是非常必要的。
词汇表是一组为项目构建一致性的常规术语而创建的词汇。
区分无形的脚镣还是大气层
经常听到，APP端的童鞋抱怨服务端的接口改了，导致一套界面无法使用。很多时候我们觉得程序无法修改了，甚至无法开始写代码，这时候不如问下自己下面这些问题：
- 这是需求问题还是技术问题？
- 商量好的方法确实能解决这个问题吗？
- 这个问题必须要解决吗？不解决会怎么样？
- 作为开发者，我能自由发挥的范围有多大？
NLP心理学说就假设
凡事有三个以上解决方案。
有时候重新解释问题，问题会自己消失。
比如现在APP开发对过场动画越来越重视，很多开发童鞋一开始实现功能时就纠缠于加动效，可有时候，领导可能只是要个演示功能的安装包而已，正式开发时，可能很多页面都不要了，如果不加以区分，一律加动效，自己做了无用功不说，还耽误了软件发布的时间，自然双方都不满意。
小结：
本篇介绍了在实际编程前，必须要做的工作：
- 对需求保持警惕，主动了解真实需求。
- 用需求卡片记录需求，挖掘领导或客户的真实意图。
- 使用词汇表，保持大家对某具体问题的描述一致。
- 重新解释问题，避免纠缠于不必要的问题。
不要收集需求，而要挖掘需求！
毕竟我们程序员是最终为程序负责的人，祝各位编程快乐！
本文为溪石iOS原创
转载务经授权
