场景再现
==================
项目经理A:
按计划，你们的项目现在进入测试阶段了吧？再有两星期就应该结束了吧？
项目经理B:
嗯，几乎没有遇到什么问题就把项目做完了，不过最近似乎不是那么顺利……
项目经理A:
出了什么问题？
项目经理B:
有一个问题到了现在才暴露出来的，是这次开发的新系统和已有的一个老系统对接得不太好，导致老系统频繁死机。
项目经理A:
你没有从测试团队得到任何反馈吗？
项目经理B:
这正是让人头疼的地方。我从测试团队那里定期得到状态更新，但是他们从来没有提到过这个问题。测试团队认为自己有能力解决这个问题。
项目经理A:
你是怎么知道的？
项目经理B:
原来是客户首先发现了问题，并反映了测试团队，测试团队自认为自己有能力解决，却选择迟迟未报。这不马上就Release了，尝试多种办法，问题还未解决，所以客户Email通知我了。
若是两个星期前，我们也许能够解决这个问题，如今能否按时Release都是未知数了，项目结束日可能要向后推了。
项目经理A:
哎呀，看来是问题升级制度出了问题……
==================
一个问题出现了，团队大多数人知道，而项目负责人却不知情，岂不悲哉？
这不是偶然，想必测试团队有他们的理由：“很多技术人员生来就是解决问题的，他们可能认为自己能够解决问题，也可能觉得如果提出这个问题，别人就要审查他们的工作。他们可能不清楚，问题升级机制会增加问题的可视化、追述性，能让问题更快地得到解决。”
问题，可以统称为要求回答或解释的题目。大项目中，可能每天都会有人向项目负责人反映各种问题，一般来说，这些都不是什么大问题、重要问题、至急问题，大部分只是一些常见问题，仅需要从一个或几个可行的替代方案中迅速做出决定即可。很多时候连问题都算不上。例如项目资料存放路径在哪？SVN密码过期了，怎么办？等等。
真正重要问题、至急问题是项目团队无法短时间完全解决的、会阻碍项目整体进程的问题。从问题现象收集、到问题本质分析，是需要特殊的项目管理过程的，而这一过程可以简单看做是问题升级制度。如下：
・积极主动与项目干系人取得联系，进行沟通，告知问题发生缘由、影响范围、后续措施等等
・持续不断的跟进，确保问题尽快解决
・如果问题不容易被解决或处理，则需要采取特殊的问题解决技巧。
实际项目中，团队成员看见最多的是问题List，是每一次例会时，收集上来的所有各式各样的问题。然后由项目负责人整理、总结成文档，然后事后逐一解决。这或许是最简单的问题升级机制之一。
我发现两个奇怪的现象：
①如果项目负责人不主动去问，或不在例会上询问团队成员是否有困难、问题时，似乎很少有人主动向项目负责人反映问题或情况。都认为自己可以克服，毕竟自己是技术人员，这样的问题都解决不了，会不会被他人小看？直到“纸包不住火”的时候，才会走上前，向你言明一切。
②有时候，项目负责人会屏蔽掉团队外干系人反应问题的渠道，误认为问题升级制度仅限于团队内部，而非外部。其不知“当局者迷、旁观者清”的道理，外部干系人虽不是团队成员，但也不能独立整个项目之外，他们可以从另一个角度，或360°来观察团队、项目的整理运转情况，并有责任及时向项目负责人反映问题、提出建议。恰恰很多项目负责人却把问题List的访问权限设置为内部反问，悲呼？
问题升级机制不是项目负责人个人的事，是团队内外共同参与的事。整个团队都要清楚，他们是其中的一部分，发现重大问题不应该依赖项目负责人主动轮询，而是主动及时上报。项目负责人需要留出反馈渠道，供外部干系人在遇到问题时都应当把问题揭示出来并上报。
提出一个重要问题的做法不是一个负面影响或包袱。是在积极主动地识别问题、发现问题，这样团队才有时间、有可能合理利用资源、调配资源，找到替代方法并实施解决方案。反之……
场景中，如果测试团队能第一时间把问题反映到项目负责人；或是客户发现问题后周知测试组的同时，若能CC项目负责人，想必都不会出现后期的被动和尴尬。
测试团队发现了问题并且认为他们自己可以解决，他们采取的第一步骤是值得肯定的。如果团队自身能够解决问题，就不用升级为重要问题了；反之，经过最初的解决方案没有成功，他们就应该把问题抛给项目负责人，使问题升级化。可惜，他们选择的是继续尝试，直至最后项目结束日后延。可见，项目的问题升级机制根本没有得到普及及强化，{项目经理B}对此难辞其咎。
---------------------------------
菜鸟级 QQ管理交流群：295388584
微信互动（管理心得交流站）：GLXDJLZ
刚刚初步，菜鸟征集中。。。。。。
