最近部门在做一个关于订火车票的需求，针对这个需求在讨论需求的过程中的出现的一些问题，笔者有一些简单的思考。
需求目标：开发一个预订火车票的功能，支持系统默认分配座位以及用户手动选座。
开发现状：
- 开发时间短，需要大约2周的时间完成获取站点区间列车信息，获取所选列车信息，选座，回传信息给供应商，向供应商预订车票等功能。
- 开发人员不足，世纪后端开发人员只有四个人。
- 需求不明确。整个需求从最开始提出，到现在敲定，用了大约两周的时间。第一次需求评审就暴露了许多问题，加上老板不认可，直接推倒重来。从第二版需求提出初稿到最终敲定，又用了大约一周多的时间。浪费很多时间。
- 场景复杂。复杂场景主要集中在选座的功能。下面具体介绍这个功能。
在介绍选座功能之前，先讲一下几个目前的现状，都是属于短期无法做的变动：
- 我们的系统创建订单是在，用户完成支付之后。也就是在选择座位，去供应商锁定座位的时候我们的系统还没有订单。也就是说用户可以频繁操作选座去锁定座位。
- 供应商支持我们在选座之前获取列车所有座位信息。但是为了缓解他们自身压力，只允许单一用户短时间内获取列车信息不超过4次。
- 供应商支持的选座过程必须走特定流程：比如两个人乘车，首先查询可用座位，然后调用供应商接口默认锁定两个座位，然后用户只能通过修改非默认锁定的座位来进行新座位的选择。不允许用户直接在查询可用座位后直接选择座位。
- 如果重新选择座位必须首先调用查询所有座位信息然后再走选座流程。
- 如果供应商发现对接他们的服务商存在存在频繁锁座不下单，频繁查询不下单，他们会降低服务商的评级，必要时候block。
面临的问题：
供应商的系统在我们用户修改座位之前，他们的系统首先会默认分配两个座位，之后用户在前端界面手动选择完成后。然后我们再去供应商那边去更改实际的座位信息。而这个更改座位信息的过程，有可能因为这两个座位已经被其他用户锁定而导致当前用户去供应商那边锁定手动选择的座位失败。
按照之前产品的期望，如果我们去锁定座位失败，但是这趟列车还有可用座位存在，我们就允许用户重新选择新的座位。而重新选择新的座位，又需要我们重新向供应商请求一次可用的座位列表，这样就会再次锁定两个默认座位，甚至可能因为恶意用户的存在导致频繁锁座。那么如果在如春运之列的订票量比较大的时间段，很容易发生多次选座冲突导致达到查询座位次数上线无法成功购票的情况，同时也会造成我们在供应商处评级降低。这样次数多的话，就会导致供应商对我们进行限流处理。
以上这些问题的出现，导致我们PM、QA、BE和FE十几人来来回回讨论了四五次，每次要讨论一个多小时，这样其实造成了时间上的浪费。
走到目前这个状况，我们必须要思考一下，问题究竟出在哪里，如何高效的解决问题？避免在这上面花费更多的讨论时间，导致最终开发时间大大降低，无法按时保质交付。
我们现在所处的环境就是面对当前我们的开发压力较大，开发周期短，同时这个需求较为复杂。
首先回到我们的最根本的出发点，我们这个作为一期的一个火车票预订的产品，它希望实现的功能最基本的功能是什么？我们要站在用户的角度来看，我真正的需求就是能够订到火车票，你的是系统如果给我提供一个自主选座的功能，我当然非常开心，但是如果我频繁去请求选座，却总是选不到座位，最终导致我无法正常的买到车票，那我会受到很大的伤害，我对你这个新推出的功能就不再信任，以后也不会用你的产品了。这样最开始使用我们的产品去购买车车票的这些种子用户就会大量的流失。
从技术角度来看，自动选座失败有两个原因：一方面因为很多人可能同时订票，另一方面如果我们多次向供应商调用，这中间出错的概率也就会更大。因为这个功能的增加，最后可能因为这些功能的增加，导致在一期过程中无法让用户买到车票。根据奥卡姆剃刀原理，我们都应该在一期砍掉这个功能。它应该作为重要但不紧急的需求。可以放到我们二期或者三期后面进行详细规划，讨论出来一种更好的解决方案，然后再来具体实行。这样既可以能保证一期的按时交付，避免参加大量无效的会议浪费时间，同时也可能最大程度的保满足用户最根本的订票需求，留存种子用户。
但是作为产品的期望，因为成熟的竞品已经具有自主选座功能。如果我们直接砍掉这个功能可能和竞品对比还是处于劣势的，那么如何修正这个方案呢？
经过大家的沟通，最终我们敲定的方案是，在我们进行自主选座的时候，在前端展示一个提示，就是用户自主选座有可能失败，失败的话我们会直接会默认给用户分配座位，让用户有一个心理预期，避免直接给他们分配默认座位造成心理落差。我们也就直接走入一个简单的流程，用户首先提交他的期望的座位，我们去向供应商请求锁定座位，在锁定完成之后，发起修改座位的请求。如果修改成功，但我们就就直接将修改后的座位返回给用户，如果修改失败，我们就将系统默认的座位返回给用户。这样既可能最大程度的保证用户能够获得自己想要的座位，又可以保证用户肯定能取到车票。开发的工作量也不会有很大的增加。
我觉得这就很好的解决了当前我们所处的这个困境，节约时间，又最大程度的满足的用户需求，也能保证一期按时交付。
所以这个给我的启示就是，首先我们在确定需求的时候，产品必须要对整个流程充分的熟悉，知道哪一部分工作可能会造成比较大的延误，然后尽快敲定一个初步的、较为可行的合理的解决方案，然后大家再来讨论，避免无效的会议。另一方面，我们必须要始终反思我们做的这个需求的最根本的目的是什么，必须要在保证最根本的前提下，然后再来讨论更好的需求。我们的最根本目的是解决用户的痛点，然后再增加自己的亮点，如果痛点都无法解决，那么为了增加亮点而导致自己产品延期，这种做法是得不偿失的。
最后，真的觉得12306是一个挺牛逼的系统。
