一些思考
做为系统架构师入职有一段时间了，虽然磕磕绊绊，总体来说还算有一些进步；
这里也梳理一些思考，既做总结，也为后面行事方式提出一些想法；
首先就是业务研发人员和架构师的工作职责区分；
业务研发人员，工作职责倾向于业务需求实现，着眼于项目如期、有质量交付；架构师，工作职责倾向于业务需求确认，评估业务当前的、未来可能的演进状况，给出合理的系统画分、边界职责、开发规范；着眼于提高团队研发效率、保证系统的可扩展性；
一度我还是一厢情愿的想二者不应独立来看，无论从个人成长、团队整体绩效，二者应该职责合一；后来慢慢发现现实很骨干；这其中的原因，我总结如下：
- 人各不同，理解问题的视角、层次不尽相同，也无法苛求一致；
- 业务需求实现研发和架构合理化演进在某些层面的认知可能存在冲突；
有的人意愿沿用规则，有的人意愿创造规则；有的人被动适应变化，有的人能主动创建变化；个人的视野、思考问题的深度是受限于个人的认知；对待团队成员我们不能像对产品一样统一规格要求；这里不展开叙述；
业务需求研发强调按时按量交付，架构合理化强调研发提效和未来扩展可能，二者在某些层面可能带来冲突；症结是技术需求和业务需求在某个时刻的矛盾（注意是某个时刻）不可调和；例如技术需求带来额外的工作量，在不能投入更多资源的时候，可能会耽误业务按期交付等；
那么，二者分工带来的好处就显而易见；但二者的组织归属又有两种形式：同组织和不同组织，各有利弊；
同组织，也就是说架构师和业务研发团队同属一个组织；有一个好处就是统一背负绩效，容易形成合力；弊端就是架构师容易陷入业务团队背负的绩效压力，没有外力的情况下可能忽视自己的职责，也很容易被一些现实处境捆绑；不同组织；这样的组织架构好处就是各背绩效，各自负责，分工明确；带来的问题就是需要组织间通力协作，绩效层面统一，才可能会有结果；往往可能还需要更上一级的压力；另外组织间可能还会形成某种层面的『对抗』；
架构师不能脱离业务，否则筑建的就是空中楼阁；必须对业务熟知、深刻理解当前的问题痛点；在复杂的业务中抽丝剥茧，找到核心逻辑；既要相信自己直觉的，也要能听取不同见解，要做到『坚持』而不是『固执』；
很多时候，技术方案不是『那种拿出来就能一刀毙命』的东西，它需要在团队中形成共识、共情，才能思路一致；而很多基本的『常识』或者说『通用化』的构建思路，没有可讨论的余地，应该坚持做下去，要做的就是需要把弊端讨论清楚，可能遇到的问题以及遇到了如何解决；
对自己提的要求：
- 首要坚持的依旧是业务为本，无论什么时候都不能丢弃；
- 团队活动中，人是最主要的对象，使用『恰当』的沟通词语，减少『误会』；
- 可以在业务团队内部组织类似于『对系统未来的畅想』的活动，追求更多的一致；
架构师也是人，也会犯错，但还是尽量少犯错，既影响个人公信力，也对工作开展不利；