如果要问我在一个项目化程度较高的传统行业软件公司如何实施产品化，我想到的是“润物细无声”。
从电信行业的传输网管，到电子运维，又从气象行业的格点预报到农业气象，几乎所有的系统平台都在嚷嚷着要产品化。但是多年来实践告诉我们，产品化之路并非像讲口号那么容易。特别是已经将所有资源都陷入项目的团队，就像一个病入膏肓的病人，想要通过一次大手术或者一剂猛药就挽救性命是很困难的，反而更大的可能是挂在来手术台上或者是用药过猛身体不支。
所以我们不妨将产品化三个字抛开，不要以为用这样一个虚头巴脑的口号来欺骗自己，影响团队的和谐。转而思考产品化背后的目的，围绕这个目的明确我们应该做些什么，我们应该避免些什么。
我以为产品化在不同公司不同的阶段有不同的目的，在我们还需要依赖项目而生存的阶段，做产品的目的只有两个，一是支撑更多项目落地，二是支撑项目快速交付。简单说就是提高收益，降低成本。所以我们并不一定是要去重新设计和开发一个一个新产品或者推倒重来，这是大公司大平台才能做的事。对于一个初创企业或者有着严格考核目标的公司，如何充分梳理现有项目成果，技术成果，业务流程，思考从哪些地方改善能够让所有项目运行更稳定，哪些模块和组键能够提炼出来供新项目复用才是关键。
以气象项目为例，我们发现气象的项目最重要也是最折腾人的就是数据问题，我们的系统应用不好很大程度也归咎于数据的环境的质量。单个项目数据采集的稳定性，数据结构的复杂性，数据种类的差异性，数据存取的性能都对数据环境质量产生影响。多个项目之间数据规范的缺失，数据库结构统一管理维护地缺失，开发人员各自为战随心所欲更改数据库结构会让整个产品的数据环境陷入恶性循环。
我们如果能静下心来对数据环境进行一次系统梳理，弄清楚数据涞源，形态，存储方式，命名规则，更新频次，同步方式等关键信息。并选择统一的数据采集方式，在数据库维护上采取更严格的管理方式，才能从数据环节打好基础。对于已经在运行的项目动用尽可能少的资源去对项目做改造是不希望尽可能减少对现有项目的影响。新的项目需要在新的数据规范，新的采集模式，新的数据库管理规范下打造数据环境。开始就不能停止，即使慢一点，所谓方向对来时间就是朋友。
关于如何进一步通过改善现有项目的质量，实现支撑更多项目落地，如何支撑项目快速交付，后面会持续思考和更新。这是一个持续改进的过程，先抓关键问题，聚焦，迭代优化，这也是敏捷思维在这个事情上的应用。
