对不起,这个评审会我没听懂

对不起,这个评审会我没听懂

———— / BEGIN / ————

产品工作中除了日常我们做前端需求之外,最为复杂的就是在所属行业或者产品架构的搭建上建立从0-1的系统流程和业务逻辑。

这两点我们在工作中熟悉自身产品外还要不断的的体验同类产品,并且还需要将一点一点分散的逻辑和业务模块集合在自己的头脑中。

因为在头脑里,我们总是零零碎碎的将业务片段和逻辑最终统一为一个合理的流程方案。

那么,你的产品方案出来了,如何让别人能够get到你的点呢?

让自己快速头脑过一遍

我们面对业务的梳理和逻辑的流程梳理需要遇到的几个问题

  • 当前的业务或流程是怎么样?

  • 现在的体系带来问题是什么?

  • 业务或流程的新版本改变优先级是什么?

  • 当前的业务或流程可以很快的通过产品的体验进行梳理,比如登陆账户体系或订单体系以及产品服务体验流程。找到测试同学或开发同学,为你开一个测试账号即可体验完整的过程。

    往往我们在做复杂的业务流程期间,都是处于重构或者在0-1搭建。在这两个节点,考虑产品设计的侧重点是不同的。

    一个是如果在改动小的情况去落地,另一个则是在从0到1搭建的情况下去落地。

    在我们体验和走过整个产品的业务或逻辑流程之后,常用的几个方法是让你把头脑中的星星点点快速体现在工作展现上,下面这个步骤是我常用的方法之一。

    找到竞品、脑图绘制节点、uml或流程图制作、excel列表梳理

    对不起,这个评审会我没听懂

    思维逻辑落地方式

    绝对不要一开始就axure,一开始就来页面的落地。

    业务流程和逻辑最为复杂的就是将脑子的流程具体的体现在纸上、体现在评审中展现出来的内容。

    一个流程有开头和难点:

    开头,是评审中最浅显易懂的开始

    我首先看下如果你已经在评审前准备了一张流程图如下,涵盖了用户、用户行为、用户触发目标对象、条件判断,但是整个流程的绘制表现,我们却找不到它的头在哪里?

    对不起,这个评审会我没听懂

    以上的这个流程图案例,是我们做业务逻辑绘制的基本现状;可能作为产品工作的你,更可能使用脑图或其他表达方式;但万变不离其宗,业务流程和逻辑的复杂性导致整个页面没有任何图片或没办法以视频的方式来演示,你需要将整个流程以下几个角色来为整个流程进行表述。

    对不起,这个评审会我没听懂

    好,现在我们整个评审开始了。

    我们需要找到一个好的开头,这里的开头最简单的方法就是从业务流程的开始。

    从0-1还是重构,都需要将本次评审中的重点改变和改变的体系或流程是否有问题交给大家去讨论。

    评审效率的关键就是在于该需求或评审的内容是否有大家积极讨论,有没有任何疑问,或者对于某一个点大家是一直处于讨论,还是没人对评审中出现的疑问点有好的解决办法提出。

    这都不是一个高效率的评审会。

    5分钟原则

    当一个需求在评审中,出现一个讨论点大家五分钟都没讨论出解决办法,那么直接过,下次评审再进行。

    往往一个好的0-1产品迭代流程,都是2周一个迭代,也就是需求在第一周进行评审通过,第二周就开始做,第三周接着准备新的需求——如此反复反复。

    当初要除开那些已经迭代n个版本的产品,这种稳定的产品,迭代的时间是根据业务的需求或公司的战略变化进行更改。

    比如一个订单系统的业务流程,我们评审中最为简单的讲解就是通过用户的行为操作为我们表述的逻辑顺序。

    这样能够让开发或参与评审的同学能够顺利的进入到该场景以及想一下该场景是否有你的设计中遗漏的部分或有问题的部分。

    对不起,这个评审会我没听懂

    在订单的行为流程中,我们可以将我们表达的逻辑按照顺序进行流程图绘制,并且以更好理解的图文方式,将复杂的流程图变为一个只有关键流程、评审中需要讨论的重点流程、以及本次0-1搭建的重点或重构的部分进行展现。

    这样的话,整个表述过程就不会说没有重点。

    另外,对于长与复杂的业务流程,我们往往在投影仪投影后的流程图是这样的:

    对不起,这个评审会我没听懂

    投影范围不能展现清楚的全屏流程

    在这样的情况下,我们更应该提前把需求同步在共享文件中可以提前让参与评审的同学中了解或在评审会后再进行同步。确保每一个问题或整个流程,参与评审的同学能知道。

    业务的流程确定后,再是我们页面和模块的产品设计。这里的设计就会按照讨论的流程进行落地。

    既然流程很长,那就直接说重点

    有时候,我们在落地产品中会碰到涉及到整个产品的业务流程,它并不是一个模块的流程而是会走过所有的a\b\c模块,因此在这样的情况下,我们从0-1搭建的难度或重构后在评审的展示,需要直接说重点:

  • 以前有什么问题(我为什么要改、要这样设计?)

  • 现在是什么样的流程?

  • 重点的流程节点

  • 既然我们不能将大家带入自己的抽象方案的设计里,那么直接说重点即可。

    在重点的沟通中,缺少的信息或对于该业务不熟悉的同事会直接提出疑问,产品同学再去解答,将脑海里的方案一点一点的分类出来,去解答来自开发同学不同角度对与重点流程的疑问。

    对不起,这个评审会我没听懂

    长又复杂的业务流程

    流程的复杂帮助你更好的落地产品

    很多产品在工作中,会担心自己的模块是否因为下一个迭代被干掉或者被弱化。其原因无非就是带来的KPI不好,或者公司的战略方向调整。

    因此,当你涉及一个0-1搭建的流程或重构某个流程逻辑,虽然过程是痛苦、反复的,但是你的全局产品观和产品业务的了解是最彻底的。

    就拿淘宝京东这样的产品线,如果你是涉及订单系统的业务部门同学,那么整个电商的模块和后台以及数据平台都会经过的你流程思考。

  • 什么字段要?

  • 有什么地方的数据重复?

  • 某个前端的模块是否有后台?

  • 运营或数据平台是否能够提供完整的数据监测?

  • 简单来说:越是大、复杂的产品设计,越是自己提升与核心竞争能力体现。

    ———— / END / ————

    对不起,这个评审会我没听懂


    点击“阅读原文”下载APP