“月亮悄悄翻过小山坡，一座座，月光慢慢悠悠温柔的洒落；路边开出小小的野花，一朵朵，走在归家的路泪眼婆娑；”—— 王海颖 《月亮翻过小山坡》
从深圳开往杭州东的G900次列车，晚上20点40分准时出发，在这个天气阴晴不定，航路时而疯癫的季节，拥有近乎百分百准点率的动卧，成为我回家的一个不错的选择。
这班动卧速度挺快，声音也不是很大，晃晃悠悠的状态，感觉还挺适合继续我们的产品工厂之旅，那就开始吧。
建设银行产品工厂虽然不是一项天大的工程，但是也会有不小的工程量，所以第一篇，我们来讨论一下契机问题，我们不给产品工厂下定义，其实一个一般的定义描述，要么准确而晦涩，要么朦胧而性感，并不能给你带来什么，所以我们索性先不定义了。直接讨论：什么样的场景下，你会需要一个产品工厂，什么样的契机下，你适合用产品工厂来解决问题。
如果你正在建设或维护的系统，只有几十个参数，这些参数一旦确定，也不怎么变，参数的数量呢，也不会经常性增加。这种情况下，系统的研发和运行处于一个稳态，其实连参数的大量变动都没有的话，是不需要产品工厂的，如果你的系统负责这种状态，可以忽略产品工厂。
如果你正在建设或维护的系统，业务非常复杂，不同的场景下，需要走不同的处理流程，这里的处理流程包括人工审批在内的一些审批流，可能这些复杂的审批流需要一套复杂的参数配置，比如每个审批流，需要配置什么节点，审批模式，审批人的类型与定义，一起其他的参数等，即使看起来这种模式比第一种情况要复杂的多，但是如果仅限于此的话，这个系统可以忽略产品工厂，使用定制和升级后的工作流引擎应该足够了。
如果你正在建设或维护的系统，业务非常复杂，本身已经存在了产品这个概念的定义，并且有相当数量的产品。不过呢，这些产品在系统内的存在只是不同的产品类型标识，并没有因为一个产品的新增，而带来大量的配置参数的新增或者变更的话，这个系统可以忽略产品工厂。
如果你正在建设或维护的系统，业务非常复杂，本身已经存在了产品这个概念的定义，并且如果新增一个新的产品，相关的代码就要进行改动；并且会导致一堆的参数需要新增，投产后，某些参数可能会进行变更；并且随着业务的发展，产品的增加，没有停下来的迹象，这种情况下，你可以考虑下产品工厂。
如果你正在建设或维护的系统，业务没那么复杂，也没有产品概念，但是呢，存在众多的配置参数，随着业务量的增长，这些配置参数呈现线性增长的趋势；并且随着业务功能的增加，可配置单元的数量，所有单元对应的参数总量在一直增加；如果需要有效的管理这些配置参数，你可能就需要用某种划分规则，把这些参数分门别类，甚至分层的进行管理，这种情况下，你可以考虑下产品工厂。
你看，在如上的几个场景中，并不是有产品概念的系统，才会有可能适用产品工厂模式，如果业务复杂度不够，参数量没有到达一定程度，即便已经有了产品概念，并且存在数量众多的产品，其实没必要上产品工厂。另一方面，即使某个系统，不存在产品概念，但是配置参数量众多，即使前期你没有在用产品工厂的概念在建设这个系统，但是你对于大量参数可管可控方面进行的方案建设努力，其实就是在构造某种类似产品工厂的东西。
也就是说，虽然产品工厂这个理念，常见于业务型系统中，但是对于技术型系统和平台类系统，也不是与产品工厂无缘，甚至于在某些情况，这些技术型系统与平台类系统实现产品工厂模式会更加彻底。
那是不是参数量多，且随着可配置单元增加呈现迅速的线性增长的系统，就可以用产品工厂来搞，然后把参数搞好了，就叫产品工厂了？是也不是，我们在以后的文章中进行展开，本章节先不管这个问题，聚焦与契机问题。
总结一下上面的论述：
1、没有产品概念的技术型或者平台型系统，也可以适用产品工厂理念。这一条很重要。
2、业务型系统，如果参数规模不大，参数扩张速度不高，不必考虑产品工厂。
3、业务型系统，参数规模大，参数扩展速度呈可预期的快速线性增长趋势，可以考虑产品工厂。
产品工厂的概念，各位可以去自己搜一下，或者听业界前辈介绍下，来源于业务团队对于业务型系统的抽象与演进。但是在我们今天的论述中，明确的指出，产品工厂理念适用于技术型或者平台型系统，不用受限于业务型系统。
系统场景适用产品工厂，只是契机合适的必要条件之一。如果要顺利开展后续的产品工厂相关工作，还需要具备什么其他条件么？即便是场景适用于产品工厂，你也需要再找到一个必须要上产品工厂的理由，并赢得利益相关方的支持。
什么意思呢？系统场景适用于产品工厂，与系统必须采用产品工厂模式进行建设与改造，是两码事。不论是你得到了领导的一个口头指示，还是说得到了业务方的强烈支持也好，默许支持也好，都要取得利益相关方的支持，再具体一点，是要找到PMO领域中的Sponser角色，也就是谁说了算，谁拦着你你就搞不成。取得这些角色的支持，才能进行下一步的产品工厂相关的推进工作。
当然，如果你只是想自己进行一些理论分析和技术尝试，并没有想着把这个事情给推到生产环境投产，那就没关系了，自己喜欢就好。如果你的目标是投产。则一定要得到这些相关方的支持。
如果本身产品工厂的提出，就是由你的Sponser提出来的，那这些理由什么的，你就可以少费脑筋了。但是如果不是，产品工厂的提出与推动的最大动力，是你自己，则非常有必要把这些事项都搞定。除非你自己可以拍板一切，如果是这样的话，请接受我的问候，领导，晚上好！
要去说服相关方，同意你建设产品工厂，只是场景匹配是不够的。建设完成产品工厂会给大家带来什么好处，有什么事情是无法通过产品工厂得到的，你需要有个清晰的阐述，去推销和宣传自己的主张。
梦中，通过产品工厂，我们可以快速的装配各种产品要素的关键配置，形成一个新的产品，并快速投入市场。以极低的开发工作量，甚至极低的配置工作量，来完成一个新产品的创建与投产。可现实真的有这么理想么？
我们在契机这个章节，谈到需要说服相关方，就需要阐明产品工厂投产后的效果与收益，但是在我看来，不同的的产品工行建设模式，以及对于产品工厂的理解层次差异，实现能力的差异，会导致投产后的产品工厂千差万别。
所以还请大家容忍下，耐心看完我们后续的对于产品工厂的系列分析与讨论，自己能够彻底搞懂产品工厂后，我们再回来把契机章节中的产品工厂收益补齐。我觉得这是一个更靠谱和更理性的选择。
因为事情的推进是按照逻辑顺序依次推进，但是前提是你要完成产品工厂理念的全生命周期的认识，才具备按照逻辑顺序去推进产品工厂的实力，在没有理解相关的细节与能力前，我只是空虚的吹水，对你是没有任何帮助的。如果只是找产品工厂空虚的收益表述，相信你有一百种方法从一堆资料中，找到各种天花乱坠的表述。此事不需要我干。
我要干的事，是去伪存真，简称祛魅。谁都不要装大尾巴狼，有什么说什么，大家讲道理摆事实，正经的论述一个事情的本质。
今天就到这里吧。其实前一篇的开篇，写完的时候，已是凌晨两点了，明天在家里的安排排满了，需要提前睡觉了。