软件工程项目管理基础架构图

先上图为敬，后面篇幅为本图的简要说明

基础工作项

以下是软件研发中必做的基础工作，每一项都输出可执行的文件，不对具体形式有明确要求，可以依据项目管理工具、可以是office或纸质文件等，输出的内容是软件研发过程中的重要依据，可以避免口口相传、信息缺失、混乱，各执一词的情形，同时也作为工作量证明、工作成果。

需求评审

需求评审的主要目的是确定可行性，需求内容，不限于使用原型、文字、动画、视频等可以描述需求的文件来确定需求。

第一步：原型设计

第二步：输出需求规格说明文件

需求评审工作重要指标

1、调研阶段与客户沟通达成一致，落实到文件

2、研发阶段有清晰的任务安排和进度把控，落实到文件

3、需求变更任务可以获得一个较为准确的变更成本，落实到文件

软件架构

第一步：选定技术体系、产品体系

第二步：划分模块、表设计

第三步：输出参数说明文件

软件架构重要指标

同类功能应当复用基础代码库，未复用的应该给出不适用原因

模块间不应存在循环依赖，数据库设计应当遵循业内规范。

统一编码风格，降低沟通成本，未能统一的应当出具说明文档。

代码走查

代码走查是唯一有效帮助企业解决经验各不相同的程序员但可以输出相同高质量代码的途径，是做团队效能量化、个人效能量化的基础。

第一步：选择一个业内广泛认可易于执行的代码规范，比如阿里巴巴代码规范，在编码过程中可以实时帮助程序员遵守规范，规避潜在BUG和设计缺陷，也可以分模块输出代码质量报告。

第二步：确保团队成员代码风格一致，减少沟通成本，避免重复造轮子。

第三步：确定业务模块、表设计的合理性。

第四步：输出代码质量报告文件

代码走查重要指标

在软件开发基础规章制度遵守的前提条件下、通过工时能够合理、公平的量化个人效能。

通用的功能应当归纳到基础代码库或产品。

运营维护

第一步：确定交付范围，以上任务分解中的每一个任务都可以约定细节来指定交付范围，这取决于主客方面的约定。

第二步：形成运营维护记录，可以归纳为运营维护成果。

团队角色

以下角色是对工作项的简单划分，不对人员数量及工种负责。

项目经理

项目经理是整个项目直接负责人，考虑到很多大型项目的项目经理非技术出身，所以完成各个工作项通常需要配备对应的技术人员，在以上基础工作项中，软件架构和代码走查严重依赖于经验丰富的工程师，所以技术经理是应运而生的角色。

工作项：需求评审，可兼任技术经理工作

技术经理

技术经理角色是整个软件工程的中枢，对产品的各个功能的完善程度有着精确的了解，把控各类开发资源配比。

工作项：软件架构、代码走查、可兼任项目经理工作

开发者

开发者是依照各类指标文件实现产品的技术人员，包括产品设计师、交互工程师、后端工程师等

工作项：依设计指标文件、实现产品。

番外篇：工作不到位的困境

根据各工作项的基本原理和职能，任何一项的缺失和完成度不到位就会导致严重后果，轻则成本增加，重则项目衰亡。满足基础工作项可以输出合格产品。

需求评审的缺失或不到位

危害一：项目经理无法把控项目整体进度。

危害二：根据熵增原理、项目会越做越混乱，一定程度上影响代码质量。

危害三：与主方产生扯皮且不利于团队协作。

代码走查的缺失或不到位

危害一：代码质量严重依赖开发者水平。

危害二：根据熵增原理，代码会越来越混乱，显著增加开发成本，直至项目衰亡。

危害三：通常难以适应需求变更，经验不足的开发者甚至难以完成需求。

走出困境

        没有带不好的兵，只有不会带兵的将，发生问题后最忌讳的是互相推诿，损其根本。所以走出困境首先项目经理需要反思：有没有系统化的做工程，哪些工作没有做到位导致出现的问题，将来如何避免，而不是先找谁的责任。因此走出困境首先要建立以上工作机制，并评估各个工作项目的完成度。

       一个企业输出合格，可控的产品并不难，难的是商务费劲心力的承接项目。虽然公司的技术高度取决于技术水平，但是行业内现存的大量规范准则、开源项目足以让咱们的项目经理输出合格的产品，只需要按套路完成各个工作项。

        大部分企业的项目经理分为技术型和业务型，针对技术型经理需要技术总监给技术型经理统一安排培训，建立基础工作项机制，输出的各个工作项文件要形成套路，而不是应付，比如如何制作清晰的需求看板，合理的任务分配等。针对于业务型经理在职责范围内的工作项达标的前提下，安排项目技术骨干负责技术类型的工作项。