甘思咪哚 2018-12-25 12:41

潘老师，我们做的app需要在各种平台各种型号的手机上使用。现在有这样一个问题，假设存在一款安卓手机操作方式和其他安卓手机有点不同，例如，手用某种方式滑动，其他手机没有问题，但在该款手机上app就关闭了，会导致不了解情况的用户带来不好的体验，所以程序员有必要对这种情况作相应处理。

那么，需求规约里需要描述处理这种情况的要求吗？如果不描述的话，程序员可能就会漏掉。

潘加宇：

这个问题属于实现平台的问题，不管针对什么领域，针对哪一款app，针对哪个用例，这个问题都是一样的。它不是需求，也不是分析，而是设计。

我们可以通过问"不这样可能会怎样"来找到真正的需求。不这样做可能会怎样？可能会提高了执行者的操作中无效操作的比例。这个才是真正的需求，属于可用性需求。

手不小心一滑导致app关闭的操作，和关闭按钮在屏幕上摆设位置不当总是不小心按到没有本质区别，和键盘布局不合理导致老是按错键没有本质区别，甚至和数据库字段设计不合理导致保存失败也没有本质区别。

我们来理一下三个不同的工作。这三个不同工作的结果之间的映射是多对多的，稳定性也不一样。

（1）可用性需求：执行者在本用例的操作中无效操作的比例不高于***。

这个比例的值不是随便乱定，而是根据相同情况下执行者使用竞争对手产品的比例而定。

负责做需求的岗位可以称为需求工程师。

（2）交互设计：某种操作环境中，什么样的交互方案是最合适的。

这个需要人机交互心理的知识、不同操作环境中人机交互方式的知识。

负责做交互设计的岗位可以称为交互设计师。

（3）界面实现：某种操作环境中，执行者真正与之交互的界面实现。

这个需要实现界面的组件库的编程知识。

负责界面实现的岗位可以称为程序员。

首先，（1）（2）（3）这三个事情要分开，就算是一个人来做，依然是三件事。

就像看病一样，不能说医生给自己看病就可以直接开药吃。医生也要老老实实钻到仪器里面自己检查，自己看影像，自己诊断，自己开药，自己吃。

我们回到上面的问题。如果需求写了（1），又没有交互设计师参与，程序员也对某种操作环境下的开发界面的注意事项不熟悉，结果肯定是不好的，但这里的问题是（2）（3）两项技能缺乏，应该补上（2）（3）的技能。

问题又来了：如果目前就没有办法请交互设计师，程序员的技能也一下提高不上去，能不能在需求规约里面写（2）（3）？

回答依然是不应该。一个东西是什么就是什么。这种情况下，需求人员如果觉得自己是目前团队中最适合做交互设计的，那么可以顺便把（2）给做了。但做的东西依然是（2）。同理，如果经过权衡，认为需求人员在界面实现的某些方面比程序员要熟悉，或者程序员是老板的小舅子，到公司来上班就是玩玩的，那么需求人员也可以顺便把一部分（3）给做了，但做的东西依然是（3）。

也就是说一个人可以做三件事情，三件事情的结果也可以钉在一起交付，但没有必要把这三件事情混在一起——"代码就是需求"，那就混淆了自己的视线，把自己给坑了。

人可以变，岗位的名头可以花样翻新，事情还是那些事情。

还是那句老话：哄人可以，但自己心里要清楚自己在做什么。而这一点，很多开发团队是做不到的。