一、管控内部需求
- 1、业务理解
- - 1.1、理解业务，要准确、全面、深入
  - 1.2、识别重难点业务
  - 1.3、识别非功能需求和质量约束
  - 1.4、业务架构
- 2、如何明确业务需求
- - 2.1、基本思维方式
  - 2.2、做需求分析的基本方法
- 3、依托工具
- 4、成立甲方专家组
二、管控供应商交付质量
- 1、为什么要有软件供应商
- 2、制定标准
- - 2.1、细分领域
  - 2.2、制定供应商入围标准
  - 2.4、制定供应商考核淘汰标准
  - 2.5、制定项目交付的全过程管理标准
  - 2.6、统一编码规范
- 3、团队组建
- 4、开发计划
- 5、风险管理
- 6、进度跟踪
- 7、业务培训
- 8、代码审查
- 9、度量和分析
三、快速响应需求
- 1、交付模式
- - 第一类是产品化交付
  - 第二类是定制化交付：
- 2、高质量的团队
- 3、组件化
- 4、PASS低代码平台

一、管控内部需求

1、业务理解

1.1、理解业务，要准确、全面、深入

架构师在做需求分析的时候，对每一个功能点，一定要准确，要求理解到没有歧义，不可再分，基本要到最细粒度的操作，比如：新增、修改这样的功能。

1.2、识别重难点业务

拿到需求后，架构师要能识别出里面的重难点业务，对它们的分析和设计，可能会影响到后面的技术选型和具体的架构设计。
毕竟，软件只是工具，是用来帮助实现业务活动的工具；而架构设计是为软件服务的，是为了更好的开发和制作软件这个工具。
因此，对于重难点业务的把握，可能直接决定了架构设计的成败，一定要非常重视。

1.3、识别非功能需求和质量约束

非功能需求：就是除去业务功能需求之外的需求，通常也是软件质量约束的一部分，比如对系统：性能的要求、可靠性的要求、可扩展性要求、可维护性要求、安全要求、备份恢复的要求等等。
这些要求对于架构设计的影响是非常大的，很多都是架构设计要重点考虑的问题，比如：性能、可靠性、可扩展等等。

1.4、业务架构

这个通常是以产品人员设计的业务架构为主，但技术架构师需要在准确、深入理解的基础之上，按照技术人员能理解的方式，对业务架构进行微调，输出一个技术落地实现的业务架构

2、如何明确业务需求

2.1、基本思维方式

只是考虑：具体要实现什么、明确具体的展现形式
不去考虑：究竟如何实现
通常，架构师都是从开发人员升上来的，有些刚开始做架构的架构师，他的思维方式，还带着浓厚的开发人员的思维，一看到功能需求，脑袋里就全是代码，自觉不自觉的就在思考该怎么实现，就差把代码写出来了。
特别提醒，这个阶段是只考虑要做什么，而不考虑具体如何做。至于如何做的事情，是接下来的架构设计、详细设计等阶段要考虑的。

2.2、做需求分析的基本方法

明确系统边界
视角进入系统，按照大业务功能（子系统、业务模块）的方式，来理解这些系统的业务边界、业务功能和业务流程
如果把系统想象成是一栋大楼的话，视角就像是镜头，由远及近的推进。
角色扮演，采用模拟业务运转的方式加深对业务的理解
采用不断问问题的方式，进行业务挖掘和深入理解
不断进行功能分解，把复杂的、较大的功能，分解为颗粒度较小的功能，直至不可再分
对业务功能点：
（1）逐字逐句的去读需求说明书，读出显示的或者是隐含的功能点
（2）对这些功能点，进行从前台页面到后台功能，逐步进行明确，要到实现需要明确下来的地步
（3）换位思考
对业务流程
（1）把流程中的每个节点当做一个具体的功能来思考
（2）每个节点的角色是什么
（3）每个节点相应的页面是什么（页面流）
（4）节点要操作的数据的来源和去向（数据流）
（5）节点的启动条件和向后流转的条件（逻辑流）
进一步应用模拟业务运转的方式进行业务走查
对于不明确的、模糊的功能
（1）跟需求调研人员或者是产品人员讨论、或者再次跟用户讨论
（2）暂时搁置，明确后再做这部分
对于非功能性需求，需要尽量明确到指标，并准确理解相关的约束条件

3、依托工具

禅道、思维导图、业务流程图等工具

4、成立甲方专家组

二、管控供应商交付质量

1、为什么要有软件供应商

借助外部专业的IT团队来完成企业的数字化建设为什么一直受到客户认可，因为它解决了企业的三个核心问题：首先是成本过高。互联网技术有行业壁垒，企业需要另外组建团队，其中所涉及的不仅是人员成本，还包含试错成本和时间成本，一旦错过了软件上线的时机，损失的不仅是资金投入，还有被竞争对手反超的风险；其次是招聘难。相信接触过人事招聘的管理者最为清楚，在IT市场供不应求的环境下，招到合适的人才需要很长的周期，高端IT人才更是大海捞针；最后是人员管理难。非互联网行业想要管理IT团队需要很长的磨合期，期间还要面临人员流动问题。

