跳到主要内容

6 篇博文 含有标签「项目管理」

项目管理相关

查看所有标签

软件成本评估

· 阅读需 9 分钟

1. 概述​

本文介绍软件成本评估的一些相关标准和评估方法，内容包括：

  • 软件功能规模度量和成本费用测算相关的现行国家标准。
  • 软件功能规模度量的国际标准，五种度量方法：分别为 IFPUG、MARK Ⅱ、COSMIC、NESMA 和 FiSMA 方法。
  • 当前 IFPUG 方法和 NESMA 方法是目前最主要的标准，优先考虑采用。

2. 国家标准（功能规模度量和成本费用测算）​

2023年3月17日，中华人民共和国国家标准公告（2023年第1号）发布，公告中发布了一系列国家标准，其中包含三项软件功能规模测量国家标准，标准由全国信息技术标准化技术委员会归口，全国信息技术标准化技术委员会软件与系统工程分会执行 ，主管部门为国家标准化管理委员会。

信息

2023年第1号中国国家标准公告（来源：全国标准信息公共服务平台 ）：

关于批准发布《公路路面等级与面层类型代码》等373项推荐性国家标准 和6项国家标准修改单的公告

三项软件功能规模测量国家标准如下：

标准类型标准编号标准名称发布日期实施日期
荐性国家标准GB/T 42448-2023系统与软件工程 功能规模测量 FiSMA1.1方法2023-03-172023-10-01
推荐性国家标准GB/T 42449-2023系统与软件工程 功能规模测量 IFPUG方法2023-03-172023-10-01
推荐性国家标准GB/T 42452-2023系统与软件工程 功能规模测量 COSMIC方法2023-03-172023-10-01

其它现行的相关国家标准（截止：2024年6月）：

标准类型标准编号标准名称发布日期实施日期
推荐性国家标准GB/T 36964-2018软件工程 软件开发成本度量规范2018-12-282019-07-01
地方标准 北京DB11/T 1010-2019信息化项目软件开发费用测算规范2019-06-182019-10-01
地方标准 昆明DB5301/T 102-2024应用软件定制开发成本测算指南2024-01-012024-02-01
地方标准 温州DB3303/T059-2023政务信息化项目软件开发费用测算规范2023-01-162023-02-16
地方标准 贵州DB52/T 1653-2022软件开发费用测算规范2022-03-032022-06-01
地方标准 成都DB5101/T 5-2018信息化项目软件开发费用测算规范2018-07-012018-07-02
行业标准SJ/T 11618-2016软件工程 MK II功能点分析计数实践指南2016-01-152016-06-01
行业标准SJ/T 11617-2016软件工程 COSMIC-FFP 一种功能规模测量方法2016-01-152016-06-01
行业标准SJ/T 11619-2016软件工程 NESMA 功能规模测量方法版本2.1 使用功能点分析的定义和统计准则2016-01-152016-06-01
行业标准SJ/T 11620-2016 信息技术 软件和系统工程 FiSMA1.1功能规模测量方法2016-01-152016-06-01
提示

上述标准有一些可以在官网进行查看，有一些采用了ISO、IEC等国际国外组织的标准，由于涉及版权保护问题，官网不提供在线阅读服务。 如需正式标准出版物，可在中国质量标准出版传媒有限公司(中国标准出版社)主办的中国标网进行购买。

3. 国际标准（功能规模度量）​

功能规模度量相关国际标准（截止：2024年6月）：

标准编号标准名称发布日期说明
ISO/IEC 20926:2009Software and systems engineering — Software measurement — IFPUG functional size measurement method 20092009-12IFPUG 方法
ISO/IEC 19761:2011Software engineering — COSMIC: a functional size measurement method2011-03COSMIC 方法
ISO/IEC 20968:2002Software engineering — Mk II Function Point Analysis — Counting Practices Manual2002-12Mk II 方法
ISO/IEC 24570:2018Software engineering — NESMA functional size measurement method — Definitions and counting guidelines for the application of function point analysis2018-02NESMA 方法
ISO/IEC 29881:2010Information technology — Systems and software engineering — FiSMA 1.1 functional size measurement method2010-08FiSMA 1.1 方法

