转载

技术角色论系列：从一个架构师的角度看产品

架构因为复杂和规模增长而存在。复杂意味着功能和结构的变化和相互影响，是一个动态的过程概念。架构的逻辑开始于产品，着力于使用IT技术实现功能逻辑（业务逻辑）和非功能逻辑（安全、可靠、健壮、可维护、可移植、可重用、可扩充等）。

一个产品的IT技术实现可以不需要架构师，无非是持续的人力投入，专注于更多的业务逻辑，维护庞杂而难延展的系统。如同任何一个专业的岗位出现，都是当收益和成本之间达不到预期、甚至不能平衡的时候，就产生了利用既有的专业知识的累积来降低成本的需求，这是经济社会自然分工的规律。

很显然重复使用是降低成本的方式（建造和维护）。重复使用代码或功能（自己构建的、或第三方开源的项目）的前提是，代码和功能必须是为重复利用而设计的。就如同标准件才是可以拿来组装和构成新产品的，而非标准件只能存在于它被制造和使用的唯一场景中。在实际需求指导下，部分构成整体后引入的复杂性问题解决，也是架构师要面对的挑战。

优化软件性能是提高硬件投资的利用率、突破硬件扩展边际递减的方式。也是优化软件系统结构、优化算法、资源分配到高价值的部分以及突破系统瓶颈，这都需要一个更高的层次去检视技术实现。

从软件工程的角度，实施及时反馈调整开发资源的有效使用。测试驱动、敏捷短周期迭代开发、自动化测试、持续发布/部署等，都是常用的工程质量及效率的流程管理（开发过程管理在团队主管和项目经理这两个角色中介绍）。

架构师的能力和工具箱丰富多彩，架构体系、模块和组件、算法和逻辑、编程语言及运行环境、工程构建和维护，系统配置和健康监测，数据分析和调优等都需要各种能力和工具的使用。比如，对SOA, Microservices, Service Mesh ,Serverless 等架构的发展与理解，对开源项目的优缺点的理解及使用，对设计模式的理解及灵活应用，对编程语言的发展及了解，对云服务大数据平台的应用及了解，对CI / CD/ Docker 应用等就不一一列举了。

逻辑和沟通能力是所有IT从业人员的基础能力，也是团队协作的基石。

架构师和产品经理的交叉点

产品经理是一个产品上下游关系的关键岗位，优秀的产品经理市面上也是稀缺的。产品经理的能力需求有，用户调查研究、竞品分析借鉴、需求管理（需求的系统化构建，未来产品的形式可能性，非功能需求的技术理解力），版本规划（产品的阶段划分，每一个阶段交给用户的模样，具备一定的完整性、可用性），数据分析，产品工具（原型、交互、业务逻辑、需求文档等）使用。逻辑和沟通能力在这个岗位上显得特别重要。关键岗位，关键职责，也承担产品成败的关键责任。是否存在低价值需求消耗高成本技术团队，产品版本功是否错过恰当市场时机的决策在这个岗位上都有一定的决定权。

当然也有极端做法，那就是什么功能都要（没有需求分析，没有功能优先级，没有版本规划）作为需求，把产品责任都交给技术团队。一个产品的存在，一定是满足一定数量用户的特定场景下的需求，用户数量不足和场景需求不能满足，或不具备竞争力，都是赔本买卖。这里说的是产品价值，能给用户带来什么价值？为什么用户要选择使用该产品？产品解决了市面上已有产品的什么缺陷（也就是产品的竞争力）？这都是开始做一个产品，要回答的基本问题。

竞争无处不在，产品要和它出生以前的产品竞争，也要和它未来的潜在对手竞争，还有非同行业产品对本行业的影响(Side Effects)。比如手机的使用减少了零售行业收银台摆放小物品的销售（付款排队时，吸引用户关注力的竞争）。初创企业（应用型，非原创技术型）在资源、人力、专业技能上都没有优势，在产品创意、激励制度创新、团队精神上倒是有船小好掉头的灵活性优势，但在试错上没有资源能消耗的起。熟读战争的艺术（《孙子兵法》英译名）还是很有帮助。

架构师和产品经理的交叉点，是对产品需求的系统构建（未来产品的模样）的共享以及版本规划的现状和未来，以便架构师能为未来产品的模样预留足够的发展空间和技术架构平衡点的选择。产品经理要理解架构师的技术架构设计的平衡点，以及非功能需求的技术约束【满足产品需求还是技术的首要任务，技术路线选择要先满足业务需求，然后体现优势】。以便理解从需求到技术实现的一些约束和优势。以便在后续中产生有自己产品竞争优势的功能实现。所以要求产品经理有一定深度的技术理解能力。

架构师在自己的领域，参考产品规划，产品功能和非功能需求，根据自己的经验和行业通常做法，做架构设计和具体设计，本着“抽象约束，封装变化”的原则，提供系统应对复杂和规模增长的能力。

架构师在技术团队的作用

架构是结构和愿景的综合，结构体现了复杂的分解，同时展现了系统未来的模样。充分展示和详细讲解，让开发人员理解实现细节中的约束如何反映整体架构的意图。松耦合的简单约束更多体现在系统级别，模块化内的结构性约束可能会更具体一些。所以沟通和逻辑能力在架构师岗位上很重要。

应对复杂，降低开发和硬件成本是架构师最重要的作用，重复利用和适应新变化是美好追求，相应的提高标准化和性能优化的能力要求，技术流程、正向激励等都需要管理者提供支持。架构师自然的分工出现，体现一个团队和产品的阶段性发展阶段，是团队和产品内在需求的推动。

测试从进入开发阶段开始，单元测试、功能测试、集成测试、系统测试、压力测试、性能测试、验收测试，部署时smoking测试等，测试是保证质量，检查系统瓶颈，验证系统设计指标是否达成的手段，也是架构师要重点关注的部分，测试涉及的测试用例设计，测试边界，测试环境，自动化测试，测试Bugs/报告等知识，会在测试经理和团队主管这两个角色中介绍。

架构师在有些团队里只体现了高级程序员或项目经理的角色职能，或者说团队和产品还没有到需要架构师的自然分工阶段。这并不利于技术团队产生内驱的能力来提高要求，也达不到增加架构师岗位就能产生的预期效果。引入架构师岗位，意味着技术管理和开发人员提高能力的整体意愿升级（创业技术团队主管兼职架构师的角色，在能做好两个角色的前提下，产生的强推动力是值得鼓励的）。

架构师如何应对业务变化

在成熟行业或场景中，约束条件和发展方向已经固定，过往经验已足够应对业务的变化，这里就不涉及了。对于创新性业务的变化，意味着约束和发展方向都在探索中，或者直接就是产品经理角色缺失，寄希望于市场对产品的反向重塑，这是个巨大的挑战，成本也相对比正向产品塑造来的大，在竞争中失败风险也大，毕竟乱拳打死老师傅的前提是大家都失去理智。

我的经验做法是，先不设约束，也不做架构设计，力求快速实现，跟踪用户使用数据，提炼核心功能。核心功能稳定后尽快模块化服务，并独立出去发展。成熟一个独立一个，及时地少量适度粒度的标准化接口，实现各功能组合的灵活性。合理安排模块抽象封装、代码复用、关键优化，适度控制标准化程度和个人习惯的协调（强制和灵活的平衡，人的能动性和制度的强约束性平衡），把握开发节奏和系统维护效率，维持团队的高效激励机制，并在过程中祈祷用户有足够的耐心、市场给你留下足够的改进时间。

原文 https://juejin.im/post/5d2c0905e51d455ca04362f8

正文到此结束