技术问题
通用性 vs 价值产出
做通用性的平台往往成形较慢，不能及时满足业务需求。
解决办法：带着业务的痛点问题来做开发，在此基础上再考虑如何构建通用的解决方案来适配其它业务。简单说，就是采用通用＋适度定制的方式来快速推进平台的构建，不怕做得不通用，就怕通用到没有业务可以适用。
系统之间依赖较多 vs 迭代演进
各系统之间依赖较多（相对），迭代演进负担较大
解决办法：尽量考虑保障系统具备灰度发布的能力，依赖多，出问题难以避免，关联系统多，系统更新可能也无法一蹴而就，那就尽可能减少变更过程的风险代价，知错就改还是好孩子，别做一锤子买卖。
通用性 vs 易用性
一个通用平台，或者，不满足业务方的定制需求，让业务方抱怨流程长，操作复杂，工作各种不高效。或者，把各种需求都拼进来，但是一个不小心，一堆旨在提供便捷的功能，反而会让系统变得更加复杂，最终的结果就是导致整个系统不再便捷。所以，简单和通用往往是矛盾的。
解决办法：一种可行的方式，是针对具体业务场景需求，在通用服务的基础上，二次垂直封装，适度定制和简化业务流程，从通用系统衍生出操作向导或者专用系统，来屏蔽和特定业务场景无关的系统复杂性。不过，代价当然也有，那就是你又多了一个系统，一层依赖关系需要维护。
服务问题
由俭入奢易，由奢入俭难
一旦用户对你的定位认知是服务提供者， 那么从情感上说，用户一定会希望你的服务尽善尽美，搞定一切，从理智上来说，多数用户也能够理解服务的构建不是一蹴而就的。但人天生就有以自我为中心，高估自己的需求，低估它人的困难的本能。所以这里关键是如何与用户的认知达成一致。首先，你要明确你所提供的服务的范围定义和质量约定，然后，要尽早和用户达成一致。
服务越多，支持的代价越高
需要考虑将运维手段工具化，最佳实践文档化，另一方面，你可能需要一个专家系统来帮助用户诊断问题。总之，服务做得多固然好，但做完一个服务，就能撒手不管一个服务才是做服务的最高目标。
服务的快速迭代改进和服务的稳定可靠
必然是矛盾的。这个矛盾无法解决，只能缓解。我能想到的方法也只有：
如果可能，制定班车式开发计划，按固定的周期和预定的计划更新系统，如非必要，不做火线更新.
提前沟通, 就可能影响，明确告知，宁滥勿缺，Again，这又是一个预期管理的问题。
影响面大的变更，如果必要，确保你有灰度过渡和回滚的方案。事前的沟通很多时候因为各种原因，不能触达用户（比如用户不在意，或者在没实际执行前，压根没仔细想会不会有问题等等），那么过渡和补救的手段就很重要了。
用户诉求vs开发需求
就这一点，我很赞同一个说法：凡事可以坚持原则，但是没有必要苛求立场。
多数情况下，你和用户的诉求冲突，并不是目标，而是在实现这个目标过程中的遇到的问题。或者说，由于立场的不同，你们的侧重点是一件事的不同方面。
比如，用户在意自己的作业跑得快，而你在意它不要影响其他人，希望集群的整体效率高。用户希望便捷，你希望安全。本质上，这些都是两件独立的事情，但最终目标，其实是一致的。所以他们未必非要冲突。只是，如何兼得，有时的确很困难。
所以，怎么办？动脑筋，讲道理呗，没有必要追求大家对所有工作真心赞同，求同存异，解决核心矛盾，寻找一个双方都可以接受的妥协点就好，这个妥协点一定存在，如果没找到，要不方案不够好，要不道理没讲够 ；）
Ref：彩色蚂蚁，跪直了，别趴下！关于构建服务化数据平台若干问题的补充
网友评论