Thoughtworks洞见

做商业模式转型，我们需要真正理解的是背后客户所期待的价值，理解这种价值，需要理解客户本身的行为和生活变化，理解变化根源才能设想解决方案，而解决方案会因人而异。

数据智能是一个领域，技术架构是实施方案，我们很难从好或者不好的维度去衡量一个架构，更多会从当下是否具有合理性，以及在可见的未来是否具有合理性的视角，来看待当前架构是不是一个最佳的选择。因此没有坏的架构，只有是否是当前上下文中最合理的架构。

一个合格的产品经理，需要理解基础的技术知识 + 把握用户需求。而对于不同类型的产品经理来说，所需要懂技术的程度也是不一样的。

我们在讨论性能优化的时候，一个经常被忽略的因素恰恰是软件本身的设计。不过经过这几个月对某组件库中十多个组件的重构之后，我们发现这两部分工作在很大程度上是同一件事的两个方面：好的设计往往可以带来更好的性能，反之亦然。

这样的美好希冀或许前路漫漫，但我相信对自我的认可以及坚持一件事情的勇气与毅力，可以让一切不可能变成可能。

虽然我做了大量的时间与资金开销记录，但我也很难评估这些开销对实现长期目标有何影响。这种困扰可以看作个人时间管理的哥德巴赫猜想：我知道我的时间有一半都被浪费掉，但就是不知道哪一半。

本文分析了微服务间身份认证和令牌管理的系统自身鉴权，API网关鉴权和authentication sidecar的方案，痛点和好处。

一个成功的数据平台建设的过程。

项目管理画布是商业模式画布的变化形式，它能帮助项目管理者在项目的启动之初以及整个项目生命周期对项目的关键信息进行系统的梳理和可视化的展示。

在面临隐私保护相关问题时，要从经济、法律和技术三方面入手，建立不断演化的安全攻击和防范体系，技术方面需要强化隐私相关技术的应用，从数据流动的角度，动态审视当前的安全策略。

精准测试不是银弹，需要巨大的投入，用的好，能够成倍的提升质量，生产效率，用不好的话，就成了领导的KPI项目，弃之可惜，食之无味。

DDD初学者最容易迷惑的概念就是应用服务和领域服务。因为一般来说代码只会有一个服务层，什么逻辑都往里面放。如果突然告诉他们还有应用服务和领域服务之分，自然是一头雾水。

相当长的一段时间内我都对在开源项目网站上进行商业露出的行为感到厌恶，认为这不过是将流量兑现的把戏罢了，但时至今日我才意识到这可能只不过是开源项目在做默默的挣扎而已。

管理者，不必是一个专家，但一定能带领团队找到方向；不必时时和蔼可亲，但是需要客观公正；不必是事必躬亲，但需要人尽其用，才尽其专。

没有数据分析师，不管一个企业中的数据管理做得有多么好都没用，都无法带来实际的价值。这些数据就像是藏在海底的石油，而数据分析师就是开采海底石油的油井设备。