项目真的是越多越好吗？答案显然是否定的。重复的项目不会给工程师们带来新的成长。不停的做项目，从而缺乏学习新知识的时间，会导致“做而不学则殆”。真正让工程师出类拔萃的是项目的深度，而不是不停地做项目。所以，在项目之间的空档期，工程师们应该珍惜难得的喘息之机，深入思考，把项目做深，做精。
很多平台化的关注点是接入能力和可扩展性，而普通业务的关注点更多。
归根结底，平台化就是一种普通需求。在实施平台化之前，一定要避免下面两个误区：
做正确的事情，而不仅仅正确地做事情。这是一个被不断提起的话题，但是错误每天都上演。为了在规定的时间内完成一个大项目，总是要有所取舍。如果没有重点，均匀发力，容易事倍功半。如果“南辕北辙”，更是可悲可叹。
果说性能优化能力体现的是架构师的静态思考能力，在线运维能力考验的就是动态反应能力。残酷的现实是，无论程序多么完美，Bug永远存在。与此同时，职位越高、责任越大，很多架构师需要负责非常重要的在线系统。对于线上故障，如果不能提前预防以及快速解决，损失可能不堪设想，所以在线运维能力是优秀架构师的必备技能。
如果达到了 I5 级别的智能化能力，根据 D2C 系统交付分级参考标准，D2C 系统交付分级可以从 L3 进入 L4， 生成的代码将不需要人工干预和验证即可直接上线。
正确的方式是，先把具体的产品抛下，多了解客户的背景、业务、状态等整体的、背景的、来龙去脉的信息，要表现出对客户“感兴趣”，要想成为客户的朋友。
比如，我们的智能文案平台，能够智能生成千人千面的营销文案。过去，一直在迭代产品、提升算法能力，力图生成更加智能、精准和个性化的文案。
比如，知识图谱平台的知识更新和智能文案平台的文案发布，都需要走打标和确认流程，我们发现标注平台的标注能力就够用了。所以，我们就没有重新开发，而是在平台之间打通连接，快速解决了这个问题。
在专业技能方面，除了要有产品经理岗位必须的“需求管理、产品设计、项目推动”等能力之外，还需要“懂技术”。要懂研发流程，要懂各种算法、模型的术语和原理，因为你不仅要与平台的开发团队对话，你还要跟平台的用户进行对话——这些用户大部分也是技术同学。
所以通过MyBase安全物理隔离的机制，可以解决很多行业合规属性问题。大家在普通的业务场景下依然可以选择普通的云服务，一旦需要完全独立的物理隔离环境就可以选择MyBase专属机群服务，作为数据库上云的选择，从而杜绝安全性合规风险。
