B端产品是服务于组织,通过帮助组织提高收入、提高效率、控制风险,从而协助达成组织商业目标的系统。一个合格的B端产品或系统,必须是基于业务出发。如何梳理复杂的业务关系?
流程图=流程+图,流程是一系列的逻辑关系(包含因果关系、时间先后、必要条件、输入输出)做需求前一定要先把这些逻辑关系理清楚,用一句话概括的话“流程就是在特定的情境或场景下满足用户特定需要的总结”。
图就是将大脑中的逻辑关系以图形化的形式呈现出来,具有图形化、可视化的特点,因为是图,可以及时的迭代,当逻辑需要修改的时候就拿出来迭代一下,同时可以更好的给项目成员进行沟通和交流。
每个人想一个逻辑的时候,不一定能把这个逻辑的细枝末节都想到,如果我们贸然的画原型就有可能做许多无用功,这个时候画流程图可以帮助梳理清楚的逻辑。
Tips:
团队讨论或开会时,如果有一张清晰的流程图,不仅便于讲解,也便于技术理解。
同频的沟通,能快速地就某个点进行有效讨论。同时把确认后流程图写入PRD文档中也方便传播,当技术忘记流程的时候,查看一下文档里的流程就知道流程了,不用反复确认。
对于输出的一个逻辑,不一定能考虑的那么周全,如果有一个清晰的流程图也方便做记录以及修改。
同时每个版本迭代的流程图可能会有相应的变化,通过对每个版本流程图的对比分析,可以知道流程优化在什么地方,产品优化了什么地方。
流程图是符号化的图形语言,有一定规范,菱形代表判断,距形代表具体的操作行为、开始和结束用圆角表示。
1)角色:都有那些人参与功能里(系统也作为一个角色)
如:coo/ceo、行政部长、内部组织或部门、业务owner、业务监管人员(前台)、员工、供应商、除供应商外的第三方组织。
2)事项:这些人分别扮演什么角色,要做什么步骤事情
如:
3)需求或信息的流向:要完成任务的流程顺序是如何?
每个功能模块中,从哪里开始,到哪里结束。
Tip1:流程是可以多进,但是必须是一出,这个是最常见的一个错误,从一个流程直接出到多个下级流程的做法是完全错误的,正确的做法是出到一个判定然后再分别到多个下级流程。
Tip2:流程里的文字描述得是谓词短语,而不能是名词短语,如:提交申请,而不是申请的提交。
Tip3:在画完泳道图后,最好给每个流程、判定、子流程加上序号,方便在和团队沟通的时候用序号来快速定位(注意:一定是在整个泳道图定稿后才加上序号,不要对还在优化修改过程中就加序号,否则很容易把序号搞得很乱)。
Tip4:如有必要,可添加必要的说明文字。
梳理陌生的业务前期思路的不清楚,会痛苦挣扎了很久,选择好的工具和一个清晰的思路让梳理业务没那么痛苦~
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。