程序员为什么拼命也要做到项目经理，转型之路怎么走
（一）程序员成长为软件项目经理
如何从一个程序员成长为一名软件项目经理？不同的人可能有不同的环境不同的机遇，或者先后有不同，也有些路线也不同。有些人可能一年，有些人可能要花五年时间，看个人的机遇及所处环境。但通常情况下，要成为一名软件项目经理的路径一般为：普通程序员-项目组长-项目经理这样的路径，当然具体的单位有些差异，还有看自己是否有心和努力。
程序员
作为项目经理需要负责整个项目在预算范围内按时优质地完成，并使客户满意。所以这样一看就基本明白项目经理要总揽项目全责，需要做好哪些事情，需要具备哪些能力。软件项目经理不需要事必躬亲，但要全局把控，大概具有以下几个方面的能力：技术能力，计划能力，组织协调能力，领导能力，控制能力等。有些能力在普通项目经理，高级项目经理之间只时能力程度或涉及的能力范围有差异。所以在普通程序员岗位上首先得练就比较拿得出手的技术能力，因为软件行业项目经理基本上是和高级技术工程师一肩挑的，没有过硬的技术能力，那么今后独立承担项目时，核心的项目框架你就会受制于人（比如技术工程师）。单位内部的竞争也并不小，一有短板也许机会就不属于你了。
软件项目经理
下一步就是如何晋升为项目组长训练计划能力，组织协调能力，控制能力，领导能力。在项目组长的位置上承担的是项目一小部分，比如子功能模块。项目组长如何计划承担的子功能模块，如何分配任务和内部人员的协调及对外部人员的协调。有可能还会涉及到如何控制该子功能模块的成本（这部分可能项目经理已经预算好了），如何管理该子功能模块的进度质量以及小组人员的管理等等。
程序员晋升项目经理
当然项目小组长涉及的范围可能还是有限，还要学习整个项目是如何从开始到结束，人员调配，项目成本及利润预算等。比如从市场或客户调研，到设计，到开发，测试，客户现场培训上线，怎样和客户交流，如何控制项目的范围，如何预算项目的成本等等。只要多经历几个项目大概就会知道项目的各个环节是怎么做的，然后实践积累经验，只要有机会就有可能晋升为项目经理的。这只是一个大概的描述，从程序员到项目经理是一个很大的转变，包括思维上的，行动上的。
（二）程序员与项目经理的薪资对比
在外界看来，程序员辛苦又加班又熬夜，经常是最后离开公司回家的。而项目经理却不加班或早走但工资却比程序员高呢？其实不同的角色有不同的责任，责任有大有小。在软件开发过程中，程序员只是担当了一部分的工作而已，不是软件的全部。一个软件简单来说有这么几个流程和角色：可行性调研及需求调研（产品经理）、原型设计或概要或详细设计（产品经理及设计师）、软件开发（开发程序员）、软件单元及综合或上线测试（软件测试员）等等，但还有相关的比如配置管理员，项目经理（项目小组长）等等。
程序员
而我们看到的人员最多的，或者工作量比较多的就是程序员（包括开发、测试、设计师等）。因为开发过程是时间比较长的，所以看起来程序员的工作量是很大的。但是程序员只是负责了自己担当部分的程序的编码，那么软件本身管理把控和整个团队的管理是靠谁呢，这个就是项目经理的角色来完成了。
程序员
项目经理是一个软件成功的灵魂。从调研开始，项目经理就要绞尽脑汁计划怎么做好这个项目，保证在一定期间内，一定人员内，一定预算内，保证质量的前提下准时提交给用户。所以项目经理每天脑袋里想的是怎么能保证项目成功，还要有利润，中途出现状况怎么办？怎么样控制风险？怎么安排人员？怎么进行项目的计划？怎么保证软件的各个阶段能尽量衔接好？怎么样最能提高效率？团队怎么样沟通？怎么样来建设这个团队？软件质量如何控制比较好？等等等等。
项目经理
最终如果项目出现问题或出现失败，首当其冲被训和被处理的就是项目经理。一个项目特别是大的项目要成功，可不是一件简单的事情。项目经理承受的压力是很大的，压力越大责任越大，责任愈大风险越大，高风险高收益嘛。程序员一旦下班可能就什么也不想了，而项目经理即使下班后脑袋里还在想今天的状况怎么样了，对项目有什么影响，出现问题了要怎么处理等等。
我原来有个同事，程序很厉害，是公司的高级工程师，后来不干了，开便利店去了。
有个同学在做直播创业.....
这都是跳出三界外的故事。其实也很平常，你的选择，你做主。如果你觉得这个行当不是人待的地方，再也不要受这罪了，那就走吧。如果一份工作带给你的痛苦比欢乐多很多，确实没有留恋的必要。真的，你肯定是走错了路。
软件项目管理流程
项目管理与软件开发的质量、效率、最终成果息息相关，下面主要围绕软件项目的风险评估、成本预算、客户沟通、需要分析、开发管理、成品交付等多个流程进行分析。
在现今国内的项目的管理形式十分零乱，对管理欠缺重视，以致很多项目因为失去管理而最终折腰。
很多的实战形人才只重视于开发环节，而对其他的流程欠缺认识，因而导致项目欠缺有条理的、阶段化的管理。
风险评估
软件项目风险是指在整个项目周期中所涉及的成本预算、开发进度、技术难度、经济可行性、安全管理等各方面的问题，以及由这些问题而对项目所产生的影响。项目的风险与其可行性成反比，其可行性越高，风险越低。软件项目的可行性分为经济可行性、业务可行性、技术可行性、法律可行性等四个方面。而软件项目风险则分为产品规模风险、需要风险、相关性风险、管理风险、安全风险等六个方面：
1.产品规模风险
项目的风险是与产品的规模成正比的，一般产品规模越大，问题就越突出。尤其是估算产品规模的方法，复用软件的多少，需求变更的多少等因素与产品风险息息相关：
(1) 估算产品规模的方法
(2) 产品规模估算的信任度
(3) 产品规模与以前产品规模平均值的偏差
(4) 产品的用户数
(5) 复用软件的多少
(6) 产品需求变更的多少
2.需求风险
很多项目在确定需求时都面临着一些不确定性。当在项目早期容忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就会对项目的成功造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生错误的产品或者拙劣地建造预期的产品。每一种情况对产品来讲都可能致命的，这些的风险因素有:
(1) 对产品缺少清晰的认识
(2) 对产品需求缺少认同
(3) 在做需求分析过程中客户参与不够
(4) 没有优先需求
(5) 由于不确定的需要导致新的市场
(6) 不断变化需求
(7) 缺少有效的需求变化管理过程
(8) 对需求的变化缺少相关分析等
3.相关性风险
许多风险都是因为项目的外部环境或因素的相关性产生的。控制外部的相关性风险， 能缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并觉察潜在的问题,与外部环境相关的因素有：
(1) 客户供应条目或信息
(2) 交互成员或交互团体依赖性
(3) 内部或外部转包商的关系
(4) 经验丰富人员的可得性
(5) 项目的复用性
4.技术风险
软件技术的飞速发展和经验丰富员工的缺乏，意味着项目团队可能会因为技巧的原因影响项目的成功。 在早期，识别风险从而采取合适的预防措施是解决风险领域问题的关键，比如：培训、聘请顾问以及为项目团队招聘合适的人才等。关于技术主要有下面这些风险因素：
(1) 缺乏培训
(2) 对方法、工具和技术理解的不够
(3) 应用领域的经验不足
(4) 对新的技术和开发方法应用不熟悉
5.管理风险
尽管管理问题制约了很多项目的成功，但是不要因为风险管理计划中没有包括所有管理活动而感到惊奇。在大部分项目里，项目经理经常是写项目风险管理计划的人，他们有先天性的不足——不能检查到自己的错误。因而，使项目的成功变得更加困难。如果不正视这些棘手的问题，它们就很有可能在项目进行的某个阶段影响项目本身。当我们定义了项目追踪过程并且明晰项目角色和责任，就能处理这些风险因素：
(1) 计划和任务定义不够充分
(2) 对实际项目状态不了解
(3) 项目所有者和决策者分不清
(4) 不切实际的承诺
(5) 不能与员工之间的进行充分地沟通
6.安全风险
软件产品本身是属于创造性的产品，产品本身的核心技术保密非常重要。但一直以来，我们在软件这方 面的安全意识比较淡薄，对软件产品的开发主要注重技术本身，而忽略了专利的保护。软件行业的技术人员流动是很普遍的现象，随着技术人员的流失、变更，很能会导致产品和新技术的泄密，致使我们的软件产品被它公司窃取，导致项目失败。而且在软件方面关于知识产权的认定目前还没有明确的一个行业规范，这也是我们 软件项目潜在的风险。
7.回避风险的方式
(1) 以开发方诱导能保证需求的完整，使需求与客户的真实期望高度一致。再以书面方便形成《用户需求》这一重要的文档，避免疏漏造成的损失在软件系统的后续阶段被逐步地放大。
(2) 设立监督制度，项目开发中任何较大的决定都必须有客户参与进行的，在该项目中项目监督由项目开发中的质量监督组来实施。
(3) 需求变更需要经过统一的负责人提出,并且要用户需求的审核领导认可,需求变更应该是定期而不是随时的提出,而且开发方应该做好详细的记录,让客户了解需求变更的实际情况。
(4) 控制系统的复杂程度，过于简单的系统结构，对用户来使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升，这又会在实现和测试阶段带来风险。适当控制系统的复杂程度有利于降低开发的风险。
(5) 从软件工程的角度看，软件维护费用约占总费用的55%~70%，系统越大，该费用越高。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展，科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。
(6) 设定应急计划，每个开发计划都至少应该设定一个应急预案去应对出现突发情况和不可遇知的风险。
（三）从程序员到项目经理的转型之路
今年可以说是我职业生涯中很重要的一年，是一个转折点。因为在7月底的时候，我经历了人生的第一次跳槽，并且从一名程序员“转行”为了一名项目经理，当然仍然是IT行业的项目经理。
说起我的上一家公司，我对它真的是有着非常深厚的感情。从2010年刚毕业，就进入了这家公司。这是我的第一份工作，一直干了6年多直到2016年的7月底。
刚进去的时候工资并不高，但是每天都热血沸腾，激情澎湃的。原本是按C++程序员被招进去的，没想到后来变成了做C#。好在有C++的底子，C#也就不难学，一边开发着一边学，真的是现学现卖了。当时适逢公司要做一个新项目，规模比较大，大家每天晚上都要9点10点才走，每个周六还要再加一天班，不过从来没觉得累，也不觉得苦，就跟打了鸡血一样。
入职后不到半年，研发部的经理就让我去带团队了（那时候叫小组长）。当时的小组里只有两个成员，还都是有两年以上工作经验的，技术也比我强。因此我作为一个应届毕业生，他们的后辈，真的是硬着头皮接的这个任务，心里十分忐忑。不过我很明白这是一个好机会，虽然没把握能带好这个团队，但也先带了试试再说，没什么可怕的。领导都是很有看人的眼光的，他觉得你行，那你就一定能行。也不用担心会把项目做砸，因为一定会有人在关注你的进展，不可能为了培养和考验一个新人就冒着把项目做砸的风险。如果你实在胜任不了，兜不住了，绝对会有人出手拉你一把的。
因此新入职的同学们，真的要胆大心细，不要因为缺乏自信就推掉好机会。年底的年会上，我还被评为十大优秀员工，总之是顺风顺水。
直到现在，我也十分感激当时的研发部经理，让我积累了很多带项目的经验。
这家公司当时没有什么产品部、产品经理，于是我们做项目的时候，从与客户沟通搜集需求、做需求分析、制定项目计划、UI设计、数据库设计、写代码实现功能，都是一条龙作业。好在还有美工、测试、技术支持。不过当时还是会有很多客户或代理商遇到问题之后直接就打电话到我这里来。
后来公司规模越来越大，直到2015年才开始由产品经理负责需求，其它的工作还是由各个项目组处理。我们几个小组长也有了个比较正式的头衔——“研发经理”，在负责项目的规划、设计、监控的同时，也要负责核心代码的编写。
为了能更好地完成任务，我在2013年的时候自费去学习了项目管理相关的一系列理论知识，并且考了一个PMP证书回来。这可以说为我后来的转型打下了一个很好的基础。
当时公司里并没有人把项目管理当做一门需要去学的技术，也没人听说过什么PMP，大家都是沿袭之前的老套路来开展各项工作。这样做其实并没有什么问题，项目照样可以按时按质地完成。但我心里总是隐约觉得不妥，觉得好像不应该是这样的做法。而且在做项目的过程中遇到的各种问题，即使解决了也说不出个什么原由来，好像一切都有规律可循但又摸不清它在哪里，是什么样子。
我一直觉得写代码是我的兴趣所在，可是我在这家公司写了好几年代码，技术上也没觉得有多大突破，主要还是本公司用得到的那点儿东西，需要用到什么了再去学什么。偏偏我们公司也没用到什么高深的技术，基本上刚毕业的新人培训一个月就能胜任。只有这个管理项目的方法，我是主动想要去了解一下的，于是在网上搜了一通有关项目管理的培训，这才发现原来项目管理也是有资质认证的，这才知道还有PMP，才知道我做的工作，除了要亲自写代码，其实和项目经理是非常接近的。
但是即使考到了PMP，也没有看出对当前的工作有多大助益，毕竟工作方式工作流程不是我能定的。
拿一个很简单的例子：文档的管理来说。之前的老项目，基本就没留下什么文档，我们刚进去的时候都是靠之前的老员工口口相传。后来做的新项目，虽然都有文档，但是很多项目组都是在糊弄而已，那些文档并起不到什么约束和指导的作用，项目有了变更之后也没人去维护，基本没多大的留存价值。再有问题了，依然是靠口口相传，大家都没有维护文档、查看文档的习惯。我可以说是几个研发经理里面对文档最重视的一个了，写得非常详细，也都会定期维护。这一点同样也为我现在的转型奠定了基础，可以说我现在每天的主要工作就是写各种文档、维护各种文档、开会、发邮件。
其实，我一直以为我能在这家公司一直待下去呢。因为它的福利待遇不错，虽然工资不高但是也够用，每年也给涨工资，还开始准备上市了给老员工们留了原始股。而且它的企业文化非常好，同事之间的关系也非常融洽，凝聚力很好。之前已经离职的员工，我们也会经常聚餐K歌，甚至连已经离职10年了的前辈，都能联系上一起聚。更重要的是，它见证了我的恋爱、结婚、生子、买房等一系列人生大事。就连我老公（是的我是女的）也是在这家公司认识的，他比我晚1年入职，座位就在我旁边。结婚之后，他就离开了这家公司。程序员的圈子很小，平时的私人时间也比较少，可以说，我从来到北京以后，95%的人脉都在这家公司里。
可惜就是这样一家我已经视为自己家的公司，却仍然不得不离开了。我们的公司正在转型，重心已经开始偏移，部门经理跳槽了，就连公司老总（创始人）都已经把所有事务交给了之前的副总，跑去经营另一家公司，只做这家公司幕后的“股东”了。我们做的那些东西，虽然公司还需要，但是已经基本比较稳定，也没太多新的需求，部门人数也已经削减了一半。
从今年开始，我们这个部门要被其它部门“吞并”的感觉越来越强烈，同事们都在私下里议论纷纷。先是一开始带过我的那个“师傅”，也是我们这个部门的“镇部之宝”，忽然就被调到别的部门去了。整个部门就只剩下两个研发经理，各带着3个程序员，在原来的那套东西上修修补补，解决一下客户问题和新的小需求。然后之前要做成什么样都是我们自己说了算，现在都要听产品部的了，我们变成了纯粹的程序员。直到这个时候，我才惊觉，原来我是不甘于只敲代码的，我更喜欢去做一个项目的管理者。也正是这件事，才让我正视了自己，这时我就开始有点想要离开的想法了，但是仍然是情感上占了上风，舍不得。
让我更加坚定这个想法的，是因为公司现在的老总从鼎鼎大名的M公司挖来的一位产品大牛，做了O2O部门的老大。我是不清楚这位的能力究竟有多牛，不过他的臭脾气可真是一顶一的。我在这个公司如此祥和的环境里待久了，冷不丁的遇到这么一位，真是有种长见识了的感觉，也第一次体会到了作为一个底层的技术人员的不易。
第一次争吵的起因是这样的，我去找这位大神商议，大意是：“我们这个功能马上就要上线了，这个部分可能不需要这样实现，否则会比较复杂也需要更长的时间。这一版本是否可以先这样实现...”云云。结果没想到这位我们才第一次见面的同事，上来就冲我发火了：“这不就是两行代码的事儿嘛！”“这不就是....，正常人都是这么实现的！”“程序员就是吃这碗饭的！”我的火气也一下就上来了：“我是负责这个功能的，我可以告诉你，这并不是就两行代码的事儿！”既不是一个部门的，也不是我领导，有问题就不能好好说话吗？你可以嫌弃我技术不好，但是你不能带着X眼看人低的情绪，直接贬低我们程序员这个行业。我程序员是吃这碗饭的，但我并不是只能吃你这碗饭。
更让人心寒的是，有一次在项目微信群里提出一个问题，因为对一个需求为什么要那么实现有困惑，就问这个地方是为什么要这样做？又是这位大神跳了出来，不分青红皂白又把我教训了一顿，说的话和上面差不多，大意就是：“你程序员连这个都实现不了，还能做什么？”“程序员就是做这个的！”“明明就是做不到还那么多借口！”气得我当时在群里就和他吵了起来：“我没有说实现不了这个功能，只是要了解一下为什么要求把这个功能做成这样”。“大家都是同事，有话好好说，再这么不客气后果自负！”但是当时的公司老总拦住了我，他说我要注意沟通的方式。可是明明是对方先开火的吧。而且他还特意加了我的微信，说：“你要多倾听，XX是我的老师，他教会了我很多...”那我还能说什么？如果公司老总一句话都不说，让我们自己解决，我反而不会觉得怎样，只是一个难相处的同事而已。但是我没想到他处理事情会这么不公平，他是公司的老总，他的作为让我对整个公司的满腔热情都一下子冷却了下来，只剩下失望。
后来，公司把我们部门仅存的两个项目组的两个研发经理，都“借”给了O2O部门，还捎带上一个资历最老的测试经理。我们三个连工位都搬了过去，每天要由O2O的同事给我们分配任务，还要给我们进行绩效考核。原以为是去合作的，没想到最后成了被管理。就连我们一直在维护的那些系统，哪里要怎么改，谁来改哪部分，也都由他分配了。我每天的工作只是写一些简单功能的代码，我感觉我似乎回到了新入职的那一年，成了一个只能写基本代码的新人。我现在正在做的事情，任何一个刚毕业的新人都一样能做。我觉得我在这里已经完全没有价值了。眼看着真的要成为020部门的最底层员工，而那位大神也真的要成为我的领导了。
另一个研发经理也提出了要离开，不过他被研发部总监用一些金钱激励挽留住了。而我的离开非常顺利，部门老大说因为我新公司开出的工资和职位，都不是他们能给的起的，所以研发部总监说就不找我谈了，那样太虚伪了，明知道留不住。他说研发总监最近也很苦恼，因为他的人都被调走了，他也有很多事情做不了主了。能走，就走吧，这边现在太乱套了，走了对你也有好处。
我不去深思究竟是不是像他说的那样，其实我内心深处还是希望研发总监能找我谈一下话的，哪怕只是虚伪的挽留一下。研发总监其实人不错，虽然离职的一些同事对他有意见，但他待我不薄。我还记得有一次我请假说要带我妈去看病，签完字之后，他叫住我，热心的帮我推荐医院，甚至画了那个医院的地图给我。我办离职证明去找他签字的时候，他什么也没有多说，签完字我就离开了。
后来我才知道，产品部的老大也在比我早一周的时候离职了，之后我们在微信里聊过，他离开80%的原因也是因为那位大神。他的离开让很多人都震惊了，我们部门的经理说前不久他们还一起去客户那里谈问题，看他根本没有要走的意思，可他甚至连已经花几十万预订好的公司原始股都不要了，直接走人，然后把钱退了出来。后来又听说有个在公司里干了十多年的老员工，也差一点就被气走了。
不管怎样，我最终还是离开了。
其实我一开始投简历是带着点赌气的成分的，还没做好思想准备真的要走。我连那些招聘网站的密码都忘记了，再登陆进去的时候，上面还都是我刚毕业的时候的信息。我更新了一下简历，投了几家，接到2个面试通知。我打印出来的简历也很简单，只有一页纸，上面连个照片都没有。收到面试的通知感觉比较突然，也没顾上准备。后来我老公有一次无意间看到了我没用完的简历，当时就笑坏了，跟我说：“天哪！这就是你的简历啊？这是我见过的最简单的简历了。”
事实证明，简历很重要，但并不是决定因素，写得多不如写得精。光我那连着六年多没跳过槽，只有简单一行的工作经历，大概就能让很多公司心动了吧。毕竟，企业都喜欢忠实稳定的员工。
来现在的这家单位面试的时候，一切都非常顺利。一共面试了三轮，没有做任何一道笔试题，都只是谈话，聊聊我之前的工作都是做什么的，怎么做的。然后就被录用了。
从此，我的职位就从“研发经理”变成了“项目经理”。再也不用写代码了，工作重心从技术转为管理。
其实对于不能写代码这件事，我还是觉得有点可惜的，会感觉有点手痒痒的。但是我也非常明白，我不能做一辈子的程序员，我已经30多岁了，需要另谋出路。而且搞技术要不断地学习，学习很多很多东西，我欠缺的太多了。并且现在作为一个2岁半孩子的妈妈，我的业余时间大多都用来陪孩子了，只要是在家里，根本就不可能有打开电脑敲代码的机会。而且，一心不能二用，我既然选择了走项目管理这条路，就需要花更多的时间和精力在这件事情上。继续学写代码，好像并不能为我现在的工作提供多少帮助。
庆幸的是，我老公还在写代码，他很用功，早就从当年那个比我晚入职的菜鸟变成他现在公司里的技术骨干了，带着个研发团队。每次看到他在书房里专心敲代码的时候，就觉得我做技术大牛的梦想已经承载在他的身上了。哈哈，这么形容可能不太贴切，但是确实有点这样的感觉。他对我能够不做程序员，而转去做管理这件事非常满意，因为他很明白要继续做一个老程序员需要付出多大的努力。
现在的这家公司与之前那家有一点很大的不同，那就是对项目管理的环节和流程非常的重视，有着很正式和规范的项目管理方法。在我入职之前，这家公司已经有至少4名项目经理了，都是从研发经理提拔上来的。只有我，是他们外招来的专职项目经理。
我刚入职，就被安排去带一个据说是对公司明年后年都非常重要的项目，有一个产品经理来带我。直到现在，我已经过了试用期，转正了，这个项目还没有完结。原本上周它就应该结项的，可惜要延迟1个月了。其实我是非常不希望，我刚进来带的第一个项目就出现延期。可是由于要和另一家公司合作开发产品，而对方却总是不能按期交付，多次拖延。公司副总多次介入，直接和对方的高层面谈，也仍然没能解决，对方的人力实在是有些欠缺。老总从立项时起就已经明确指出，这是一个产品型的项目，不是研发型的，因此以产品经理为第一责任人，其次是我这个项目经理，就算后期出问题，也只会去找产品经理，不会找到我头上。但我总是觉得有点遗憾，没能交上第一份完美的答卷。
正因为这样，我已经有了要继续充电的打算。我希望能够从专业的人士和培训机构那里，学到更多更好更有效的项目管理方法，让我再遇到这种类型的项目时，能够处理得更好。这也是我明年的重要计划之一。