破解软件项目管理难题，从改变看待问题的方式开始。开发流程根据不同的项目应有不同的变化，但是团队中每个角色的责任应该是相对固定的。
一 既然屁股决定大脑，就让屁股放好位置
传统的项目管理书籍，往往会从一个项目的生命周期开始，描述每一步应该怎样做。但是从实际践来看，项目的生命周期往往不是那么简单。特别是互联网公司的项目，有长期项目和短期项目的交错，还有短期项目变成长期项目的，或者并行几个项目的。如何真正的管理好项目，完全根据时间线索来照本宣科，几乎是不可能的。这也是很多“开发模式”实际上并不能很好的“指导”互联网项目的真正原因。
在纷扰复杂的项目开发过程里面，最重要的因素就是开发者即人。很多项目成果的根本也是因为人，而不是用了什么流程或者开发模式。不管什么项目，最稳定的因素也是“人”这个因素。所以项目管理从对流程的关注改变到对人的关注上是必然的，只有这样，才能真正把握好做项目管理的核心。
人的思想往往受各自立场所限，所谓吃着地沟油就不要操中南海的心，打工仔自然不会好像老板一样有责任心。然而对于项目管理来说，要调动人的积极性，就必须让人明确自己的位置，很多时候并非人对于位置不满，而是不知道自己的位置真正应该做什么。
作为项目管理，最重要的事情就是了解项目团队的每个人，然后确定每个人应该在项目中发挥什么作用，通过关注这些人的需求，给他们订立目标，鼓励大家以创新以满足自己的需求。
每个人的能力不一样，他们的兴趣和方向也不一样。他们的需求也各有不同。有的人关注工资收入，有的人关注职业发展空间，有的人喜欢学习更多知识，有的人想工作和生活能得以平衡，有的人偏爱冒险，有的人比较老实。而对于项目开发过程当中，也有很多不同的角色需要设置，比如需要有做沟通协调的，有需要细细检验的，还有需要创意发挥的，当然也需要老实写代码的。
作为项目管理，所做的就是把合适的人赋予合适的项目角色，然后不断推动以提高开发人员对工作的主动性，从而达到最后完成项目的结果。如果不关注成员的需求，成员没有工作主动性，那么不管是用哪种牛逼的开发模式，或者是多先进的开发技术，还是什么厉害的“管理手段”，都不可能加强团队执行力。在软件项目多变需求的折腾下，能维持团队稳定也是一句空话，更不要说提高开发效率来适应项目发展了。
项目角色的设定也是后续章节中重点讲述的内容。
小TIPS：行政上要设置尽量粗一点的岗位，工作流程设置尽量细的岗位。工作岗位和待遇级别区分开来。
二 以教训和经验为规范和流程
有很多创业团队，成员都很有激情，但是最后很多都失败了，有很大一部分原因就是团队成员缺乏开发能力，或者说开发效率很低。然而这些团队里面都会有一些牛人，并不是完全没有能力。只是这些牛人并没有手段，让自己的经验或能力让团队共享，最后要么就是累死自己，要么就是干着急。
很多项目管理的理论都有一套“完美”的开发流程，并且为这些流程编写了大量的文档。但是笔者却认为，真正的流程必须是实践出来的经验。而且一定要把经验教训变成规定的流程，才能真正“共享”给团队。
每个有开发经验的项目经理，都一定会有很多经验和教训，然而他们并不知道如何去传授这些经验。他们或是偶尔苦口婆心的讲述自己的遭遇，或者在开讲座时稍微提到一点。在真正做项目的时候，开发人员还是记不起来这些经验，因为不是亲身经历。而且每个项目都不一样，这些经验也不是完全对的上。
所以要让项目经理从一人敌，变成万人敌，真正提升团队的开发能力，就必须在开发项目过程里面，针对具体项目的实际情况，去制定专门的开发流程、开发规范，并且在工作中不断的去修正这些规范。而这个过程中团队成员也能不断的学到一些知识。学到了真才实学，才不会老是想着跳槽，而且也会更好的完成开发任务。
[例子]我曾经参加过一个多人在线大型网络社交网站的开发，因为需求变化很快，一开始大家很习惯的把新功能，直接丢到服务器上，这样用户就能立刻给予回应。但是不久之后，就出现了很多BUG影响用户的事情。
在最开始只有我一个人开发时，还比较少BUG，但是开发人员增加到3个后，我们之间的代码经常就会产生冲突，导致一些逻辑性BUG产生。更重要的是，我们一般只在开发服务器上测试自己的代码，很少整体的去测试。而QA人员也是依照我们的提示去测试。在一次严重的运营事故后，我们商量了一个方法，就是：搭建内外两套测试环境。内网测试环境用于开发，策划、美术、技术用来做测试和联调；外网测试环境则只用于QA人员测试。而且开发人员是没有外网测试环境权限的，只有运维人员才能做部署和更新。这个做法明确了开发、测试、运维的岗位权限，也明确了发布功能的流程：内测试-外测试-运营。
当然项目开发并非都是差异很大，有很多比较“通用”的经验，特别是和行业领域、公司背景相关的经验，都是可以不断总结和坚持执行的。有很多“一句话”的流程，我们叫“做法”，往往是很有价值的。
[例子]电工操作规范要求任何操作都必须有2个人同时在场。这个规范救了很多人的性命。
这些就对于项目经理的工作提出了很多的创新性要求，不只是按照某个“模式”去组织大家搞一些活动就可以了。
[例子]K公司在制作大型WEBGAME的过程中，发现这个项目和以前的不同，因为美术资源选择了使用矢量图，这种格式对于传统的位图格式，有更多的技术规格。开始的时候美术人员并不了解这些，导致程序运行起来非常慢，而且在技术和美术共同花了很多时间调好之后，因为一个新的功能，可能又让程序变得很慢。于是开发团队一起想了个办法，在美术组里面找了一个对技术感兴趣，而且也踏实肯干的成员，专门成立一个叫“美术资源处理”的岗位，专门用于处理从美术组生产的图片资源，很快经验就积累了起来，这个岗位和强制图片经过他处理的流程，让项目开发变得顺畅起来。事实上，很多3D游戏公司，都有一个叫“美术技术”（简称美技）的岗位，专门配合技术人员，去研究实现那些既少消耗硬件资源，又能表达很好效果的做法，是一个非常关键的高薪岗位。
三 用接口代替检查
很多管理的理论认为，对于工作过程的控制很重要，其中检查是一种重要手段，因此我们很多的项目经理就不停的去检查，结果很多被认为是吹毛求疵不切实际，也有说项目时间紧资源少做不到那么好，项目经理如果和善一点，检查的作用就很小，要是脾气强势一点的，又容易让团队成员不爽，最后萌生跳槽的想法。
对于工作过程中的控制，是不是一定就只有这样一种对抗的玩法呢？其实检查本身，是包括了两部内容，一个是检查标准，一个是执行检查的人。如果检查标准不确定，就会影响检查活动的质量，也容易诱发抵触心态。如果检查的人总是老板或者项目经理，一来忙不过来挂一漏万，二来这种检查也难以让开发人员主动参与，总是怕被挑错。但是这两点是可以改变一下，效果就好的多。
第一，检查环节按分工环节设置，各自对自己的出品负责。接受出品的人就是负责检查的人。
第二，检查标准按照开工实际需求，由相关人员一起商讨确定，确定下来后就按此执行。
第三，项目经理负责检查这些已经设定好的流程是否有在执行，而不需要去具体检查每一件内容。
当然以上是一个纯理想状态下的情况。实际上项目经理还是要参与到很多具体的审核和检查过程中去，特别是产品最终的检查。但是团队一旦形成那个了这种工作流程，就等于全团队都参与产品的质量控制，不再是靠项目经理单打独斗了。
[例子]N公司的短信项目是公司的收入重点，因此业务负责人总会有各种统计需求。一开始这些需求的表达方式五花八门，有时候是一句话，或者一封邮件，甚至一个图。负责平台的程序员需要自己去理解，然后加日志，根据理解再做统计。这种做法效率很低，因为经常会理解错误，而且做这个的程序员也觉得统计工作繁琐，毫无技术含量，屡次表达希望换个事干。后来技术部门的经理根据之前的多次统计需求，整理了一个统计需求的接口规范。要求提出需求的部门或人员，必须提供一个EXCEL表格，用来表达统计最后想看到的结果。而且统计表格本身，只能按时间选择输出，否则就另建新表，作为一项新的需求。虽然需求部门感觉到一定的压力，但是事实的结果却很好，因为理解错误导致报表不能用的事情几乎被杜绝了。而程序员也因为有多个类似的报表需求，去开发一些公用的生成代码，提高了技术水平。
[例子]K公司的游戏策划案经常被技术和美术吐槽，什么都没写，大量的需求实际上是在开发过程中去沟通的。流程错漏和关卡数据遗漏这些错误的经常发生，在程序做出来之前，策划也无从去检查。美术则总是抱怨做了很多版，策划都不满意。策划也很郁闷，因为技术和美术做出来的东西和沟通时预期的结果往往不符，但是又无据可依，更重要的是，策划文档要记录最新的讨论结果，这也是一个枯燥和容易漏掉的活，但是如果没有文档的话也无法测试。
于是后来大家商量了一个标准的接口：技术要求策划案一定要有处理流程图，不接受纯文字描述；所有关卡和配置，都以二维表的方式表达；所有的界面都必须有示意框图，以及框图的关系调整图，测试人员和策划则按策划案来验收，检查是否所有的流程和数据、面板都是完成的；美术要求策划案要提供图量表，每个图片需求需要风格参考图片的截图，并且美术会以草图反馈回策划，策划签名后开始进入制作。
有了这些接口规范后，大家自然就按标准去做，再也不需要反复的沟通和检查，因为工作流程中本身就是一种检查，发现有漏了或者不对的地方，都是先改文档——也就是接口，然后才继续开工。
小TIPS：在推行检查标准时，多总结以往类似的实际经验教训，让大家明白检查的必要性。
四 不打鸡血不洗脑
市面上有大量的“成功学”书籍，也有很多公司采用排队喊口号的方式来“训练”员工，但是笔者认为在互联网公司，大部分员工都是具备比较高的理性思维，特别是程序员，爱较真爱推理，靠感性来感染洗脑，或者用一些做法来鼓动激情，只会在一段时间内有效，不可能成为项目开发真正的推动力。
有一些大公司，喜欢搞军事化管理，似乎这样就能统一大家的想法，然后让大家都想着为工作努力，实际上，每个人都是有自己的个性，所追求的目标也各有不同，强行扭曲到一起，只是让自己成为竞争对手培养人才的黄埔军校而已。
真正有效的做法应该是让成员都知道，公司的目标和个人的目标在某个地方是一致的，让大家自愿自觉的去工作，然后得到自己想要的东西。没有一个公司是完美的，也没有一个人是完美的，项目、公司都有出生和消失的一天，注重在这个过程中，公司、管理层、个人是否都能得到一些想要的东西，才是一个合理的目标。
[例子]K公司想尝试挑战自己的开发能力极限，开发一款从技术、策划、美术来说都没有前例可循的前卫的游戏。项目经理尝试提议团队迎接这个挑战得到回应了。于是他想了个办法，就是请来了很多玩家，在公司试玩各种游戏，然后让团队观察，然后选出一个最受欢迎的游戏类型——横版动作。
在总结观察结果的会议上，大家一致认为做这个类型的是最有前途。然后项目经理又组织了多个产品筹备讨论的会议，让大家发起头脑风暴：“如果我们要做这样一款产品，应该怎样做”。
大家从商业前景、实施难度、技术可行性、产品设计方向方面，进行了多次开放式沟通，这些沟通结果，都被一一记录下来。在这个沟通的过程中，整个团队开始对开发这样一款产品，有了动力和信心。随后项目经理组织开始做一个原型测试型产品，针对技术难点和产品设计的重点做尝试性开发，产品出来之后，虽然不够完整，内容也不够丰富，但是是可以扫清开发的障碍，是可行性的。这个原型产品随即被投放到市场上，虽然没有大力推广，但是也能搜集一定的用户意见和BUG。
开发团队针对这些反馈，在完善了几个版本后，非常有信心的开始了正式产品的开发。在这个过程中，项目经理逐步的让团队树立起挑战难度的信心，并且成功的发动起团队的热情，让大家看到市场前景，知道公司为何要做这个产品，然后放手让开发团队按自己的方法去追求质量。因此产品在短时间内高质量的完成了，让众人耳目为之一新。
真正能推动软件开发效率的，只有一条路径，就是提升团队的开发效率。重要手段有两方面：一方面通过关注团队成员的需求，提高他们的主动性，降低内耗。另外一方面，通过实施流程、规范检查、各种培训来提高团队成员的开发能力。只要团队有能力去做，而且愿意去做，工作就一定会做的更好。
笔者希望从改变项目管理书籍中，按项目流程顺序的方式来介绍项目管理的方法，转而去描述作为项目核心角色的项目经理，他应该承担怎样的责任，又如何推动别人承担自己的责任，并且描述每个角色应该注意的规范和流程。希望读者能通过对每个角色的认知，了解到互联网项目中每个人要做些什么事情，从而真正提高整个团队的开发效率。也希望能以此赢得互联网软件项目的巨大挑战——需求变更。最后总结一下本书重点关注的地方：
- 角色的职责：描述每个人应该做哪些事情，应该专注于解决什么问题
- 角色的诉求：说明每个人所承担的角色，有什么需求，应该如何满足
- 流程和规范：描述角色应该如何去做事，做事的方法是如何影响结果的
从以上三个重点，希望能完整的描绘出，互联网项目管理的核心方法：以角色组织工作，用流程来优化方法，通过角色来理解诉求，从而打造士气高昂，流程规范，学习能力强，能力专业的高效开发团队。
感谢大家的阅读，如觉得此文对你有那么一丁点的作用，麻烦动动手指转发或分享至朋友圈。如有不同意见，欢迎后台留言探讨。
