之前有一篇文章专门写产品的三板斧，分别是准确判断出来该做什么，推动事情落地，让产品能用和好用。今天来看，更加认同这个说法，但这些只是产品层面看得见的能力，还有很多看不见的能力，尤其是在阿里这样的环境下。
产品经理不仅需要判断出来该做什么，还要能够说的明白，让业务方/技术能够认同你，才会在后面推动时更加顺畅。
为什么要说大道至简，是因为最近两个月都在打磨一些方案，其实看着很低效，但回过头看中间又有很多细节是被补充进来的，方案也更加丰满了，但从需求来说，却很容易说清楚，就像需求清单一样，让商家和用户一眼就能看出来你做了什么或想做什么。
而至于怎么实现这个功能，就需要产品经理结合系统现状逻辑，结合用户体验，结合合理的流程，不断地打磨/思考更多细节，然后补充方案，其实这个过程让我很享受。
举两个例子：
1、最近反思思考的库存调配流程
为什么纠结 呢？是因为库存调配是涉及两个不同的运营主体，按照最完整的流程，应该是调入方发起申请，调出方确认申请，就可以完成库存调整。但为什么不这么设计呢，有两个考虑点，一是两个运营主体一定会在单据发起前做线下沟通，二是存在两个运营主体同一个团队管理的场景，这种设计会让用户觉得复杂难用。但如果简化流程为取消线上确认呢，那又会涉及到调入方创建单据还是调出方创建单据，如果调入方创建单据可以直接调整另一个运营主体的库存，如果线下沟通到位，就会出现库存异常。而如果按下图所示，由调出方申请虽然不会有库存莫名其妙减少的问题，但呆滞库存也可以被突然调给其他运营主体。
那到底该怎么平衡这个方案呢，后来跟同事一起商讨了这种方案。即如果创建单据的账号同时拥有调入和调出两个主体的权限，就不需要线上确认操作，而如果只拥有一方的权限，则由调入方创建单据，调出方线上确认后生效。
库存调配单流程
2、公告设计
本以为公告是一个比较简单的功能，只需要把功能编辑好放到系统中就可以了，但跟同事仔细对焦后发现有很多业务逻辑存在，都是需要一个个对焦的。
仅考虑支持公告管理和商家端交互，涉及场景和逻辑如下：
~ 公告需要进行归类，不同类别的公告有不同的交互要求；
~ 某些公告需要在用户登录系统时强制弹窗，必须点击已读后才能操作系统；
~ 公告发送需要支持全量商家或指定商家清单或根据众多条件筛选商家的功能，且还要能够指定到商家某些角色的账号发送；
~ 如果商家一段时间未登录系统，存在多条强制弹窗信息，该怎么处理？
~ 公告需要具备下线功能，便于错误的公告及时撤回
~ 公告设计考虑的四个层级：首页弹窗->首页公告标题->公告列表->公告详情，每一层扮演角色不一样，但相互有关联，存在比较复杂的交互设计逻辑。
我现在理解的“大道至简”，更多是从商家角度出发，即能够很简单地说清楚用什么功能解决了商家什么问题，哪怕一个很复杂逻辑的项目也能说的明明白白，而另一层则是即使产品方案和逻辑特别复杂，也一定要让用户感觉到“简单”。这才是优秀的产品经理应该达到的水准，“大道至简”，我希望每个人都能做到。
网友评论