名出色的项目经理知道什么样的组织、团队和产品不适合自己。如果你发现自己身处下面的状况，问题可能不是出在你的身上。所在的组织可能有问题，而现状可能已经无法控制了。

至少，你总是可以有下面几个选择：接受目前的状况并心中有数，转换到组织中的其他项目，改变所处的组织。你有可能促成组织的改变。下面是应该注意的警告信号。

什么样的组织不适合你

你不能选择团队成员。很多项目经理的团队成员会随着他们转战各个项目。偶尔，有一个成员不能完成你分配的工作，或者不能融入团队。你也无权让他离开团队。

如果项目经理不能获得自己需要的人，先想想自己是不是解释过为什么需要这些人，而且要确保这么做。如果能够把成本或是收益与这个职位相关联，那就再好不过。我曾经要求给项目分配一个发布经理，结果被告知：“JR，我们是不会把钱白白花在一名发布经理上的。开发人员非常清楚如何签入他们自己的代码。”

我不担心代码签入的问题，我担心的是不同分支和不同平台的代码如何管理。我让每个人记录日志，记下自己使用SCM遇到问题时耗费的时间，还有必须自己手工写SCM脚本用去的时间，等等。这样记录了一周，发现团队在SCM上用去了30小时。我把这个结果告诉我的经理，可他不相信。我就让团队再记录一次相关的时间。下一周，他们用了38小时。这下我的经理就同意了，我也雇佣了一个人作为承包商，后来此人成为了永久雇员。项目经理可能要用“人时”（person-hour）来说明项目的损失。

不过问题不仅仅是无法雇佣新人。我见过一些团队，项目经理备爱一个团队成员的困扰，这位成员要么是无法完成工作，要么是无法跟团队整合。如果你处于类似的状况，要确认你首先提供了有效的反馈。要是你已经事先说明了你要的结果，并且已经就工作或是个人的行为提供了反馈，那么让这个人离开团队就是有意义的。

我曾试图将工作状况不佳的团队成员与团队离开，可从未成功过。让这些人在身边转来转去，会令其他的团队成员焦躁不安，这就像是有问题的人反而得到了奖励，因为他没有从事相关工作，或是没有融入团队。

项目经理要让不合适的人从团队中离开。如果不能，想想你自己吧。也许是该换到别的项目，更有可能的是，离开这个组织的时候了。

出席会议变成行政任务。如果在开会时，高层总是盯着谁列席了会议，谁没有来，你也因此不能选择参加哪些会议，那干嘛还在这样的组织里浪费时间？要先打听下是不是有人在盯着会议的人员参加情况。也许你做出了与事实不符的假设。如果你的假充正确，还是收拾收拾东西走吧。现在的这个组织很快就会被淘汰掉。

出资人让你不得好死。你告诉出资人，让他对不太乐观的项目前景有个心理准备，结果他跟你说：“那我就把你的头拧下来。”如果人们受到威胁，或是觉得项目的失败全都归罪于自己，他们就很难在工作上再现出色，起码我见过的大部分人如此。

有些项目经理觉得这样的环境很能鼓舞人，我不这么想。要是你这么想，那恭喜你，希望你能更加强壮。你会需要它的。不过要小心，这是一种命令与控制式的环境，而不是协作式的。协作是绝大部分项目成功的必要条件。

出资人坚持认为人们都应该同时处理多个任务，而且不愿意作出改变。你已经解释了多任务会带来的延迟效应，而出资人仍然无法想清楚哪个项目的优先级最高。而且，能否成功交付项目对你来说至关重要。

如果拿下着高薪的这帮人不愿意做出关于项目组合的决策，那你为什么还愿意管理一个注定要失败的项目，并将自己置于毫无获胜希望的局面之中呢？你不必如此，还有别的选择。

别人想让你承担一些开发相关的工作。项目团队除了你之外，还有三个人，而且别人觉得你应该写代码、测试、写文档以及其他的工作。反正人家觉得你处理完项目管理的工作之后，应该做一些技术和开发上的事情。

咳咳，如果你担任项目经理的团队成员多于三个人，而且你也兼任他们的项目经理，那你是不会有闲暇时间的。（如果只有两个人，你还有可能干点儿技术活儿，只要你能确保自己的工作永远不会处于关键路径上。）要是团队成员以矩阵式方式加入项目，而且他们只从事与项目相关的工作，并可以按时完成，假定有5个成员，那么你也许还能做一些没有处理关键路径上的技术工作；要是少于5个人，那么你所负责的任何技术任务将位于项目关键路径之上。（如果所在的项目应用敏捷式生命周期，你作为教练或是Scrum master,而且团队已经做到了自行组织和管理，那你每周就能腾出来更多时间干技术活儿了。）

我看到的情况是，项目经理没有管理项目。他们在编写代码，但是没有管理风险，他们没有留意测试的进度，他们没有产生仪表板上的数据，他们也没有评估版本发布条件。如果你在一个喜欢开会的公司工作，还得把所有的会议加到工作列表上去。

如果你在管理项目时，要帮助大家看清目标、移除障碍，还得监控他们的进度，你是没有时间间从事技术工作的。

管理层强制切分项目工作。假如你是开发经理。你启动了一个项目，努力工作，并声称开发已经完成，并向下一个项目进发。你的同事——测试经理——开始测试工作。两天以后，他冲进你的办公室，跟你说：“你的开发人员活儿没有干完。项目是不可能在四天之内完成了。你得把你的人都给我用，好修复缺陷。”可是你已经把人员都分配到另一个大项目中了。现在怎么办？

你们都是职能兼项目经理。两个人都不能完全对项目负责，而且你们有人（很可能是测试经理）会因为延迟发布而遭受责骂。这并不是测试人员的错，也不是开发人员的错。当高层将项目组织成互相隔离的部分，而且作为职能经理的你对此毫无怨言，这都是管理层的问题。

在7.3.1节中，我提出了一些建议，读者可以尝试一下。不过对你来说，真正的问题在于：当组织不以结果作为导向时，你能在自己的职位上发挥作用吗？要想一想：是不是值得花时间和精力来改变组织？还是干脆改换组织？

噢，成为拯救公司的英雄，这种感觉真得很好。不过当你卷起袖子，接受并不完整的资源并准备启动项目时，这么做对于团队其实毫无益处。在资源不足的情况下启动项目，是完全不可接受的。

如果项目经理不能帮助管理层发现项目的驱动因素，这个组织就不适合你。这个组织会继续利用你善良的天性，并将你推入必死的项目之中。别让自己掉进去。要么改变项目，根据驱动因素、约束和浮动因素来重新组织，要么走人。在资源不足的情况下启动项目，必败无疑。

你总是听见人们说“你没法融入团队”。项目经理的工作要求你将项目视为组织中最重要的工作，而且必须依此行事。如果你为了项目的成功而推行的做法得不到认同，而且总是听到“你没法融入团队”这样的说法，那么也许这个组织根本不需要你。

工程经理的视角并不仅限于一个项目。不过，即使是工程经理也不允许组织对他们横加干涉。你是项目经理，你说了算。你对项目的成功负有责任，要满怀热情地实现这个责任对你的要求。