产品设计核心流程：
刚过的新春，宠游客的重庆封闭了道路只为游客有更好的视野，再现了人山人海。那自驾游的大家，在停车的时候，遇到了一些啥情况呢？
你知道哪里有停车场不？
那个停车场可以停多少车？还有没有车位呢？
1.5元还是2元一个小时？
这是最常见的询问方式了吧？只不过当前，导航系统都可以导航出来，就不再使用询问的方式了。但是，导航搜索出来的停车场依旧没有剩余车位和计价方式。嘿嘿，各位地图导航的产品们，这就是需求哟 [偷笑]
这里司机师傅最关心的就是：哪里有停车场？停车场还有多少车位？停车费怎么计算？
既然都是智慧车行了，这些当然都需要提供。产品设计最核心当然是完善整个业务场景。
生活中一个小的问题，通过互联网的方式来解决，就需要产品经理来转化，将问题和解决方案融合起来。但问题只是整个解决方案的冰山一角，要解决方案能够完整运行，就需要将整个业务的全貌找出来。停车场本身的信息，在这个问题里是没有体现出来的，那么怎么做，才能完整整个业务流程呢？
梳理完整解决方案参与的角色及其所需要的功能（用例图），然后串联着整个业务流程（业务流程图），将相关的所有因素串联完整。
智慧车行用例图
司机知道哪里有停车场，停车费可接受，也能够停进去之后，就会进行停车，然后去处理自己的事项。辅助这个决策，就需要知道 停车场位置、收费标准、是否有停车位。
随着当下车牌识别技术的成熟，很多车库已经无人值守。这就是信息化的便捷、效率。做以上的业务分析，本身在停车开车的场景下是闭环的。但在现实中是不够的，很多停车场是小区的，是园区的，是公司的，那就需要更为完善的支持，提供停车月卡、年卡服务。
另外，若是小区物业的车或公司领导的车，是需要有特殊权限的，需要进行额外管理。
智慧车行业务流程图
整个停车场管理业务最小闭环业务流程包含：停车场管理流程、停车流程、开车离开流程。
停车场管理流程主要是维护好停车场基础信息，如位置、停车位数量等；并设置好收费标准，为后续的费用管理奠定基础。
司机开始停车，遇见门卫管理。门卫确认扫描信息，然后开门允许停车。是停车的流程。
司机办完事情，开车离开。在车库门口扫描，系统计费，然后缴费；经门卫确认后开门，开车离开。是开车离开的流程。
在真实的系统设计中，需要完善月卡办理后的流程、以及设置白名单的流程，也就是离开扫描时，需要判断资费类型，然后确定结算的处理方式。系统内部设计会复杂很多，但业务流程实际上就是这样。厘清业务，对于系统设计，至关重要。
在停车业务场景中，业务流程相对比较简单，比较清晰，也没有太多状态、操作需要管理。但在扩展的月卡管理上，就有较多的状态操作需要管理。
通俗一些来说，月卡常出现的场景包含：办卡、缴费、欠费、停用；而涉及系统的管理，就需要增删改查等操作。如此，就包含了5个主要操作，也就包含了5个状态。使得整体业务复杂度增加。在不同的月卡状态，可以做哪些操作，就变得比较复杂和不好记忆。在页面交互上，会在不能操作的情况进行对应按钮的置灰或者隐藏，但如何在设计时候更明确的表达并向下宣贯，这个就很重要了。
设计下面的操作状态图，是不是就很明晰了。
月卡操作状态图：
月卡状态在不同的操作下，进行了状态的修改，实现了月卡数据流转的核心流程，实现系统构建的完善。
月卡不同状态有哪些操作：
月卡在不同状态下有哪些操作，一是反向检查流程是否有遗漏，二是明确的告诉下游开发、测试各个状态下有哪些操作。相比于口述或者文档表达，这里清晰明确。
在一开始的设计中，月卡操作状态图中的黄色连线，实际上是遗漏了的。
对应状态可以进行的操作，有个简便的处理方法：将所有的操作都放置到状态下，然后把这个状态下不可执行的操作删除掉，最后统一整理即可。
信息实体字段梳理
基于整个业务场景的分析，主要实现4个信息实体的管理：停车场管理（含车位管理）、月卡管理、白名单管理、出入记录。其中，停车场管理、月卡管理、白名单管理为管理事项，而出入记录才是使用最频繁的模块。
出入记录
在临停车辆出的时候，需要计算费用。系统可以通过出入记录的费用计算和最终缴费经费作比对，以便对于门卫进行经济方面的核查。
停车场管理
停车场和停车位是绑定的基础信息，一次性维护。一般只会在停车场进行改造或者维修的时候进行调整。
月卡管理
月卡管理主要明确哪些车辆是通过月卡通过门禁的。这里需要注意是，开门时，若月卡已经欠费需要按照临停规则处理，程序实现时需要做异常流程兼容。
白名单管理
白名单管理主要明确哪些车辆可以特殊权限通过。这里需要对有此权限的人员在业务中加以管理，谨防以权谋私。当然，这些情况都可以通过数据汇总统计的方式来进行监控。由数据来监察业务执行情况。
经历以上五个部分的逐步完善，整体需求就很明晰。在本身的设计逻辑上，不会存在巨大的漏洞，并通过整个过程的反复检查，逐渐细致到每一个需求功能点。但，可能还是存在漏的可能！
如，第五步所示，出入记录就缺少“费用”字段，这是在设计之初遗漏掉的，但在详细设计时，发现并得以补充的。也就有了当前这一步，数据追踪。
在系统实现中，所有的字段都是有意义的，需要明确字段在哪些场景会用到，最终在哪些场景消失。选用几个字段，在每个场景中再去检核一次，就会发现最后的遗漏。甚至于能发现业务不合理的地方，从而优化业务。
1，在停车位管理中，增加了“是否私家车位”，当前业务并没有串联该字段，也就是系统还需要继续完善，或者在设计中去掉该字段；
业务中可能存在，私家车位就相当于白名单的情况，那就是创建车位时，选择是 私家车位，就同时创建一条白名单；也有可能，办理月卡就绑定车位，那就是月卡创建时，选择车位就好。这就需要依据业务的具体情况来定。
但，即使因为这个变动要修改，系统变化始终可控的，并不会影响产品主框架。
2，钱是串联整个业务的，那么，就用“费用”这个字段来检核整个流程。
缴费发生在2个场景，一是临停车扫描出停车场的时候（这里检核出入记录少字段的情况），二是月卡缴费的时候。线下业务每月需要做账，那么线上，就可以出具临停车缴费记录、月卡缴费记录，并做相应的统计。可以和线下费用做核对，也可以依据该表单进行后续的数据分析，如：停车位的使用情况、月卡占比，以及同比环比的比较，从而挖掘出来，是否可以扩展一些停车业务。
数据追踪的字段选择，不必要太多个，也不一定非得专门挑选。这里主要是用字段这个角度，再次来检核一遍整体的设计，完成设计本身的自闭环。
智慧车行的整体设计还并没有完成，需要完成PRD文档的撰写，方便信息的传递和存档，用于产品成长的追根溯源。
以上，在产品设计环节，并不一定需要每个环节都按部就班，随着经验的丰富、逻辑能力的完善，产品在接触到这个业务的时候，就已经有了产品的大框架。这也是产品本身的提升和增效。终归来讲，业务流程的梳理，始终是非常必要的。
为何经历产品经理这么严谨的思考，经过开发、测试反复验证，仍有产品在上线后不符合使用者的预期，需要不断的迭代。就是在于业务的分析不彻底，整体的流程未和现实业务相匹配。当然，本身也存在，线下业务因为种种复杂原因，需要进行特殊调控的情况。
保持开放的心态，尽可能的保证产品大框架的稳定性，终归产品会在版本迭代中升华，面世中有那么多优秀产品就是明证。
当然，本期题为“智慧车行”，这里智慧体现远远不够，或许，大家可以加一些柴火，烧的更旺。等你们哟~
本文由 @壹叁零壹 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
关注微信
