项目管理核心仍然是团队和人

原来有篇文章我谈到过项目管理的核心要素，包括目标驱动，系统思维，风险意识，数据量化和以人为本。而这些要素也可以明显看到主要集中到思维和意识方面的内容。项目管理要做好很难，特别是IT项目管理，需要考察多方面的综合素质和能力，但是最重要的仍然是意识的转变，意识没有转变就无法真正的去驱动自我能力的提升。特别是从技术岗位走上管理路线的项目经理尤其重要。

项目管理最核心的问题仍然是人的问题，从招人到识人，从用人到激励人，从单个人到团队。所有的流程，方法，工具和技术固然重要，但是最终执行的仍然是人。不论企业是实施了ISO，CMMI还是IPD，最终都不能忽视了人在项目和团队中的作用。所有的招聘，培训，技能评估，绩效等全文围绕人来展开。这个时候你会发现企业的HR其实重点已经过渡到了制定大的人力资源流程和方案，到了具体的执行很多还要靠项目经理落地，对于矩阵式的组织中同样的道理，项目经理务必不能有一种思想就是人的问题是职能线领导的事情，跟我没有关系，我只管用人。在强矩阵环境中人基本都跟着项目走，因此平时的沟通，激励，团队，培训很多内容其实都需要在项目层面开展。

对于招人，项目经理务必要高度重视，我们强调的是招聘到合适的人而不一定是最优秀的人。最合适的人是能够基本胜任现在工作而且有培养前途的人，这就是项目经理需要的识人的重要眼光。招到一个不适合的人不仅仅是增加单个人的成本，而且该人后续的处理和流失等都会直接影响到整个团队的氛围。为了让后面开除人少痛苦，那么前面就更加应该严格控制。对于招人，一个是态度，一个是能力，或者能力可能是潜在的，需要考察其学习能力来说明潜在能力。态度的考察比较容易的几个方面，一个是对待本次招聘的态度，一个是对待以往工作的态度；对于能力的考察往往并不需要考察你需要的新的工作技能或知识点，最好的方法就是考察面试者最熟悉的知识点，考察其对经常用到知识点的掌握程度和知识外延的熟悉度，这种方式一是考察现有能力，一是考察自我主动学习能力，看看工作时间是否换了了等周期的工作经验，而不是大量工作的重复。

是否能够招聘到合适的人是和你愿意投入的招聘和找人的时间完全成正比的。为什么朋友推荐的人应该拿人才推荐奖，因为朋友帮前面很多工作帮你做了，节约了你的招聘时间。对于招人，招聘网站仍然是我们的重要渠道，一方面是需要主动的发布招聘信息，一方面还需要主动的去搜索已经有的人才库。所以一个招聘网站的好坏往往更加重要的是体现在第二点上面，是否能够提供便捷的方式让你能够快速地找到你需要的人。对于招聘网站的简历可以对人进行初步筛选，大多数的人简历上都会反映大量的潜在信息，比如是否频繁跳槽，写建立的语气，是否什么都精通，工作实际内容等都可以帮助你做初步的选择。这个阶段的工作量很大，很多时候不注意往往优秀的简历就从你眼皮底下溜走了。

招到合适的人进来的，首要的就是要安排指导老师形成以师带徒的模式，要让新员工时刻的感受到这是一个团队，我有问题是可以问师傅的，我是有人教的，很多时候我们不注意这点，一个是新员工很难快速融入，一个是本身新员工学习不系统技能提升很慢。老员工是否愿意教，新员工是否愿意学很大程度都受到团队气氛的潜在影响。

