Coordinator在项目中指的是项目协调员，一般这一类人员会在某个职能部门兼职做项目经理，因为现在做的很多都是标准化产品，所以企业并没有设置全职项目管理岗位也是非常正常的。对于文科生的项目经理来说，特别是IT行业自己是一个技术小白也是很正常，我觉得并没有很多必要去恶补那些IT的技术语言、代码、命令行等等的东西。取长补短这句话固然没错，但是人的精力往往是有限的，你应该发挥自己的长处来弥补自己的不足。

如果回到我自己过往的职场，如果我是你我确实是会补一部分IT知识，但是这些知识只是保留在沟通层面，而不是代码的应用层。你可以根据客户的业务需求转换为项目的交付目标，让团队们去完成即可，毕竟项目经理是对接客户业务和团队交付的一个非常重要的桥梁。你可以是个优秀的沟通者，你更是一个能理解客户业务语言的那个人，PMBOK整本书上真的没有提到过很多技术方面的内容，你要做的是比技术更重要的管理和协调工作。

技术这个东西没有底，而做技术的IT团队们可能他们的视角并不很高，他们可以单兵作战，但是他们并不能做好很多团队协作。就好比你是一个团的团长，你没有必要上战场去拼刺刀，你要让整个团队动起来和配合协作，然后达到战略目的即可，这才是一个优秀的团长，优秀的项目经理。

另外一点就是现在已经是2025年了，很多你不懂的IT知识你完全可以通过AI辅助去分析，然后再跟团队们去沟通和协调，文章篇幅有限，今天我就给大家讲讲AI时代真正优秀的项目经理如何通过人工智能做好项目的需求管理。

需求是什么，需求是多变的，在项目启动的时候并不可能规划的非常清楚，而这一点是需要靠优秀的项目经理去收集需求，去确认需求还有筛选需求。这一点如果做的偏差，未来整个项目可能都是偏离范围的，而这些内容并非一个IT程序员能懂的。而熟练的运用PMBOK上的知识和工具，再配合AI是完全有可能给你提供大量的辅助。

一、首先我们要知道需求从哪里来

这时候对于项目相关方的识别非常重要，如果你有一个权利、利益方格去对相关方们进行分类的话你会很清楚未来使用什么样子的工具去收集他们的需求。

权力、利益都很高的人。他们相对项目起着至关重要的作用，他们的需求我一定会利用访谈这种工具好好的去明确他们的想法，甚至我会带上一两个项目的技术核心团队，直面沟通我们是否有他们想法的解决方案。而他们这种人可能包括了项目发起人、客户、用户部门经理等等。甚至我们为了保持他们之间的有效沟通，我们会让他们想办法一起参与项目需求会议，这样子各方的人的沟通是有互动式的。

权力低、利益高的人。这些可能有很多很多的人，我可能没有必要一对一访谈或者开个几百人大会，这时候我们使用的工具往往可以事先做好一些问卷来收集他们的意见和想法，说不定可能会有一些意想不到的对项目有利的各种想法的存在和出现。问卷怎么做呢？当然我们可以使用AI来协助我们使用，只要提示词准确，往往可以几分钟就做出一份你非常满意的问卷。

以上两类人的需求是最容易提出项目需求和想法的人群，而这些人在很多沟通和会议的时候我也是会使用人工智能帮我去自动化的做会议录音和纪要，记得带一两个自己的IT技术核心团队一起去，既看上去是对客户的重视，也可以面对面的去谈很多技术上的问题。你需要把每次会议内容都有会议纪要，你要存档问卷的很多内容，这些就是初始的需求文件了。

对于那些权利很高、利益很低的相关方。我觉得如果他们愿意给我们项目提出需求更好，但是我并不一定会主动约他们访谈或者会议，因为他们虽然权利很高但是并不关心项目。说白了就是项目的成败根本不会影响他们在企业中的利益，这些人我不得罪他们即可，也不用花很多时间去沟通。

