在本篇播客的节选中，敏捷项目专家Joseph Flahiff澄清了关于产品开发周期和项目管理周期之间的一些困惑，并解释了为什么有些产品开发活动与敏捷项目管理会发生冲突。在完整的播客中，你可以了解到敏捷项目管理所必需的控制，以及为何在敏捷项目中使用甘特图（Gantt chart）可能是无法回避的。

　　SearchCIO.com：你曾经说过，企业里的项目经理们在面对敏捷项目时总是感到有心无力，那么他们到底遇到了哪些问题呢？

　　Joseph Flahiff：首先，在一个普通企业中开展敏捷项目和在一个软件公司里遇到的情况有本质区别。敏捷方法最初是软件企业中的开发人员用来进行软件产品开发的。这种方法论是卓有成效的，取得了巨大的成功。于是，有人就提议：“我们为何不采用敏捷方法呢，它在小企业中已经取得了成功，在大企业中应该也可以派上用场。”

　　我并不是说运用敏捷方法的软件企业都是小企业，但是的确尤其行业特殊性，所以在普通企业中的推广会遇到很大的障碍。而存在各种障碍的根本原因在于不是所有企业都是以软件为主业。在敏捷的实践里，你必须和软件产品责任人有大量的交互，这在软件企业中是一个特定的职位。

　　而在其他企业中，产品责任人是一种角色而非一种职位。设立这样的角色是因为我们都知道这是敏捷项目的必需，否则将导致项目的失败。于是，我们选出一个人（其拥有其他的全职工作）说：“你现在成为项目负责人了。”这个人从而在其本职工作以外又在敏捷项目中承担了特定的职责，这样做自然会产生问题：他无法挤出一个敏捷项目责任人所需的工作时间。

　　你是否有办法来解决这个问题呢？企业是否已经开始指派特定的人来专门负责？

　　Flahiff：这依然还是个问题，而且企业通常也没有指派专门的人手。我认为首先要做的是认识到这个问题，否则就还会陷入到僵局里：“我们的产品负责人投入得不够多。”或者“他们从来都不够投入，不要指望了，另寻它路吧。”

　　解决问题的关键所在何处？关键就是你需要有人在项目中能够代表重要客户。因此，真正需要的可能是数人，而不是仅仅一个产品负责人。敏捷偏执主义者会认为我的看法是错误的，但是，我的观点来源于真实的世界（这才是具有现实意义的）。再次强调，只有你认识到了这个问题，你才能去切实了解问题所在，比如这个角色的目的以及我们到底想要做到什么。在此基础上才能找到具有创造性的方法，恰如用一群人来代表客户，而非仅仅一个人而已。

　　这是问题的关键所在吗，或者另有其他主要因素？

　　Flahiff：另一个关键因素在于敏捷是一种产品管理方法，而不是一种项目管理方法，这两者之间存在着本质的区别。项目是工作的一个具体部分，对此Project Management Institute Inc.有着明确的定义：一个项目是为了创立特定产品、服务或结果的临时性投入，有确定的开始和结束。

　　而如果你是在做产品管理，这些都是不存在的。首先这不是临时性的工作，而是一种持续的投入。它可能拥有确定的开端，但是未必有确定的结束。虽然可能趋向结束，但是这并非是产品管理定义的一部分。产品管理可以这样来描述：“嗨，我们有个这样的软件产品 – 我们想用其来开发客户基础，或者服务于一个客户基础。我们知道客户的需求是持续变化的，因此我们会不断地进行工作以保证产品特性的随需而变。”

　　至此，再次回到产品负责人上来：在一个传统的项目中，项目经理的部分角色在于项目范围的管控。你知道在敏捷项目中不应该进行范围的控制，我们也确实没有这样做。我们是把范围看做一个不断变化的事物，但是如果你要试图把项目作为一个具有确定开始和结束整体进行推进，你就会面对范围控制的问题。当项目负责人决定添加新功能的时候，你会认为他们做错了。但是如果考虑到他们作为产品开发周期掌控者的角色，就必须承认他们有责任按需加入新功能，否则就是失职！所以，我们其实是想让产品经理能够跟上需求变化的。功能的加入是具有明确定义的，而且确实是我们在敏捷项目中所需要的。最终可见，这是一个产品开发管理周期而非项目管理周期的范畴。

　　现在可以得出结论，一个产品也许有和项目相关的生命周期，比如其拥有各个版本，而每个版本都可以看作一个具有确定开始和结尾的项目。但是这些项目都局限在产品的特定范畴内。如果你以这样的角度去看待项目，将其作为产品维护和交付工作的一部分，那么就可以更加容易地运用敏捷方法（因为你对自身工作在企业整体中的定位有了更宽广的视角）。你不再把眼光局限于项目范畴，而是着眼于如何帮助企业向内部客户交付完整的产品。