综合应用：向老子取经将项目管理于无形

学老子，在无形的
平台上管理项目，不知道有没有；其次，这对你有好处。其次，恐惧它；其次，侮辱它。当我成功的时候，众人都说:我自然——老子道德经上面的介绍
摘自老子道德经。是的:我们的领导就是要让下属感受到他的存在；二等领导是人人爱戴的领导，三等领导是人人畏惧的领导，四级领导是人人都渴望带他的领导。当一切都做好了，老百姓以为没有干扰，自然发展就实现了。也就是说，完成的过程不是别人强迫的，而是人的本性使然。
项目经理的领导，项目经理的指导，项目经理的规划，项目经理的管理，是项目经理需要担负起的让软件项目实现商业价值的重任。虽然项目经理在整个交付机制中起着关键作用，但是如果他成为一个团队的中心，就会给团队带来不必要的风险。实际上，项目经理应该以更温和的方式执行项目，从内部帮助团队取得成功，建立一个能让所有人(包括他自己)受益的系统。
*传统领导风格
敏捷和极限编程方法的基本原理非常适用于隐形项目经理的观点。在传统模式下，项目经理负责所有事情，包括技术工作的详细描述、管理客户、分配任务、跟踪和监控进度以及指导团队的运动。一切都紧紧按照计划执行，并通过正规渠道反馈。另一方面，敏捷方法将客户和开发人员尽可能紧密地联系在一起，允许客户优先考虑他们的工作，允许开发人员评估他们的工作并协调他们的意见。在这种情况下，虽然项目经理的各项工作仍然可以正常开展，但是需要态度上的转变。
自始至终的信息透明
建立一个开放、诚信的环境是所有项目经理的重要任务，需要从项目一开始就开始。越快越好。将信息分发给整个团队可以让成员不那么担心是否有任何重要细节被隐藏。一旦建立了这种透明度，团队的信任度就会增强，他们自然会信任项目经理。这是最理想的情况，这样团队成员就可以专心于手头的工作，而不用担心是否有什么突发状况在等着他们。
具体来说，这种氛围意味着团队和利益相关者可以通过一系列的渠道得到良好的沟通，比如:站会、回顾会、重要的状态报告、非正式会议，并鼓励其他人提出问题。
这几乎可以与极限编程中的持续集成相媲美。通过持续集成，开发者每完成一段代码，就可以把它放入信息库，对它进行一系列测试，并立即得到状态报告(如失败或通过)。如果团队可以在一天内多次重复这种活动，那么他们就可以大大降低项目在发布代码时可能遇到的风险。也可以说这是每天一点小麻烦，避免通常潜伏到发展末期的危机。
作为一个项目经理，同样的原则也可以应用在团队的进度、问题的处理和汇报上。项目经理要听到尽可能多的“坏”消息，比如延期、事故、失败，或者成绩，这样才能对实际情况有一个准确的了解。通过在整个企业中传播这个原则，不隐瞒一些信息，团队遇到难以应对的突发事件的几率会大大降低。而且，其实所有的问题都可以由团队来解决——只要能提前告知，并给予足够的空时间。只要你满怀信心的把所有的事实告诉整个团队，到了该调整的时候，自然会做出调整，成功之路也会更加顺畅。
睁大眼睛，竖起耳朵
管理团队可以说是一项实时活动。计划管不了人，只有人才能管人。时不时的看一眼，都不能称之为参与，而且如果没有人帮助团队处理路上的障碍，项目就很容易陷入一些不重要的事情，从而达不到目标。
理想情况下，项目经理应该始终关注整个团队。用眼睛看，用耳朵听现在发生的事情，快速收集信息。然后，通过思考，做出决定和行动。通常正确的行动是很小的或微不足道的，但由于时机和环境条件，它可以发挥非常大的作用。说服、建议和询问都是比权力、命令和指挥更有力的武器。如果涉及两个或更多的团队，坐在他们中间，或者最坏的情况，在每个团队上花费一定的时间。一个复杂软件项目的需求和方案的流动性也必须在管理模式中得到体现。
正确的推广和协助
在每个团队中，都有各个技术领域的专家来编写正确的方案。但是，衡量一个项目成功的标准不是和计划有多一致，而是能不能实现商业价值。所以项目经理不需要知道各种问题的答案。他要做的就是把每个人的想法放进计划里，同时注意每个人喜欢做什么，擅长什么，应该做什么——如果这三件事一致，那么工作效率就有保证了。
促进团队成员之间的正确沟通，帮助一个群体做出正确的结论，或者清除团队内部的障碍。在这些过程中，项目经理的助理角色应该关注个人的需求，通过给每个人分配少量的职责，详细解释每个问题，或者在他们完成一项任务时简单地表扬他们，来提振成员的士气。
让项目经理变得多余
项目和公司一样，只有系统地执行，才能带来效率。这个“系统”不同于“定义的过程”。系统代表了一种不完全依赖于特定人的做事方式。所谓“不可或缺”，就是一个制度的致命点。关键的、不可替代的、稀有类型的人才都是巨大的风险，通常需要在这类人身上花费昂贵的费用。
所以，要考虑借助敏捷思维在整个团队中发展“冗余”，以及培养一对多匹配的全能型人才。这包括团队的所有部门，比如项目经理。当然，如果项目经理需要离开几个星期，他应该为这个职位找到合适的人。然而，如果你只离开一两天，应该不会给车队带来任何问题。领导和管理可以分配给其他人，如果信息是分布式的，或者至少是随时可用的，瓶颈的影响就会减少。开发人员在团队中提高信息共享，这种做法可以扩展到团队中的任何职业。一个警觉的项目经理必须注意当他们或其他人离开时，整个团队会发生什么。这时候可以把问题作为参考，找到团队弱点，并以此为契机提高团队效率。
传统上，项目经理被认为是项目成败的负责人。因为无论是成功的荣誉还是失败的责任都没有被广泛分散，自然导致项目经理的活跃度高于整个团队。但是，要充分发挥整个团队的效率，就需要在团队和高层管理中灌输责任共担的理念。项目经理可以通过自我毁灭和分配责任来逐渐施加影响。
这并不是说你应该忽视自己的成就或者把它们拱手让人。我们的宗旨是在团队中分享成功的回报和失败的教训，让大家都自觉的放到第一线去推动项目的发展。如果项目经理能够忽略自己的需求，追求整个团队的智慧，根据情况分配责任，那么这种集体责任感就会随着时间的推移而逐渐建立起来。
激发和保护团队动力
把团队想象成一辆运行在铁路上的旧蒸汽火车。让这个庞然大物动起来自然需要一些时间，但是一旦它开始运行，它自身的力量就足以让它继续运行下去。然后，项目经理就可以把工作重心从加煤、煽风点火(项目前期的内部活动)转移到铺设铁路、保证列车速度(外部事务)上来。
项目经理的任务就是创造一个环境，让每个人都能发挥所长，写计划，解决问题。团队成员通常都想在自己的领域展示自己的才华，这种动机要好好利用。然而，任何企业的这种熵权往往会将团队的意图变成一个错误——臃肿的会议、冗余的文档、转换项目和其他分心的事情会极大地浪费团队资源。
有时候，我们会发现，下班时间的工作效率是很高的，这不是偶然。因为这个时候基本没有开会，也没有人会打扰你——只是单纯的埋头于手头的工作。你可以参考这个环境，在正常工作时间建立更高效的团队氛围。
最终责任还是在这里
虽然组织这样一个分散而系统的团队听起来很高级很开明，但项目经理的最终目的是实现商业价值。领导层会这样看——这是一种方法；它是一套用来实现价值的工具和技术。所以，并不是说项目经理就可以一走了之，把所有的责任都推给团队。实现价值最有效的方式就是打造一个真正高效的团队，能够主动消化需求。一个独立推动项目发展的团队远比一个由项目经理和任务驱动的团队更有能力。
项目经理永远是团队的关键人物，但不应该是关键人物。通过以上原则，项目经理可以利用团队成员的共同目标和共生关系，让各种角色协同工作，创造任何个人都无法比拟的业绩，无形中管理项目。