架构师的产品思维

工程师要以产品经理的角度思考问题。代码最终要变成产品，通过产品来提高服务。如果用户不接受产品，那么再好的代码也没有实际用途。如果一个架构师只关心程序的性能和实现，那么他只是一个好的程序员，却不能成为一个优秀的架构师。

利用代码实现程序只是手段，不是我们做产品的目标。我们的目标是软件对用户有帮助，可以解决用户的痛点。所以一个架构师要有产品思维，从产品的角度去思考程序设计，理解产品需求。

一 体验业务

架构师也要像产品经理一样，多体验自己的产品，关注运营数据，查看用户的反馈，收集社区中用户反馈的痛点。

1 通过体验业务验证服务是否正常

作为架构师，我们可以从技术角度发现产品经理体验不到的问题。有时系统会做一些柔性设计，当系统出现一些异常时，用户侧却表现正常，这就导致某些场景下看似正常，实际上是通过柔性设计隐藏了问题。

2 通过体验业务增强工作的成就感

当真的看到自己设计的后台支持了海量用户进行通信、海量玩家进行游戏时，会觉得自己的努力没有白费 。通过实际的场景来观测系统实现的价值，有利于增强工作的成就感，激发热情。

另外，我们除了是架构的设计者，也可以是一个普通的用户。以普通用户的角度体验产品，如果发现问题，则可以快速反馈给开发人员尽早修改。如果开发人员自己都不体验自己的产品，开发的产品连自己都打动不了，那么怎么去打动千千万万的用户呢？

3 关注运营数据

架构师除了关注服务的性能数据，比如 CPU 负载、内存容量、网络带宽、磁盘容量、系统的访问量、时延统计等，也要像产品经理一样关注运营数据。

通过对业务数据的了解，明确自己设计的架构的意义。另外，通过一些数据指标也可以知道未来产品的导向。开发人员也可以自己思考一些需求，基于对技术的了解，知道哪些功能是容易快速实现并能快速解决问题的，提出这种事半功倍的功能是架构师的一大优势。

二 体验竞品

竞品和我们的产品实现一样的功能，大家殊途同归，面向一个目标。我们要从竞品中学习和借鉴，提高我们的产品质量和服务能力。

多体验竞争对手的产品，才能知道竞争对手最近的打法，他们有什么创新，什么地方比我们强，什么地方不如我们。

开发人员体验竞品有一种优势，就是“透视能力”——通过产品的外在表现和使用反馈推断出产品是如何实现的，有什么局限，有什么地方是可以借鉴的。

根据产品的特点寻找最适合自己的产品体验来弥补不足，不可以一味地照搬全抄，因为有时产品的形态相似，但产品的使用场景不同。

体验竞品可以激发潜能。例如，我们很久都解决不了的问题，竞品给解决了，而且还解决得很好。即使不知道竞品的处理问题的方法，也可以确定该问题具有可行性的解决方案。体验竞品能够增强我们寻找解决方案的信心，也能够激励团队持续寻找解决方案。

三 扬长避短

在评审需求的时候，产品经理会从产品体验的角度来提出意见。但技术是有约束的。不是所有的需求都能实现，这样就造成了产品经理和技术人员之间的矛盾——产品经理认为技术人员实现不了需求，技术人员认为产品经理提出了无理的需求。

但具有产品思维的技术人员会把技术约束给产品经理讲明白。同时，也会理解产品经理的本质诉求，能够提出有效方案，避免技术约束。有时，技术人员也能提出修改产品的建议，提高产品的稳定性，避免上线遭受损失。

四 控制欲望

架构师不要仅从技术角度思考问题，还要从产品功能出发来设计架构。架构师设计系统架构最终是为了实现产品的功能，而不是为了炫技。所有的设计和决策的最终目标是为了满足用户需要，不要本末倒置。

在设计系统架构的时候，要从实际需要的角度选择相应的技术和组件——选择成熟的组件，而不是最新的组件，也不要为了提高个人某种技能而选择某种技术。

五 献计献策

开发人员可以从工程的角度为产品提供新思路——产品经理和开发人员互相学习交流，才能够产出更好的产品。

六 反哺方案

具备产品思维后，开发人员在实现业务需求的时候，也会从本质需求来思考最简单的解决方案，而不是找到一种方法后就用这种方法实现需求。

1 用户背后的真正需求是什么，解决问题的方法并不一定很难

2 是否是一个真正的需求，是否有所取舍

例如，一个需求是做一个内部客服 Web 系统。如果实现一些桌面端软件的操作功能，则需要使用比较新的前端库，不一定所有浏览器都兼容该系统。所以让客服把浏览器都升级为最新版就能保证系统是可用的。如果出现什么问题，那么让使用系统的用户把浏览器升级到最新版本，而不是通过技术开发来实现兼容全部浏览器的需求。

3 对用户友好一点，给出好的提示

开发一个系统，出错弹窗是避免不了的。好的产品在出错后会给出正确的提示，并且有进一步自助解决的方式。

例如，用户已经提交过一次资料（成功了），如果第二次又提交了相同的资料，那么直接返回提交成功即可，不用返回失败。因为用户的目的已经达到了，这时尽量不要麻烦用户。