项目经理的核心价值是什么
前段时间在赤兔上收到邀请，参与一个讨论，讨论的主题是“项目经理的核心价值是什么”。
看到这个题目的瞬间我觉得自己简直文思如泉涌-----有太多太多想要说的了。
憋了好几天，好不容易把自己脑袋里想的所有的东西拼凑成一篇文章，却发现好像偏离了主题了。所以也就没有去赤兔上发表。但是又不想浪费了，就记在这里吧。
/**
* 我是码农风格的分割线
*/行业：IT
行业细分：软件工程
专业出身：计算机软件工程
职业成长路线：程序员、软件工程师、架构师、项目管理、创业
工作了这么多年，经常自己也会时不时地思考这个问题。随着自己的成长，身边也越来越多接触到这个行业里的同行们，也看到了这个行业在这10多年里所经历的发展过程。但是真的要提笔写一点关于这个话题的想法，又一下子觉得东西太多太砸，有点无从说起的感觉。我是一个典型的工科生出身的人，不善表达的缺点在这个时候就暴露出来了。
不过我觉得，要聊这个话题，与自己所在的行业脱不了干系。既然与行业有关，我觉得还是先从这个行业入手开始聊吧。
软件行业的项目管理概念本身就出自传统的工程行业，例如建筑工程等。这个行业在10年前，也就是我刚参加工作的时候，跟现在是有着天壤之别的。现在的软件开发人员，已经工作细分到不可想象的地步。我的工作主攻的方向是互联网软件系统的开发，其实“互联网”这个概念是近几年才兴起的，在技术人员眼里，其实整体的软件系统架构还是那回事。一个所谓完整的“互联网架构”，其实是相当复杂的，但是我们可以从最最简单的结构出发来进行讨论，毕竟万变不离其宗：有一台服务器，运行着一款数据库软件;另一台服务器运行着一个服务端系统。这两部分组成了最简单的所谓的“后台”，这个后台为所谓的“前台”提供支撑，而构成前台的，10年之前是各种浏览器，现在又多了各种智能化移动设备，除了最常见的民用设备例如手机或平板电脑之外，还有很多工业级的设备。
现在在这个行业里参与各种软件开发的工程师们，已经被细分为“后端”、“前端”两大类，这两大类又被各自细分，比如后端又可以分为“数据库开发”、“DBA”、“底层架构”、“业务逻辑”、“表现层交互”等等，如果再算上不同的开发语言，例如最为常见的Java或是微软.NET系列等，其细化程度会变得很多很多;而所谓的“前端工程师”，在这几年中也逐步细分出来，比如“HTML/CSS”、“JS开发”、“安卓开发”、“iOS开发”等等。在这种细分的过程中，某一个细分领域的工程师会专精于自己所在的领域，但是对于其它领域就逐渐丧失了驾驭的能力。
除了一线的开发人员，也就是现在被大家戏称为“码农”的人群，其他相关的工作岗位也同样被细分，例如UI设计、系统架构师、需求分析、产品经理、售前经理，当然也包括项目经理。
而在我刚刚参加工作的时候，也就是仅仅10年以前，所谓的软件开发人员根本就没有这样的细分。也许是因为我从参加工作起就一直是在小型团队里做事，所以无论客户或是公司的上级领导，只会向开发人员发布一道简单的指令“我要一个软件系统”。然后指派某一个人去负责完成。那个时候为了能够顺利交付任务，我经常不得不一个人做完所有的事情，从打电话联系最终客户开始，到整理需求，反复与客户反馈沟通，到一个人画UI原型，再反复与客户反馈沟通。现在的程序员们可能都想象不到，一个专职写代码的开发人员居然会精通以PS为代表的各种绘图软件，甚至比某些初级的平面设计人员都要精通。但10年前的我就是这样工作的。等客户都差不多认可了，然后再根据客户的预算和项目的实际情况，选择数据库软件，开始设计数据库结构，将UI原型转化为网页界面代码，然后开始架构工程，为了能够缩短开发时间，不停得动脑筋“偷懒”。这个所谓的“偷懒”就是整天思考怎么能够高度抽象出可以复用的源代码，以便大量减少写代码的工作量。也许有人会说你为什么不用成熟的架构体系，例如对于Java开发人员来说，Spring就是一个不错的选择。但是这是现在，回到10年以前，还没有那么多可以选择的并且成熟的架构，更多的时候我们不得不自己来设计自己的架构。
搞定了这一切，就是码代码。因为规模小，所以没有人能够有空余的时间来帮助我。这就意味着我必须一个人完成所有从后端到前端的代码。随着乔老爷惊天发布第一代iPhone，谷歌爸爸又及时跟进了安卓开始，我的日常工作就又多了两大部分：iPhone和各种安卓手机的客户端开发。
近几年，互联网行业出现了一个听起来很牛逼的名词，叫做“全栈”。对于传统计算机工程专业出身的我来说，看到“栈”这个字的时候，第一反应是这是不是又是国外哪个软件大厂推出的全新技术。后来一查才了解，原来我前几年干的那些活，就是对“全栈”的活生生的定义：啥都会。
不出意料，有过1到2次这样的“全栈”项目的经验后，我和我的小伙伴们在当年都开始顺利地成为了项目管理人员，简直可以用“水到渠成”来形容。因为我们每一个人都十分清楚一个项目从立项开始到最后验收以及日常运维的每一步。
后来我个人就去考了一个项目管理的资质。并不是烂大街的“PMP”，而是另一个名字很拗口的资质，叫做“系统集成项目管理工程师”。不过这个资质跟PMP本质都是一样的，全部都是源自“PMBOK”理论体系。提到“PMBOK”体系，各位从事项目管理的同行们应该就十分熟悉了。
终于来到了本次讨论的正题了。
最早为了考这样一个资质，自己也买了些理论教材，也参加了几次应考培训，在过程中我就发现，所谓的“项目管理”不过也就是那么回事了，而那些理论体系也完全没有任何难以理解的地方，因为所有的管理理论或方法，我都早早地自发应用在日常工作中了，尽管那时候自己根本意识不到这就是项目管理。
纯粹的项目管理理论体系和方法论，无外乎围绕“成本”、“进度”、“质量”、“风险”这些。稍微展开一点点来讲，就是考虑怎么花最少的钱（成本），在最短的时间内（进度），把事情做到最好（质量），同时不要捅楼子（风险）。
在进行项目管理工作的早期，确实是这样，而且我自认为对自己来说，要做到这些并不难。这得益于当时的团队成员，大家几乎全部都是“全栈”，并且也都认可很多项目管理的理论和方法，尽管可能有些小伙伴没有系统接触过“PMBOK”。毫不夸张的讲，在配合最默契的时候，连话都不用讲，一个眼神，团队里的小伙伴们就知道要做什么了，并且能够保质保量并且按时交付工作。
既然大家的能力都强了，大家就开始逐步逐步脱离团队了，有的选择了去别的团队，有的会去独立负责其他工作。问题就从这时候开始了。
有了新的团队成员进来了。然后我发现，新的团队成员开始出现了之前所说的那种“岗位细分”的情况了。有一件事令我至今都记忆犹新：一个负责后端开发的“码农”，完成了自己责任范围内的代码编写任务后，完全不顾与前端页面开发的对接。当项目的功能出现BUG时，那个开发人员的态度是：“那与我无关，我的代码是能够正常运行的，不信我run给你看”。相对应的，负责前端的小伙伴当然也不会主动承认是自己的问题了。我花了非常多的时间去协调这件事情，而其中大部分的精力都花在了说服两个人并且向他们提出一个可行的技术解决方案，其中也包括测试方案。
另一件令我印象深刻的事情是，当一个项目处于测试上线阶段的时候，用户方向我提出了一些改进的意见，主要都是与UI交互和操作便捷性有关的建议。我带着这些建议向开发团队进行了反馈，出乎意料的是，有关的开发人员完全不愿意针对这些意见进行调整。理由是“我开发的功能没有任何问题，是用户自己不会用”。后来为了这件事情我与这个开发人员起了争执，他是从一家所有人都知道的国际IT巨头跳槽出来的程序员，我不知道他为什么会放弃这家巨头公司，也不想去关心他在这家巨头公司里究竟发生了什么事情，但是他浑身上下透露着一股典型的程序员的傲气：“我是最牛逼的程序员，我来自超级巨头公司，你们这些傻X懂什么”。
在后来的两三年，我发现几乎这一时期所有的新人程序员们都被“细分化”了。所有人无一例外的认为自己在自己的细分领域是专家，其他人对他来说都是“你们这些傻X懂什么”。其实我并不反对“技术专精”，但是其实在很多情况下，技术只要够用就可以了，甚至有时候稳定和可靠才是最重要的。另一个问题就是，其实这些程序员们并不如自己所想象的那么牛逼，因为我不止一次发现大段大段惨不忍睹的代码，思维逻辑混乱，效率低下，又没有一句注释，甚至很多人连工整的缩进排版都无法做到。我一度怀疑自己是不是强迫症过份了，难道这些程序员看到像狗啃过一样的层次不起的代码排版自己不会觉得难受么？远看成岭侧成峰？
后来我又在进度方面发现了很多新的问题。所有安排好的进度，在执行的时候，我得不到任何的主动反馈。只要我不问，就没有人会主动来进行沟通，甚至包括当项目的进展出现问题的时候。而当我召开例会，甚至是按照计划进行评审会议的时候，才发现开发人员的工作成果早就已经跑偏。我很纳闷，很多开发人员在进行模块开发的时候，完全是凭着自己的想象去做事的，哪怕最终完成的软件功能在UI交互上非常难以操作，甚至是连他自己现场演示的时候，他自己都很难进行顺畅的交互操作，但是他们似乎对此根本不在乎。然后我发现除了功能开发得像屎一般之外，进度还严重落后。刚开始的时候，我还以为是不是大家的能力都有限，无法按照我的标准去完成进度。但是后来当我坐下来跟其中一个开发人员逐条查看工作内容的时候，我发现是我太天真了。这个神奇的开发人员居然完全不懂代码复用。且不说常规的抽象、继承、封装这些基本开发思路，但就是一些在产品上重复出现的功能点，每出现一次他就会再去从头开发一遍。我开始怀疑自己是不是外星人了，难道已经做过的功能拿来直接使用不好吗？后来在我“无微不至”的帮他重新梳理工作点和进度，当中还夹杂着些许震天吼和砸桌子的情况下，原本他自己认为需要2个自然周才能写完的代码，3天后他就全部完成了。
所以在很长一段时间内，我的项目管理工作状态都是，对外保持与客户及现场的及时沟通，对内承受来自公司高层的压力，同时还要像“事儿妈”一样每天盯在所有团队人员屁股后面，好像他们每个人都欠了我的钱一样。甚至是，我还需要坐下来帮他们解决代码上的技术难题。好吧，谁叫我比他们多码了那么几年代码呢。
我甚至还不止一次对90后们说过，别光瞧着BAT的高工资，首先你没那能力进得去，其次就算进去了你也不见得承受得住那个压力。然后不厌其烦地告诉他们“代码的功夫都在代码之外”，告诉他们为什么在国内很难一辈子靠码代码混饭吃-----因为我们国家人太多-----等你过了30岁，你就会明白了。所以好好地打好基础才是真的，不要觉得会一门编程语言的语法就能走遍天下都不怕了。你得不断提升自己，这样即对自己好，也对团队好。
有时候自己想想我为什么要替你们操那个心，你们的未来说到底与我何干...我真不知道别人家的项目经理是不是也这样整天为这为那操碎了心。
所以我觉得，一个项目经理的核心价值，也是决定一个项目成败的关键，绝不是所谓的平衡“成本、进度、质量、风险”，而是“操心”-----看你究竟能操多大的心。
其实做什么工作不需要操心呢？