4. 五种功能规模度量方法​

在度量方法的发展演进中，有五种方法被 ISO 国际标准组织接受成为了 ISO 国际标准，分别是：

  • IFPUG
  • Mark-II
  • NESMA
  • FiSMA
  • COSMIC

1979年10月，Allan Albrecht 博士首次提出了一种评估软件系统功能的技术方法。他的技术方法被采用，成为国际标准。1987 年，IFPUG 成立，负责管理和发展 Albrecht 的技术。在接下来的几年中，又启发了其他几种度量方法出现。它们（按出现顺序）是：Mark-II（1988）、NESMA FPA（1990）、FISMA（199x）和 COSMIC（1998）。

五种度量方法的发展历史

history-of-functional-size-measurement

5. 该选取哪种方法标准​

对于上述五种不同的规模度量标准，它们的功能点类型、应用范围、可操作性和应用现状等方面都有各自不同的特点，但就其应用的广泛程度来看，IFPUG 标准和 NESMA 标准仍然是目前最主要的标准。国际组织中超过 90% 的数据采用 IFPUG/NESMA 方法，国内的行业数据则 100% 采用 IFPUG/NESMA 方法；同时，由于 IFPUG 方法和 NESMA 方法被认为是等效的（即 IFPUG 方法所度量的1个功能点基本等同于 NESMA 方法所度量的一个功能点），近几年各行业在应用软件成本度量行业及国家标准时，主要采用 IFPUG/NESMA 方法，各地政府在制订地方标准时，也主要参考 IFPUG/NESMA 方法。

6.相关网站：​

[1] 全国标准信息公共服务平台
[2] 国家标准全文公开系统
[3] 中国质量标准出版传媒有限公司(中国标准出版社)
[4] 中国质量标准出版传媒有限公司(中国标准出版社) 主办中国标网
[5] 北京软件造价评估技术创新联盟
[6] 中国软件行业协会软件造价分会
[7] ISO 国际标准化组织
[8] IFPUG 国际功能点用户组
[9] nesma
[10] COSMIC

7.其它参考​

[1] 40 Years of Function Points: Past, Present, Future
[2] 五种ISO功能点方法介绍
[3] COSMIC 度量手册中文版
[4] COSMIC-FFP and IFPUG 4.1 Similarities and Similarities and Differences

用 BPMN 进行业务流程建模

· 阅读需 5 分钟

1. 概述​

本文介绍在梳理客户业务流程时，使用 BPMN 来进行流程建模绘图。 并提供一些可以供学习的资源链接。

2. 使用 BPMN 表达业务流程的好处​

  • 简单易懂一目了然。
  • 具有丰富的符号，可以精确的表示从简单到复杂的每个用例。
  • 为需求人员提供了以图形符号理解和表达客户业务流程的能力，并可以以标准方式向其它相关方传达这些信息。
  • 它是工作流建模的标准。是众多商业或开源工作流引擎底层采用的技术。

3. BPMN 简介​

BPMN(Business Process Modeling and Notation 业务流程建模和表示法) ，是业务流程建模的全球标准。BPMN 图表允许项目中不同的相关方可视化的表达业务流程。项目中的业务客户、需求分析师、开发人员、业务经理，每个人都使用相同的表达语言来描述业务流程，从而更容易使业务需求沟通的更加准确和高效。

BPMN 最初由 Business Process Management Initiative (BPMI) 开发，是一种用于记录业务流程的精确图形符号。它通过直观地描述完成特定流程所需的业务活动和信息流的顺序来解决流程规范的歧义。

自 2005 年以来，BPMN一直由对象管理组 Object Management Group（OMG）维护。BPMN 2.0 是 OMG 关于流程改进三个标准之一，另外两个是：CMMN（Case Management Model Notation 案例管理模型符号)和 DMN（Decision Model and Notation 决策模型符号）。

