我从事智能制造（TO B）产品研发的一点经历

很多都说，产品从0到1难，从1到10易。而我所经历的产品经历恰好与此相反。

我经历的两家公司，都是做TO B领域产品的。0到1大家都看得清楚、清晰，所以都在重复这个过程。1到10太远，看不清，都是浅尝辄止，望而却步。

A公司是一家从事智能制造的央企数字化公司，其核心产品是MES。真正从事MES产品的人应该比较清楚，MES是一个个性化定制化非常强的产品，其需要下沉到具体的工艺流程，可谓是“千人千面”。真正负责产品的，是一个从事ERP开发和实施20多年的老师，我个人认为他对ERP、MES的了解和应用，远远超过很多大牛对智能制造等的理解。实际上，很多经常讲智能制造、工业互联网的大牛，他们从来都是纸上谈兵。有次参加一个CIO的会议，听他们讲数据要素如何重要，如何做到精益和经营优化等，我感觉就在听他们在讲共产主义如何美好一样，但是过程中社会主义建设的道路如何艰辛，如何摸着石头过河，他们是只字不提的，这种理论派真的是要不得的。当初跟着老师，建立了一套完整的产品管理体系，很多都是基于他以往失败或成功的经历而来的。举几个例子。

（1）拒绝现场开发，将需求回传，需求经过严格的评审，然后进行归类开发。实际上，将需求写下来，回传的过程，就要求现场实施工程师对需求进行一定的筛选和过滤。有些是企业特别个性化的需求，根本不需要产品改善的。实施工程师得现场与客户沟通解决。

（2）项目版本和产品版本分开。项目中有些需求确实只是对应企业特有的，无法合到产品版本中，所以就分版本控制。而且产品版本为了打造一个更加通用或者主要适用于某些特定的行业，不可能将弄得特别庞杂，否则不利于实施和后期维护应用。MES产品，以至于多数信息管理系统，我个人认为，都不是功能越复杂越完善越好的。产品标准化和定制化的工作量应该控制在7：3，是性价比最高的。

（3）需求需要多方多次评审，再开发。需求是引导产品方向的重要依据，当初制定了比较想尽的评审机制，甚至需要很多人同时在场的情况，所以很多时候都在加班。而且多方评审，往往会加入一些莫名其妙的业务逻辑（可能很正确，但不是客户当前最需要的）。如果是产品类的话，需要对需求的业务逻辑再抽象，形成一个模板，便于后期产品的开发和并入。

上边只是列举了3个A公司产品开发的管理体系，其实弊端非常明显。就是项目交付过于缓慢。前期A公司因为起了个大早，而且又有央企做背书，过得还不错。但是后边各种MES产品如雨后春笋一般涌现时，就显得捉襟见肘了。

我个人认为A公司是确确实实做产品，而且领导是有情怀要做一款伟大的MES产品的。当初因为经营不好，我还建议做自己央企的供应链电商平台，整合央企集团内部的信息化业务；代理国外的工具软件，形成一条工艺工具的业务线……，除了让我尝试做一个行业的工具业务线外，其他都拒绝了。

实际上，在产品开发的过程中，我们一直都在经历推导重来，推到重来的过程。实际上就是在反复经历0到1的过程。

在经营管理上我是不敢苟同A公司的，但在产品管理方面，我觉得A公司是我见过听过最好的MES甚至工业互联网类产品团队。

很多创业公司明面上产品有十几种二十几种，甚至产品数量都比项目数量多，这怎么可能了？这些企业产品总监、技术总监走马观花似的换，甚至连本身的产品管理体系都没有建立起来，重复得更是0到1的过程。

在做TO B领域产品时，我一直都是建议要类似军工企业一样进行“型号”化管理和开发，同时产品功能要“小”要“简单”。