项目管理与软件开发的质量、效率和最终结果密切相关。 本文主要讲述软件项目的风险评估、成本预算、客户沟通、需求分析、开发管理、成品交付等。
目前国外项目的管理方式非常狭隘，缺乏对管理的重视，导致很多项目因管理的流失而流失。
很多实践型人才只关注开发过程，而对其他过程（包括我自己）缺乏了解，从而导致项目缺乏组织性、阶段性管理。
我是一个典型的只注重发展的管理者。 通过多次的教训我深深感受到管理的重要性。 因此，我借这篇文章对项目管理做一个总结。 其中还有很多不足之处。 请给出意见！
1. 风险评估
软件项目风险是指整个项目周期所涉及的成本预算、开发进度、技术难度、经济可行性、安全管理等方面以及此类问题对项目的影响。 项目的风险与其可行性成正比，可行性越高，风险越低。 软件项目的可行性分为四个方面：经济可行性、商业可行性、技术可行性、法律可行性。 软件项目风险分为产品规模风险、需求风险、关联风险、管理风险、安全风险六个方面：
1、产品规模风险
项目的风险与产品的规模成反比。 通常，产品规模越大，问题越突出。 特别是产品规模、软件复用量、需求变更次数的计算方式与产品风险密切相关：
(一)产品规模的计算方法
(2)产品规模计算的信任度
(3)产品尺度与上一产品尺度平均值之间的误差
（4）产品的用户数量
(5) 有多少软件被复用
(6)产品需求变化有多大
2、需求风险
许多项目在确定需求时面临一些不确定性。 当这种不确定性在项目开始时被容忍，但在项目进展过程中没有得到解决时，这种问题就会对项目的成功造成很大的威胁。 如果不控制与需求相关的风险因素，则很可能会创建错误的产品或构建质量不佳的预期产品。 每种情况都可能对产品造成致命的影响。 此类危险因素有：
(1)对产品缺乏清晰的认识
(2)缺乏对产品需求的认知
（3）需求分析过程中客户参与不够
(4) 无优先需求
(5)因需求不确定而创造新市场
(6)需求变化
(7)缺乏有效的需求变更管理流程
（八）缺乏对需求变化等的相关分析。
3、相关风险
很多风险是由于项目的外部环境或者激励的相关性而形成的。 为了控制外部关联风险，缓解策略应包括可能性计划，以便从辅助资源或协同工作资源中获取必要的组件，并发现潜在的问题。 与外部环境相关的激励因素有：
(1) 客户提供的物品或信息
(2)交互成员或交互组依赖
(3) 与内部或外部分包商的关系
(4) 拥有经验丰富的人员
(5) 项目的可重用性
4、技术风险
软件技术的快速发展和经验丰富的人员的短缺意味着项目团队可能存在影响项目成功的方法论激励。 早期识别风险并采取适当的防控措施是解决风险领域问题的关键，例如：培训、聘请顾问、为项目团队紧急招募合适的人才等。 就技术而言，主要有以下风险激励：
(1)缺乏培训
(2)对技术、工具、技巧理解不够
(3)应用领域经验不足
（4）不熟悉新技术的应用和开发方法
5. 管理风险
尽管管理问题阻碍了许多项目的成功，但风险管理计划中并未包含所有管理活动，请不要感到惊讶。 在大多数项目中，项目总监往往是编写项目风险管理计划的人，他们有先天的缺陷——他们无法发现自己的错误。 因此，使得该项目的成功显得越来越困难。 如果不解决这些棘手的问题，它们有可能在项目期间的某个时刻影响项目本身。 只有当我们定义项目跟踪流程并明确项目角色和职责时流程图软件，才能处理这种风险触发因素：
（一）计划和任务界定不够
（2）不了解项目实际情况
（三）项目业主和决策者困惑
（四）不切实际的承诺
（5）无法与员工充分沟通
6、安全风险
软件产品本身就是一个创造性的产品，对产品本身的核心技术保密非常重要。 但我们对软件的安全意识还比较淡薄，软件产品的开发主要注重技术本身，而忽视了专利的保护。 软件行业技术人员流动是一个非常普遍的现象。 随着技术人员的流失和变动，很可能会造成产品和新技术的泄露，导致我们的软件产品被其他公司盗用，导致项目失败。 而且，软件知识产权的认定还没有明确的行业标准，这也是我们软件项目的潜在风险。
七、规避风险的方法
(1)由开发人员归纳可以保证需求的完整性，使需求与客户的真实期望高度一致。 然后，方便地以书面形式制作重要文件“用户需求”，防止在软件系统的后续阶段因疏忽造成的损失逐渐扩大。
（二）准备建立监督体系。 项目开发中的任何重大决策都必须在客户的参与下进行。 本项目中，项目监理由项目开发中的质量监理组进行。
（3）需求变更必须由统一负责人提出，并须经用户需求初审领导批准。 需求变更应定期提出，而不是随时提出，开发人员应做好详细记录，让客户了解需求变更的实际情况。
(4)控制系统的复杂性和过于简单的系统结构会给用户的使用比例带来明显的折扣，甚至导致软件寿命过短。 相反，软件结构过度的灵活性和通用性必然会降低软件实现的难度，增加系统的复杂度，从而在实施和测试阶段带来风险。 适当控制系统的复杂度有助于降低开发风险。
(5)从软件工程的角度来看，软件维护成本约占总成本的55%～70%，且系统越大，成本越高。 忽视系统的可维护性是小型软件系统最大的风险。 在软件长期运行的过程中，业务规则肯定会不断演化。 解决这个问题的科学方法是在保证可维护性的前提下，不断升级软件系统的版本，逐步扩展系统。
（六）制定应急预案。 每个发展规划至少应制定应急预案，以应对突发事件和不可预见的风险。
2、成本预算
1、成本预算的形式
(1) 自上而下的预算方法
自上而下的预准备方法主要是根据中下层项目经理的管理经验，对构成项目总体成本的子项目的成本进行判断，并将这种判断的结果传递给下层管理人员。 在此基础上，该级别的管理者估算组成该项目的子任务和子项目的成本，然后继续将其成本估算向上层传递，直至传递到最低层。
采用这种预算形式，当下级管理者根据经验将费用分解向上级时，上级员工可能会觉得下级资金可能不足以完成相应的任务。 这时，上层人员不一定会表达自己的真实看法，也不一定能与下层管理者进行理性的讨论，从而得出更合理的预算分配方案。 在实践中，他们往往只能默默等待下级管理层自己发现并纠正问题，这往往会导致项目出现很多问题。
自上而下更适合项目启动初期，与实际成本相差30%~70%。
Scrum采用自上而下的成本估算形式，它并不是立即准确地确定成本，而是最大程度地适应客户未来产品需求带来的变化。
(2)自下而上的预算方法
自下而上的技术需要使用WBS（工作分解结构，Work Breakdown Structure）来仔细检查项目所有工作任务的时间和预算。 最初预算是针对资源（团队成员的工作时间、硬件配置），项目总监加上适当的间接费用（如培训费用、管理费用、不可预见的费用等）。自下而上的预算方法需要综合考虑涉及的所有任务，更适合项目的前期和中期。 它可以经过深思熟虑地估算出项目的成本，与实际成本的差异在5%到10%之间。
注：工作分解结构
WBS是项目对交付结果的分解。 从交付结果列表中，可以确定每个交付结果需要执行的活动。 Scrum将WBS进一步细化，将一个迭代分解为一个或多个工作包，然后将工作包分解为小的开发任务（通常开发任务的开发周期在15个工作小时以内）。
2.确定项目费用
总体成本预算是结合以下多种成本预算方法综合估算的开发成本：
(一)零基预算
在成本预算前期，应采用零基估算的原则，而不是用上一年综合成本加20%等简单形式估算项目成本。
(2)软硬件成本、项目成本
项目成本是指类似于：服务器（RAM硬盘CPUNIC卡RAID集群）成本、维护成本、机房租金、光纤通信成本、软件成本等成本。
在估算成本时，需要考虑组装硬盘所需的时间长短、所需技术人员的素质、产品供应商提供的质量保证以及是否需要额外的管理人员进行管理。
(3) 软件许可费用
(4) 外包成本
在使用视频、短信、移动联通业务、门户网站等子项目时，可以考虑外包，以降低开发成本。
(5)人力资源成本
在估算人力资源成本时，应采用工作效率最高和最低的平均效率的计算方法来估算人力资源平均成本。
(6) 维修保养费用
3、客户沟通流程
从客户沟通的角度来看，软件项目可以分为四个不同的阶段：需求识别、解决方案定制、项目实施、项目完成，每个阶段都有不同的沟通重点。
1.需求识别阶段
(1)文字沟通
在需求识别前期，要通过问卷调查、原型展示、界面展示、逻辑处理展示、标准化文档模板等进行全方位、多角度的分析，有不清楚的地方要随时反馈给客户，希望得到客户的解答。 并以文本记录的形式构建需求分析文档，并要求客户先审阅需求分析文档，从而达到需求分析与客户真实期望高度一致的结果。
(2)业务逻辑通信
在进行业务沟通时，应了解客户的行业语言，以促进业务分析的进程，弥合应用需求与开发之间的差距。 沟通过程提倡以草图或可视化信息的形式，为不同层次的企业用户提供最适合的操作界面。 多角度思考问题，聚焦需求关键点，尤其是客户方领导关心的创新性、实用性需求。
(3)需求变更标准化管理
需求变更在软件开发项目中是可以理解的，但必须以标准化的方式进行管理，以防止需求无休止变更的风险。 需求变更必须由统一负责人提出，并经用户需求初审领导批准。 需求变更应该定期提出，而不是随时提出，并且开发者应该做出详细的文字记录，让客户了解需求变更的实际情况以及开发者为此付出的成本。
2、方案定制阶段
此阶段项目的主要任务是根据前期明确的需求、双方的资源情况、项目启动阶段、实施时间协议、项目造价限额等情况，与客户共同制定可操作的项目计划。 从这个阶段开始，客户全面参与项目管理，并基于双方的共同利益来考虑项目实施和风险规避的具体方案。
三、项目实施阶段
在这个阶段，软件项目团队应与客户一起主导项目的实施。 同时，项目团队应实时评估客户满意度，通过持续改进提升客户满意度。 还应要求客户参加必要的培训，并在必要时测试项目产品。 在客户的需求发生变更之前，应积极与客户沟通，让客户充分了解项目的各个环节以及变更的影响，从而减少需求变更。 如果客户要求发生变更，则因变更而引起的成本、进度、质量变化应与客户共同解决。
4. 收尾阶段
此阶段主要进行项目成果的移交，并将系统交付给维护人员，帮助客户实现业务目标并付清各类款项。 完成此类工作后，应进行项目评估，回顾项目成果，总结项目经验。
5、售前人员注意事项
当产品型项目作为开发成果时，相关销售人员要注意：产品的宣传不要太有前景。 如果承诺过多，会给后续的项目实施带来困难； 如果承诺没有兑现，也会增加客户的满意度，影响以后的合作。 如果有额外的承诺，必须以文本形式记录下来，以便项目执行总监能够获悉并传达给项目团队成员。
注：在软件项目中，需要明确以下四种客户角色
A、需要明确最终使用部门和用户，了解他们现有的工作方式，让他们知道项目的目标框架，知道项目将为他们解决哪些困难，但绝对不是所有困难，这样才能更好地控制项目的范围。
B. 需要明确请求者，他或他们必须能够代表最终的客户群体。 提出产品需求的客户必须具备一定的技术、业务能力、权威，才能真正代表最终客户团队的意愿和意见。 最好有IT基础，用IT语言描述问题和需求，方便双方沟通协作，防止歧义。
C、做一个需要明确身份的中层领导，必须把握方向。 软件开发项目是为了解决实际的生产或管理问题，也是领导系统建设的具体实现。 作为需要确认的客户负责人，不仅要了解高层领导的体系建设重点和方向，还要遵循具体的业务和生产管理实践。 如果是这样的客户领导来把握和决策，对于企业软件开发项目的顺利进行会有很大的影响。
D、需要明确谁对成品提出意见，谁做初检。 工程的初检是工程的最后一个环节。 如果初检人员不了解项目的早期需求目标，从心态和产品的实际使用角度都会对初检产生负面影响，尤其不利于提供产品的公司关闭项目。 根据实践总结，项目的初步检查应由请求方和确认方共同完成，以促进项目的顺利完成，防止延误。
4.需求分析
1、需求分析的流程
需求过程包括需求开发和需求管理两部分：
（1）需求开发是对开发前期以及与客房沟通过程的管理，可分为需求获取、需求分析、需求编写和需求验证四个阶段。
(2)需求管理：是在软件项目开发过程中控制和维护需求协议的活动。 包括：变更控制、版本控制、需求跟踪、需求状态跟踪。
2. 需求层次
需求层次包括四个方面：业务需求、用户需求、功能需求、非功能需求。
3、需求开发阶段的重点
(1)提取业务对象
业务对象是指系统使用的真实对象。 例如，供应链管理（Supply Chain Management，简称SCM）业务对象主要包括：生产批发商、零售商、配送公司以及多个层次的客户。
(2)提取业务流程
在理解业务逻辑的过程中，应列出所开发的软件模块各自的功能，并详细说明每个工作流程，以深入分析业务逻辑。
（三）性能要求
在分析前期，应关注客户开发的软件的技术性能指标，如存储容量限制、运行时间限制、安全保密等。
（四）环境要求
环境要求是指软件平台运行的环境的要求流程图软件，如硬件：型号、外部设备、数据通信插座； 软件：系统软件，包括操作系统、网络软件、数据库管理系统； 使用：使用部门在系统和操作人员技术水平方面应具备哪些条件。
(5)可靠性要求
根据实际运行环境要求所开发的软件投入运行后出现故障的概率。 对于重要的软件，或者运行失败会导致严重后果的软件，应提出更高的可靠性要求。
（六）安全保密要求
在进行需求分析时，应在这方面做出适当的规定，并对所开发的软件进行专门的设计，使其在运行过程中能够保证其必要的安全性和保密性能。
(7) 用户界面要求
详细指定用户界面的到达要求。
（八）资源使用要求
所开发的软件在运行和开发过程中所需的各种资源。
（九）软件成本消耗及开发进度要求
软件项目立项后，根据协议，对软件开发的进度和各步骤的成本提出要求，作为开发管理的依据。
（十）发展目标要求
提前担心系统将来可能实现的目标，以便更容易对系统进行必要的添加和更改。
4.需求分析的任务
需求分析的主要任务是利用当前系统的逻辑模型导入目标系统的逻辑模型。 流程如下：
（1）确定系统的综合要求（功能、性能、操作、扩展要求）
(2)制作产品需求文件(PRD)
（3）分析系统的数据需求（概念模型、数据字典、归一化）
（4）导入目标系统的详细逻辑模型（数据流图、数据字典、主要功能描述）
(5) 开发原型系统
(6)从PRD中提取并编译软件需求规模规范(SRS)
注：SRS格式
1. 前言 2 系统概述（项目背景、系统目标、核心业务流程） 3. 术语描述？ 4.系统结构（架构图、功能图）
5. 主要功能和业务逻辑（重点） 6. 套接字需求（内部和外部套接字） 7. 整体网络设计（拓扑网络、主机、组网）
8、运行环境（Linux、Windows、IIS、WebLogic、Tomcat、OLAP、OLTP、JDK8.0、.NETframework4.0等）
5.面向对象编程（略）
1. 设计原则
(1)SRP单一责任链
每个类应该只负责做一件事。
(2)OCP安阳封闭原则
软件实体（类、模块、函数等）应该是可扩展的且不可更改的。
(3)LSP替换原则
泛型类型必须能够替换其基本类型。
(4) DIP依赖反转原理
高层模块不应该依赖于低层模块，两者都应该依赖于套接字和表示类。 表征不应该取决于细节，细节应该取决于对象。
(5)ISP套接字隔离原理
不应强迫客户依赖未使用的套接字，而应分离胖套接字。
2. 实现UML建模
(1)业务对象的提取
(2)基于SRS、CRC等的用例建模。
(3)实现业务时序图
（4）构建类图，根据用例图构建对象之间的关系
(5)勾画活动图、实现协作图、状态图
6. 开发管理
1. 制定项目计划
(1)总体结构设计
根据系统的实施需要，采用合适且成熟的框架结构。
(2)控制扩展性
如果扩展时间过大，会增加系统的复杂度，延长开发时间； 如果扩展时间太低，将直接影响系统的二次开发和维护。 控制系统的可扩展性可以提高开发效率，降低系统维护难度。
（三）基础设施建设
合理分配部署软硬件等基础设施所需的时间和成本（例如：购买和安装服务器、光纤接入、购买软件平台）。
(4)定义开发任务
借助 WBS（工作分解结构）对可交付成果进行分类和定义。 每个项目可以定义为多个不同的阶段，每个阶段又可以分为多个工作包（WorkPackage）。 工作包是WBS中最小的可交付结果，最终从工作包中分解出多个开发任务清单。
(5)部署开发进度
一个项目应根据进度划分为多个开发阶段，每个阶段的开发周期通常在30~60个工作日内。 此阶段应与客户召开协商会议制定产品路线图，并邀请客户在开发过程中积极参与并提供反馈。 之后，根据开发难度、依赖性、重要性等各种条件，将本期的开发任务定义为多个迭代周期。
在Scrum敏捷软件开发的原则中，每个迭代任务应该进一步细分为多个开发任务清单，然后将开发任务分配给班委，开发时间控制在15个工时以内。 如果开发时间超过15个工作小时，则应考虑重新细化开发任务。 开发任务建议应由班委会自主选择，而不是采用强制分配的形式。
(5) 测试项目结果
每个工作包应同时部署和测试，以提高项目质量。 错误BUG的工作包应该由测试人员以文本形式记录下来，向开发人员展示错误，以便开发人员及时进行修改。
2. 管理开发团队
（一）组建团队
根据工作任务和项目时间的前提条件完善团队，并根据团队职责分配人员。 通常，团队成员数量应控制在8至12人之间。 当团队超过15人时，应考虑将团队划分为2个独立的团队，负责不同的开发任务。
(2)分配开发任务
在每个迭代周期（一般为15-30个工作日），应将每个工作包进一步细分为多个开发任务，然后将开发任务分配给班委，开发时间控制在15个工时以内。 如果开发任务的开发时间超过15个工时，则应考虑再次细化任务。 开发任务应以自由选择的形式分配给各班委会。
（三）监督开发进度
迭代初期召开会议，让班委会了解开发进度和流程，并以自主选拔的形式分配开发任务。 在此期间，可以使用Microsoft Project等工具来记录开发过程的进度。 每个工作包开发完成后，应进行性功能测试，并以文本形式记录测试结果。
每天晚上召开15分钟的半蹲会，让班委交代明天已经完成的开发任务、当天要做的任务以及开发过程中遇到的问题。 并每周六召开例会，讲解整体流程。
迭代结束时召开冲刺会议，总结项目进展情况、银行完成的任务，回顾迭代周期中遇到的问题，并制定下一次迭代的计划。
(4)系统测试
对每个已完成的工作包及时进行测试，确保系统质量和性能。 将测试结果以文字记录，将测试结果与绩效工资收入挂钩，用真实数据估算班委的绩效收入。
（五）解决开发中遇到的问题
对开发人员进行前期培训，根据工作能力分配任务，指导班委的发展。 遇到问题应立即在当天半蹲会上提出，并在15个工作小时内解决遇到的问题，避免问题进一步扩大。
3、监督产品质量
(1)质量需要的是规划和设计而不是评审。 在产品构建的中间阶段，必须与质量保证 (QA) 部门协商以文件的形式确定适当的质量政策和标准。
（2）在开发过程中采用TDD（测试驱动开发）模式，提升开发质量。 测试人员应以文本形式记录Bug，并与开发人员合作，向开发人员展示突出的缺陷，以提高变更效率。
（3）在每次迭代结束时对产品的功效进行演示，并收集客户、用户和高层领导的反馈。 在团队内部召开评审会议，分析测试结果，了解产品性能，并计划上一次迭代中需要进行的改进。
4.改变项目计划
(1) In the stage of product needs identification, the product functions and development process should be recorded in the form of documents. When the development plan needs to be changed, it should be explained together with the customer, so that the customer can understand the impact of the plan change on the project progress.
(2) Changes to the project plan should be proposed by the unified person in charge, but approved by the leader of the initial review of user requirements. Requirements changes should be proposed regularly rather than at any time.
(3) The change of the plan should be well documented in detail, so that the customer can understand the actual situation of the demand change and the cost paid by the developer.
7. Product delivery
1. The later preliminary review of the project
After the project development is finally completed, it can be regarded as a heavy burden of work for the developers, but for the project director, this is often a critical moment of the project. The previous risk assessment, cost budget, requirements analysis, and software design are all to guide the project towards this moment, and all eyes will be on the project management personnel at this time. You may find that a large amount of complicated work is about to be completed within a few hours. At this moment, the project director needs to stay awake and calm, and treat the final work as a mini-project. Carry out a preliminary preliminary review of the project in detail, analyze the project results, the efficiency of the project team, and the value of the deliverable products, so that the results of the preliminary review can be used as a part of the project management experience summary.
2. Quality review
Before the project is delivered, the project should be handed over to the relevant "Quality Assurance" (QA) department for quality review, and typical users should be invited to experience the quality of the product.
3. Final delivery of the project
Under normal circumstances, a project delivery contract will be signed in the early stage of the project. The project delivery method is divided into two types: non-imminent initial inspection and imminent initial inspection. Usually after the completion of the project, a non-imminent initial inspection will be carried out first, so that customers can feel the quality of the project and give feedback. Finally, after the customer confirms the product quality, the upcoming initial product inspection will be carried out in the form of a written contract.
4. Final report of the project
At the end of the project, a final project report should be drawn up, which can be considered a record of the project, but the report need not cover all aspects of the project. Typically the final report should include the following:
(1) Early project view when the project was first introduced
(2) The value assessment and supporting information of the project
(3) Scope of the project
(4) Project development process and WBS
(5) Minutes of the meeting of the project
(6) Report on project changes and reasons for changes
(7) Communication process documents related to the project
(8) The initial inspection report of the project and the customer's initial inspection report
(9) Performance reports of project members
(10) The final result of the project
