提问：我是做直播的，项目需求方不懂直播，往往给出的时间不够完成项目，而且项目执行期间会随意添加需求，就造成需要添加人手来确保时间内完成项目，项目的需求方的职级又高于自己，对于这样的需求方要如何去管理？
老邱解答
其实甲方也是需要去管理的，而不是一味的修改需求，特别是直播的互联网产品。我们改变不了甲方的很多思路和想法，但是我们一定要知道变化是存在的。如果我们还是按照原先瀑布式项目管理方法的话，先排一个大的项目计划，然后由于甲方那里需求变化一直在变导致我们的项目一定是手忙脚乱，是甲方错了吗？还是我们应该更懂得要适应现在需求变化非常大的项目模式呢？
世界一直在变化，用户习惯一直在变化，项目交付物一直在变化，所以我们项目管理人的思维也需要与时俱进。我们不再是定了计划直接往下拼命的去做项目，我们更多的要考虑如何去拥抱变化，我们应该把更多的时间放在人与人的交付，我们应该尽量少的把时间浪费在文档撰写上面。在这样子的挑战下面，对于项目经理的能力也是拥有相当大的变化，我们需要更有弹性，我们需要更多的引导技术，我们需要更多的拥抱变化。讲简单了，就是不要一根筋的死做项目，我们需要把项目做活了！
我们对于甲方的管理应该是由软至硬的一个过程，之前我们需要大量的引导触发他的需求，然后尽量确定需求，定义初步范围。我们也要很清楚的了解到这个范围是随时可以更改的，所以尽量把范围做的可灵活可调整一些。敏捷式的管理甲方，敏捷式的管理需求，最终可以有非常好的效果，客户也满意了。
项目启动之后，我们需要首先定义角色是谁。甲方是（Product Owner），他负责明确他自己的需求和待办列表中用户故事的价值排序；项目经理（Scrum Master）敏捷教练，他最了解敏捷的原则和方法；敏捷团队可以是主播、道具、灯光、剧务等人员大家一起参与进来。
首先我们要明白甲方真正需要的是什么，我们完全可以用敏捷的用户故事撰写方式，为甲方把这些想法写下来，然后询问每一个故事在他心目中的价值，那么我们可以知道哪些是高级别的需求，哪些是低级别甚至可以不用去考虑的需求。而对于这样的触发和引导是非常关键的，只要是他的想法，务必以用户故事的模式写下来。
作为什么用户，希望如何，这样做的目的或者价值何在。用户故事在软件研发中又被描述为需求。用户故事通常的格式为：作为一个<角色>, 我想要<功能>, 以便于<商业价值>。
另外我们需要为甲方营造一个环境，用户故事不单单只是甲方自己的需要，更多的要引导甲方以甲方的甲方去思考很多拥有商业价值的用户故事。因为只有他懂得自己的甲方们到底喜欢什么样子的产品或者什么样子的效果。
通常可以这么写：
作为一个30岁的家庭主妇，我希望能够XXX，以便于XXX
作为一个正在上学的女大学生，我希望XXX，以便于XXX
作为一个35岁上班男性，我希望XXX，以便于XXX
甲方的甲方的思路撰写其实很有用，因为直播最终要产生的效果是能为你的甲方产生变现，所以你也要非常清楚甲方的甲方到底喜好是什么，以便于规划更好的直播效果。
当然对于这些用户故事我们的团队需要一起估算故事点，然后自我认领故事大家一起准备即可，这些我就不做更详细的分享了。
另外一个思路就是需要粘着甲方一起做项目，我们尽量鼓励甲方一起参与到我们的直播中来，因为直播应该不单单只有一次，我们需要他切身感受和参与到我们的项目中来。我们可以把这个当做是敏捷的评审会议，让甲方真实的感受我们为了他当时的需求准备的这一次交付（一次冲刺）。当然，直播之后也可以听一下他的感受和建议，作为下一次直播的优化线索。
当甲方爸爸走了之后，我们需要对本次直播做回顾会议，我们团队们一起大家做一次总结：这次直播过程中我们的经验教训是什么，我们如何优化未来的项目过程。
我们通过这样专业的敏捷体现，甲方对于你们项目管理的专业程度应该是非常赞赏的。我们也没有一味地把甲方的一些想法变化认为是变更管理，我们更多的是拥抱变化，这样真的是朝着我们效果为导向的目标挺近的。
其实，作为项目经理好好管理项目，甲方其实也是需要去管理的，不是没有好的方法，是我们真的懂不懂项目管理。世界变化真的很大很大，甲方的需求变化也很大很大，一切的项目管理都需要我们与时俱进，我们一定要有一个与时俱进的心态，这样才能更好的管理项目。