IT项目管理是一项复杂的任务，需要管理人员具备良好的项目管理技能、软件开发经验和团队管理能力。本文主要从八个方面提炼了项目经理需要具备的技能：慎始善终、谋定后动、明察秋毫、借力而行、见微知著、同舟共济、明哲保身、团队养成，希望能帮助项目管理者更好地应对各种挑战和问题，保证项目的质量和进度。

01

慎始善终 - 交接售前工作

慎始善终是一种处事原则，意为要在开始时审慎考虑，然后在结束时做到完美，从而确保任务可以圆满完成。对项目管理来说，项目的开始并不是项目准备和项目启动工作，而是售前顾问和项目经理的交接（当然有些项目经理自身参与售前例外）。

售前工作交接通常需要售前顾问将售前阶段埋下的一些坑充分传递给项目经理，比如过度夸大和保证项目未来的实施成果和效果，或者口头和私下承诺的一些在SOW（工作任务说明书）中没有体现的需求。

还有一个重点就是交接项目关键干系人的相关情况，如决策影响力（决策、执行）、行事风格（革新派、保守派）、对我方的态度（支持、中立、反对）、交往程度（无交往、短暂交往、交往深厚）等等。在实际执行过程中，很多项目由于缺少售前工作交接这部分工作，导致后续项目经理在项目执行和管理过程中陷入被动。

02

谋定后动 - 做好项目计划

相信每个项目经理都能做项目计划，但项目计划是否做得细致、是否具备可执行性就要看项目经理的经验和能力了。通常来说乙方内部的工作相对好协调和控制，所以在做项目计划的时候尤其要关注客户和第三方的情况。

通常不同行业、不同领域的客户都有其特殊业务属性。比如酒业通常在春节前1-2个月是业务繁忙期，如果这个时候计划大范围业务调研、蓝图确认、UAT测试、培训和上线试运行，肯定是不切实际，最终的结果就是项目要延期。通常制造业通常会有高温假（设备检修）、不同企业的财年不一样，在高温假和财年开始和结束期间也不能安排客户深度参与的工作。不同企业决策和签字流程也不一样，需要事先了解客户的签字流程和周期，并融合到项目计划里。

在制定项目计划的时候，尽量将整个项目周期的各个环节和场景在脑海里设想和回放出来，将相关的各种资源包括里程碑节点、人员、场所、系统都体现到场景中，并考虑是串行还是并行。导演拍电影通常都会事先在脑海里讲剧本场景化，然后才会考虑选景和物色演员；三国演义里将帅也往往是依据特定场景来结合天时、地利、人和及地方将帅的性格特点来排兵布阵，以期做到疏而不漏。

比如上线之前有没有建立运维体制，性能测试是在UAT环境还是生产环境执行。如果在生产环境执行，如何备份和恢复系统和数据库以清除测试垃圾数据，系统上线后需要做哪些关键点检查和制定上线失败的回退方案。

03

明察秋毫 - 严控项目进度

如果问一个项目经理项目为什么延期了，估计70-80%的回答是由于第三方的原因导致项目延期，可能还有10-20%回答是客户原因，很少会承认是乙方或者项目经理自身的原因导致项目延期。

其实也不能说这个说法不靠谱，或者说实际情况也许确实是如此，比如甲方需求经常变动，甲方资源协调困难，乙方配合度不够等等。但对一个有经验的项目经理来说，其实这种局面往往是可以改善的。

关于第三方配合问题下一标题阐述，这里先谈下客户资源协调和配合度的问题。我列举几个方面的例子：客户内部派系（反对派、政治斗争），项目涉及部门利益，客户内部改变现状的阻力，客户资源问题，甲乙双方的磨合问题。这里就体现了在项目前期需要做售前阶段工作交接的重要性。

