项目干系人管理的主要内容

第一步：

1：找全项目主要干系人,了解他们的想法

2：可用用多种方法进行调研,如问卷调查/头脑风暴/原型法/会议等

 3：做好需求确认

第二步：做好调研表格，如下格式

第三步：

     市场调查工作必须有计划、有步骤地进行，以防止调查的盲目性。一般说来，市场   调查可分为四个阶段：调查前的准备阶段、正式调查阶段、综合分析资料阶段和提出调查报告阶段。

    1：调查前的准备阶段。

    2：正式调查阶段。市场调查的内容和方法很多，因企业和情况而异。

    3：综合分析整理资料阶段。当统计分析研究和现场直接调查完成后，市场调查人员拥有              大量的一手资料。对这些资料首先要编辑，选取一切有关的、重要的资料，剔除没有              参考价值的资料。

干系人分析是系统地收集和分析各种信息，以便确定在整个项目中应该考虑那些人的利益。通过干系人分析识别出干系人的利益、期望和影响，并把它们与项目的目的联系起来。干系人分析也有助于了解干系人之间的关系，以便利用这些关系建立联盟和合作伙伴，从而提高项目成功的可能性。在项目或阶段的不同时期，应该对干系人之间的关系施加不同影响，所以，要基于干系人的价值进行分析。

故事地图是客户价值优先级排序的工具，提供了一个关于功能合适交付的产品路线图。故事地图解释哪些会纳入第一个版本、第二版本或者子版本。故事地图还可以用作和跟干系人沟通的工具，把地图放在墙上作为一个项目计划的信息发射源。故事地图鼓励大家用不同的凡是参与，通过可视化的展示引发干系人的关注。

把干系人和用户的优先级纳入到项目的优先级中并且执行，结合干系人的优先级来进行项目优先级的排序，让干系人价值具体化，确保不要做一些干系人不支持或者没有价值的功能。

管理干系人的参与是指在整个项目中，与干系人进行沟通和协作，解决过程中出现问题，促进干系人合理参与到项目的相关活动。管理干系人的参与可以帮助项目经理提升来自干系人的支持，并把干系人的抵制降到最低，从而显著提升项目成功的概率。管理干系人的参与有多种方法，但是不管采用哪种方法，都要确保管理干系人的参与是可视的并且是可监控的。另外，要鼓励干系人参与计划会和回顾会，从而提高干系人的参与。

有效沟通是敏捷的奠基石，沟通是在不同部分传递信息。沟通管理是敏捷的一个知识领域，PMI除此之外有几个关于沟通的定义。

从敏捷的角度而言，团队间的沟通建立在过程中，通过写作、信息发射源、日常站会、回顾会、等得以促进。敏捷中的沟通倡导可视化，希望产品负责人、顾客、用户能高度参与项目并使用沟通技巧。

在敏捷中，最好的沟通方式就是面对面沟通。面对面沟通是沟通中最高带宽的沟通，所以面对面沟通也可以称为"高带宽沟通"。面对面沟通在同一个时间内可以传递的信息最多，并且能够获得一些及时的信息。而静态的沟通方法，例如文档，就不能做到这些。

项目通常需要很长时间才能完成，但是客户经常在描述他们期望的东西后希望可以尽快获得。因此，频繁地给干系人展示项目已经实现的东西就显得很重要。这些模型或者展示并不是单单让我们检查我们正在构建的东西，还可以给客户或者发起人进行一些过程展示。因此，需要及时跟干系人沟通，确保他们被及时告知当前项目的状态。

与客户密切联系并且给他们展示已经构建的项目的一些组件，保证项目过程的实际速度是可视的。过程的实际速度并非发起人或者客户所听到的，有时候会存在偏差，甚至对干系人来说是坏笑话。如果这些信息能够被尽早交付，即使坏消息也是有价值的。通过监控和讨论这些信息，可以做出更好的权衡。

速度是每个迭代中对团队能力的一个度量。这个度量帮助我们基于上一个迭代完成的故事点数评估团队后续的工作能力。当我们想跟联系人沟通已经完成什么功能，将要完成什么以及我们期待什么时候完成项目，速度就是一个很好的度量方式。团队可以在任何工作单元去测量其的速度，所以，这些单元可以是小时数、天数、点数。

敏捷建模涉及敏捷项目中常用的建模技术。模型在敏捷方法中非常重要。敏捷经常聚焦在模型的讨论和创建，而不是最终的产出物上。敏捷模型经常需要在白板上画出来，然后通过拍照记录下来。

不管你创建的是什么模型，目标都是为了交付价值而不是无关的文档。所以，要保持轻量级，快速移动以适应变更。

知识型项目的产出经常是无形的，为了减少彼此理解的偏差，把项目中出现的每一个新的想法或观点尽早地且频繁地展示出来，对于干系人之间的连接非常重要。如果团队想减少一些沟通中的隔阂，减少受到低质量的产品，那么其就要去频繁地讨论什么是"完成"。创建一个共同认可的"完成"的定义在管理干系人期望时非常重要。对软件项目来说，在声明什么事是"完成"时候之前，可以参考诸如以下常规的说法。