总结起来，企业自建IT团队所付出的综合成本，要数倍高于寻求外部的专业IT团队。

2、制定标准

我们经常说一流公司做标准，二流公司做产品，三流公司做项目；

2.1、细分领域

数字化趋势不只影响着甲方企业的未来，同时也考验了IT服务企业的创新能力。我们从未停止对人才的培养和对行业的深入，为了应对数字化时代下客户的需求，完成从横向发展到纵向深入的战略升级，专注于数字教育、智慧医疗、新零售电商、数据可视化、在线学习平台、智慧园区6大细分领域，制定每个领域供应商的标准，每个领域都明确指定甲方的负责人和乙方团队，为企业提供高端、专业IT团队定制服务。正常情况下不建议一个开发团队什么领域都涉略。

2.2、制定供应商入围标准

公司规模、成功案例、团队能力、行业深度

团队能力里面，比如中级，高级不同梯度的人员比例等

2.4、制定供应商考核淘汰标准

制定考核标准，以及考核周期，考核团队；
可以从服务能力，团队能力，价格能力，履约能力，应急能力，信息安全，创新能力制定扣分标准。可以采取末尾淘汰

2.5、制定项目交付的全过程管理标准

可以使用CMMI3以上的管理体系，规范软件开发流程，，提高产品质量，进而而实现公司商业目标。
明确项目各个阶段的输出资料

2.6、统一编码规范

由于每个供应商的团队能力层次不齐，而且有些中大型项目周期较长，可能存在中途换供应商的问题。所以我们有必要对所有供应商统一编码规范，过程工具，版本发布流程等。

3、团队组建

与传统人力驻场的单一服务模式不同，为企业提供了按年度、按月度、按项目3种不同的合作模式，企业可以根据自身的数字化转型需求，进行灵活的人力资源配置，实现价值最大化。

大型项目综合开发团队定制
标准人员备配20人，平均工作经验10年左右，适用于进行大型项目开发的企业，以帮助企业推动数字化发展为目标，提供综合IT团队定制方案。
专业业务型开发团队定制：标准人员备配12人，平均工作经验7年左右，适用于阶段性实施数字化转型的企业，以帮助企业数字化高效落地为目标，提供专业的IT团队定制方案。
小而美敏捷开发团队定制：标准人员备配7人，平均工作经验5年左右，适用于进行中小型项目开发的企业，以帮助企业实现数字化建设为目标，提供敏捷的IT团队定制解决方
比如电科院项目，甲方问了高质量完成软件建设，分别从两个乙方团队中抽调精兵强将组建团队。

4、开发计划

在策划阶段，需要制定一个全面的并且可以指导团队贯穿项目执行和终止等各个阶段的操作路线图，还要在关键的节点设定截止日期。此外，还要做好资源的分配。将任务分解为更小且易于管理的活动，可以更轻松地管理风险、成本、质量、项目进度等。同时，将任务分解为可消化的部分将使每个参与者能够按时完成项目并保持在预算范围内。简单来说就是，明确项目优先顺序，然后进行计划和人员安排。

5、风险管理

在公司高层领导角色方面可能存在的风险分析
在CMMI项目管理过程中可能存在的风险分析
在开发团队实施CMMI过程中的风险分析
具体参考：https://www.sohu.com/a/538478897_121191967
问题跟踪。

6、进度跟踪

跟踪计划进度，跟踪问题整改进度

7、业务培训

乙方人员也就是所谓的外包人员，现状是人员素质参差不齐，流动性大；甲方可以定期组织培训，或者要求乙方做好培训和交接工作。

8、代码审查

可以组织多乙方团队相互审查

9、度量和分析

建立和维护度量目标
规定数据搜集、存储、分析的规程
搜集和分析度量数据
存储数据和结果
报告结果给干系人
其实就是制定KPI指标，考核，总结

三、快速响应需求

项目管理不是一件容易的事情，很多时候要平衡多方的利益，哪一边没照顾好，很快投诉就过来了。但不管怎么说，凡事都有优先级，关键干系人如用户高层和公司高层的需求通常是要最先需要去做的，那么对于软件项目的交付，从公司层面如何更好地响应需求提出方的需求呢？

1、交付模式

第一类是产品化交付

比如结合在行业多年的经验，打磨出一套所谓标准化的产品，直接在需求方提供的服务器换做快速化部署，或者把自家的云端软件开账户给用户进行使用。
这种模式的好处是能快速铺开市场，哪怕软件卖便宜点也没关系，量一上去了也能赚钱。缺点是当面向需求方定制化需求的时候，会缺少一些灵活性，一般会尽量说服需求方用自己的标准化产品，比如早期的金蝶和用友产品系统就是这种模式。
但如今面向企业和政府端的系统，这种模式越来越走不通了，现在的用户都需要有自己特色的定制化系统，要有能出去申报拿奖的亮点。

第二类是定制化交付：

