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

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

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

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

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

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

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

逻辑和沟通能力是全部IT从业人员的基础能力，也是团队协做的基石。

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

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

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

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

架构师和产品经理的交叉点，是对产品需求的系统构建（将来产品的模样）的共享以及版本规划的现状和将来，以便架构师能为将来产品的模样预留足够的发展空间和技术架构平衡点的选择。产品经理要理解架构师的技术架构设计的平衡点，以及非功能需求的技术约束【知足产品需求仍是技术的首要任务，技术路线选择要先知足业务需求，而后体现优点】。以便理解从需求到技术实现的一些约束和优点。以便在后续中产生有本身产品竞争优点的功能实现。因此要求产品经理有必定深度的技术理解能力（对产品可开发、可设计及公司资源可承受的可行性了解）。

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

架构师在技术团队的做用

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

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

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

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

架构师如何应对业务变化

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

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

---

原创文章，转载请注明出处