做事情需要讲究心法，这是因为只有内在的理解了，才会真正地运用。
作为PM，其实是一个承上启下的角色，对于下面，需要做的就是搭建一个平台，让你的项目组成员在里面起舞；同时你要告诉他们：做什么以及怎么做。比如做项目你有没有在每次迭代开始开项目启动会，告诉本轮迭代的周期是怎样的，项目组各个成员谁都负责什么任务？然后是你要指导他们，如何来做任务才能做得好。其实对于成就感太强的人做不好PM，因为这种人什么事情都希望自己做，追求一种独立的成就感，但是项目那么多事，你干的完？及时你干的完，那么要你PM是要站在一个项目的高度上面，系统的来看待问题，就是因为成员每个人都是各司其职，每个人都作为系统的一个节点而没有考虑其他节点，而你PM，其实是一个站在系统之上观察各个节点的人。所以，PM的成功是指导的成功，而不是独立完成的成功。其实很多技术转管理需要时间甚至失败就在于做技术出身的人很多都是追求成就感的人，因为历史上这种成就感带给过他们很多荣耀和"奖励"的成分，所以他们认可并追逐这种感觉；所以，其实大部分的技术人员其实是不适合做管理的，就在于这一点，到底能不能绕过这个弯，同时是否能够掌握新的工具和模式：指导，是他们转型成功的关键。
其实，作指导对于一个人的挑战更大，因为指导就需要你有更高的理论水平以及实践经验，同时还要有比较好的表达能力和沟通的意愿，不能等着项目成员来找你，而是你主动去找项目成员，和他们沟通交流，并作出指导；我突然之间觉得饿自己其实有必要看一下《Code Complete》以及《Java 设计模式》，这些都是谈资和指导方针，作为一个专家型的PM其实是最就有权威和说服力的，那么不醉心于专家的专家才是高手，他懂得"专家"其实只是工具，他的本行是管理。
再回到平台的问题，那么引出这个概念其实是想要说明：你的项目组成员要能够在这个平台上面恣意的起舞的前提是：他要从你那里得到信心！其实这种信心是来自于你的系统性的输出得到的，比如来了一个需求变更，你是着急败坏的分派下去，还是稳当的记录下来变更，对变更进行评估，和团队成员讨论时间节点以及对评估的认可，最后发给客户确认；这两种反馈，成员所获得的信息是完全不一样的，信心也是完全不一样，讲到这里，信心的本质来源于PM本身的处理方式，或者说PM的信息如何。信心传递可以这样看待：PM就是一个骑士，你的团队就是坐骑，那么你的信心骑士直接传达给了团队；那平台作比较可能会更加有形象一些，所谓的平台就是一种你的场，你的处理机制所形成的一个项目范围平台。那么，你首先就要形成你自己的处理项目管理各个阶段各个情形的系统，当项目平台有输入的时候，你的这个项目系统就会根据输入进行有条不紊、有理有据的处理，保证项目平台的平稳。
对于高一级的管理层而言，他们希望看到的是一个充满活力的"管家"，将一个项目交给你之后，就相当于把一单子事情交给你了，你需要呈现的就是：你是这件事情最熟悉的最了解的人，这一点就像是管家背后其实是一个PMIS（Project Management Information System），我需要什么数据，我需要了解什么情况可以从你这里得到最新鲜最及时的最准确的情况；至于你是怎么搞的，没有人关心；你可以自建系统，你可以摆弄Excel或者其他，甚至强迫项目组员每天为你上报信息；这些都不重要，重要的是当他需要数据的时候，你可以脱口而出。这些信息包括人员的（谁，负责什么职责，什么时候加入，什么时候退出），项目的（有多少个功能块，多少个页面，风险多大，现在有多少个Bug，客户反馈如何），进度的（进度延迟还是正常，共多少个Bug，已经解决多少个Bug，已经完成了多少个页面、多少个功能点）；这些信息都是每天你作为PM需要跟踪和思考的，因为风险分析都是通过这样的每天的跟踪和监控来实现的。总之，能够告诉他们项目的感性内容（客户反馈，团队情况）以及理性内容（数字！数字！数字！）是他们想要看到的情况大，当然如果还有各种美妙的图标再好不过了（领导都喜欢看图，最不烧脑）。
好了，你需要好好考虑一下，你是如何来呈现在你的团队中的你以及领导面前的你。