FAQ-UML 在产品经理的日常工作中有多大作用？

UML图是给码农，架构师，专利局，版权局看的 。老板不看，市场不看，设计不看，产品经理懒得看，更懒得画。UML是系统分析师的专用工具，我见过一个系统分析出生的产品经理搞了一堆UML讲立项PPT，什么接口，系统，时序了。业务老板直接看睡着了，与会的其他人也睡着了，后来我帮他把所有的UML图全删，精简了一堆技术化的废话。只留5页最精华的，立项才算通过，给boss就讲大局的就行啦。执行的时候，可以找码农们去讨论如何设计和实现！

一般中小型的项目，核心主程序员都具备一定的系统分析和设计能力，他们看了前端APP原型，理解需求，自己可以UML建立系统模型。人力不够，或者涉及到大型复杂系统设计的时候，才会去再招个系统分析师来做这事。

产品经理的首要职责是抽象场景，管理需求，最终推动需求落地。立项时，找利益关系人，比如需求方，Boss等参与，这里面主要讲清楚业务流程就可以。研发时，xMind用于梳理功能，有利于功能规划，版本规划。原型草图主要给交互设计师，UI设计师，APP工程师看。UML主要是给系统分析师/工程师看的。实例图用于搭建数据库，时序图用于编写接口，流程图用于编写输入/输出逻辑。状态枚举值用于状态机开发用，状态之外就是异常。

经验上讲：一般用UML进行系统分析的工作量相当于预先进行了一次“准编码”，如果UML搭建出来的模型有问题，就在UML的基础上修改，分析师和架构师评审OK后，再交付给码农们正式编码开发。也就是说，整个项目进行了至少两次代码编写。 通过这里，可以看出UML会延长项目周期时间，至少1倍编码时间 ，对于求快的项目，都会省略掉UML这种过程，直接对着prototype原型草图开干了。至于以后要拓展，要兼容的功能点，以后再说，先把当下过了。从这个角度来看，在一些创业型，小型，独立的，赶工期的项目，很少有团队去通过UML进行一次预设计——太费时！

以前做单机游戏，离线工具，由于工作范围单一，产品单一，用户单一，设计产品的工具大部分是Axure，Mind之类的，没怎么用UML工具，最多画个流程图。但后来从事平台，大型通信SaaS，物联网，交易系统设计和分析，就用上UML。

下面是我的一些项目经验中涉及到UML的感悟：

Android系统工具：

由于我也当过Windows码农，我就写个Windows演示代码给Android+Linux资深码农，说我要在Android需要这么一个类似功能，至于具体的数据结构和逻辑交互，他再自行安排就完事了。因为整个界面就一个输入框和一个确认按钮，我用Windows C#演示代码用了300行搞定，但那位资深码农用Java，C和汇编就写了上万行代码。因为他要在Android上重新开发一个引擎库，这个引擎库要很多代码量，但UI Java层和我类似，只需几百行代码。比如我输入1，他就要对1的内存序列做解析，比如字符串的“1”，整数1的序列，长整数的1，浮点数的1.0，高精度浮点数的1.0，然后要对这五种1做不同的逻辑处理，五种之外他又预留了兼容处理办法，以免我输入额外的1，导致Android手机变成砖头。

这么复杂的系统，他用了UML工具吗？没有！因为我们项目非常急，三个月开发，然后火急上线！更重要的是，他是老手，他以前在就做成功过类似的事情，全公司只有他懂Android底层代码，其他人也看不懂。所以，我们的APP一开始考虑非常简单粗暴，甚至没有登录，注册这些功能！！！产品上线后，APP激活数很大，三个月达到100万。我们才考虑这里加点登录，那里搞点广告的，但也没有做什么UML建模，因为十万火急要和超英赶美，所以费时费力的破事都省略掉了——包括UML建模。还有他高考650多分，985学历让我深信他搞这种纯技术的事绝对没问题！因为我觉得UML如果可以让系统第一次设计正确率达到60%才可以开工，但有的人直接编码整体正确率就可以达到90%，那就不需要UML了。

不过这里面合作有一个很有意思的地方，我是需求提出方，他是底层代码实现方，其实他说的技术术语我听不懂，我的用户也听不懂，我说的需求他又觉得太飘。于是在我和他之间有这么一位程序员帮了忙，这哥们也不写代码，他就理解我的大白话需求，然后翻译成他的底层需求和技术用语，我老板甚至觉得这哥们不写核心代码是不是没有干活。到现在我细想，他不就是在做需求分析，代码测试的事吗，只是没用UML而已。

