本来写完上篇，我发现没有太多必要单纯讨论这一部分内容，因为对于很多人来讲，缺的不是具体的做法，而是做这件事情的意义以及目标性的明确。一旦对这件事情的意义和目标有深刻认同，那自然会产生较大的动力去研究How这个层次的所需方法和技能。时间管理也如此，很多时间管理技巧牛逼的人未必能够把时间管理做到位，因为内心克服不了强大的拖延症，而克服拖延很多时候是一个心理问题而不是技巧问题……咳咳，这不是在说我自己吗？
业务流程图的表达的6个关键问题
话又扯远了，扯扯扯回来啊。那么为何还专门狗尾续貂（恩，原文也不见得是貂，成语有限，暂时凑合吧），又来这么一篇How的枯燥乏味的文章呢？因为在上篇文章后，Heidi确实在邮件里收到一些邮件，询问业务流程图的具体操作指南——这东西很好，这东西很有用，但是似乎上篇都是讲的“真实的道理”，但是具体怎么做呢？我应该注意什么呢？……
所以，干脆也分享一下吧。但在书写过程中，我发现一个大难题在于收集整理出更生动易懂又典型的案例。不能使用工作中的实际案例，但是短时间又难以找到合适的。所以本人对这部分不太满意。也希望各位读到本文的人，能够提供更多案例分享。
———————————————分割线————————————————————————
1. 业务流程图的“烹饪三部曲”在绘制业务流程图前，思考如何精美、如何交互以及使用什么工具，都不应该是重点。
真正重点的是将业务流程图的关键要素给搜集一番。请试图回答清楚以下几个问题，否则不要开始绘制流程图：
整个流程的起始点是什么？整个流程的终结点是什么？
在整个流程中，涉及到的角色都是谁？
在整个流程中，都需要做什么事情？（可是是一个会议，可以是一个任务）
这些会议和任务是可选还是必选的？
分别产出什么文档？
这有点像一个头脑风暴，能够帮助你将所需用到的原材料获取到，有了这些“米”和“水”，那就不愁去如何烹饪了。
在项目管理中，上个月，我们也试图给去规范化一个数据产品的设计开发流程。
这是一个数据产品的项目，而我们都不是对此很有经验的人。所以我们召集到所有相关的角色，组织了一次头脑风暴及卡片分类法的混合式应用。
让大家头脑风暴出自己认为在项目里必须的节点，如“需求调研”，“需求分析”，“kick off会议”，“PRD撰写及确认”，“数据评估”，“技术架构”，“DEMO绘制”，“指标算法定义”，等等。
在头脑风暴过程中，主持人将这些节点都写到白板上，等没有新的节点诞生后，大家一起对节点进行合并归类。之后呢？
将这些剩余下来的真正有价值的节点，撰写到即时贴上，开始进行排序。在排序过程中，可以由一个人先主导，他会按照自己的理解，将各个节点放到按角色排布的泳道中，并设计好先后的顺序。在他进行的过程中，其他人不断进行提问：“这项任务开始前，需要什么样的条件？”“这个任务是必须的吗？”然后一起调整先后顺序。直到最终没有人有任何重大的异议。
之后拍照留念。
然后可整理成电子文档，如 project 或者 excel 版本（使用 excel 做项目管理？）
但是，业务流程图和上述项目中的流程不太相同的是：
项目中的各种活动节点有更宽泛的可配置性，任务A和任务B是否并行，还是串行，如果项目组成员达成共识，是可以调整，并且多做尝试的。所以可以用集思广益的做法去头脑风暴出一个暂定比较合理的流程。而业务流程图的梳理，有两种:
一种是基于现实发生的业务流程如实反映。这显然不是你一个团队能够YY的结果。更需要走到现实环境中，去调研，去梳理，去确认。
另一种是基于流程优化的方案，当你已经掌握了目前的流程现实如何运作时，基于分析，讨论，能够判断出流程中不合理的地方，给出一个更完善或者有更效率、成本更低的新的流程出来——或许你要求增加一个部门，或者你需要删减一个环节，或者中间的若干步使用新开发的系统去取代。
