跳脱程序员思维 从开发到管理的蜕变

【IT168 专稿】

　　因为我在参与的软件项目开发表现出色，公司在新一个软件开发项目上委派我做项目经理，全权负责项目各种事务的管理。繁忙的事务处理使我体力透支, 有一种脱了一层皮的感觉，但最使我心力交瘁的是从软件程序员到项目经理的一种思维方式和观念的痛苦转变。

在软件越来越复杂，需求多变的情况下，程序员式的个人英雄主义已经行不通了，从程序员到项目经理需要主动转变思维方式，否则将陷入心灵和精神的痛苦折磨。在我负责项目管理时，痛苦的经历使我深深明白到转变思维方式和观念对于一个项目的成败是至关重要。

痛苦转变之一：跳脱典型的程序员思维

• 典型的程序员思维：代码是一切

　　我在刚负责项目的时候认为保持团队高效的工作，和让项目成员有成就感当然重要，但如果连代码工作都完不成的话，就不能谈什么高效工作了。因此，在我接管项目团队的时候，我认为从某种程度上讲项目经理最重要而且唯一的目标就是控制代码编写进度，团队所有工作的成果就是要提交一份高效的代码。所以，成员代码的质量以及对代码的控制，是项目经理管理的主要任务。例如软件程序主要由代码组成，编码阶段就是整个软件项目的最重要的阶段，应该给与大量的时间，并且集中主要的资源。

代码就是一切的程序员式经验让我尝到了做项目经理的第一个苦果。实际上，与以前相比，由于软件的规模和复杂度的增加，以及半自动化软件代码开发平台的出现，软件项目管理的中心发生了转移——不再着重编码阶段，而是着重系统总体/详细设计阶段。一般说来，软件项目管理中各种资源的合理分配比例是：项目论证、风险评估阶段10% ，项目需求分析阶段10%，系统总体/详细设计阶段40%，编码阶段10%，系统测试阶段30%。

• 项目经理眼光应专注于：项目控制和协调

　　在我过往编写代码的程序员经验中，优秀的程序员与平庸的程序员效率差5－10倍。因此，我在项目启动的第一要务就是选择最优秀的程序员，并时时关注这些优秀程序员的进度表和满足他们的需求。我认为，用一个优秀程序员要比用2个或3个平庸的程序员来的划算。

在多次痛苦经历后，我终于明白到项目管理第一要务应该是：控制项目范围，控制项目进度和合理分配各种资源。完成客户需求和公司任务应该要让每个成员都发挥作用，和都觉得有成就感，这样的项目经理才能算是比较合格的项目经理，而不仅仅只是关注最优秀的程序员。这个苦果让我明白到，即使是有优秀的程序员，如果缺乏项目控制和协调，要完成客户需求和公司任务往往也会是天方夜谭的事情。

• 跳离个人大侠主义，建立系统管理理念

　　只有专注于程序设计，才能成为一名优秀的程序员，这是程序员的座右铭。然而这种专注所付的代价是忽视了团队合作，过于以自我为中心。有调查结果显示，许多程序员只局限于在某一小范围内结交知心朋友，探讨技术。但也正因如此，当程序员转变为项目经理时，就会发现处理项目各种纷繁复杂的事情时能力衰退，缺乏通达权宜，灵活反应的能力，这无疑不利于程序员综合素质的提高。

因此，在程序员转变为项目经理，从从事“技术”到“管理”这一跨行上，必须转变思维方式和观念。项目管理是一种典型的系统管理，也是一种典型的管“人”的管理。在一个软件项目中，有成百上千的相互关联的活动，例如各种人际关系，资源和突发性事情。哪一种活动都可能会在工期、资源和预算等方面发生变化而对整个项目开发过程产生连锁反应。例如项目组成员存在不同的分工，他们各自的工作对项目目标都会产生不同的作用和影响，不能仅靠鼓励他们提高对项目的自发性的责任感，也不能仅靠评价机制来驱动他们共同承担项目的责任。

项目管理的定律之一是“魔鬼藏在细节中”，项目经理必须在对项目各种活动变动全面了解的基础上，才能确定工作的焦点。因此，在程序员转变为项目经理最容易犯的就是“一叶障目，不见泰山”的错误，这个时候需要跳离大侠式的个人主义思考方式，建立系统化管理的思维方式，这是我从程序员转变过程中得到的一个重要教训。

痛苦转变之二：痴迷于技术，忘记管理控制

　　项目管理的三要素:进度、质量、成本，哪个都不能少。项目管理要处理的事情非常多，需要调度非常有限的资源去完成一大堆的工作。资源包括:人力，时间，金钱。这三种资源往往只是刚刚够，或者还缺少很多，这个才是考验项目经理的地方。

但在我刚刚开始做项目经理时没有转变观念,一味地按程序员的思维方式去追求完美,痴迷于技术,而忘记及时交付,这也是软件开发人员的通病。

• 事必亲躬，还是各司其职？