对于用人，其实已经和项目的培训，实际项目的资源分配和进度安排等很多工作关联起来了。用人就是根据员工实际的技能和性格特点等为他们分配最合适的工作，即扬长避短。为什么系统不能自动的帮你把进度全部排出来？因为执行者是人而不是机器，人的因素又往往很难进行公式化。所以项目经理进度安排最重要的往往不是WBS分解和活动排序，而是搞清楚我现在团队技能情况和性格特点，考虑多方面因素后来分配合适的工作，让团队成员能够更加高效的协作，减少沟通障碍等。在管理里面我们谈到过一个重点，就是通过管理，是否让每个员工都清楚了自己所处的岗位，该岗位对工作技能的要求，对工作输出的要求，如果一个员工来自己的角色和工作要求都不清楚，又如何可能把一项工作做好呢？所以发展到后面自然就转变成了一种混乱局面。

谈到用人自然涉及到工作和任务的分配，这个过程也是需要注意的，很多时候不要搞成了员工完全被动的接受工作任务而减少了必要的沟通。工作任务的安排更加会强调需要获取员工对完全工作任务的承诺，当员工愿意为工作任务进行承诺的时候，就表明大家对工作的要求和内容达成了一致，一种单向的工作传递变成了一种双向的工作任务沟通和协议达成。

培养人和激励人的问题就显得更加重要的，人是需要团队，团队需要不断的发展提升核心竞争力，而团队中的人也随着团队的发展和运作的规范化提升了自我的技能。这是一个双方都受益的过程，员工是企业的核心资产，只有员工本身升值才能够带动企业整个核心资产的升值。培养人不可避免的有成本，但是在这方面却来不得半点的节约，培养人不仅仅是通过正式的培训，而更多的是需要通过日常的工作，案例分析，故事管理，言传身教都多种方式进行。前面一篇文章谈到企业的地头力，其实每一个人都应该加强地头力的培养，则现时，现场解决问题的能力，而这种能力的培养必须要通过出现故障和问题后现场直接的案例分析，通过故事管理来推动。

项目经理的内在修养将直接影响到团队的管理和人员的培养，项目经理最重要的就是自律，谦虚，开放和包容，以及其它最基本的职业道德。项目经理首先要加强自律，以方便推动纪律和团队规则的执行，团队要逐渐凝聚，刚开始阶段一定是项目经理的能力和个人威望，在团队发展和规模不断壮大后会转变为通过团队文化来达到这种凝聚的效果。项目经理一方面是严格的执行项目管理规程，制定项目计划和分解任务，跟踪任务的执行，但是更重要的还是观察人，沟通，团队活动策划，员工培训，团队纪律等重要内容，这些内容才是项目真正能够有序执行的基础支撑。

项目管理就是风险管理

风险是什么？风险就是不确定性，而项目管理的过程就是不断地消除风险的过程，没有风险的项目一定应该是成功的，如果失败都说明前期没有充分的失败和应对风险。风险和风险管理都谈得比较多，但是其重点往往并不在于系统化的风险管理方法和流程，而在于风险意识的形成和转变。风险意识和危机意识是项目管理最核心的一个思维意识。对于风险管理可以再谈下其重点的核心如下：

风险管理是项目目标驱动的，这样的风险管理才有意义。

达成项目的目标究竟还存在管理，技术，支持等各个方面的哪些不确定性？这个不确定性如果不解决对目标影响是否可以接受。

做计划是对项目目标和结果进行预测，但是预测无法100%准确，风险管理目的就是应对计划本身的不确定性。

风险管理的难点在于通过历史经验积累，识别项目的关键风险，只有识别出来才谈得上应对。

项目应该预留合适的时间和资金的缓冲，但是缓冲太大确实灾难，它可能让我们忽视了风险本身，因为即使风险已经转化为了问题也没有影响到最后目标的达成。

风险意识重点就是在项目启动前或项目执行过程中都随时有意识的去识别项目的关键风险，只有先把风险识别出来，才谈得上如何去分析和量化，如何去应对。