对于那些权利、利益都不是很高的相关方。你虽然识别了，但是也不用放很多精力在他们的需求整理和收集上面，按照PMBOK的说法应该用的是监督。因为他们的权力利益是会变动的，也有可能是当时你识别的时候是有误差的，因为甲方也有可能会有公司的人事调动和办公室政治问题。

二、其次我们应该如何梳理这些需求

这时候一个PMBOK上提到的很多次的需求跟踪矩阵他会很好的帮助你，他是连接了需求源头（它们在需求文件里）和我们交付的一张表格，也记录了由谁提出的需求以及提出日期等等细节。等于是一张需求的简化汇总表，里面要比需求文件更加精炼和直观。

这时候的项目经理往往会发现一定是会有需求蔓延的情况，这时候你千万别自作聪明的以为哪些重要哪些不重要来删除需求，这带来的一定是客户那一头的不满意，你不可能得罪任何人。如果是我会邀请权利、利益高的那些相关方们（其实他们能拍板）一起确认这个表格里面哪些要做哪些不要做，如果有疑问可以找当时的需求文件。这时候我可以想象会议中因为大家的利益不同肯定会争论或有不同意见，那么项目管理中的投票技术可以帮助到你去筛选和删除一部分不需要做的需求。对于那些争论不休的需求，我甚至会找某个高层独裁去判断，其实这些都是PMBOK上的知识，很多人只是看了但是并不会熟练的去运用。

三、如何确认这些需求

要确认这些需求我会暂时删除这些需求的来源，把某些一致的需求放在一起，这个就变成了一类需求，这种图法就是亲和图和思维导图的运用。这样做的目的是既美观又能跟那些重要的相关方们去确认这些需求，我会约一个需求确认会议。

当然这个会议可以是面对面也可以通过现代互联网技术的腾讯会议、钉钉会议来远程进行，如果有时间其实我会事先把范围说明书也写好。一个会议两件事情完全都可以解决，当然也有可能有需要调整的地方那么我们会上面直接确认和沟通。甚至有的相关方可能会忘记当时某些需求从哪里来，我们可以拿出需求跟踪矩阵和需求文件来帮助他们回忆起来。

这个会议的最重要的内容就是确认项目的最终需求，明确项目的范围基准，项目经理们别怕沟通麻烦，这些都是一定要做的事情，也为了项目在后期可以寻找各种各样的依据。我也可以用AI来做会议记录和最终确认的整理文稿，希望得到相关方们的确认，最好是签字确认，这些都是项目的痕迹。

四、如何来管理这些需求

首先大家要知道的事情就是未来可能会有需求的蔓延，讲简单就是提出超过当时范围的需求，我们在项目管理中把这些叫做变更。如果变更未来都是口头不可追溯的话将来项目肯定会出现各种问题和各种扯皮，就算项目有变更单和流程，都是项目经理自己去接受或者否决则都是非常武断的行为。另外你往往会发现每天都在得罪人，因为相关方们很关注自己提出的新需求，而每次都被你否决，他们会怀恨在心，反而他们成为了项目的阻力。

所以变更委员会会来帮助你，在你的变更管理计划中应该设立变更委员会成员，由他们来投票决定项目是否允许这样的变更，甚至你会为项目变更预留出一部分经费来做这些多出来的功能点。客户那里提出的变更请求你可以很官方的告知对方，经过我们变更委员会的投标，最终否决了这次加入这个新功能，这样就不会得罪人了。

当然他们有可能会扯皮说当时其实提出过，我们项目组遗漏记录了这些需求，那么你可以拿出当时的范围说明书、需求跟踪矩阵、需求文件来好好的证明这些需求当时是谁提出的，什么时候提出的证据了。

你看项目经理要花这么多精力在需求的整理和收集，这样我们项目未来才不会偏离初始目标，如果你的精力都花费在学习IT技术上面，那么项目管理就本末倒置了。范围是项目的初衷，需求是范围的初衷，需求也是当时商业价值的初衷。

什么是项目？为完成独特的产品、服务、成果而进行的临时的工作。

为什么要做项目？它一定是有商业价值的！