[答疑]需求规约要不要提醒程序员界面设计的注意事项
甘思咪哚 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)。
也就是说一个人可以做三件事情,三件事情的结果也可以钉在一起交付,但没有必要把这三件事情混在一起——"代码就是需求",那就混淆了自己的视线,把自己给坑了。
人可以变,岗位的名头可以花样翻新,事情还是那些事情。
还是那句老话:哄人可以,但自己心里要清楚自己在做什么。而这一点,很多开发团队是做不到的。
====广告分隔线====
| ||||||||||||||||||||
[训练介绍] 软件开发中,需求是解决“产品怎样好卖”的问题,设计是解决“降低生产成本”的问题。二者相辅相成,缺一不可。而且,不能相互取代。要迈向“低成本制造好卖的产品”的境界,并非喊喊口号就能达到,需要静下心来,学习和实践各种技能。 在这个强调“做减法”的时代,建模是正确帮助您“做减法”的绝佳工具。 本训练就是教授如何使用UML2.5相关的需求和设计技能来全程实例剖析一个系统的过程。 本训练对每个开发工作流,结合讲解、做练习巩固、应用到实际项目三种方式,展示使用UML2.5相关技能开发软件系统的全过程,解答实际应用中的疑难细节问题。 [学员要求] 有一年以上项目经验的需求或设计(编码)人员。不需要您有“UML基础”,只需要您有项目经验。欢迎学员携带自己的项目来听课,由专家在现场进行剖析。 [专家] UMLChina首席专家 潘加宇。在1999年还是一名程序员时,利用业余时间创建了UMLChina,潜心研究软件需求和设计技能。2002年开始对外提供UML需求和设计的技术指导和训练服务,到现在为止,已经上门为超过270家的软件组织提供服务,覆盖了国内各个领域的领袖企业,包括通信、企业管理、电子商务、房地产、网络游戏、地理信息、物流、数码设备、医疗设备、工业控制.....等领域。 [课程大纲] 1. 概论 以上时间分配会根据项目特点和训练进程调整。 |