通常在项目开始阶段甲方对乙方由于企业文化差异、实施方法论差异造成相互不了解而导致不信任，这个时候项目经理需要尽快缩短磨合期，这个磨合期通常会延续到蓝图确认结束，项目管控不好会延续到开发、测试甚至蔓延到项目整个周期。如果项目开始后乙方越早越快取得甲方信任，后面项目基本就会比较顺利。所以尽快取得甲方信任，是项目经理在项目启动后的重中之重。这也间接说明，在蓝图阶段项目通常会有所延期，但在项目后程可以赶上然后确保项目整体如期交付。

如果客户资源不好协调，可以考虑双周滚动计划甚至四周滚动计划，尽量提前预约客户资源尤其是关键资源，确保项目计划可控和可执行。通常项目经理容易忽视的就是客户评审和签字环节，计划里往往留1-2天的时间做评审和签字，但实际情况有时找某个领导签字可能一周时间都不够。

04

借力而行 - 管理好第三方

项目由于第三方原因导致延期确实是常态，但这个其实很多时候还是可以避免。要避免第三方造成对项目的延期，就需要对第三方做一个初步分类：

第三方的系统在运维阶段

其当初主要项目成员早已撤离现场，运维人员能力很弱且对项目背景和需求把握不强。这种情况，第三方的战斗力就会较弱，如果安排紧凑计划将很难如期完成；

在主项目立项的时候，没有考虑外围系统的预算，或者预算很少

这种情况第三方可能会由于没有预算或预算少不会投入精兵强将，项目执行力度也会打折扣。还有一种极端情况，有些第三方在没有预算的情况下拒绝配合，甚至不走完完整商务流程不投入资源的情况。我曾经在项目遇到有第三方需要在签完合同才入场干活（总共不到20人/天的工作量），不是通常在谈好工作量和价格在启动商务流程的时候入场，结果走这个商务流程花了2个多月。

第三方可能是竞争对手，故意不配合

比如我们替换竞争对手的老系统，或者本项目在竞标中赢了竞争对手，这种情况期望竞争对手正常配合往往不现实，项目需要提前做预案。

以上三种情况之外的就是正常情况，对于正常情况很多项目经理也是约定好双方的开发完成时间和集成测试开始时间，然后坐等集成测试节点的到来。如果真是这种情况，第三方进度延迟的概率会很大，因为第三方是配合项目，钱不多就不会太重视，需要主项目的乙方项目经理随时去推动。比如每周或每天拉上甲方一起Review第三方负责的每个功能和接口，有问题和风险及时发现并处理。

05

见微知著 - 管控变更重点

对于需求变更控制点的重要性每个项目经理都知道，也各有自己的招数和套路。很多时候，对业务人员来说，他（她）认为的一个简单需求，可能实现起来非常复杂，甚至有些会受限于甲方或乙方系统的架构和平台；或者他们认为很复杂的需求，从IT实现角度很容易的事情。

抛开变更需求是否可以收费的问题，那么对于客户提出的变更需求是否接受，有没有判断依据和标准呢？我通常坚持二个大原则：

依据一：不同项目阶段可以接受哪些类型变更？

需求分析阶段：所有策略、目标、需求、功能及实现均可更改；

功能设计阶段：功能和实现可更改；

技术设计阶段：仅实现细节可以更改；

编码实现阶段：仅实现方式可更改；

测试改错阶段：仅能更改错误。

依据二：什么情况下不能拒绝客户的需求变更？

需要变更的业务需求是“生死攸关”的，如果某个业务需求不实现，客户的主流程和主价值链无法跑通，或者该需求不实现失去项目立项的初衷，这种需求无论付出什么代价都是需要实现的。当然如果涉及到费用问题，可以同步走商务程序。如果某个业务需求在企业出现的概率极低（比如1%不到），最好建议客户不要落实到系统里。

所有的其他解决方案已经被证明不可行，也没有任何规避的方法，或无法设计一个折衷的方案；打破管理传统、业务习惯或适度降低管理要求是不可行的。

依据三：如何引导客户评判需求是否要变更？

通常可以从这几个方面思考：

能给企业带来多大的收益；

能在多大程度上提高业务的操作效率；

能给企业增加何种收入；

能给企业降低多少成本。

