现象一： 6月6号服务中断问题，技术总监应该对引入新框架或新技术后，给平台带来的以下共性问题进行充分评估：
1. 解决或优化现有的什么问题
2. 带来哪些向下兼容性问题，（优美的）解决这些问题的方案
3. 新特性对平台带来了哪些问题隐患（这些隐患不一定要立即处理，但是至少要心中有数）
4. 引入新特性时如何保持平台的扩展性
现象二：请看以下changelog：
3.1.2.4 发布日期：2015-06-11
取消将标准 UTC 时间自动换换为本地时间
3.1.2.3 发布日期：2015-06-10
将服务端返回的标准 UTC 时间自动转换成本地时间
这是在一位用户对3.1.2.3的变更提出抗议后，iOS工程师立即发布了3.1.2.4的变更
LeanCloud是一个跨平台的SDK，产品总监应该对任何一个功能变更或功能引入进行以下评估：
1. 解决或优化现有的什么问题，这些问题是单平台还是多平台问题
2. 对本平台带来哪些向下兼容性问题，对其它平台会造成哪些影响
3. 其它平台是否能支持这些特性，其它平台引入这些特性后，会产生什么隐患
4. 引入新特性时如何保持整体的扩展性（而不是iOS、Android、H5自己开发自己的）
以上内容可能有点虚，就拿UTC这个问题来说。
新特性：将服务端返回的标准 UTC 时间自动转换成本地时间。
产品或技术总监应该考虑以下问题：
1. 这个特性解决或优化了什么问题（不作讨论，LeanCloud当然后自己的考虑）
2. 兼容性问题，以前的版本是不转的，现在要转了，必须要考虑以下问题：
(1) 是否优先考虑使用扩展的方式来提供这个特性（比如提供一个参数，让需要转的用户使用，这样可以不影响现有功能，一般软件设计不会轻易使用功能变更）
(2) iOS转了，Android, H5是否需要转，如果其它平台不转，会不会发生时间错乱，用户会confuse
(3) 如果Android, H5需要转，应该如何转才能保持整体的扩展性（每个工程师的思维方式是不一样的，应该达成一致的目标）
(4) 即便意识到3.1.2.3的问题了，3.1.2.4简单粗暴的回滚，是不是稍显随意？
再往上说一下，根据现象二，我目测，可能LeanCloud有一个大的产品方向管理，但似乎没有细化到一个集中式的需求管理，iOS、Android、H5是自己管理自己的需求，开发人员也是自己处理自己的模块。
这个自然是好的，充分给予开发人员灵活度，看的出来LeanCloud的工程师也都很厉害，但是作为一个跨平台的产品，如果没有一个集中大脑，带来的问题不是代码是否优雅的问题，而是产品一致性问题。
我个人觉得LeanCloud产品不错，只是从中看到一些问题，希望能与工程师们交流一下。
