如果一直沿有固有的通用的流程，那么就谈不上创新了，脚步应该一直向前走…
做不的需求，改不完的Bug，每天都处于极其高压的工作状态中，这就是产品技术的日常生活。需求讨论、任务分配、系统设计、测试、联调、上线等和每个人都有关系，虽然有时项目很简单，但更多的是焦虑、紧急。
产品与研发互怼、研发与测试互掐，这些不可调和的矛盾似乎始终存在，不想去过多的评论，因为没有谁真的是错的。回顾下多年的工作与项目，不禁有些黯然，感觉有些需求分析与设计都是为了完成而完成，很少有系统性的、合理性的考虑。
本篇就以一个简单的盘点需求来与各位分享下近期的总结。
案例描述
公司有线上商城线下门店，一直采用线下线下融合的方式促进销售，线下门店从总部进货，总部门店运营也可以铺货给门店，目前门店有自己的一套进销存系统，总部有ERP系统，门店进货或总部铺货时都需要掌握每个门店的商品准确库存，要求门店每天（定期）进行盘点，对于盘盈、盘亏要及时申报处理。
门店店长希望每天的数据都要保存完成，可以查询到历史库存及盘点记录，总部更关注的是门店盘亏、盘盈的原因。
大家在接到这个需求会如何考虑，如何实现呢？
常规流程
1，产品会根据业务需求进行调研，然后输出一份PRD文档，有需求场景，目标，相关系统的具体功能。
2，接着研发与产品共同讨论，主要是针对功能性需求进行探讨，针对具体的字段、功能界面做进一步的确认，对于有异议的或功能上比较麻烦的操作步骤会各抒己见，最终会有一种平衡的方式。
3，研发进行任务分配，负责门店进销存的与总部ERP的可能是不同的开发组，这时两组根据PRD进行任务拆分，各回各组，去分析设计。
4，研发组进行接口需求进行沟通，根据功能界面讨论出每个接口提供方和调用方，确定后双方排期去实现。
5，后续在编码过程中有新的想法或问题，与产品、其它研发组进行进一步的讨论，确定解决方案，继续编码，循环往复。最后按开发计划进行接口联调，测试(测试用例由测试组进行)。当然编码时涉及程序代码和数据库脚本，所以此阶段是涉及研发组各个职能部门的协作。
6，研发编码时，技术负责人会进行服务器资源、网络资源等申请，同时准备上线安排；最后按计划发布到生产，需求完成。
这是常见的流程步骤，整个需求过程也一直实行设计-评审，快速迭代的方式，项目分期实现，尽快提供给业务方可操作的软件，上线后有问题也会积极配合业务进行调整尽可能满足业务要求，最后项目进行复盘总结。
如何改进
相信很多人都在积极寻求一种好的方式去提高研发效率的同时，也能够使自己和团队成员有所提升，从而晋升、加薪。
我们一直推崇项目责任制，在项目中尝试推行敏捷的项目管理方法，定期组例会和月度总结会，与产品、研发相关组负责人制定标准的流程，规划代码规范、产品流程、研发流程、数据规范…
有了这些就真的会好吗？其实未必。流程、规范是规矩，能保证不出格或不出错，但不能保证质量、效率，所以重要的还是在各个阶段过用什么样的方法，技巧，使复杂问题简单化，有输入、有输出、有结果、有绩效。
下面针对“门店盘点需求”从开始到最后进行下梳理。
一、需求阶段，在此阶段依然采用5W2H的模式，先来确定为什么做，做什么，谁来做，如何做，需要资源等。
此阶段主要考虑的是业务需求即业务部门想要什么，目标是什么等，往往忽略了用户需求与开发需求，注意「业务需求!=用户需求」，这是要改进的部分。
用户需求是针对业务需求中涉及的不同场景，不同的操作者的相关需求，如在盘点这个需求中，门店提出要数据及时、准确，要有盘盈、盘亏的操作，输入正确的盘点结果等等。但门店中有店长和普通店员两类用户，实际盘点功能的使用者是普通店员，店长可能只会进行盘点复核和盘盈亏原因的确认。这两类用户的需求有可能不同，在复杂的项目中涉及的用户可能会更多。
业务需求与用户需求大部分属于功能性需求，一些非功能性需求要尤其关注，功能性与非功能需求组成开发需求，在系统架构设计时是要考虑的。
用户需求—业务需求—开发需求
所以在需求阶段，研发的提前介入是非常必要的，在需求讨论与设计时要从三个方面进行，即功能、质量、约束条件，这就是从「一维需求」转换为「二维需求」。
二、研发阶段，在此阶段不能为了实现而实现，需要运用架构思想去设计。
说到架构应该属于架构师的工作范畴，一些小的需求项目可能不需要架构师参与，即便参与有些公司的架构师有的也只是从技术角度来考虑问题，对业务可能并不会深入了解。
记得在上上家公司技术年度规划会议上，有同事问当时的CTO说，“为什么我们公司不单独设架构师这一岗位？”，CTO回答说，目前好的架构师不多，而且对于技术研发经理级以上人员应该作为架构师去规划系统，而不单纯的团队管理或编码。
像门店盘点这样的需求，需要进行架构设计吗？应该遵循架构设计的一些原则，这样有助于锻炼提升自己，虽然于技术我只能说是简单了解，但是这样的观点我是推崇的。
1.要将需求进行分类，并从中提取关键功能，必做功能和其他功能。
关键功能决定架构，其他功能验证架构。门店盘点中的关键功能是什么？应该是盘点及库存数据的实时同步。假如每个门店有500个SKU，而且会有一品多商，按10%估算，那么SKU数量增加到550个，同时SKU的生产日期不同会有不同的批次号，这时在库存表中数量可有会有近千个，再考虑已售再无采购计划的商品，数量会越来越大。
在需求中店长希望每次盘点都要备份前期的库存数据，如果每天都盘点，那么盘点备份表数据增长非常快。
约束条件是门店网络性能，这是用户体验的关键影响，所以在设计时要先分类，然后根据“目标-场景-决策”的方式去考虑。
2.设计时不是简单的“模块+接口”，要注重模块间关系
接到任务，理解需求，然后开始设计数据结构、定义接口、界面等，需要外部数据时就会找到相关的模块负责人提供一个接口给自己调用。
在门店盘点需求中，门店开发组与后台开发组就针对前端需要展示的数据提供了很多个接口，如查询库存的，盘点提交或查询等（说明一下，在此案例中门店开发组只负责门店盘点工具界面，数据由后台提供）。
系统是不同用户操作不同功能模块的协同作业，这就是“职责协作链”，在设计时要充分理解这部分，才能满足业务、用户需求。
站在用户的角度，不断转换角色，来模拟操作场景，结合需求去考虑如何定义接口，可能会更好，要提高代码的重用，减少频繁的接口调用，前后端研发不能脱离，对一些校验、类型转换、逻辑处理要合理分配，不能一股脑推给前端或后端。
研发与研发之前因为接口、逻辑处理究竟是谁做，互相推诿，上线后因为问题互相指责的事件也是常见的，所以要改变“模块+接口”的开发方式，要注重关系处理，培养大局观。
3.非功能需求的约束考虑
门店盘点这个需求，经过产品、研发同事的努力，如期上线了，但很快便出现了问题。
盘点时按要求备份了大量数据，导致在查询数据时后端返回结果很慢；此外对于零库存的SKU商品没有单独处理，在盘点时有大量的数据需要过滤，店长操作很麻烦；库存数据更新有时会延迟导致盘点有问题，这是前期遗留的问题；对于盘盈盘亏总部审核不及时，会影响门店操作或销售。
个人觉得出现这些问题的主要原因是对于盘点项目中非功能需求设计不足导致的。
一个系统是否好用，要从业务环境、使用环境、构建环境、技术环境几个因素考虑，如在门店盘点的使用环境上就要考虑网络的影响，要避免大数据量的查询与返回，要考虑使用缓存、分页显示，但分页在数据提交时又要考虑，这些都涉及技术实现。
性能!=效率，性能=速度+吞吐量+持续高速性，效率=CPU、硬盘、内存和网络的利用率，这是在一本讲架构的书中看到的。
非功能性需求需要考虑性能与效率，这样才会提升用户体现，否则需求做完了也上线了，但并没有得到用户的认可，这会让研发与产品有严重的挫败感。
非功能性需求主要有：「性能、安全性、持续可用性、可操作性、易用性、可测试性、可重用性、可扩展性、可维护性、可移植性等」。
在系统设计时考虑了这些，那么就会离架构师更近一步了，概要设计->详细设计在开发过程普遍要求的，无论项目大小也应该尝试从整体到概念架构，再到细化架构的一个过程，不断打磨。
三、测试上线与总结
前面两个阶段工作完成的好，那么测试就会顺利，上线也会有保障。这里不想多啰嗦了，每个项目需求完成后都要进行复盘。
复盘分为两部分：
首先，要针对从需求到编码、上线整个过程的问题进行总结、归类，为什么会有这些问题，由谁来跟进，解决的时间期，如何改进，改进后如何验证，这又是一个5W2H的分析方法。
其次，针对上线后的数据监测与分析。这里包括使用中产生的生产数据及日志等分析，如对于盘点需求则要针对盘盈、盘亏的比率进行分析，对于库存准确性进行监控，还可以出具各个门店盘点的频率对比，由此制定运营策略的改变等。
总结
本篇仍是本人对前期工作的的一个重新认识和总结，「软件需求=功能需求+质量属性+约束」，由于接触的都是软件项目，所以对于软件产品如何实现，如何能够更好服务于用户是目标，这里针对常规的流程中的每个阶段进行了一点改进，在需求阶段要用二维的方式去思考，在研发阶段要运用架构思想去设计产品，改变一些固有的工作方法或许会得到不一样的结果。