首先我们应该看到的是从自己的失败中总结前车之鉴，历史的项目为什么失败了？为什么项目目标偏离了？要去分析这些问题的根源，要去考虑如果再接新的项目的时候如何去预防，如何避免问题再次发生。挂在嘴边的不仅仅是风险两个字，而是风险应对措施的真正落地，你需要去考虑哪些事情需要提前预防和提前介入，哪些事情需要制定备选方案，哪些围绕项目团队和环境的事情提前展开，这些工作都必须要做，都是为了降低和消除不确定性。有时候你做了这些事情后，风险没有转变为问题，大家可能看不到这些风险应对措施的价值，但是你仍然必须要去做。有时候可能往往成功救火的人反而得到了表扬，但是这些都不应该影响到你的思维和应对。

其次，从组织的失败中找寻经验。这也是我们说的组织级的风险库，别的团队和项目出现了问题，那么你自己的项目或团队就有可能出现问题，你可以去看他人的经验教训总结，看组织多年积累的风险库来审视自己的团队是否会发生类似的问题，这是一个组织成熟的重要体现。同时你也必须意识到你原来没有发生类似问题并不代表你将来不会发生类似问题。通过组织级的风险库和风险检查单，你就可以从团队，项目，环境，技术，支持过程，客户等多个方向去寻找可能存在的不确定性。

前面两点可以看到都是从自己和组织的历史中去找寻经验，比对现在项目可能存在的风险和不确定性。那么最后一点就是从当前的完整的项目计划中去找寻风险和不确定性。项目的进度是否能够达成？项目的质量和成本如何保证不出现偏差或偏差可控？项目的进度可以通过WBS分解到细化的活动和任务，项目的成本也可以通过预算逐层分解，而这个分解对应的往往正是一个项目的风险树，你需要考虑的就是风险树上的每一个节点在保证质量的前提下成本和进度都是可控的。

注:这里还要提到风险管理不仅仅是项目经理的事情，需要把风险意识下达到整个团队，每个团队成员都应该做这样的思考，如我这周的任务是否有100%把握完成，存在哪些不确定性？如果不能完成我应该这么办？

IT项目管理和软件生命周期

在这里主要是谈软件项目经理，因此和其有关的就是软件生命周期模型，PMBOK是标准的项目管理知识体系模型，而对于软件开发项目经理必须要了解的就是软件工程域和软件生命周期模型在软件项目管理中的重要作用。这是做好IT项目管理工作的基础。对于参加的瀑布，迭代，螺旋，增量等各种软件什么周期模型在原来的博文中都已经有详细描述，在这里仅重点讲对软件什么周期模型的一些重要认识。

什么周期模型最基础，最核心的就是瀑布模型。所有的增量，迭代，螺旋，原型等各种生命周期模型都来源于瀑布模型。如在敏捷方法论中常见的迭代模型，在每一个迭代周期中就是一个小瀑布模型，如果连瀑布模型都用不好这很难用好其它什么周期模型。生命周期含义就是产品演化和事物的发展有气必然的阶段和顺序，因此各种什么周期模型都不能跳过程。在这里再解释下TDD测试驱动开发，为什么没有设计开发就已经在测试了，注意这里不是在执行测试，而是在写测试用例，并通过测试用例来进一步明确需求的How to Test部分的内容，这和测试里面的V模型是一致的。

需求分为业务用户需求和系统软件需求两个重要阶段，当时我们做系统的时候往往是直接进入到了软件需求。用户需求阶段重点是业务建模和流程建模，重点是搞清楚业务主题域和业务场景；软件需求阶段重点是需求用例分析和功能分析，重点是搞清楚需求细节以支持可实现性。在这里前面关于SERU需求方法论的博文有专门的描述，总之要重视业务建模环节，不要跳过该环节直接进入到了软件需求，导致功能实现不能真正解决业务问题。

需求要条目化，在FDD和SCRUM等各种敏捷方法论中都可以看到需求条目化的例子。条目化的需求即用户故事，是实现业务价值的一个最小单位，是业务目标驱动的需求，条目化的需求为后续项目细粒度的进度跟踪和进度可视化打下了坚实的基础。同时条目化的需求方面了后续一系列需求，实现和测试的追踪过程。