　　软件项目的复杂决定了需要协作，也决定了协作时沟通与交流的复杂。一个项目想要做到管理有条不紊，就要有管理层次，这是我在四处碰壁，燋头烂额后得到的经验。软件开发项目中各层次，各成员都分有与之相对应的职责和权利，例如项目主管负责计划管理和组织开发，程序员负责具体的代码编写操作。

作为项目经理，如果管理过细往往会打破正常的管理秩序，使管理处于紊乱状态，影响项目进度。因此，项目管理应具有层次，而从程序员出身的项目经理应该特别注意，避免“越俎代庖”的现象发生，不要一看到下属程序员做事效率低，就自己下场亲自操刀编写代码，事事都包揽不是一个好的项目经理。因为这样的管理是有问题的，会滋养了成员的惰性，造成了事无大小全凭指挥的缺乏思考和创造性的局面，以至于离开了项目经理，项目便无法正常运转。

就管理成效而言，这是一种十分糟糕的情况。包办一切的另外一个害处，是不利于调动成员的积极性与创造性，不能尽人才之用。对于那些有才华，有能力的成员，他们在工作中处处都得不到体现，在这种情况下，难免会有一种压抑感，时间长了，要么就在此磨洋工，要么有些能耐的就干脆辞职走人。

因此，在项目管理中，项目经理可以和成员打成一片，但在涉及到具体的权利和职责，或处理项目内部中的种种问题时，就必须注意管理的层次，切忌越俎代庖和越权指挥。这也是程序员转变项目经理的一个大考验。

• 关注个人绩效，还是团队绩效控制？

　　我们的项目面临着多变的环境，各种突发事件层出不穷，特别是项目经理工作负荷大，频于应付。出于程序员需要先把自己需要做的工作做好的习惯，我把大部份时间花在了个人绩效的工作上。但在进度总结会议上，我遭遇到最难堪的事情，就是我个人的绩效不错，但团队的绩效是一塌胡涂。后来我明白到项目经理要做正确的事，而不仅仅正确的做事。就是要分清工作的主次—哪些工作应该由项目经理来做，哪些工作可以交给其他人员来做，哪些工作需要资深人员来完成，哪些工作由一般人员做就行。

项目管理强调的是团队行为，而不是个人行为。面对一个复杂而多变的软件开发项目，只有项目经理一个人是无法解决这些问题的。因此，项目经理需要关注每个人的进度和绩效，重点是技术经理和资深人员。而且，项目经理仅管好自己的时间还不行，还要掌握授权的技巧。应当明白管理是通过别人的手达到项目目标，通过计划、组织、协调、控制和兄弟项目组和业主等有关人员来实现这个目的。所以，项目经理是一个过程转化者，他要把目标转化为结果，把资源转化为成果。

因此，项目经理应当花费相当的时间在对项目组人员的管理上，花费时间在对下属指导、激励、团队建设、项目协调和控制上。强化项目成员以项目为荣，以项目为目标，提高团队的士气，目前这也是程序员转变为项目经理的最大薄弱环节。

• 加强成本观念，决策先要权衡轻重

　　在软件项目管理中成本管理一直是一个很让项目经理心伤的事情，我们也经常听到许多项目成本超支，预算失控的消息。软件项目管理成本的控制实在很难，主要原因有：需求不确定，项目工期不确定，费用无法控制等。

性能和成本永远是一对矛盾，程序员出身的项目经理常常为此陷入两难的境地，这种状况下常常考验着项目经理对质量、成本、轻重、缓急判断的均衡感。因此，项目成本估算和控制是程序员转变为项目经理所遭遇到的最大困扰，这也常常构成了程序员向管理方向发展的恐慌。

痛苦转变之三：到底是项目经理还是技术经理？

　　在我刚刚负责项目的时候，由于各种原因导致一个人身兼多职。正常来说，项目经理的关注点应是项目的进度把控，协调各方资源使项目能够如期完成，但结果是我这个项目经理经常这也做那也做，有时还要管理编写和测试代码。这样的后果是一方面把人搞的很累，另一方面也是一个很大的风险。

后来，经过挫折和打击后，我明白到理想的项目经理无需参与具体设计，他们只需要运用独特的管理能力去协调各种流程、项目、预算和团队成员，优秀的项目经理需要做一个领导者，象汽车司机一样操作汽车。而理想的技术经理，是一个有着技术天赋的人员，是其他技术人员眼中的技术领导者，他们是技术导航员并能够解决问题，就像一个汽车发动机一样。项目经理是对项目整体负责，技术经理是对项目的技术负责，项目经理主要负责成本和范围，技术经理则负责技术实现和质量。项目经理监控技术经理的质量工作，技术经理从技术角度协助项目经理的成本、范围工作。

后来经过多次的混乱后，我们决定把项目经理和技术经理分开。这个事情也让我深深明白到，项目经理不应该把应是技术经理做的事情也做，必须转变思维方式，立足于管理才是正道，这也是我从程序员到项目经理转变的最宝贵经验。