需求变更可能会引发一系列的变化和风险，在不影响大原则的情况下，一些工作量较小的需求变更，涉及产品框架的变更要慎重。小需求变更答应多了，客户后期也不好意思多开口了。

任何变更都需要有记录和流程审批（无论是否收取费用），在接受任何变更的时候要表现得很“痛苦”，痛苦次数多了，客户可能也不好意思多提了。会上解决不了的问题，先记录问题线下再沟通，有些会上问题只是刷存在感，会后线下交流也许问题就不存在了。

06

同舟共济 - 注意沟通策略

在跟客户沟通的时候，多用换位思考。比如我们要说服客户的时候，虽然我们内心知道这个事情主要有利于乙方，但不能只站在乙方的角度来沟通，否则会让客户感觉就是想省事、省钱。如果先从客户的立场来沟通，比如做与不做对客户有哪些好处或不足，我想效果会更好。其实如果我们自己都说不出给客户带来任何好处，那建议还是不要去提。

比如某件事情做与不做，对我们有80%的好处，对客户有20%的好处，可以先从对客户的好处来沟通，让客户引起共鸣和积极响应，但最后也不用回避给乙方带来的好处，共赢的结果通常更让人接受。

其实不管是甲方项目经理还是乙方项目经理，他们都是执行层，项目成功也是各自的KPI，要经常重申在小范围内项目组关起门来就是一家人，要从项目整体角度一起去面对最终用户。在项目沟通过程中，以下几个方面比较重要：

沟通应提前准备，尽量考虑对方可能提出的问题及应对方案；

顾问永远不要不假思索地说“No”，但也不要轻易说“Yes”！说“No”是需要策略和程序。客户花钱不是来购买“没法解决”，没有不能处理的问题，只有不动脑筋地敷衍。没有Solution就找 Walk around。

基于客户需求、项目需要，但要在思考上超越客户需求、项目需要；是否思考过与是否在本项目中实施，是两码事，但客户感受会不同。

会上解决不了的问题，记录下来，思考成熟之后，先单独沟通。

问题上报，不能将球无限期地留在手中导致留下大的隐患，也不要遇事就让上级处理。

关键问题需要列出多种解决方案和方案优缺点，表明我们倾向的方案，供用户选择。

用户需求要谈透，关键需求要明了业务场景。

07

明哲保身 - 远离甲方内争

有人的地方就有江湖，对企业来说也是一样，任何企业都会存在一定程度的竞争，其实竞争也是可以说是维系企业发展的动力和推力。很多时候大家喜欢用“内斗”或“政治斗争”来取代竞争的说法，对于乙方来说不要轻易介入甲方的“内部竞争”，更不要指望能从中获取到什么。

任何时候不管乙方是主动入局（甚至是投名状）还是被动卷入，最终的结果都不会对项目有利，最后出问题后乙方就是“临时工的临时工，外包公司的外包公司”，有什么比乙方更好用来做替罪羊的？要摆脱困境和局面，可以更换项目经理或项目主要负责人，一方面从姿态上摆正，另一方面安排更擅长应对这种局面的项目经理。

因为作为局外人，乙方永远只能是看到水面上东西，水面下到底有多深未知，背后的线牵扯有多远也不清楚，所以乙方只能坚守自己的初衷，做好自己的项目才是正解。

08

团队养成 - 助力团队成长

评判一个项目是否成功，通常的认知是项目按时、有品质地在预算范围内交付，并实现了客户对项目的预期目标。如果在此基础上，整个项目团队成员均得到不同程度地成长，比如培养了后备项目经理和BA（业务分析师），并且还能赢得后续持续性项目（非正常运维），才认为项目是真正的成功。

09

结语 - 以终为始

希望以上分享的“天龙八诀”能给大家有些借鉴和帮助，但毕竟这些大多还是“术”的层面。项目成功的本质还在于乙方使用自身的核心价值能力，为客户创造价值，满足客户和利益相关者的需求，并为组织带来商业价值和社会效益，并以这个本质目标来指导“慎始慎终”，并贯穿项目整个全生命周期的管理。