技術問題
通用性 vs 價值產出
做通用性的平臺往往成形較慢，不能及時滿足業務需求。
解決辦法：帶着業務的痛點問題來做開發，在此基礎上再考慮如何構建通用的解決方案來適配其它業務。簡單說，就是採用通用＋適度定製的方式來快速推進平臺的構建，不怕做得不通用，就怕通用到沒有業務可以適用。
系統之間依賴較多 vs 迭代演進
各系統之間依賴較多（相對），迭代演進負擔較大
解決辦法：儘量考慮保障系統具備灰度發佈的能力，依賴多，出問題難以避免，關聯繫統多，系統更新可能也無法一蹴而就，那就儘可能減少變更過程的風險代價，知錯就改還是好孩子，別做一錘子買賣。
通用性 vs 易用性
一個通用平臺，或者，不滿足業務方的定製需求，讓業務方抱怨流程長，操作複雜，工作各種不高效。或者，把各種需求都拼進來，但是一個不小心，一堆旨在提供便捷的功能，反而會讓系統變得更加複雜，最終的結果就是導致整個系統不再便捷。所以，簡單和通用往往是矛盾的。
解決辦法：一種可行的方式，是針對具體業務場景需求，在通用服務的基礎上，二次垂直封裝，適度定製和簡化業務流程，從通用系統衍生出操作嚮導或者專用系統，來屏蔽和特定業務場景無關的系統複雜性。不過，代價當然也有，那就是你又多了一個系統，一層依賴關係需要維護。
服務問題
由儉入奢易，由奢入儉難
一旦用戶對你的定位認知是服務提供者， 那麼從情感上說，用戶一定會希望你的服務盡善盡美，搞定一切，從理智上來說，多數用戶也能夠理解服務的構建不是一蹴而就的。但人天生就有以自我爲中心，高估自己的需求，低估它人的困難的本能。所以這裏關鍵是如何與用戶的認知達成一致。首先，你要明確你所提供的服務的範圍定義和質量約定，然後，要儘早和用戶達成一致。
服務越多，支持的代價越高
需要考慮將運維手段工具化，最佳實踐文檔化，另一方面，你可能需要一個專家系統來幫助用戶診斷問題。總之，服務做得多固然好，但做完一個服務，就能撒手不管一個服務纔是做服務的最高目標。
服務的快速迭代改進和服務的穩定可靠
必然是矛盾的。這個矛盾無法解決，只能緩解。我能想到的方法也只有：
如果可能，制定班車式開發計劃，按固定的週期和預定的計劃更新系統，如非必要，不做火線更新.
提前溝通, 就可能影響，明確告知，寧濫勿缺，Again，這又是一個預期管理的問題。
影響面大的變更，如果必要，確保你有灰度過渡和回滾的方案。事前的溝通很多時候因爲各種原因，不能觸達用戶（比如用戶不在意，或者在沒實際執行前，壓根沒仔細想會不會有問題等等），那麼過渡和補救的手段就很重要了。
用戶訴求vs開發需求
就這一點，我很贊同一個說法：凡事可以堅持原則，但是沒有必要苛求立場。
多數情況下，你和用戶的訴求衝突，並不是目標，而是在實現這個目標過程中的遇到的問題。或者說，由於立場的不同，你們的側重點是一件事的不同方面。
比如，用戶在意自己的作業跑得快，而你在意它不要影響其他人，希望集羣的整體效率高。用戶希望便捷，你希望安全。本質上，這些都是兩件獨立的事情，但最終目標，其實是一致的。所以他們未必非要衝突。只是，如何兼得，有時的確很困難。
所以，怎麼辦？動腦筋，講道理唄，沒有必要追求大家對所有工作真心贊同，求同存異，解決核心矛盾，尋找一個雙方都可以接受的妥協點就好，這個妥協點一定存在，如果沒找到，要不方案不夠好，要不道理沒講夠 ；）
Ref：彩色螞蟻，跪直了，別趴下！關於構建服務化數據平臺若干問題的補充