不要想着需求不变化，或者把项目延期的责任归咎到需求变化大上面。软件项目经理应该更多考虑如何更好的去适应变化，如果让需求变化导致的影响最小。这就涉及到需求优先级和迭代内容划分，架构可扩展性等一系列内容。举例来说，如我们装修房屋，最后主人要求在卧房床边增加一个壁灯，这个时候我们如果原来预留了插座则该新需求带来工作量是相当小的，反之如果当时什么都没有考虑，这可能影响到已经完成的管线等隐蔽工程，这个代价就会相当大。但是如果到处留插座带来的管线工程成本和复杂性也是相当大的，因此项目经理就应该和架构一起来考虑这个问题，如何去适应变化。

原型法 迭代的短周期版本是为了适应变化的重要方法和工具，通过原型法可以更好的和用户沟通和确认需求，通过短周期迭代可以尽快的拿出系统的第一个正式版本，让用户尽快使用系统，并在使用基础上挖掘更进一步的需求。

对于架构，一定要注意的就是软件项目经理往往还需要承担部分的架构设计和评审的职责，对于全新的产品必须进行架构设计而不适合采用敏捷开发的方法论。因为架构的重点就是通过分解和组件化将复杂的系统实现简化，最后再按照预订的接口进行集成。架构师不适合多人共同进行，架构最好掌握在一个人手中以保证概念完整性，即我们所的即时架构存在一定的问题也可以保证整体上还是一致的而不是五花八门。对于数据库设计应该纳入到架构设计的内容，架构的重点就是通过分解进行系统组件化，在组件化后又开始考虑复用，同时考虑各个组件间的接口和集成。对于全新产品的开发架构起到至关重要的作用，架构不仅仅是要熟悉纯技术架构，同时还需要熟悉该系统所在的业务领域知识。原来我们谈的系统分析员更应该是业务架构 技术架构。

源代码就是设计，对这句话我还是相当认同的，特别是在架构设计和数据库设计完成后，真正的详细设计内容完全可以体现到源代码的代码框架上面。在这种情况下没有概要设计，概要设计是一个很模糊的词语，简化的流程应该是将概要设计中重要的内容升级到架构设计中，将概要设计非核心内容下移到详细设计和源代码中。写代码的过程就是设计的过程，当时往往很多程序员是没有理清设计思路就开始写代码，写到哪里算到哪里，这是一个很不好的习惯。要知道设计的中间环节越多，这些中间输出的一致性就越无法保证。而我们花费了大量时间编写的设计文档，到了最后往往自己都不会再拿出来看一眼。

对于测试而言，在敏捷方法论中对传统的测试V模型有很大的改进。即我们所的每日构建和冒烟测试，以达到敏捷里面谈的持续集成的作用，只有持续集成才谈得上开发进度的可视化。通过冒烟测试是很好的建议开发人员工作是否完成的方法和工具，在2009年我曾经翻译过软件开发中的进度游戏一系列的文章，其核心就在讲没有得到最终验证的进度都是虚假的进度。一项工作完成了90%花费了一个月，而完成剩余的10%往往还会花费掉你一个月的时间，这在软件开发中是经常出现的场景，即个人对进度的评估是不合理的。

评审是贯彻了软件生命周期模型的重要过程，重点的评审包括计划评审，需求评审，架构评审和代码评审。评审的目的不仅仅是提前发现和纠正缺陷，同时要认识到通过评审是团队共同学习的机会，是团队形成通用词汇表的重要方式。

交互设计和易用性，往往是软件产品成败的另外一个关键内容，易用性过程贯彻整个软件生命周期模型。从前期的UI设计，交互流程设计，用户行为分析，到后期的易用性测试和易用性评估改进等。这些都是为了真正让产品符合用户的需要。需求挖掘和需求开发是解决能用的问题，而易用性才能够真正的解决产品好用的问题。