新手用了UML后，却被领导痛批，如何避免？

说了你又不听，听了你又不懂，懂了你又不做，做了你又做错，错了你又不认，认了你又不改，改了你又不服，不服你又不说！你让我怎么做。

——《江湖》

一些人看了《图解产品》后，就把书中内容用起来了。在这个过程中，有人收获了惊喜，有人收获了惊诧。

收获惊喜的同学说，研发夸他了，说“小伙子不错吗，连状态图，顺序图都会，有两下子。”

收获惊诧的同学说，领导痛批她了，不听她说完，就全部否决了。痛批的原因，一方面是领导不懂UML，另一方面是她用的有问题，沟通也需改善。

下面就是我和金鱼网友的对话，她也是我星球的读者，下面内容还原度80%。也希望看《图解产品》的小伙伴们都来看看，避免栽坑。

— 1 —

很无语且好笑的事

金鱼：刚刚发生了一件很无语且好笑的事。我和项目经理评审PRD文档，我按照你书里的框架把目前做的系统往里套，他都不听我说完，就全部否决了……。

然后他说他的想法，在我看来也是逻辑混乱。然后他说着说着，也说不通了，就把他自己也气跑了。

擎苍：看情况把，书中内容算系统思考，但是中小项目也可灵活裁剪和改变次序，我在业务调研章节中讲的排队系统有意没用四层九要素，目的就是告诉大家可以灵活运用。另外在信息设计那一章中，我举例的BSSP方法，可认为是个更小的业务设计步骤。

擎苍：他怎么认为逻辑不通？

金鱼：就比如状态图里，线上写的是流程（人+动作），框里面是的状态。他硬是说我动作描述反了，而且要写上业务规则。

然后我就问他，我现在梳理的是核心业务操作流程，而不是规则问题，规则问题单独看，而状态图就是这样画的。

金鱼：他又说开发会看不懂。这种图要给啥也不懂的人看，让他一看就能理解。我就沙雕了.....，研发不可能不知道状态图啊....。

金鱼：然后他就拿出他那张又繁杂，字又多的图说了几句，说的也不清晰。

擎苍：他似乎不了解状态图，这样他就没有发言权，更无法指导你。很多研发是懂的，如研发认可你的图，那就没有问题。

金鱼：如果他认为我梳理的有问题，但又说不出所以然来，我就无法信服他。最后他自己也无法自圆其说，还把自己气跑了，搞笑。

点评：遇到问题就解决问题，而不是意气用事，并质疑别人否定别人，这只会把事情搞糟。

— 2 —

有问题的状态图

擎苍：如果构建复杂系统，一般要先梳理流程图或者顺序图，然后再说状态图。

擎苍：我能看看你梳理的图吗？

金鱼：我是按照业务流程图-交互流程图-状态流程图的顺序来的，这是状态图。（涉及隐私，图不做展示）

擎苍：你这个状态图略有问题，但大体上意思对，还是可以的。这样看你的状态图还是有必要的，甚至可以直接梳理状态图而不管流程图。

擎苍：这一段状态迁移可能是：[待街道查办]-<街道点击转公安查办>-[待公安确认]-<公安点击确认>-[公安已确认，待查办]-<公安点击已查办>-[公安已查办完成] ，我简写了，你应该明白什么意思。（涉及隐私，状态梳理做了修改和简化）

擎苍：你的状态可能有缺失，且业务操作少了一些。

金鱼：我觉得我也有问题了，我还不熟练。

点评：其实金鱼做的状态图的问题，我在书里都说了。金鱼应先看书，然后严格按照书中步骤做一遍，最后再看书，对照着找问题。 我的经验表明90%的人都不能一次做对，这就是因为做的快，而没有记住书中所讲，也不检查所致。 我看了很多人画的错误图，做的不对的地方我就会在书中说，所以只要照着我的书梳理就没有问题。另一方面，有时书要反复读，常读常新，这比读了多少本书更重要。

— 3 —

如何做好沟通？

金鱼：但他也有问题，他说我这图也没说“XX”名词是什么意思。我说这些名词在概述部分都解释了。如果连“XX”名词都不知道啥意思，做个鬼业务啊。

擎苍：你和研发沟通了吗？

金鱼：他要先和我对齐，还没找研发。

擎苍：建议你先私下找关系好的研发，说说这种状态图的梳理方法，有的研发可能会认可并欣赏你，有的研发则不同。这样可以找到同盟。

擎苍：如果研发也不明白，就画成流程图，基本上是把这个图转化一下，可对照业务操作章节的身份认证状态图和流程图的转化。

金鱼：我倒是可以找研发先沟通一下。另外我画的也有问题，这就没法完全说服我们项目经理。他老项目经理了，工作十几年了，我刚工作这个月底刚满两年😂😂😂

擎苍：是的，他看的是有些费劲。但你不用担心，改两次就能做好。也许他还有能力，但野路子，能力低的上级有很多，你超越他们很容易。

擎苍：一位现在上市公司的CTO，当年也管着所有的研发，我给他看状态图，他也不懂。他还在会上反复问啥是对象的状态，画的小黑点是什么意思，我也很无语啊，也要教他。

擎苍：其实你先画个流程图到更保险，因为我这些做法有些抽象，不适合给抽象思维略弱的人看。

金鱼：我还是得多多修炼自己，也要情绪稳定。

擎苍：恩，保重身体。

点评：和领导有冲突需谨慎处理，此时要注意： 一方面，产品经理不是要显得专业，这种专业有时会让人尴尬、不适；而是要让对方明白事情，这样才能成事。 比如对方不懂状态图，也不愿意学，就不要画，而用更加形象易懂的流程图或页面流程图来代替。状态图可自己看，从而便于完成原型图。 另一方面，寻求同盟仍然是不二法门，只要研发认可，一切都不是问题。有可能研发一句话“妹子行啊，这都懂，有两下子！” ——就能让你在团队中获得威信。

全文完！

▊《“图解”产品：产品经理业务设计与UML建模》

擎苍 著

• 用图解构产品经理的知识
• 业务设计的开山之作，UML建模的学习宝典

作为产品经理，你是否遇到过如下问题：写出的文档有漏洞，上线的产品要返工，或者在调研的时候无逻辑。出现这些问题的原因往往是产品经理没有分层思考，没有用UML 建模。

为此，本书提出业务设计整体框架中的四层九要素，从而将问题从大到小拆分，并给出每个问题的思考步骤。

本书适合有一定基础的C 端和B 端的产品经理阅读，所讲的知识既可用于C 端领取优惠券、身份认证等的设计，也可用于B 端内容管理、订单管理、CRM 等的设计。

快快扫码抢购吧

（京东满100减50）

如果喜欢本文欢迎 在看丨留言丨分享至朋友圈 三连

 热文推荐  
一行Python代码解决问题是时尚还是玄学
看半小时漫画，通晓计算机基础
基于Spinnaker的全自动渐进式交付
1024程序员：算法&仓鼠&创业

▼点击阅读原文，查看本书详情~