技术转管理，程序员如何进行自救？( 二 ) _程序员

但我认为，催促同事干活的不应该是项目经理，而是项目流程，是规则。每个人明确自己的角色，各司其职，由规则约束着大家前行。而不是简单靠项目经理赶着大家往前走。
但我并没有做好这个工作，目前还是处于制定计划、监督执行的死循环中。对于规则、流程只是有个模糊的想法，还不成型，也未经试验。暂不与大家分享。
2.4 救火能力固然重要，要防范于未然
我由技术转管理的初期，最擅长的事情就是技术。所以一直在项目中充当救火队员的角色。
有突发情况？我自己来；没有人能攻克的技术难点？那我自己来；开发了很久，发现需求理解错误？咔咔咔自己一顿改。
总之就是这有问题，咔咔咔自己一顿弄；那有问题，嗒嗒嗒自己一顿搞。总用自己的技术能力挽救项目中的各种突发情况。
而作为一个项目管理者，救火能力固然重要，要在关键时刻能够站出来力挽狂澜。但更重要的，我想是如何去避免突发情况吧。
要避免突发情况，就要思考如何做好风险管理。提早做好准备，把可能出现的未知风险扼杀在襁褓中。
在 IT 项目管理中，我认为风险主要存在于以下几点，应思考准备以便规避风险：

需求变更。开发中需求变更是难免的，但如何控制需求变更，如何管理需求变更是我们着重要考虑的问题。SCALPEL 方法，大家可以了解一下。
项目干系人不清楚，导致项目需求分歧。
技术难点预估不足。总是会存在开发过程中才发现某项功能无法实现或者实现成本过高，这主要是由于前期对需求理解不足，对自我或团队太自信造成的。
计划制定问题。开发计划制定有问题，可能由于错误的估计了团队的能力，项目的难度造成的。
计划风险通常是由项目经理自己造成，需自我强化、学习、思考来避免此问题。
组织成员问题。开发成员不足、人员离职、其他项目需紧急支援人手、团队沟通不畅都可能引起此问题。
流程风险。过于流程化，导致流程工作占用太多开发时间，流程和灵活是一对冲突的概念。
如何解决项目管理中流程化和灵活度的问题，我认为是项目经理较重要的能力之一。
性能问题。开发过程中，最怕的是功能做完了，最后发现性能不行。导致前期开发工作全白费。
所以在需求阶段，软件的用户量，数据量都是要考虑在内的。在开发之初，就要在程序设计过程中将性能问题考虑进去。

2.5 保持内心强大
项目管理是一个磨人的工作。虽然外面说要做风险管理，但突发情况避免不了。一个合格的项目管理者，要有泰山崩于前而色不变的内心。
需求变了不要紧、计划变了不要紧、成员情况发生变化不要紧。毕竟我们都知道世界上唯一不变的就是变化，尽可能的给自己准备好 Plan B 。
2.6 背黑锅要上，邀功也要上
我相信各位做开发的时候，最讨厌的就是那种黑锅你背，有功他领的 Leader 。既然如此，希望我们也不要变成这样的人。
项目经理嘛，统管这个项目的一切。项目出了问题，不管因为什么原因，都一定是项目经理的责任。
你的同事可能在项目里表现不佳，你的客户可能经常变更需求。不管多少理由，都不是你甩锅的理由。有锅一定要自己扛着，所以，背黑锅要上。
做的好，也要说出来。超出客户预期的项目闪光点，要告诉客户团队的优秀。
项目完成的不错，要告诉老板团队的优秀。让客户让老板知道你们团队做的好，下一次他们才会给你们更充分的信任。
项目成员表现优秀的地方，不光要表扬，也要和上级说。你是和你团队成员接触最紧密的人，他们的优点别人不知道，但你知道。
所以他们优秀的地方，要宣扬，要让别的部门知道，要让上级知道。所以邀功也要上。
在帮派里，不能为兄弟们挡刀并引领兄弟们前进的老大是不值得追随的，弟兄们在你手下做事受尽委屈，争不了一口气，那这个老大也做不长。
技术出身的管理者中，我相信背黑锅要上是大家都能做到的。但技术人员不善言辞，总是闷头干活，不会表达。所以要适当学会邀功，为团队邀功。希望大家都能学会邀功也要上。
2.7 别抛弃技术，它可能是你的救命良药
做项目管理以后，尤其是像我现在这种一个人带多个项目的情况。管理工作会占用每天极多的时间。