当前 OMG 的 BPMN2.0.1 规范已作为国际标准 ISO/IEC 19510:2013 Information technology — Object Management Group Business Process Model and Notation 发布。

4. 可视化编辑器​

参见：安装 Red Hat Process Automation Manager VS Code 扩展捆绑包

5. 入门指南​

5.1 BPMN 提供以下三种图类型​

  • Collaboration diagrams 协作图显示了使用多个池的两个或多个进程之间的交互。协作图侧重于每个池执行的工作，反过来，每个池可以在彼此之间传递消息。
  • Choreography diagrams 编排图显示了两个或多个参与者之间的交互。编排图可以包含在协作中，添加任务和序列，以确定参与者如何更充分地交互。
  • Conversation diagrams 会话图是协作图的简化版本。它们显示了业务流程中的一组相关消息交换。

5.2 入门指南​

这是一篇简单的入门指南，介绍了基本符号的使用。

5.3 一个简单的人员招聘需求发布的示例​

personnel-recruitment

6. 接下来​

本文的内容非常简略，只是一个简单的介绍，下面的几个链接资源包括了上面所提到的内容，可参考。

7. 其它一些额外的资料​

系统与软件工程国家标准（GB）与国家军用标准（GJB）

· 阅读需 8 分钟

1. 系统与软件工程标准简述​

系统与软件工程领域国外有一系列指导标准，随着近年来我国信息技术的发展，国家也推出了中国自己的标准，这些标准不是强制性的，而是推荐和建议指导性质的标准。这些标准种类繁多，覆盖了系统与软件工程领域的各个过程，其中有一些标准是比较重要的，这里仅列出国家标准（GB）和国家军用标准（GJB）中最主要的几个。

2. 国家标准（GB）​

提示

下述标准是当前现行标准（截止：2024年4月），有一些可以在全国标准信息公共服务平台官网进行查看，有一些采用了ISO、IEC等国际国外组织的标准，由于涉及版权保护问题，官网不提供在线阅读服务。 如需正式标准出版物，可在中国质量标准出版传媒有限公司(中国标准出版社)主办的中国标网进行购买。

GB/T 虽然是国家推荐标准，但如果被纳入经济合同中，就具有法律上的约束性；GB/Z 则不具有法律上的约束性。

（1）基础标准

标准类型标准编号标准名称发布日期实施日期
推荐性国家标准GB/T 11457-2006信息技术 软件工程术语2006-03-142006-07-01
指导性国家标准GB/Z 31102-2014软件工程 软件工程知识体系指南2014-09-032015-02-01

（2）文档化标准

标准类型标准编号标准名称发布日期实施日期
推荐性国家标准GB/T 8567-2006计算机软件文档编制规范2006-03-142006-07-01
推荐性国家标准GB/T 9385-2008计算机软件需求规格说明规范2008-04-112008-09-01

（3）生存周期管理标准

标准类型标准编号标准名称发布日期实施日期
推荐性国家标准GB/T 8566-2022系统与软件工程 软件生存周期过程2022-10-122023-05-01
推荐性国家标准GB/T 22032-2021系统与软件工程 系统生存周期过程2021-04-302021-11-01
推荐性国家标准GB/Z 31103-2014系统工程 GB/T 22032（系统生存周期过程）应用指南2014-09-032015-02-01

（4）质量与测试标准

