记一次WMS的系统改造（3）— 行进中的复盘

行进中的波折

革新总会面对一些阻力和风险，一种新的观念、一种新的模式要来替代既有的产品，从来都不是一件简单的事，在WMS改造这件事上我们一开始就提出两种概念货物驱动和任务驱动，并找到一个标杆产品Slack就是为了建立心理上的信任感，并从侧面证明这件事不是一件纯新的模式，提供成功案例来降低阻力，但在实际落地的时候还是没有多么顺利。

惯性的强大力量

有时候大家不支持和反对，并不是真的不支持和反对，而是因为习惯某一种模式和状态，而恰恰新的设计和他熟悉的不同。
习惯就意味着第一时间出现在脑中的就是那个样子，所以很难想象出还有其他的可能性，也没有办法接受其他的可能性，这也就是所谓的想象力比较匮乏吧。
在做这一版WMS的过程中，首先出现的问题是，产品经理的设计拉不齐。说完设计的方向和原则后，大家一块做了一个功能的设计用于对齐设计理念，然分别去做了不同功能的设计，在阶段汇总时立即就发现，绝大多数人的设计都没有做到明显的体验改善。
当时发现这种情况后，大家坐在一起一页一页的复盘每个功能每个点的。里面其实包含了几种情况

• 思路上不自觉的、很自然的就转回原来的设计思路上
• 碰见设计样板中没有提供，不能照抄的功能点，不自觉的用原来的模式进行设计，不能领会新的设计的风格要点
• 遇到苦难的流程，自动切换原来的模式
• 设计的负责人，面对现实的各种细节困境并不能坚定的执行设计思路
  面对这样的情况，其实我们采用了两种办法
• 一遍又一遍的高频开设计评审会，让大家高频的对齐设计
• 打破成本的幻想，绝不接受已经设计成这样了、已经做了这么多了、时间太紧了等理由，不合理的设计必须重新设计

三版设计之后（大致1周多的时间），再看总体的设计就很有眼前一亮的感觉了。不过没想到的是最后给UED人员时还有一次反复，因为他们不理解生产类的软件系统的设计要点，包含的特别放大的部分和特别明确的分区，经过UED人员后反而都弱化了，所以在效果图出来后还要做一轮调整。

除了UI设计的问题，还有业务架构设计的问题。

传统业务系统的三个问题

UI设计进行中的同时我们又复盘了一遍即有系统的所有菜单，结果从中发现了一个具体的问题。
纵观整个WMS，由三个部分功能组成：

• 业务主流程
• 操作容错/运营容错
• 系统容错
  业务主流程，为仓储而设计的主要业务操作节点，业务主流程一般由关键节点和附属节点组成，比如仓储里面有个关键的业务节点叫做“上架”，附属的节点就可能有很多，比如储位推荐、路径推荐、任务分配等等
  操作容错/运营容错，生产辅助的软件是一个强人员属性的软件，软件的基础功能就是指导和记录人员的生产动作。不管操作员如何仔细，人员操作在一个比较长的时间范围和比较多的人数范围内，错误都是不可避免的，操作错误需要由系统来提供补救的功能。
  系统容错，WMS往往使用环境的条件都不会太好，远离IDC，远离闹市，网络条件很差；服务器和终端的硬件条件往往也很差；而且软件开发本身也不能完全避免BUG的产生；但是因为生产辅助软件的特殊性，每一个软硬件、网络环境等等不可预知因素产生的异常，都会影响到具体的货物，所以一般也会提供一些（或很多）业务工具来进行异常后的生产流畅，确保货物生产不会因为软件原因而无法进行。
  即有的系统中，这三部分是混合在一起的，这属于顶层设计问题，新的设计中最开始只考虑了单功能或功能流的使用体验优化，现在就要将重构顶层设计考虑进来了。
  业务主流程是正常的系统节点，系统应该围绕着这部分功能，将附属的节点巧妙的融合进去，然后把绝大部分操作容错和系统容错用技术手段处理掉，确实需要人工参与的，需要很慎重的设计一个异常流程，且不能散列放置要让它与正常流程形成闭环。
  最终我们设计的方案是
• 运营容错，因为涉及一个系统的动与静的问题，所以要单独拎出来，做一个新的技术方案处理。
  ::（系统的动与静会单写一篇）
• 系统容错，尽量让系统自主处理，如非阻塞不设计人工干预流程。

顶层设计的重要性

开始仅仅是想改善一下仓储人员的使用体验，从UI的优化开始一直推导到设计的规范，再发现运营容错的技术方案系统的动与静，还有系统容错软件自动化处理（可能会从此开端WMS的智能化）。
这里我们有一个体悟，一个软件的顶层设计是极其重要的，点线面从来也不是单独存在。后续我想我们部门每个软件都会有一个业务架构师，这么一个人对整个软件的研发太过重要了，他可能不是专职的但岗位职责一定要明确。
下一篇离题一下，写我们在另一套软件上面的优化成果
『2018年12月24日 广州白云』