作者|少了一个分号Bug对于软件来说是显而易见的，程序员稍有不慎就会带来Bug。需求不同。不当的需求往往不是那么明显，而且暴露的很晚。错误的需求往往不归咎于需求者，因为互联网时代要求快速“试错”，改正需求的工作落在了工程师身上。显然，这似乎不公平。错误的需求很难被质疑，这也带来了需求的肆意膨胀，这也是软件设计不对其进行约束的原因。下面是一份清单，供软件工程师在接受需求时检查需求是否合理。原则是屁股决定脑袋，产品经理和软件开发人员的立场不同，所以关注点不同。这是造成需求产品经理和开发人员矛盾的主要原因。一个好的产品经理考虑的是软件市场及其背后的业务，而不是用户交互；一个好的软件工程师考虑的是软件模型和整体设计，而不是偏爱某项技术。如果说软件开发好比建筑行业，那么产品经理就是设计院。如果设计院输出的图纸不能由施工方实施，设计院将承担巨大的责任。在互联网时代，软件就像建筑一样无处不在。软件给人一种容易修改的错觉。产品经理随意调整需求，被质疑感觉很无辜。不就是改代码的问题吗？为什么这么难说，这人一定是技术不行。简单的软件确实容易修改，在农村盖个棚屋也是，但不包括复杂的软件和摩天大楼。由于复杂的软件承载着大量的商业模式和各种现有的用户数据，修改运行软件的工作量往往比预期的要大得多，同时还要考虑发布软件的兼容性。需求变更应该是一件严肃而谨慎的事情，这是原则。Advance《一本小小的红色写作书》是我最喜欢的写作入门书。作者BrandonRoyle为初学者提供了一条写作建议：当你想到一个绝妙的话题时，写下来发表并等待人们赞美它，还不如先放下它。当一个好主意冒出来时，人们往往会把所有的优点都寄托在这个想法上，而看不出有什么不合理之处。其实，人的冷静是需要时间的。产品经理经常会想出一些“奇葩”的点子，自己奇葩“上位”。其实在登陆的时候，会遇到各种各样的问题。提前准备需求非常重要。提前三到五周设计的需求，随着时间的推移，实际上每周都可以优化。软件工程师应该建议产品经理提前准备需求。如果要求在2-3天内，他们需要保持警惕。尽管网络时代瞬息万变，但没有理由恐慌。刚接触系统的人可能对“系统”这个词有些吃惊。我们明明只是做了一个软件，网站或者小程序，为什么叫系统。我们称这些软件系统是因为现代软件不像独立的桌面软件，它们有很多组件。由Web、APP、管理后台、开放API、定时任务等多个组件组成。系统性，它带来的是一根毛发牵一发而动全身。有一次产品经理提出要收集用户的公司信息，于是在注册表中增加了一个字段，但是在管理后台创建用户时，并没有对应的字段，造成数据混乱。产品经理提出Web端需求时，参考检查项：对应的后台是否有对应的管理功能？其他APP、小程序等终端是否有类似要求？暴露的API是否受到影响？是否需要迁移现有数据？会不会和其他功能冲突，造成逻辑上的矛盾？产品经理或BA需要知道系统当前的运行状态。一个把软件系统当成黑盒子的产品经理是无法提出严格要求的，只能以创新为借口。使用遵循约定俗成、不遵循行业运营惯例的软件是非常不爽的。索尼无反相机的软件操作方法比主流相机更奇怪。即使很多人认可它的拍摄性能，也不愿意为它买单。不符合行业运作惯例而被称为创新的创新需求往往会导致来回变动。按照惯例，信息系统的列表页都会有分页、搜索、过滤、排序等组件。如果列表页没有分页设计，在可预见的情况下性能会很差。对于表单组件，每个组件元素背后都有一个交互逻辑。刻意改变用途，不仅不能带来创意效果，反而会让用户产生混淆。表单有四个基本元素，缺少说明需求不合理，需要调整：标签表单字段提示信息操作按钮另外，表单设计还需要考虑数据回填视图，可能有此视图中的不同交互和UI。一致性要求一致性反映了软件是否专业，影响用户的主观感受。一致性有几个维度：组件在操作逻辑上的一致性UI的一致性文案的一致性同一种交互使用同一个组件，避免多个组件。例如上传文件的逻辑、文件大小、交互方式、允许的文件类型等都应该保持一致。在之前的一个产品中，领导要求将UI设计稿还原到接近100%，我们通过在浏览器中叠加设计稿来实现。但设计师中途离职，新设计师无法保持与原设计师完全相同的设计尺寸和颜色。这种情况继续坚持100%还原，结果就是前端代码中所有页面都有自己的样式文件，组件很难复用。大团队往往有自己的设计规范、设计体系等，这也降低了高保真度的输出。使用设计系统不需要输出高保真。开发者可以在设计系统中使用原型+组件，打造出统一美观的软件界面。用原型图表达整个系统的交互逻辑，不考虑UI细节，UI细节留给设计系统去完成。文案的一致性要求系统的所有部分都使用相同的名词概念和表达方式，以免混淆用户。在针对非功能需求评审需求时，非功能需求是最容易漏掉的需求，也是需求的冰山一角。下图是一个添加文章的需求，后面是交互、性能、UI等方面的非功能需求，里面有大量描述非功能需求的文章。这里简单列举一下：(1)交互体验相关的二次提交输出格式化请求Loadingform请求用户确认和提示(2)安全相关的身份验证和权限表单验证(3)性能相关的响应时间和有效时间(例如，允许重新登录生效相关的权限）（4）可用性相关的兼容性、专用设备适用性、本地化和国际化升级策略成本效益最后一项是成本效益。有一些要求不适合当前的软件模型并且更改起来非常昂贵。但是，如果产品经理根据当前的技术模型和架构进行一些取舍和调整，则可以保持当前技术模型的一致性，降低开发成本。比如将用户的会员信息保存在Session中，这样就可以非常高效的完成每次请求的权限检查。但是，代价是用户的会员资格到期后，需要重新登录才能生效。大多数系统都会处理这个问题，因为成员资格到期是一个频率极低的事件。如果产品经理要求，会及时通知用户会员到期，重新登录时不会触发该行为，而是续订。即使技术上可行，但成本很高，这样的要求在评审时应该提出质疑。
