招聘信息 要求有从需求到上线的经验，这其实就是为了规避那些不必要的影响和提高开发效率
公司没有所谓的「开发流程」，这句话很泛，有人不能理解，觉得没有流程怎么开发？ 换一个解释就通俗易懂了：
boss: 你们做一个聊天软件
开发: ……
这就是公司目前的现状，某个人提出需求，甚至都不能称之为「需求」，只是「一句话」而已，然后开发人员就开始开发…..🙋🏻
需求的形式的改变与带来的影响
在入职之初，并没有什么大的需求，只有一些小功能的优化和调整，仅需要后端提供接口，前端对接，修改一些字段而已（没有测试）。此时，因为需求量的原因，还能正常开发，并没有形成实际上的影响。
随着业务的发展，需求量越来越大，开发人员的工作量也越来越大，开发效率也越来越低。
公司并没有「产品经理」！！！（后面向公司反馈增加产品经理岗，但公司并未采纳。） 需求最初都是项目负责人以「口头形式」提出，并没有形成文档，添加什么，交互逻辑是怎样，全靠开发人员自己摸索。这种方式可以说是最原始的方式了，开发一大部份时间是用来沟通功能的，很多情况下都是开发了一部份之后，沟通，修改，再开发一部分，反反复复，效率低下。
后续，多个需求一起堆积，「口头表达」已经难以介绍需求，不用说细节了，就简单的介绍「这个功能是干什么的」都较为费劲。此阶段，项目组成员也有了变化，新增一位测试和后端，原来的后端（项目负责人）开始转变为「产品」角色，开始负责需求的整理和设计，并开始制定开发计划。但是，我觉得始终是个人能力的问题，整理出来的「需求」可以说是可有可无。
负责人初步接触 Axure ，所以输出的成果仅仅是几个方框搭配两句话，连最简单的交互逻辑都没有，我甚至觉得用手在纸上作图都比这详细。我无法理解，耗费了几天时间，最后还是没有形成文档，交互逻辑，甚至连开发计划都没有，这让我很郁闷。
在所谓的「需求评审」中，「需求」的实际提出者并没有参与会议，而负责人对需求的介绍仍然是停留在「口头」上，介绍的内容非常简单，根本没有涉及到细节，举个例子，页面上有个「删除」按钮，「什么状态下可以点击按钮」，「什么状态下显示按钮」，「按钮点击之后的操作」等等，这些都没有在所谓的 Axure 原型中体现，「口头」的讲解也没有涉及到。对于各种的交互细节，全部是开发人员提出的，另外开发完善后，负责人仍没有完善「需求」。
这会议是「需求评审」会议，但实际上，并没有起 评审 的作用，即对某个需求的合理性进行评估并做出调整，所以与其说是「需求评审」，不如说是「需求完善」。
话说回来，我难以理解为什么在几天时间里，仍然无法出具一份详细的需求文档，用普通的说法，这个需求文档其实就是「产品说明书」。文字才是重点，应详细的介绍某个按钮、某个功能的交互逻辑、功能的使用场景、当前功能与其他功能的关联性以及需求变更后对整个系统的影响等等。而这个配图，只是让人能直观知道页面上文字、按钮、图标的位置，同时给UI设计师提供设计思路而已。所以，对于负责人的输出成果我是不满意的。
需求初步确定了，按照正常的流程，后续应该是「功能设计」，进而进行评审，测试人员根据「功能设计文档」撰写测试用例…… 但实际上直接砍掉了「功能设计」环节，测试人员按照简陋的「需求」文档撰写测试用例，测试用例也只是说明了页面应当具有哪些内容和简单交互逻辑，并未涉及前端的页面交互、请求参数验证、数据交互等与后端的表建立、脚本验证、接口验证等等。
可以说，测试也并不完善，经常是主观的认为某个功能是bug，但并无依据。
另外，需求频繁变更与提出，这是公司的一个特点，，这就不得不提到一个重要的角色———— 「客服、业务人员」。很直白的说，他们的思维没有任何逻辑，在不同的时间点提出各种各样的需求，完全不明白该「需求」的业务逻辑与以前逻辑的关联性，也不明白该需求对整个系统的影响，完全没有风险评估的能力。不仅如此，经常变更需求，开发经常返工。缺乏产品思维，经常因为「方便使用」而将功能改的面目全非，甚至推翻了整个系统的逻辑。
需求的提出————毫无远见
公司是做租车业务的。电动车从厂家发货后到投放市场这一过程，需要一个大方向的管理，可以理解为「资产盘点」。
没有明确的文档体现该业务逻辑 全部是 借鉴 别人系统的，有一堆「库位」和「门店」，在它们之间随意「调拨」。这是我入职前的业务逻辑，后续他们意识到这样有问题（出现了资产的丢失），因此，需要完善这一过程（提出需求，但是没有文档）。
如上可以理解为一个大需求，很宽泛的概念。
1. 类别的取消
简单理解，这个项目是 借鉴 别人的，别人的业务范围广，拥有多种「资产类别」，如电动车、电池、维修工具、车辆配件等等，而我们只需要其中一种，因此，考虑到后续只有「电动车业务」（他们认为的），遂取消了「类别」的概念，仅保留了电动车。
这是一个比较大的变更，但同样是没有任何需求文档，变更的影响（前端交互、页面展示、后端逻辑、数据库数据）都没有考虑。
对于之前的「调拨功能」，我已经在小程序上开发了一版。所以，此次对所有相关的功能都删除「类别」相关的展示与交互，只保留「电动车」相关的功能。可以说是，写了又删。
另外，由于之前存在「类别」功能，数据库里有电动车和电池（借鉴别人的，在那个时候，还没租车业务）。离谱的是，类别不使用枚举，而使用id自增。 不仅如此，测试环境（刚开发的）中电动车的id 是 「1」，而生产环境（以前根本没有这项业务，也没开发过）中电动车的id 竟然是 「17」。 数据不一致，导致在发版时报错（前端通过判断类别做一些交互和展示）。
2. 扫码入库
这是对「资产盘点」的一个体现。厂家发货一批电动车，并给出清单，现场人员并不知道是否有足量的车辆或者编号错误的车辆，因此这一过程可以被理解为是「资产盘点」。
将清单导入系统，此时资产是「未确认」的状态。现场人员需要手动的扫描车辆的资产码进行确认
这个需求的提出，是为了解决「资产盘点」这个环节，但由于没有需求文档，导致后续的开发工作无法进行，只能在「需求评审」会议上，将需求简单介绍，并没有详细的设计，由开发人员沟通具体的实现逻辑。
3. 资产的出库
如上的扫码确认后，对应的资产为「已确认」状态，表示可以进行出库操作。「出库」，可以理解为从仓库中取出资产，挂名到某个业务人员名下。
资产出库，同样需要现场人员手动的扫描资产码进行出库（在资产导入系统时，就填写了仓库）。
同样，相关需求没有文档，全靠画几个框框加上一些文字，由开发人员自己摸索。
4. 资产的入店
其实，在他们的需求中，把这一过程称为「资产入库」，我并不认同这一名称，上一步骤就已经出库了，表示出到某个具体的仓库了，这次再说入库，显得有些奇怪。
资产入店，同样需要现场人员将已经调到仓库的资产手动的扫描入店。
同样，需求没有文档，开发人员只能自己摸索。
5. 流程梳理
其实，这是他们（业务人员）提出的概念需求，然后由负责人整理出的具体需求（但仍然没有需求文档）。
原先这个流程只有正向的，即扫码入库到门店，无法进行平调或返仓，对于其他如维修、更换的资产无法处理。后面修修补补，出库的时候不限制状态，即已经在门店的资产可以进行出库到其他仓库的操作。
起初，我们在沟通时，我提出了一个「资产盘点」的方案，如下：
应当有几个角色，拥有不同的权限。 总仓库： 运营人员的老大、有高权限的客服、有高权限的业务人员。 仓库： 仓库负责人，负责资产的入库工作和其他审核工作。 门店： 门店负责人，负责资产的调拨入店工作。
此时，没有「扫码入库」以确认资产状态的操作了，最初则由总仓库的业务人员进行操作，将厂家发来的清单导入系统。
现在来模拟一下正向的调拨流程：
-
- 资产录入
此时，总仓库并不是实际接受资产的地方，可以说只是一个概念仓库。需要提前将资产清单录入系统，给后续调拨流程提供数据支持。
-
- 资产入库
这是从总仓库调拨到具体的仓库的操作，需要由「仓库负责人」进行调拨申请，并由总仓库的业务人员进行确认。总仓库确认后，这些资产已经挂在该仓库名下，属于
待验收和已入库状态。 -
- 资产入店
资产入库后，门店负责人能看到这些资产，并可以进行入店操作。门店负责人提交申请后，由仓库负责人进行确认。仓库确认后，这些资产已经挂在该门店名下，属于
待验收和已入店状态。此时，所谓的资产还是「虚拟」物品。
-
- 资产验收
资产入店后，厂家可同步将电动车发货到该门店，门店负责人依照所入店的资产，对所有实物电动车进行扫码验收。将该门店下的资产与厂家发来的实物电动车进行对比，匹配后，将该资产的状态设置为
已验收状态。
这是正向的操作，当然，整个流程中是「单线」联系，各个仓库、各个门店之间是不能看到对方的资产信息的，即「A门店」和「B门店」之间不能进行资产的调拨，只能将资产逐层退回。
如果要将某资产平调到其他仓库或门店，则由门店负责人进行退库申请，由仓库负责人审核，仓库负责人同意后，该资产则挂在仓库名下，资产状态为 待返仓之类的状态。随后由仓库负责人将资产退回总仓库，待总仓库的业务人员进行确认。总仓库确认后，该资产状态设置为 已返仓 状态。
此时，另外的仓库管理员可以依照正向流程，进行资产调拨。注意的是，该资产在数据流中已经是返还到总仓库了，但实物是需要邮寄的，因此此时实物还处于原来的门店中，那对于该资产的某种状态应该为「保管」的意思。另外仓库从总仓调拨，一路到门店后，也应该进行验收操作，验收成果后，该状态从 保管 变为 已验收 状态。
每个资产应当有其生命周期，包括从总仓————仓库1—————门店1，或着因维修进行返仓，门店1————仓库1————总仓，再到别的门店申领这个资产，总仓————仓库2————门店2。应当由一条时间轴展示。
需求的反复————需求撤回————逻辑冗余————体现
很明显，我的方案他们并没有接受。但他们的方案存在弊端，如资产无法变更状态，如这辆车需要维修、这辆车已经停用、这辆车已经卖出，这些情况下，无法跟踪这些资产。
不仅如此，还频繁变更需求，甚至推翻之前的逻辑。
1.添加类别的概念
原先的业务是租车业务，现又提出可以租赁单电池，又提出了「类别」的概念。原先已经删除了此功能，现在又要重新添加。另外原先的下单逻辑是针对电动车的，与电动车的品牌类型相关联，现在多了单电池，导致整个下单逻辑全乱。
2.下单形式变更
原先的逻辑是从门店下单，原因是他们觉得目前的调拨流程太长（本就是他们提出的），需要到门店之后才能调拨，现在提出一个「站点」的概念，对于扫码入库的资产，可以直接入到「站点」，在站点下单。 资产的状态完全被打乱，套餐的绑定逻辑也被打乱，可以说是推翻了整个「资产盘点」与「下单」的逻辑。
3. 资产盘点方式的变更
以上的资产盘点的流程是他们（业务人员）提出的，目的是明确资产的状态和对资产进行跟踪，方便了解资产是谁操作的，便于追责。但是，如今却觉得这个流程需要手动操作，过于复杂，要求在运营管理后台可以进行资产的调拨….. (🤡🤡好无语)
4. 页面内容的变更
这属于🧠不正常了，正常情况下，后台列表仅展示重要内容，如订单列表，主要的信息是订单号、下单时间、订单金额、订单状态、操作人，而需要查看更详细的信息，应该看详情。但是现在却因为「看不全」、「不想点」、「点进去麻烦」等原因，把更多的内容在列表中展示，导致列表有 30 列。
5. 数据的处理
这其实就是历史遗留的问题，前面谈到的「类别撤销」、「电动车id不一致」等都是历史导致的数据不一致的情况，我们在处理这种情况时，一般是要兼顾历史数据和现有数据。
对于「电动车id不一致」，在一般情况下，我们不能修改或删除电动车的id，但是，这属于全新需求，生产环境根本没有电动车的任何数据，而电动车id为 17 ，则是有人在生产环境中添加后删除再添加，频繁操作导致的。所以，基于这种线上没有任何数据的情况下，我不理解为什么不能删除或修改电动车的id，此时谈论的数据溯源有什么意义。
另外，在资产导入系统时，必须填写 仓库 （模板要求），才能进行后续的扫码入库等操作。在后台系统中，可以对该条资产进行仓库变更，这是「新版」的交互流程。但是，现在生产环境中存在一批没有仓库的数据，导致了无法进行资产调拨的流程，其实问题很好解决，后台已经提供了编辑功能，业务人员可以进行仓库的维护。
这在业务上是没有任何问题的，但是，业务人员反馈数据太多，一个一个编辑太麻烦了，希望开发能够处理一下。这其实很简单，只需要业务人员提供仓库名称，然后使用脚本批量编辑就可以。然而，离谱的是，他们不满意这种做法，认为会存在错误，希望在「扫码入库」的时候手动进行🤷。
后续是，负责人的方案是在后台系统添加一个功能，可以将某个仓库设置为「默认仓库」，这样就可以在「扫码入库」的时候，直接选择默认仓库。事情还没完，负责人的这个方案已经开发完成，在交付到业务员手里时，他们说「扫码入库」时默认了仓库，这个不好，我们要能手动选择仓库…… 我的建议是让这些远离电脑，远离互联网。 他的这个需求和后台的编辑里操作有什么不同？
这就是一群毫无逻辑的人，需求乱提，前后矛盾，多此一举。
成果验收与对接
我觉得这是非常重要的，尤其是进行绩效考核的时候。原先没有所谓的评审，后面后了「需求讨论」后，没有进行排期。后续开发结束，没有标准来核对开发的成果，因此，对于xxx的成果的评估非常模糊。第一没有时间约束，第二没有量的体现。
在交接中，前后端与测试几乎混在一起，即后端开发提供了一个接口，前端立即联调。前端通过了直接交给测试，整个过程混在一起，完全独立的时间，也没有所谓的交接，还言之凿凿说这样能赶进度提高效率👇。我不知道他哪来的这个自信，首先后端提交接口，如果用本地环境测试，后端接口报错，则打断前端的开发思路。如果发布到测试环境，接口质量不行，则去需要频繁构建，服务器已经崩过很多次了，还增加了内容。
如果是没有考核，大家一起修修补补，磨洋工，还是能完成，只不过会没有明确的成果。
我觉得就是应该明确开发计划。
-
前后端需要多长时间开发，有明确的规定。
-
后端需要将开发成果交接给前端与测试。
-
规定联调时间。
-
前端将成果交接给测试。
-
测试将成果交接给相关人员，并由其进行验收。
这样，才能有明确的成果，有时间约束，有量的体现。
总结
总之，一摊烂帐，没吃过猪肉还没见过猪跑吗？ 前期没有明确的开发流程还好理解，但我们已经提出了思路，明确了「开发流程」的重要性。从 需求汇总 -> 需求评审 -> 需求排期 -> 开发 -> 对接 -> 验收 -> 交付，这一个完整的开发流程，我们都做了解释，但最终仍然没有采纳。
后面敞开天窗说亮话，反馈是，如果明确了流程和成果，那「业务人员」的重要性体现不出，也没有留下空间让老板指导🤷