很多刚进入到某个行业的企业，通常来讲都是采取定制化软件来和做产品化软件交付的企业来进行竞争。

从用户的角度，他们当然是欢迎做定制的，但对于软件供应商，定制通常意味着需要较长的开发周期和较高的开发成本，一旦控制不好或者研发能力不足，亏本赚吆喝是常有的事情。

以上两种模式各有各的优势和劣势，但无论你是产品化交付还是定制开发交付，假如需求方提出的功能在你的产品或过往项目中没有做过，那么快速响应的核心就是高质量的团队、组件化设计和开发，可以说没有比这更好的解决方案了。

2、高质量的团队

前面已经讲过

3、组件化

简单说就是当我们接到一项新的需求时，在原型、UI设计和开发层面都有一套组件库（或者叫模块库），能够快速的完成需求的设计开发落地。
单个的组件是通过一个一个的行业项目沉淀出来的可复用资源，组件本身经过了反复的质量稳定性验证，需求落地过程中通过组件和组件的快速拼装，从而达到快速响应软件新需求的实现。
比如搭建前后端的私有仓库

4、PASS低代码平台

平台即服务，提供一个基础平台（包含应用设计、应用开发、应用测试和应用托管等），用户可以基于平台自定义开发出自己所需要的应用和产品。相比于传统的开发方法，开发人员可自定义字段、对象、报表、工作流，可灵活设置用户的使用权限和对象数据安全性访问，支持所有对象数据的导入导出、数据批量删除和转移。PaaS平台大幅降低技术门槛，并显着提升开发者的开发效率。

低代码开发平台的价值

对开发者而言
图形化操作，容易上手；
提供成熟案例模板库，不用从零开始；
支持所有主流应用服务器和数据库，降低开发难度；
接口丰富，节省开发时间；强大的代码调试功能，提升开发效率；
对企业而言
优化流程，提升企业运作效率;
节省成本，提升企业效益;维护方便，即改即用;
一键升级，方便实用.
对使用者而言
操作简单、友好、人性化;
消息驱动，合理利用工作时间;
即用即改，优化完善软件功能;
多客户端入口，随时随地办公.

甲方IT人员管理办法实践相关推荐

国家互联网信息办公室公布《互联网新闻信息服务单位内容管理从业人员管理办法》【软件网每日新闻播报│第10-31期】
每一个企业级的人都置顶了中国软件网中国软件网为你带来最新鲜的行业干货小编点评互联网三大错觉 WP崛起索尼倒闭谷歌返华知情人士透漏谷歌新入华计划与搜索安卓无关人工智能是中心 ...
制度通用模板-数据安全组织建设及人员管理办法
数据安全制度管理体系-<数据安全组织建设及人员管理办法> 下面就全是干货,直接上内容!!!!!!! 第一章总则第一条为规范XXXX科技有限公司(以下合称"公司") ...
《演出经纪人员管理办法》修订发布
#营业性演出许可证#办理经纪人员是办理营业性演出许可证的必备条件之一,为加强演出经纪人员队伍建设和管理,促进演出市场繁荣健康有序发展,近期,文化和旅游部对<演出经纪人员管理办法>(以下简 ...
Java基础学习总结（146）——开发人员日志实践规范
一.日志规范日志作用: 1.日常排查问题(基本作用),快速定位问题的根源 2.分析日志,构建常见问题排查平台 3.报表输出(日活.周活) 4.追踪程序执行的过程,追踪数据的变化: a)在系统启动或 ...
甲方人员Shiro漏洞检测工具
高能预警本工具适用于甲方安全人员进行漏洞检测,切勿非法使用,如果使用者进行恶意破坏,笔者概不负责,且一经查实,必向相关安全机关上报,切记,切记~ 工具下载下载地址:https://github.c ...
信息系统监理与审计我国实践与美国的经验
一. 引言目前,我国信息化建设已经进入新的阶段,我国信息化事业已发展到一个新的阶段.各级政府正在积极推进"电子政务",许多城市及企业也已着手整合与升级其信息化应用系统.可以预计, ...
干净架构在 Web 服务开发中的实践
干净架构(The Clean Architecture)是 Bob 大叔在 2012 年的一篇博文 The Clean Architecture 中,提出的一种适用于复杂业务系统的软件架构方式.干净架 ...
软件开发向大数据开发过渡_如何过渡到开发人员关系职业
软件开发向大数据开发过渡假设您已经找到了一个自己真正喜欢的开源项目,并且您想做的不仅仅是贡献. 或者您喜欢编码,但是您不想花一生的时间与计算机进行交互,而不是与人进行交互. 您如何将对开源软件的热爱 ...
系统工程理论与实践投稿经验_钱学森的系统工程 | 如是读
国之重器,两弹一星,钱学森,是我们熟悉的联想,作为中国著名的科学家,在新中国内忧外患之际,造就了前所未来的战略力量,为中国创造了稳定和平的国内外环境. 但除了两弹一星,钱学森还留给我们了什么? 为什么 ...

甲方IT人员管理办法实践

目录