在需求输入的时候,架构师最头疼的是,需求太浅显,没有抽出需求问题的本质,如果按照需求的原意进行构建,就会没有重用性,总是一次性的解决问题,对于潜在问题的解决就没有兼容和扩展的设计考虑。有人会问,重用抽象就是架构师进一步的工作。这个问题忽略一个问题:架构是为业务服务,不是为技术服务的,架构的抽象的思路来源于业务及产品后期规划特征,在需求分析阶段不进行这方面的工作,架构师就需要重新从最原始的客户来源和市场的产品状态审视问题的本质,从而在进行一种模型定义,这个时候的需求,哈哈,说不准,基本的意图都发生了变化。
所以,好的架构师需要好的需求分析师的配合,才能设计出好的架构。架构师本身并不会独立考虑架构,他们会从业务模型中需求架构构建的平衡点。有时,一个好的架构师遇到一个蹩脚的需求分析师,忍不住就想自己做需求。可惜,公司的流程制度有不会要求这样处理,人才结构的错位,是大部分工作错位的基础。
现在的公司大部分知道需求的作用,从流程结构上,分解出需求分析师的岗位和角色,但合适的人才有很难胜任,但需求分析师具有许多决策权,而架构师却没有产品的决策权。反过来,如果架构师具有很好的决策权的话,架构师,就会影响和要求需求分析师用更深远的眼光来捕获需求和定义需求。
一个公司的高层技术管理者,首先应该是一个好的架构师师,一个好的产品规划师,其次才是一个好的需求分析师。好的架构师和产品规划师密不可分。架构师首要的任务,并不是解决技术问题,而是解决产品长期规划的支持问题,和公司的资源、战略规划紧密结合起来进行考虑。
所以,好的架构师需要好的需求分析师的配合,才能设计出好的架构。架构师本身并不会独立考虑架构,他们会从业务模型中需求架构构建的平衡点。有时,一个好的架构师遇到一个蹩脚的需求分析师,忍不住就想自己做需求。可惜,公司的流程制度有不会要求这样处理,人才结构的错位,是大部分工作错位的基础。
现在的公司大部分知道需求的作用,从流程结构上,分解出需求分析师的岗位和角色,但合适的人才有很难胜任,但需求分析师具有许多决策权,而架构师却没有产品的决策权。反过来,如果架构师具有很好的决策权的话,架构师,就会影响和要求需求分析师用更深远的眼光来捕获需求和定义需求。
一个公司的高层技术管理者,首先应该是一个好的架构师师,一个好的产品规划师,其次才是一个好的需求分析师。好的架构师和产品规划师密不可分。架构师首要的任务,并不是解决技术问题,而是解决产品长期规划的支持问题,和公司的资源、战略规划紧密结合起来进行考虑。