研发管理系统的业务架构与技术架构是怎样的？

kekek

1 B0 ]6 R9 P0 w" E4 j

• 从业务架构来说，通常涉及几个方面：团队划分，工程流程 ，管理流程 还有一些支撑的流程。
  $ K2 l0 w' _' S: N7 f

团队划分通常会有两个维度： 一个是专业能力的维度，比如po,ba,sa,java团队，测试，安全等等。 另一个就是各个系统/子系统 的团队了。 这里面就涉及到组织的管理风格和资源情况。 有些组织里，资源是优先按照系统构建开开发团队，然后再从资源/技能共享角度构建一些专业能力团队，比如java团队之类的。 还有些组织一开始就是按照专业组织资源，然后再抽人组建成系统开发团队。  
有时候为了进行一些特定领域的控制处理，也会成立一些技术组，比如专门针对某类型数据进行集成的小组，专门写接口的， 专门做某个共享技术平台的。  不同的组织有不同的问题，没有什么特定的模式。
1 z: {; A9 O2 u, g' @; x然后为了做好整体管理，通常还会设置几个跨系统的专业辅助团队，有时称为tmo 和 pmo，负责技术管理 和 项目群管理， 其实就是帮助老大做一些整体性的决策。
还有一些组织如果开始实施cmmi或者整体敏捷之类的组织持续能力提升工作，通常还会出来一个工作组，cmmi里面叫epg，是负责流程持续优化分析，通常就是围绕本问题的两个核心来开展工作， 这个软件团队要改进哪些流程，要设立什么工具。
3 F& Q; d/ W1 i从流程来说，会有两个比较大的流程，一个是工程流程，就是如何从需求到上线的这个工程过程。 涉及软件工程学的了，如何分析需求，如何设计，如何开发，如何测试，如何部署等等。 还有一个是项目管理流程， 就是讲清楚团队中各个管理层级的人如何做好各种的pdca 管理循环吧。 目标计划如何由上往下分解，执行情况如何由下而上的汇聚，各种类型问题的决策步骤。
0 T* s6 b& s$ x% ]- v( n  j对于大型项目来说，这两个流程的实施的顺利与否都涉及到一个很重要的模型，就是系统架构模型。如果大型软件没有好的架构团队对系统进行分解，就无法为工程流程和管理流程提供一个合适的分工框架。 这也就是为什么架构师显得特别重要的原因。可以把管理团队看到是上半身， 工程团队看着是下半身，架构团队就是腰了。
. a& X1 p2 C7 T  E. Y! w( i- ~其他还有一些支撑流程，比如配置管理，质量过程保证，度量之类的。这些流程在团队规模小的时候看起来不重要，但团队规模大了就很重要了。
! b5 n+ f; M( v7 u/ c; a当然，作为一个大型团队，任何团队的基本管理框架也是必不可少的，人员管理，绩效管理，资源管理等等。
7 g, k) `. ]  Q1 c7 {; `一个好的研发管理系统， 起对于目标系统的架构设计， 团队组织结构，管理流程和工程流程，还有支撑流程应该是一致的。 否则就会感觉乱乱乱，乱的一个现象是，如果老大能干，很多问题就都找老大。 如果老大不能干，大家就各行其事。 决策靠吵架了。
+ T( x% @& P' I' p0 K
: |# D( y. N9 Q) d3 Y然后说说技术架构吧，技术架构就是考虑如何找到好的工具把前面讲的工程流程和管理流程给支撑起来的。 目前在数字化转型领域有个比较流行的话叫开发工具链。
简单来说， 从devops出来后，以代码为核心的一段，代码到集成测试到部署这段是整合了不少。
但软工前期的以需求为核心的需求收集和分析段，以模型为核心的设计图案，都还没有什么太好的工具。 原先有些case工具，也都不太好用。
+ K* V) s- `0 [; O7 M: b! I然后就是工程工具和 项目管理工具的集成了，有点类似于制造业中erp 和 mes的集成了。
还有些组织会把项目管理的和组织职能管理（如hr/财务/工作流）也整合起来
2 f8 R7 i! I, g; u. T$ [1 [一个组织中如果要把这些工具整合起来按照自己的设计的业务流程跑起来，是需要下蛮大的功力的。
% \; B( c5 }; P0 D这里有一个模型可以参考一下
! s$ V0 v% Q0 d, I

llbnmo

任何团队的基本管理框架也是必不可少的，人员管理，绩效管理，资源管理等等