⻆⾊转换：程序员做项⽬管理的三⼤误区
在成为⼀名专业的项⽬经理之前 ，我曾做过四年的“程序媛”。在那时的我看来 ，程序员是个很有意思的职 业 ，⼀个⼈敲代码的⽇⼦ ，现在回想起来 ，我依然觉得有很多乐趣。我喜欢⽤代码尝试各种效果 ，折腾新的 技术和语⾔ ，从图书馆背回来厚厚的《设计模式》 ，⼀边学 ，⼀边在我的项⽬上应⽤实践。
那时的我 ，不怎么需要跟⼈交流 ，⼀天到晚对着屏幕 ，只要跟我的代码在⼀起 ，就觉得⾃⼰可以上天⼊地， 玩得不亦乐乎 ，真当是“代码在我⼿ ，天地任我游”！
尽管当⼀个很⽜的程序员是⼀件很酷的事情 ，但是我却很早就意识到 ，做技术⼤概不是我⼀⽣的饭碗和追 求。 当我开始成为这个岗位上的“熟练⼯ ”之后 ，我发现⾃⼰开始有了更多的渴望。
直到有⼀天 ，摆在我⾯前的路 ，出现了新的转折。那时 ，组织中成⽴了新的项⽬管理部 ，于是 ，我通过内部 转岗 ，顺利地成为了第⼀名全职的项⽬经理。从此 ，项⽬管理的世界向我敞开⼤⻔ ，带领我⾛上了⼀条完全 不同的⼈⽣轨道。
美国电影中经常有句话说 ，Great power means great responsibility（能⼒越强 ，责任就越⼤） 。项⽬管理 这个岗位 ，让我从管好⾃⼰的事 ，到开始操⼼别⼈的事 ，责任范围⼀下⼦扩展开来。这种责任范围的扩⼤ ， 极⼤地锻炼了我的全局分析能⼒ 、统筹规划能⼒ 、 以及沟通协调能⼒。
但由于并⾮天⽣适合跟⼈打交道 ，刚开始时 ，我丝毫体会不到什么power，反倒经常感觉有劲⼉使不出来 ， 被新的责任压得喘不过⽓来。正是这段经历 ，让我对想要从程序员转做项⽬管理的同学 ，有了更多的同理⼼ 和体谅。
结合我的经历 ，我把这个转换过程中常⻅的问题 ，归纳为以下三⼤误区：
误区1：凡事恨不得事必躬亲
当我做程序员时 ，我的⼯作是⾼度可控的 ，我可以把每天的⼯作安排得井井有条。但在做项⽬管理之后 ，我 发现⾃⼰的产出全部依赖别⼈的⼯作 ，于是我会经常性地陷⼊⼀种抓狂的状态 ，着起急来 ，甚⾄会忍不住冲 上去 ，替别⼈做好⼈家本该做好的事情。但是 ，后来我慢慢地意识到 ，对于团队⻓期的发展⽽⾔ ，这种⾏为 的效率是最低的。 可当时的我 ，跟⾃⼰直接去做相⽐ ，想办法影响他⼈去把事情做好，要难得多。
那么 ，如何影响他⼈去做好⼀件事呢？ 在不断地反思之后 ，我总结出了成功施加影响的三个层次，分别是让⼈知道要做（Awareness）、有动⼒做（Desire）和有能⼒做（Ability）。
我曾经跟⼀位产品总监合作 ，他交待⼯作⾮常⾔简意赅 ，团队只知道最终输出的指令和结论 ，但完全不清楚 背景 ，更不⽤说明⽩他的思考过程是什么 ，以及为什么要这样做了。有⼀次 ，他的下属跟我说：“⽼⼤昨天 晚上突然给我打电话 ，让我⻢上把就要上线的活动停掉 ，不要再做了。”他⾮常困惑 ，因为团队已经投⼊了 ⼀个⽉的精⼒ ，⻢上就要⻅到成果了 ，但没等他问为什么 ，⽼⼤就直接把电话挂了。
这样的团队 ，听上去应该执⾏⼒不错 ，⽼⼤的指令都会被⽴⻢执⾏ ，可事实却并⾮如此。我发现他们完全谈 不上有做事的动⼒ ，很多时候都只是照章办事 ，出了问题也不敢去问 ，结果往往导致执⾏效果与预期相差甚 远。
对照刚刚我们所讲的三个层次 ，这应该只是第⼀个层次。单⽅⾯的⼯作交待和告知，停留在浅层次的信息传达上，只是让⼈知道要做，但并不⾜以让⼈产⽣动⼒，去促成有效的⾏动。
事后我了解到 ，这位总监之所以着急叫停 ，是为了规避短期的政策⻛险。在我和他沟通之后 ，他主动找来这 位下属 ，讲明了⾃⼰的意图。 随后 ，他们⼀起制定了⼀种合理的策略 ，经过调整之后 ，这个活动还是如期上 线了。
这个例⼦告诉我 ，在把⼯作授权给别⼈时 ，对于动⼒ （Desire） 的关注尤为重要。讲清楚为什么要做，为什么要现在做，获取理解及认同，激发团队的动⼒是项⽬经理成功授权⼯作的关键。
在动⼒的基础上 ，你还要确保你所选择的⼈有相应的能⼒来做到这件事情。如果现阶段的团队都没有对应的 能⼒ ，该怎么办呢？项⽬成功关键路径上的核⼼能⼒缺失，是你作为项⽬管理⼈员，要当作最⾼优先级的⻛险管理的事项。
从外部引⼊相应的⼈才 ，是最直接有效的⽅式。 除此之外 ，你还可以去积极争取短期借调、内部转岗等。从 ⻓期来看 ，你还需要有意识地发现和投资那些团队中最有潜⼒的⼈ ，给他们安排相应的⼯作辅导 ，开展有针 对性的培训等 ，帮助项⽬组成员发展相应能⼒ ，让事情真正落地。
以上 ，就是授权⼯作时 ，成功施加影响的三个层次，从让⼈知道要做、到有动⼒做，再到有能⼒做。
误区2：追在别⼈屁股后⾯做监⼯
在我做项⽬管理的第⼀年 ，经常会有种“赶鸭⼦上架” 的⽆奈。通常情况下 ，我会在⼼⾥设定⼀个⽬标 ，然 后费尽⼼⼒地把⼤家往⼀处赶 ，但往往我赶得越是卖⼒ ，鸭⼦们就越是跑得到处都是。
其实 ，项⽬经理最该做的 ，不是每天逐个⼈逐条事项的监督 ，⽽是要明确⽬标，建⽴机制，并让这个机制运转起来，最终在项⽬组形成⼀种良性的秩序。
⽐如 ，项⽬经理要带⼤家⼀起开启动会 ，清晰愿景⽬标 ，定义阶段⾥程碑和完成标准 ，接着制定分段执⾏的 计划 ，把事情的所有环节从头到尾捋顺了；项⽬经理要建⽴上下游协同的流程规则 ，明确各个⻆⾊在整个过 程中的职责 ，获得⼤家的认同和共识；项⽬经理还要建⽴站会、周会等制度和模版 ，让进展和⻛险通过这些 良好设计的信息渠道汇聚 ，借助规则和⼯具来达到监控的⽬的。
我会在接下来的内容中 ，把我的经验系统化、分步骤地传递给你。这⾥你需要记住的是 ，项⽬管理并⾮要让 你成为监⼯ ，要始终依靠流程和规则来约束⼤家的⾏为。 当成熟的秩序在团队中形成之后 ，从⽇常琐事中解
放出来的项⽬经理 ，就可以集中精⼒去做愿景驱动、激励团队等更⾼层⾯的⼯作 ，真正做到 变“赶”为“ 引”。
误区3：拿着锤⼦ ，看哪⾥都是钉⼦
我曾经⻅过⼀位新官上任的项⽬经理 ，可能是因为终于得到施展的空间了 ，⼀上来就左突右攻 ，恨不得把⼗ ⼋般武艺全都套上去 ，结果激起了许多不必要的⿇烦。开站会也好 ，电⼦看板也罢 ，本来都是好⼯具 ，但是 如果引⼊过程不当或时机不对 ，会让团队产⽣抵触⼼理 ，最终拿不到好的效果。
看到项⽬中的问题 ，哪⾥都很想修理⼀下 ，这种⼼情我⾮常能理解。但是 ，你要知道的是 ，每个项⽬的现有 执⾏⽅式 ，都有它本⾝的背景和成因 ，不管现有⽅法是否先进 ，都是更加适应本⼟环境的。
在这个课程中 ，我会跟你分享很多新的⽅法和⼯具。但我担⼼的是 ，越是好学⽣ ，越有⻢上上⼿实践的冲 动：“看到好的东西 ，我就想⻢上在⾃⼰的实践中尝试⼀下。”
如果你也是这样 ，那么 ，我要提醒你 ，先不要急 ，你要与项⽬中的重要⼲系⼈加强沟通 ，理清前因后果 ，多 想想⾃⼰的项⽬现阶段到底最需要什么 ，这对项⽬管理⽅法的成功推进⾄关重要。每个项⽬都有它独特的情 境。你可以试着问⾃⼰⼏个问题：
在你的项⽬组中 ，时间、成本、质量、范围这⼏个因素 ，到底哪个更重要？ 哪些是允许有⼀定调整空间 的？
. 各个⻆⾊⽬前的痛点在哪⼉？ 哪些是最先需要解决的？ 这些问题背后潜在的原因是什么？ 团队对于这个痛点的改进是否有真实需要？ 需求的迫切程度如何？
你的⽼板或项⽬发起⼈对于项⽬管理以及你本⼈的定位是怎样的？ 关于这些问题与可能的改进 ，你是否与 其沟通过并达成了⼀致？
如果你打算引⼊新⽅法或⼯具 ，更适合⽤怎样的路径进⾏ ，是⾃上⽽下地全⾯推⼴ ，还是⾃下⽽上地⼀步 步优化呢？ 最有可能从哪个问题切⼊？
这些问题能够帮助你理清思路 ，从项⽬和团队当前的真实痛点出发 ，找到真正解决问题的⽅法和步骤。
回到刚刚说到的那位新官上任的项⽬经理 ，在我和他对照着以上这五个问题分析完之后 ，他终于明⽩了问题 到底在哪⼉。 在他的项⽬中 ，时间绝对是第⼀要素 ，拖延⼀天交付都是直接损失。在这样的情景下 ，团队对 变更的容忍度很低 ，最头疼的就是客⼾的需求变更⼜很频繁……实际上 ，变更的背后是对客⼾需求管理的失 控 ，⼤家对这个痛点的改进要求⾮常迫切 ，项⽬发起⼈也很是头疼。
之前他看哪⼉都是问题 ，眉⽑胡⼦⼀把抓 ，现在经过梳理之后 ，他意识到⾃⼰应该找准变更这个切⼊⼝ ，让 ⼤家看到切实的效果 ，其他的改进⼀步⼀步来。说⼲就⼲！他和发起⼈沟通了⾃⼰改善变更的思路和⽅法 ， 很快就得到了认可 ，⽽通过这些有效的改进 ，团队对他的信任也与⽇俱增了。
总结
最后 ，我们来⼩结⼀下。从程序员⾛向项⽬管理 ，是从“左⼿习惯”到“右⼿习惯” 的转变。其中 ，思维模 式和⾏为习惯的转变 ，远⽐学会使⽤那些⼯具⽅法要有挑战得多。从管好⾃⼰的事 ，到管好别⼈的事 ，你需 要有意识地避免3个误区。
第1个误区是凡事都要亲⼒亲为。遇到事情时 ，你不要⾃⼰直接去做 ，⽽是要想办法驱动他⼈去做好事情。 在授权⼯作时 ，有三个层次 ，从让⼈知道要做 ，到让⼈有动⼒做 ，再到有能⼒做。你需要讲清楚为什么要做，为什么要现在做，获取理解及认同，激发团队的动⼒，同时为每个任务选择能⼒匹配的授权对象。
第2个误区是追着别⼈做监⼯ 。做项⽬管理 ，不是要你变成监⼯ ，⽽是要你带领团队明确⽬标 ，建⽴机制， 并让这个机制运转起来 ，要始终依靠流程和规则来约束⼤家的⾏为。
第3个误区是拿着锤⼦看哪⾥都是钉⼦ 。每个项⽬的现有执⾏⽅式 ，都有它本⾝的背景和成因 ，你要与项⽬ 中的重要⼲系⼈加强沟通 ，理解前因后果 ，从项⽬和团队当前的真实痛点出发 ，找到真正解决问题的⽅法和 步骤。
如果你已经⾛上了项⽬管理之路 ，在开始系统学习之前 ，你最好整体梳理⼀下⾃⼰所在项⽬组的背景情况，
这将会为你之后的学习和实践找到⽅向。
