IT行业中，有两条普遍存在的程序员晋级路线：
1.从开发工程师升职做项目经理
2.从乙方跳槽到甲方
无论哪条路，都意味着从技术到管理的转型。
转型的过程中，与工作内容的转变相比，更核心的是完成思维逻辑的转变。但包括我在内的大部分人，短则三、四个月，多则一、两年，甚至更长，都没有完成这一点。
暂且把转型前后的思维逻辑分为技术思维和管理思维。
所谓技术思维，就是做正确的事
所谓管理思维，就是正确的做事
首先说技术思维。
如果你是项目组的技术骨干或核心人员，对所做的系统有充分的了解，熟悉系统的核心技术、框架、逻辑机构等，那么你在项目组将会有很高的工作自由度，且承担了部分管理职责：
你可以根据自己的经验，选择合适的编程语言、数据结构、算法，完成需求开发。
你可以根据自己的理解，制定优先级，排列任务顺序，及时完成重要的业务需求。
这一阶段，你需要做一定的管理，但不需要做复杂的管理。你的核心工作依然是最大程度的发挥技术优势，在给定的时间内，高质量的完成系统开发工作。
项目经理因为要统筹项目的各方面工作，很少会介入技术细节，因此只要作为骨干的你认为是正确的，项目经理一般会支持你去做，也就是以成果为导向，完成你认为正确的事。
再说管理思维。
成为项目经理后，你将面对与信息系统建设相关的从立项到验收的全部工作。包括可行性分析、立项审批、招投标、谈判、签订合同、需求分析、设计、开发、集成、测试、投产、验收、运维等等。
在整个项目过程中，项目经理要不断的协调成本、进度、质量三者的关系，预测和处理各种风险事件，协调各主要干系人的关系。开发不再是项目经理的核心工作。
以上是对于新项目而言，但目前更普遍的情况是，项目经理要负责已投产系统的增量业务需求，而且是同时处理多个增量需求。对于团队技术骨干，只要考虑如何完成已分派的需求，但对于项目经理而言，则需要考虑如何合理分派需求。
需求来源于哪？
1、产品经理
2、应用用户
3、监管机构
4、领导分派
……
对于项目经理来说，经常会同时收到来自不同方面的不同需求。但遗憾的是，对于开发出身的项目经理，再也不能单纯的以哪个需求做了更有用，对系统的发展更好作为安排任务的主要依据了。因为在所有的需求放中，你必须把领导分派的任务作为第一位，哪怕分派的任务要实现的功能可有可无，哪怕耽误你认为更重要的需求的开发进度。
没有领导喜欢不按要求干活的人！
同样，明明给小弟安排的任务A，他偏要做任务B，这种人你也不会喜欢。
你还要在公司工作，你就需要得到领导的认可，你才能得到更多的资源，才能交出足够的成果，才能拿到满意的绩效，才能得到可观的奖金。
总结来说，项目经理要学会正确的做事，更直白的说，要学会正确的做领导交办的事，要懂“政治”。
技术出身的人，比较看不起那种对领导唯唯诺诺，什么事情都满口答应，然后分派给手下去完成，自己只是“等、靠、要”，定期给领导汇报的人，但又不得不承认，就是这部分人，工作不忙，加班不多，工资不低，领导满意，升值更快。这，就是现实…
我并不提倡技术出身的人放弃原则，变得圆滑，我只是以自己的经历，建议大家，藏起一点点棱角，让自己的过得轻松一些。
就这样…
网友评论