物联网：

我要做一个绑定功能，就需要涉及到终端硬件系统，业务系统，资源系统，手机前端APP系统4个系统的整体交互。如果是放在以前的工作，我最多在APP画几个界面，交互几个跳转就完事了，但这完全不管用。说白了，那也仅限于APP系统设计，没有后台系统，硬件系统支持，不管用。

我主要的精力集中于市场竞争，用户体验和APP前端原型的设计。我们组的项目经理就很厉害，研发开会的PPT就是架构图，时序图。我们的物联网项目涉及到六、七个部门的沟通和交流，哪些功能该放在哪个系统里做，该放在哪个部门开发，他搞得清清楚楚，搞得同事们都没脾气了，按道理这事要吵一通架： 这个功能应该前端开发，那个功能应该后端开发 。这事让我来协调，我也就能够打通设计，APP，后台，但他能够打通到硬件，接入，服务等部门。总的来说，他充当了需求分析师，架构协调师的角色。UML画得很好，根据UML时序图就清楚的看出哪些功能归谁开发。公司的新专利会由他安排人员编写，然后他来审核。

有时候我觉得产品经理要想推动项目落地，还是需要有个给力的项目经理和需求/系统分析师。

推荐系统：

如果仅仅是画个破UI，商品详情下面来个三个商品推荐列表，一页！搞掂！3000块实习生就能搞掂这个破页面。但该展现哪三个商品，这又是另外一套系统来搞掂！

数据采集是一个系统，实时数据是一个分支，离线数据是一个分支，离线采样试验数据又是一个分支。

数据过滤又是一个系统，过滤方法有ABCD，权重有1,2,3,4。

然后就是个性化推荐分析。

最后是输出结果。

手机通信：

要做一个手机eSIM上网的APP。UI就一个首页。控件就一个开关：开就上网，关就不上网。这个页面让扫地阿姨都会做！问题如何实现上网？需要一步步做系统分析。要涉及到4G无线通信系统。细分下来，基站系统，管道，运营商鉴权，SIM卡系统，高通芯片，Android底层系统，Service服务，APP UI系统，都要层层分析。这么多系统之间有各种不同的通讯协议，光是这块，我们就要招聘专门的协议工程师来打通所有系统的通讯。 这个项目正式编码就1个月，但是我在这之前做了建模，准编码，就花费了2个半月——1个{启动}按钮按下去，背后涉及到数个系统，数千行代码的编写，我甚至用了伪代码来表示逻辑算法。

PS：之前的SaaS产品系统分析师直言不讳的就说我这个搞互联网的就是一个画UI，画流程图的（汗！）。因为光是画原型/流程图，项目是不能落地的，还得借助UML进行更细更深的分析，很多底层工程师，系统工程师和协议工程师根本就不看UI，他们要的是系统分析的场景，流程，数据表，实体，活动，状态枚举，时序等等。产品经理/需求分析师需要拆解给他们。

按我的经验看来，跨系统的应用/服务需要用到UML，很多东西不是画个UI原型就完事了。之前我在做某个物联网项目，立项的时候把原型画好了给Boss们审核，结果他们说，别这么急，还没到界面这一层，先把场景，硬件，服务，协议全部打通再搞APP。

著作权和专利权：

软件著作权申请文档里需要提交结构图，流程图，用例图，这些可以用UML来表示。最后还要附上60页的代码。

软件专利就不需要具体的代码，只需结构，流程，用例外加标注说明即可。

也就是说， 专利聚焦于设计，著作权聚焦于实现，都会用到UML工具来建模 。

所以：一般的研发序列是： 先建模，验证合理性，有重大创新的，紧急申请专利，再编码，最后申请著作权。 所以产品/项目经理不会画UML，可以让系统分析师画。没有的话，主程序也可以！什么？没有主程序，那就让水平较高的码农画吧。因为专利和著作权是有政府补贴的！！！有的公司甚至用专利来挣钱，你可以认为他们公司的律师团队都是UML看图高手！

2B业务系统：

核心流程是如何设计订单，订单的起源来自于哪里，订单如何结算。一个订单要从开始，到走完，要涉及多个公司，多个部门，多个操作审批，多个应用服务界面，才能完整的走完整个订单流程。

招聘：

我们在做一个全新的B2B+SaaS系统，我负责前台分析和设计，我的后台工程师说一定要有全面可行的物理模型，他才会开始执行代码后台开发，就这样被卡一段时间。有大型系统分析/后台设计的产品经理/需求分析师，有兴趣加入我们的，欢迎私信我。