标准类型标准编号标准名称发布日期实施日期
推荐性国家标准GB/T 25000.1-2021系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第1部分：SQuaRE指南2021-04-302021-11-01
推荐性国家标准GB/T 25000.2-2018系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第2部分:计划与管理2018-12-282019-07-01
推荐性国家标准GB/T 25000.10-2016系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第10部分：系统与软件质量模型2016-10-132017-05-01
推荐性国家标准GB/T 25000.12-2017系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第12部分：数据质量模型2017-11-012018-05-01
推荐性国家标准GB/T 25000.20-2021系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第 20 部分：质量测量框架2021-04-302021-11-01
推荐性国家标准GB/T 25000.21-2019系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第21部分：质量测度元素2019-08-302020-03-01
推荐性国家标准GB/T 25000.22-2019系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第22部分：使用质量测量2019-08-302020-03-01
推荐性国家标准GB/T 25000.23-2019系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第23部分：系统与软件产品质量测量2019-08-302020-03-01
推荐性国家标准GB/T 25000.24-2017系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第24部分：数据质量测量2017-11-012018-05-01
推荐性国家标准GB/T 25000.30-2021系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第30部分：质量需求框架2021-04-302021-11-01
推荐性国家标准GB/T 25000.40-2018系统与软件工程 系统与软件质量要求和评价（SQuaRE）第40部分：评价过程2018-12-282019-07-01
推荐性国家标准GB/T 25000.41-2018系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第41部分：开发方、需方和独立评价方评价指南2018-12-282019-07-01
推荐性国家标准GB/T 25000.45-2018系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第45部分：易恢复性的评价模块2018-12-282019-07-01
推荐性国家标准GB/T 25000.51-2016系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第51部分：就绪可用软件产品（RUSP）的质量要求和测试细则2016-10-132017-05-01
推荐性国家标准GB/T 25000.62-2014软件工程 软件产品质量要求与评价（SQuaRE） 易用性测试报告行业通用格式（CIF）2014-09-032015-02-01

3. 国家军用标准（GJB）​

主要标准

  • GJB 5000B-2021 军用软件能力成熟度模型
  • GJB 2786A-2009 军用软件开发通用要求
  • GJB 438C-2021 军用软件文档编制通用要求
  • GJB 5612-2006 军队计算机信息系统安全保密防护要求及检测评估方法
  • GJB 9001C-2017 质量管理体系标准
  • GJB/Z 141-2004 军用软件测试指南
  • GJB 439A-2013 军用软件质量保证通用要求
  • GJB 2115A-2013 军用软件研制项目管理要求
  • GJB 8000-2013 军用软件研制能力等级要求
  • GJB/Z 161-2012 军用软件可靠性评估
  • GJB/Z 102A-2012 军用软件安全性设计指南
  • GJB/Z 172-2015 军用软件风险管理指南
  • GJB 5234-2004 军用软件验证和确认

可视化项目进展一 - Burndown Chart（燃尽图）

· 阅读需 8 分钟

1.用 Burndown Chart（燃尽图）可视化项目进展​

燃尽图用于衡量工作进度，它反映的是完成的工作量以及剩余的工作量之间的关系。

下面是一个简单的燃尽图示例，这里为了简单起见，假设总共有 100 个任务项要完成，需要 10 天的时间来完成它们。用纵轴表示 100 个任务项，用横轴表示 10 天。

对于任何一项工作，最理想的方式是每天以一致的速率进行。在这种情况下，意味着每天要计划完成 10 个任务（10天*10个任务等于100个任务总数）。

实际上，如果第一天只完成了五个任务，第二天完成了四个任务，第三天完成了两个任务，则进度落后于计划，因为实际完成数少于了计划数，后续团队需要努力赶上，在接下来的几天里，会完成比原计划更多的任务，在项目结束时，燃尽图可能会如下所示：

信息

下载这个图表的 Excel 文件。Download

burndown-chart-simple.png

2. 更实际一点的示例​

信息

下载这个图表的 Excel 文件。Download

burndown-chart-demo

  • 横坐标表示一个时间周期，这里表示一个 sprint 周期（15天）
  • 纵坐标：左坐标轴表示待完成的工作量，右坐标轴表示每日完成的工作量（小时数或故事点数）
  • 三条折线：
    • Ideal Trend（绿色）：理想线，假设按照固定速率每天完成 25 （小时或故事点）的趋势线。
    • Remaining Effort（Actual）（蓝色）：实际的完成工作进度。
    • Trend Line（Actual）（红色）：实际完成工作进度的趋势线。
  • Daily completed：实际每天完成的工作。
  • 在第7天之前，蓝色线在绿色线上方，表示开发进度落后。从第7天蓝色线在绿色线下方，表示进度逐步追赶上来。

