一些思考

做为系统架构师入职有一段时间了，虽然磕磕绊绊，总体来说还算有一些进步；这里也梳理一些思考，既做总结，也为后面行事方式提出一些想法；

首先就是业务研发人员和架构师的工作职责区分；

业务研发人员，工作职责倾向于业务需求实现，着眼于项目如期、有质量交付；
架构师，工作职责倾向于业务需求确认，评估业务当前的、未来可能的演进状况，给出合理的系统画分、边界职责、开发规范；着眼于提高团队研发效率、保证系统的可扩展性；

一度我还是一厢情愿的想二者不应独立来看，无论从个人成长、团队整体绩效，二者应该职责合一；后来慢慢发现现实很骨干；这其中的原因，我总结如下：

有的人意愿沿用规则，有的人意愿创造规则；有的人被动适应变化，有的人能主动创建变化；个人的视野、思考问题的深度是受限于个人的认知；对待团队成员我们不能像对产品一样统一规格要求；这里不展开叙述；

业务需求研发强调按时按量交付，架构合理化强调研发提效和未来扩展可能，二者在某些层面可能带来冲突；症结是技术需求和业务需求在某个时刻的矛盾（注意是某个时刻）不可调和；例如技术需求带来额外的工作量，在不能投入更多资源的时候，可能会耽误业务按期交付等；

那么，二者分工带来的好处就显而易见；但二者的组织归属又有两种形式：同组织和不同组织，各有利弊；

同组织，也就是说架构师和业务研发团队同属一个组织；有一个好处就是统一背负绩效，容易形成合力；弊端就是架构师容易陷入业务团队背负的绩效压力，没有外力的情况下可能忽视自己的职责，也很容易被一些现实处境捆绑；
不同组织；这样的组织架构好处就是各背绩效，各自负责，分工明确；带来的问题就是需要组织间通力协作，绩效层面统一，才可能会有结果；往往可能还需要更上一级的压力；另外组织间可能还会形成某种层面的『对抗』；

架构师不能脱离业务，否则筑建的就是空中楼阁；必须对业务熟知、深刻理解当前的问题痛点；在复杂的业务中抽丝剥茧，找到核心逻辑；既要相信自己直觉的，也要能听取不同见解，要做到『坚持』而不是『固执』；

很多时候，技术方案不是『那种拿出来就能一刀毙命』的东西，它需要在团队中形成共识、共情，才能思路一致；而很多基本的『常识』或者说『通用化』的构建思路，没有可讨论的余地，应该坚持做下去，要做的就是需要把弊端讨论清楚，可能遇到的问题以及遇到了如何解决；

对自己提的要求：