最近有小伙伴说觉得自己的工作流程比较乱，不知道怎么梳理工作流，问我有没有什么好的方法…说实话我也没有什么好的方法，因为个人的工作流程肯定是从属于组织的流程的，而某些时候我们能做的事情可能真的很有限。
最近看到一个观点，还是比较值得思考一下的，观点来源于润米咨询创始人刘润的《5分钟商学院》。
大致的观点是当我们看到不努力工作的人，会倾向于指责这个人，其实这是不对的。人的问题的本质都是组织问题，要从战略，到组织，最后才是人。说一个人不努力工作，如果他在你那里不努力工作，到其他公司如狼似虎，就是你的问题了。
上面植入的观点算是对最近所见所闻的一些事情的小小感概吧…文归正传，后来我就梳理了下自己的工作流程，把整个过程中可能需要产出的一些东西整理了一下给小伙伴了。
大家的工作流程可能都差不太多，基本上都是需求分析→竞品分析→流程设计→产品设计→UI设计→开发测试→运营迭代…
不同团队的工作流程可能有些差异，但是核心的流程估计都差不多，所以我就按照这个流程来梳理一下自己在工作中可能会产出的一些图，希望能够给大家带来一些启发或者帮助。
业务流程图顾名思义就是用来梳理业务流程的图，多为泳道图的形式，相当于一个整体的架构。可以利用横向和纵向两个维度来绘制，有的时候也可以利用颜色来表明第三个维度，下图为我之前绘制的现金贷的整体业务流程图。
个人觉得业务流程图的绘制还是很有必要的，因为通过绘制业务流程图既能够加深自己对整个项目的理解，又方便梳理后续的其他流程，而且在向团队成员讲解项目的时候也能够有的放矢，便于团队成员快速了解项目。
业务流程图和任务流程图有点类似总分的关系，业务流程图主要用来梳理整体的流程，任务流程用来梳理单独的子流程。
任务流程图一方面是基于用户的操作，另一方面是基于系统的操作或者判断，会比业务流程图更细致一些，下图为我之前绘制的一个任务流程图(未考虑分支流程和异常流程)。
大多数情况下，任务流程图的主要受众群体是开发人员，所以对异常流程和分支流程的考虑和处理应该要更全面一些，不然在和开发过需求的时候发现逻辑上的漏洞，就会比较尴尬了。
那种比较复杂的流程图开发人员看起来也会很头大的，所以我一般都会尽可能的将流程图拆解成一个个独立的子流程，这样对方看起来会比较容易理解，自己在讲解或者调整的时候也会相对容易一些。
绘制流程图的时候，我一般会先将整体的业务流程和比较核心的主线流程绘制出来，最后才会将一些分支流程和异常流程细化出来。之前写过一篇关于流程图的文章，感兴趣的可以去看下…
产品设计之流程图
功能结构比较接近于我们平时看到的产品结构了，我一般是通过脑图的形式先对功能做加法，最后再基于需求本身和项目的目标来做一些减法。
下图为之前文章中写过的一个案例，这是通过产品表现层梳理出来的功能结构图，注意这个仅仅是结果，是产品经过多次迭代后最终呈现出来的形态，不是在产品设计过程中的过渡产物。
在我们自己进行产品设计的时候就相当于是一个逆向操作了，需要在用户的目标与产品的目标之间找到一个平衡点，然后基于这两者来合理的组织产品的功能结构，最终再将产品的功能结构转化到产品的原型上。
对于功能结构图和信息架构图，我之前一直有点傻傻分不清，后来在网上看过一篇文章说信息架构主要是用来梳理数据字段的，是开发人员用来参考着建数据库表结构的，当时觉得说的好像有点道理，就一直这么相信了…
后来看完《信息架构 超越Web设计》这本书之后，就再也不敢有事没事随便提信息架构这几个字了，因为我发现信息架构本身是一门学科，根本不是一本书能够说清楚的，更不要说一篇文章了…
根据《信息架构 超越Web设计》这本书里面的定义来看，信息架构包括组织系统、标签系统、导航系统、搜索系统以及叙词表、受控词表和元数据等…
而以前提到的部分只是信息架构里面的九牛一毛，仅仅只是元数据里面的一部分，下图为一个所谓的“信息架构图”的样例，可以看到所有的内容都是以名词的形式出现的。
我在实际工作中用到这个“信息架构图”的次数很少，而且也确实是在和开发人员确定具体字段的时候用到的…
页面流程图的核心是表现出来不同页面之间的流转关系，即用户从哪里来，能够去到哪里，通过什么样的操作能够实现怎样的页面跳转，通常情况下也可以通过在原型上加跳转链接来说明页面之间的关系。
下图为整理的摩拜单车的核心页面流程图，但是实际工作中这两个流程的顺序应该是相反的，即应该先有页面流程图，然后才是原型中的页面跳转关系。
这个应该就是我们比较熟悉的东西了，至于是用什么工具去展现，其实并不是那么重要，我个人的习惯是先构思一下整体的页面布局，确定了大致的区域和内容，把草图先画出来，最后才是使用工具来绘制原型图。
素材来源于互联网
最后要说的这两个东西在平时工作中遇到的可能会比较少，但是也是比较重要的东西。在产品形态比较复杂或者角色较多时，可以使用用例图来帮助梳理产品的主要功能，下图为在之前案例中绘制的用例图。
用例图和产品的功能结构图有些类似，它们两个应该是同一个环节中的产物，用例图的核心在于说明用户能够通过这个系统做什么事情。明确这些之后，就可以直接将用例图转化为产品功能结构图，然后指导后续的画原型工作了。
顺序图在工作中用到的次数最少，我只在产品和另外一个系统进行对接的时候画过一次。下图为之前案例**现过的顺序图，和业务流程图中的泳道图有些类似。在一些公司开放出来的API的文档里面通常也会有一个时序图，用来说明系统间是如何进行交互的。
之前我写过一篇文章，是关于UML中常用的一些图的，感兴趣的可以去看下。
案例分析 || UML大战需求分析
平常工作中可能会遇到的图差不多就这些，其中流程图、功能结构图、原型图是肯定会遇到的，至于其他的几个图需不需要绘制，则需要具体问题具体分析。一方面是基于遇到的问题，看用哪种方式能够更清楚的表述出来，另一方面则需要结合团队习惯和个人习惯。
个人觉得文档管理还是比较重要的，一方面是能够为团队成员之间的交流提供便利，降低协作成本，提升整体的协作效率，另一方面是能够将产品本身的迭代历程记录下来，在之后查找相关东西的时候能够有文档可寻。
以上就是本文的主要内容，主要梳理了在整个工作流程中产品需要关注的一些图，希望能够对大家有点启发或者帮助。
欢迎斧正、指点、拍砖….
产品学习｜交流分享
长按二维码即可关注
评论(0)