授权团队进行自主管理，了解如何通过最少的管理参与解决问题，是敏捷方法论的基石。这与传统项目管理者的观点不同，传统项目管理者控制所有决策同时委托任务给团队，几乎无反馈。敏捷团队决策必须包含所有成员和干系人且决策方便。因为客户参与到开发中非常重要，所以需要鼓励客户通过集中/现场支持与敏捷团队密切融合。当敏捷团队承担产品传递的责任时(即拥有所有权)，团队自身感受到授权。

谈判在敏捷项目中会出现，尤其是在讨论需求或者功能的优先级以及完成的定义的时候。团队和客户可以在功能和成本之间进行权衡，从而找到一个合适的方案。在敏捷项目中，谈判并非一定要做，而不是一个零和游戏，正如敏捷宣言"客户合作胜过合同谈判"。"健康的"判断可以给双方一个机会去充分描述每个观点，权衡利弊。

冲突是项目工作中不可避免的一部分。当大家集中去解决一些问题时，就会存在观念的差异性以及竞争利益。有些程度的冲突是"健康的"，可以确保一些观点在应用之间被充分地阐述和验证。但是，我们需要确保冲突不要升级。

创建一个让大家可以提出建设性的冲突的环境，对成功管理干系人参与项目来说非常重要。当冲突超越了正常界限时会变得具有破坏性。Seep BLeas提出了一个描述冲突的框架，帮助我们判断冲突的级别并且更好地理解冲突从1级(解决问题)上升到5级(世界大战)，如下：

如果这个冲突在第1~3级，不要立刻采取行动去解决冲突，而是让团队自己去解决。因为自组织团队是需要尝试自行解决问题的。如果团队能够自己克服冲突，它将会提升一项重要技能，在将来可以自我管理类似的冲突。如果对于这个冲突，团队不能解决，而且这个冲突还有可能升级，那么敏捷项目经理就需要介入。

减少误解和错误信息传递的一项沟通技能是积极聆听。积极聆听是指听到说者想表达什么，站在说者的角度去考虑，而不是仅仅听到说话的内容。根据关注点的不同，可以把聆听分为以下三个层级。

参与式决策鼓励团队成员参与过程决策。决策的速度和团队对这些决策的认可程度都会直接影响项目绩效与团队凝聚力。沟通和参与决策对保持每个人参与非常重要。如果在做决策的时候不咨询团队成员的想法，团队成员就有可能感觉自己被孤立或者隔离，这对于自组织团队的打造是一个风险隐患。

敏捷鼓励领导进行更多的授权和更少的命令控制。团队授权不仅可以提升干系人的满意度和生产力，还可以提升决策过程的有效性。以下为常见的几个参与式决策的模型。

我们需要找出一些方法让干系人参与到重要的项目决策中，包括迭代计划和版本计划，估算讨论和回顾会。如果这些人不参与，他们就不会对这个决策做出承诺。最终，他们也不会对这个项目做出承诺。

领导需要确保"做了正确的事情"，关注方向。管理需要确保"正确的做事"，关注方法。相对于领导来说，管理聚焦更多的流程机制、任务控制上。领导更关注人与目标。但是，并非说领导比管理者要好，有些场合依然需要管理，把领导和管理结合起来去打造团队的高效生产力。

敏捷提倡服务型领导，聚焦在给团队成员提供需要，移除障碍，并且执行一些支持型性的工作进而最大化团队生产力上。一个领导在团队中的主要角色为以下四类：保护、保障、保持、保姆。

我们要不断的创新以寻找一些改进的方法，通过实践去学习和成长；鼓励干系人为改进提出一些新的想法，并给他们机会去尝试；鼓励团队去挑战现状，既可以践行过程改进，还可以激励团队成员。

分布式团队在面对面的沟通中会存在一些挑战，用信息发射源这样的协作工具会比较好。但是，这是一个大部分项目需要解决的挑战。数据显示，超过50%的敏捷项目团队至少在一个不同的物理办公区域。为了解决这个问题，分布式团队可以用一些沟通的技术，比如语音会议、实时聊天或者用它们自己的方式提供一个共享的团队环境让分布式的这些干系人进行实时交互和聊天

1、项目干系人分析

识别出项目的干系人，并对干系人的兴趣、影响力等进行分析，理解关键项目干系人的需要、希望和期望；

2、沟通管理

根据项目干系人分析的结果，制定相应的沟通计划，并执行；

3、问题管理

对沟通过程发现的问题，记录，并采取行动进行解决；

以上就是关于如何进行IT项目的需求调研全部的内容，包括:如何进行IT项目的需求调研、PMI-ACP 敏捷项目管理10——干系人分析与管理干系人参与、项目干系人管理的主要内容等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！