【51CTO.com原创稿件】一个技术精湛的程序员，只要有机会，就有可能被公司提拔为项目管理人员，掌控项目中的一切。
但所谓权力越大责任越大，要想成为一个合格的项目管理人员，我认为最重要的首先是扭转自己的思想。
正如老子说的“道为体，术为用。”我们的思维模式改变了，各种管理的方法和工具自然的就会去学习使用了。
正所谓“有道者术能长久，无道者术必落空。”所以在本文中，我就和大家聊一聊管理中的“道”，我们程序员如何修炼管理思维?我们要先懂得道理，再去学怎么做。
你不是一个人在战斗
很多兄弟刚转型管理的时候，更多的关注事，而不是关注人。不断的把任务分派下去，到点验收，期待得到一个好的结果。
遇到任务出问题，马上跳出去指责。“你为什么又没完成!”，“怎么这点东西都做不好!”。
这样只能导致一遍又一遍的出问题。你想想，你可能是因为业务精湛才被提拔为项目经理，其他同事业务上没有你那么娴熟，无可厚非。
而任务分派下去以后，你是否需要和同事聊聊难点，说说你的想法，有问题给予一些简单的指导。
出问题的时候，首先应该引导而不是指责。
有的兄弟刚转型管理的时候，一旦遇到同事完不成的任务，遇到的难点，马上跳上去三下五除二一顿敲，解决问题后，不留下一片云彩，挥袖而去。
这些兄弟总会替代同事做他们自己本应该做的事情导致同事得不到成长，而自己则搞的很疲惫。
我想有一点我们需要明白：项目经理是团队中的指战员，掌控着整个团队前进的方向和打法。你不是一个人在战斗，你的行为影响着整个团队的战斗力。
作为程序员，我们习惯了单兵作战，不断的钻研打磨自己的技术，就能高效的完成任务，提高战斗力。而项目经理，是需要指挥一群人，去打赢一场又一场的战斗。
所以我想说的是：
- 你要给予团队里的同事包容，给予引导而不是指责。
- 给予每个人锻炼的机会。事无巨细的帮助或者亲手操刀，只会毁了团队。
- 夸张点说，你决定了整个团队的战斗力，请为同事负责也为自己负责。
- 培养人是你的职责，团队的进步才是真的进步。
并行工作可以拯救你，也可以毁了你
做了管理以后，你会发现自己被各种事情同时缠身。你不仅仅要处理技术那点事了，你可能同时在处理多件事情。
你要维系干系人、要做任务 WBS(工作分解结构)、要沟通需求、要项目演示、要协调团队关系、要处理各种紧急情况、甚至于要填报材料、要写合同、要解决客户乱七八糟的问题等等。
总之刚开始的时候你会发现，你事情多的做不完，被各种事情缠的脱不开身。但这又是你的工作职责，必须要去处理。
我们程序员最擅长的就是抽丝剥茧，把一个复杂的需求逐渐理清，结构化后编写成代码。同样的，你也需要在这些纷乱的任务中抽丝剥茧，有章有法的去处理开来。
这些事情如果处理不好，你会发现自己一直处于忙碌之中，而不知道自己到底在忙些什么。
长此以往，你会对自己失去信心，项目也会一塌糊涂。但从另一个角度来说，如果你能有条有理把这些杂乱的任务整理清楚，你一定会有质的飞越。
所以我想说的是：
- 拥抱混乱，但别陷入其中。
- 这是展示你真正技术的时刻，如何做好个人时间管理，是你最重要的一课。
码代码很重要，但其他事情也同样重要
我们程序员总认为：码代码才是正事，其他事情都是扯淡。但你别忘了，你肯定也经历过需求改来改去导致的痛苦、设计稿一改再改带来的重复劳动、没有设计就开发导致的各种问题。
既然我们身为程序员的时候，已经经历过这些苦楚，那为什么要让我们的同事再经受一遍呢?
所以，请重视项目前期的阶段。去搞定干系人、去敲定需求、去定稿设计、去指导代码设计。这些工作完成的越好，开发过程越顺利，项目进度越有保障。
身为项目经理，你需要额外做很多事情，保障项目的进度。很多事情等到开发阶段再介入，你会发现为时已晚。莫要坑了同事也坑了自己。
所以我想说的是：
- 先设计后开发。
- 防范于未然的能力，比救火能力更重要。
不断挖掘，发现本质
我们程序员啊，总是亦或者是习惯了别人说什么，我就做什么。但其实我们也应该多问问为什么。
而项目经理我认为需要有透过表象发现本质的能力：
- 需求来临的时候，你能否透过现有的需求发现客户更深层次的需要?
- 某同事任务完不成的时候，你能否透过日常点滴发现他完不成的原因?
- 测试团队和开发团队起冲突的时候，你是否能透过日常的交流发现矛盾的根源?
- 团队士气低落的时候，你能否透过大家的表现悉知团队状态低落的问题所在?
首先，要想做到一步到位透过表象发现本质我认为是很难的，需要大量的锻炼。
但我认为我们保持一颗好奇之心，就能把问题的本质掌握的八九不离十。不断给提出问题，同时去挖掘问题的答案。
举个例子：
- 客户：“我想造一架飞机。”
- 项目经理：“您为什么想造一架飞机呢?造完飞机还需要建飞机场才能飞呢。您是要去什么地方吗?”
- 客户：“我是想去西班牙，觉得有架飞机比较方便。”
- 项目经理：“您去西班牙做什么呢?是旅游吗?去西班牙的话，可以搭乘现有航班和渡轮也可以。”
- 客户：“我这不是想去巴萨罗那看看比赛吗。”
- 项目经理：“咱中央五台不是有直播吗，也可以看的。去巴萨罗那成本比较高。”
- 客户：“我觉得去现场看比较有气氛，这点成本我能负担。”
- 项目经理：“好的，那咱搭乘国际航班去可以吧?”
- 客户：“好的，没问题。”
以上，客户的最根本需求是要到巴萨罗那现场去看球赛。而他的想法大概是要过去得有飞机，所以提出了造飞机的需求。
而项目经理在不断的交谈过程中，一次次的给出新方案，以探寻客户最需要的东西和摸索客户的想法(例子中为性价比和体验，客户更想要体验)。
假设交谈过程中发现客户就是想要造架飞机，你也要告诉他飞机造出来了还要建飞机场。让他权衡成本是否可以接受。
不要飞机造出来了没地方起飞，这不光是客户的问题，是你没给客户提供完整的方案。这就叫做发现本质。
以人为中心，而不是机器
我们程序员天天和机器打交道，习惯了非 0 即 1 的二进制生活。
但项目经理是需要和人沟通的，与人打交道。所以面对我们的同事，面对整个团队。应该多考虑人，以人为中心。
所以我想说的是：
- 减少应激反应，多听取别人的说法，不要急于反驳。
- 保持同理心，多从同事的角度想想，出错前做好预防工作。
- 不要轻易给同事下结论，贴标签。人都是会改变的，这次不行不代表下次也不行。
- 不能为兄弟们挡刀并引领兄弟们前进的老大是不值得追随的，弟兄们在你手下做事受尽委屈，争不了一口气，那这个老大也做不长。
放弃完美，是走向完美的路
我相信大多数程序员都有个毛病，追求完美。代码格式要最舒服，代码逻辑要最简洁，细节一抠再抠。就像强迫症一样，追求自己代码的完美。作为程序员来说，这是一个非常棒的习惯。
但作为项目经理来说，我们最需要的是平衡。一味的追求完美，会导致项目成员压力大增，成本不可控制。
作为项目经理来说，我们都希望自己带的项目细节无可挑剔，功能一应俱全，代码质量无懈可击，团队氛围融洽得体，项目质量高的无以复加，项目周期如约达成。
但其实项目里，所有事情都是互相平衡的。工期和细节打磨之间的平衡、成本与需求开发的平衡、批评与赞扬之间的平衡等等。
平衡是一方面，另一方面是迭代。保持迭代，一步一个脚印的把项目逐步推进。
所以我想说的是：
- 把握平衡的尺度，是项目逐步趋于完美的路。
- 不要追求一步到位，完美是迭代出来的。
少写代码可以，脱离技术不行
以上都是针对项目管理说的，而这最后一条，是为了引起各位的警惕。
我们上面说会有很多琐事缠身，可能导致你几乎没有写代码的时间了。这是正常的也是正确的，你的工作不是去当机枪手，你的工作是指挥大家战斗。
但这就代表我们要脱离技术了吗?我认为不是这样的。我们可以少写代码，但我们不能抛弃技术。
我有个朋友告诉我说：不要过早涉足“纯管理岗位”。我想他的意思，就是告诉我技术乃是一个软件开发的项目经理安身立命的根本。
我们程序员做项目管理，最大的好处就是，不会出现外行指导内行的情况。所以我们即便转型了，也要时刻保持对技术的敬畏和对技术的关注。
你可能不需要对各种技术的细节了解的特别透彻，但要心里有底，知道各种技术的适用范围、使用条件、优势劣势等等。保证在项目需要的时候，能够快速选型。
而作为一个项目经理，最大的一个好处在于可以让团队同事去学习，让他学习整理后来教你，以达到快速学习的目的。
所以我想说的是：
- 不要抛弃技术，它总有一天会拯救你。
- 学如逆水行舟，不进则退。
后记
程序员的管理思维修炼就写到这里。明白了道理之后，大家再去练习工具，练习方法，才会卓有成效。
总结下来，我们要锻炼的管理思维如下：
- 从个人到团队的转变。
- 从专心做一件事到同时处理多个任务的转变。
- 从只关注点到关注面的转变。
- 从说什么是什么到为什么的转变。
- 从追求完美到掌握平衡的转变。
以上，就是我和大家分享的内容，希望越来越多志在管理的程序员，能够顺利走上管理岗位。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】