3. 燃尽图的类型​

有几种类型的燃尽图常用于敏捷项目管理：

  • Sprint 燃尽图：这种类型的燃尽图跟踪一个 Sprint 中剩余的工作。它帮助敏捷团队在短迭代期间监控他们的进度，并确保他们在设定的时间范围内按计划完成 Sprint 目标。
  • 产品 Backlog 燃尽图：与 Sprint 燃尽图不同，产品燃尽图表示整个项目剩余的总体工作。它提供了项目维度进度的视图，并帮助项目经理和团队跨多个 Sprint 或迭代跟踪工作的完成情况。
  • 发布燃尽图：显示了产品发版的所有计划功能和需求的进度。

4. 燃尽图有什么好处？​

  • 监控工作进度：允许敏捷团队跟踪项目的所有剩余工作并预测何时完成。
  • 告警：当偏离计划发生时提醒团队，以便及时采取纠正措施。
  • 决策影响：显示项目期间做出的决策的效果，并为未来的决策提供信息。
  • 沟通：促进团队和利益相关者内部的进度沟通，确保每个人都了解情况。
  • 估计：帮助根据当前进度和趋势估计工作何时完成。
  • 动机：通过展示进度和提供绩效反馈来鼓励团队成员表现得更好。
  • 透明度：通过明确比较计划和实际进展来提高透明度。
  • 协作：通过让每个人在项目状态和目标上保持一致来促进有效的协作。

5.燃尽图的局限性是什么？​

提示

燃尽图并不能展示所有内容。例如，它只显示已完成的故事点数。燃尽图不显示任何变更。燃尽图可能无法很好地适应范围发生重大变化的项目，因此在这种动态环境中准确跟踪进度具有挑战性。因此，我们通常很难判断燃尽图中的变化是由于已完成的待办事项导致，还是由于故事点数的增加或减少所导致。

另一个是它依赖于良好的估计，主要涉及理想工作线的准确性。实际工作线位于理想工作线的上方还是下方取决于任务的原始时间估计的准确性。如果团队高估时间要求，进度似乎是按计划或提前进行的。但是，如果团队低估了时间需求，他们会觉得进度落后。

燃尽图的其它局限性还包括：

  • 工作质量：燃尽图不能反映已完成工作的质量，因为它们只关注已完成任务的数量。
  • 具体挑战：它们可能不反映项目期间遇到的具体挑战，这些挑战可能会影响整体进度。
  • 复杂性：一些项目可能过于复杂，以至于燃尽图无法有效跟踪进度，尤其是当团队要求严格遵守敏捷方法时。
  • 团队成员的压力：如果进度慢于预期，燃尽图会产生过度的压力，影响团队士气和动力。
  • 学习曲线：对于刚接触敏捷方法的团队来说，学习使用燃尽图在敏捷框架内准确估计工作和管理任务可能需要时间并引入复杂性。

6. 燃尽图和燃起图（Burnup Chart ）的区别​

主要区别在于它们如何表示项目进度。

信息

下载这个图表的 Excel 文件。Download

burnup-chart

  • 红线表示总的工作量，可以看到第6天的时候，发生了变更，总的工作量由 100 变到了 120。
  • 绿线表示当前完成的工作量，最后项目完成时，两条线应该相交。

7. 敏捷和看板方法相关书籍​

信息

百度云盘下载 PDF

链接: https://pan.baidu.com/s/1RLyyEnqqzz2NQuBNLohwnQ 提取码: vwvt

可视化项目进展二 - Cumulative Flow Diagram（累积流图）

· 阅读需 4 分钟

1. 用 Cumulative Flow Diagram（累积流图）可视化项目进展​

我们希望团队尽可能高效地工作，但是掌握事情的真正进展可能很有挑战性。累积流图是敏捷、精益、Scrum、看板和 SAFe 方法中使用的管理工具，用于随时间可视化和分析工作项流程。可以直观的了解团队的工作情况，以便可以弄清楚如何改进它。

2. 累积流图示例​

下面是一个累积流图的示例

信息

下载这个图表的 Excel 文件。Download

cumulative-flow-diagram-demo

累积流图纵轴（表示任务或工作项）、横轴（表示时间间隔）、不同的彩色线或带（表示各个开发阶段）

提示

累积流图的作用是让团队很容易发现项目中的某些东西工作不正常。理想情况下，图表的所有部分应该平滑地一起（几乎平行）上升。这意味着新任务进入工作流程的速度与任务完成的速度大致相同。如果看到突然的跳跃或下降，这表明工作流程有问题。

3. 累积流图可以反映的指标​

有四个主要的指标是我们应该关注的，通过了解和跟踪这些指标，可以识别流程效率低下的地方并进行改进。

  • Lead Time 交货时间，任务从流程开始到完成的时间。它是一个重要的指标，因为它揭示了瓶颈在哪里，并提高了交付的可预测性。假设您在晚上8:00下了晚餐订单，您的订单在晚上8:30送达。在这种情况下，您的交货时间是30分钟。这是从您提出请求的那一刻起到您收到请求的这段时间。
  • Cycle Time 周期时间，是完成一个任务花费的时间。假设厨房在晚上8:10收到了，厨师开始准备你的订单。你在晚上8:30收到食物；在这种情况下，你的周期时间是20分钟。这是处理你的订单所需的实际时间。
  • WIP（Work in progress）进行中的工作（在制品）
  • Throughput 吞吐量，团队在指定时间段内交付了多少工作
提示

关于进一步了解如何理解累积流图，可以参考链接:

  • Cumulative Flow Diagram[3]
  • [PDF]The Ultimate Guide To Reading The Cumulative Flow Diagram[6]

参考​

[1] Lead time and Cycle Time and the importance of Flow in Kanban
[2] Kanban Metrics: An Overview of the Most Important Kanban System Metrics to Track
[3] Cumulative Flow Diagram
[4] How to read a cumulative flow diagram
[5] What Is a Cumulative Flow Diagram?
[6] [PDF]The Ultimate Guide To Reading The Cumulative Flow Diagram

与客户谈判

· 阅读需 9 分钟

在项目实施过程中，会在各个时间阶段有各种可能的事项要与客户进行沟通或者谈判，通常可能主要是下面几项：

  • 开发报价
  • 交付里程碑与时间进度
  • 系统的设计、架构、解决方案或技术实现方式
  • 需求范围变更
  • 日常工作的方式

需求范围变更，通常是这些事项中最主要的，也是对项目顺利交付影响最大的因素。

在与客户沟通谈判时，有一些原则、方式或方法可以遵循。

1. 定义明确的界限​

在项目启动阶段要与客户对一些基础事项形成一致意见，例如：系统的功能目标、总体的里程碑计划、处理接受变更的流程、验收的标准、输出的交付物等。与客户达成一致，这样就有了一个基础的界限边界。

在与客户进行沟通时我们就有了一个这样的基础。如果客户要求更改，要参考这些文件。根据项目的目标、时间来评估。这不是对客户说不，而是引导客户理解所涉及的影响，双方一起来做权衡。

2. 了解客户需求，提供替代方案​

可以通过提出开放式问题、积极倾听和总结客户的想法。仔细审查他们的要求、时间和预算，并澄清任何模棱两可或理解上的偏差。了解客户的需求将有助于使自己的建议与他们的期望保持一致，并向客户展示价值和可信度。

在对范围变更做出任何决定之前，评估它们对项目的影响。考虑这些变更将如何影响进度、资源和最终产品的质量。提议的变更是否与项目目标一致，是否值得额外的时间和精力。如果影响太大，可能需要找到一个折衷方案，在不过度资源投入的情况下满足项目目标。

面对迫在眉睫的最后期限，要确定任务的优先级。必须确定哪些功能或任务对项目的成功至关重要，哪些可以推迟或完全放弃。与客户一起根据任务的紧迫性和重要性对任务进行分类。这将指导我们就范围变更做出明智的决定。

当客户要求更改时，必须传达这将对项目时间进度和成本资源产生的影响。解释一个更改可能对项目的各个方面产生的连锁反应。使用清晰的非技术语言来阐明为什么更改可能需要额外的时间或预算。通过使后果具体化，客户更有可能理解额外资源或时间调整的必要性。

提供一个替代的方案，也许可以在系统上线以后的运行阶段再考虑逐步引入新的功能，也许那时的想法会跟现在不同。或者在产品的下一期开发中对其进行改进。与客户一块寻找可能的解决方案。

也许最终我们可以同意这些额外的变更工作，但要协商延长最后期限或额外付款来支付额外的工作。这期间是有非常多的谈判技巧可以运用（参见下面小节 5. 学习利用一些谈判技巧）。

3. 寻求客户高层利益相关者的支持​

客户的高层利益相关者才是对项目具有决定权，要让高层利益相关者充分了解项目当前的情况，了解其真实的想法，并寻求支持。

4. 寻求商务支持​

最后，也需要保持一定程度的灵活性。在软件项目管理中，变化通常是不可避免的。虽然管理范围变化很重要，但过于僵化会给客户关系带来不好的影响。

当处于僵局时，需要寻求商务支持，大量事实表明，事情在商务层面沟通时，仿佛进入了另一个维度，很多难题也有了解决办法。

5.学习利用一些谈判技巧​

罗杰·道森（Roger Dawson）作为国际首席商业谈判大师，以其丰富的谈判经验和深刻的洞察力，创作了广受欢迎的谈判指导书籍《优势谈判》。这本书不仅在全球销量超过1000万册，而且被广泛应用于各种商业和日常谈判场合。

信息

本书有多个版本，最新的英文版
Secrets of Power Negotiating, 25th Anniversary Edition Roger Dawson 2021-10-01

中文版也有多个出版社的不同版本，百度云盘下载 PDF 中文版

《优势谈判》作者:(美)罗杰·道森，刘祥亚译 重庆出版社 2019-11-01

链接: https://pan.baidu.com/s/1rebh0PxY_HAARZQbV7VeLA 提取码: geq8

书中介绍了一些谈判技巧，以下是部分标题摘录:

开局谈判技巧

  • 开出高于预期的条件：强调在谈判开始时提出高于自己期望的条件，以争取更多的谈判空间。
  • 永远不要接受第一次报价：阐述为何不应立即接受对方的首次报价，并探讨如何有效应对。
  • 学会感到意外：通过表现出对对方条件的惊讶，来影响对方的谈判策略。
  • 避免对抗性谈判：倡导通过合作而非对抗的方式来解决分歧。
  • 不情愿的卖家和买家：利用“不情愿”的策略来增强自己的谈判地位。
  • 钳子策略：通过要求对方做出改变来逐步缩小双方的差距。

中场谈判技巧

  • 应对没有决定权的对手：识别并应对那些没有最终决策权的谈判对手。
  • 服务价值递减：讨论在谈判过程中逐步减少让步的价值。
  • 绝对不要折中：解释为何折中往往不是最佳解决方案，并探讨更有效的策略。
  • 应对僵局：提供解决谈判僵局的方法和技巧。
  • 应对困境：讨论在谈判中遇到困境时的应对策略。

终局谈判策略

  • 白脸—黑脸策略：分析并应对这种常见的谈判技巧。
  • 蚕食策略：在谈判即将结束时提出小要求，以逐步达到自己的目标。
  • 如何减少让步的幅度：探讨在谈判中如何以最小的让步换取最大的利益。
  • 收回条件：在必要时收回之前提出的条件，以重新掌握谈判的主动权。
  • 欣然接受：学会在适当的时候接受对方的条件，以达成双赢的谈判结果。