软件项目交付实战技巧

我是一名IT老兵，在软件行业已经干了二十多年。一路走来，身边有很多人创业，但成功的不多，我一直在关注这些人。我发现一个规律，凡是能让公司走到最后的人，都是做交付出身或是对交付很熟悉的。而那些做销售或售前出身的人，大都是高开低走，有能力拿单却没能力交付，结果都不是太好。

所以对于一家做管理软件的公司，什么能力最重要？有人说是研发，有人说是销售，有人说是交付。而我认为一定是交付！

研发能力决定公司的发展上限，销售能力决定公司的发展速度，而交付能力决定的是公司的生死存亡。

我做过产品，做过销售，也做过交付。相比而言，我认为交付是最难的。因为销售失败可以重来，但交付失败就没有机会了。销售不成功公司损失不大，交付不成功则会导致公司亏损及负面的市场形象。销售人员是光芒万丈的，因为他给公司带来了业绩，他很容易成为同事们崇拜的偶像，而交付人员是默默无闻的，即便项目成功上线，大家也会认为他们只是做了该做的事情而已。

我见过很多项目经理，他们低调又务实，冷静又坚韧，当项目验收时，他们也会兴奋得像个孩子，而一旦平静下来，他们又回归到理性而谦和的状态中。但我知道，他们在刚刚结束的交付战场上是如何的惊心动魄，九死一生！

所以我把自己多年项目交付的成功经验以及失败教训总结归纳出来，形成十篇文章，为有心创业的同行，以及仍奋斗在交付一线的项目经理，提供些力所能及的帮助，让大家能够在朔风中逆行，在激流里强渡，在绝境处逢生。

在我这里没有空洞的理论，只有实用的技巧，没有华丽的辞藻，只有朴素的道理。文笔未必流畅，但见解一定独到！

在接下来的章节中，我会以项目的生命周期为脉络，分阶段，分主题的来分享我的方法和技巧。

项目团队的创建标准不是一成不变的，需要根据项目的实际情况和自身产品的成熟度来匹配人员。在此章节，你会了解到怎样组建项目团队？怎样选择项目经理？在团队人员不足时怎样操作？

项目开发过程的管理最重要的是两个点，一是开发模式的选择，二是评审节点的把控。开发模式的选择会影响到项目的交付成本，评审节点的把控会影响到项目的交付质量。在此章节，你会了解到怎样选择开发模式？怎样进行关键节点的评审？

项目交付过程中最大的风险来源于客户需求的变更，需求变更对项目进度和项目成本的影响很大，对需求变更的控制在很大程度上决定了项目的成败。在此章节，你会了解到怎样从自身的角度避免需求变更？怎样从客户的角度控制需求变更？怎样在需求变更的同时说服客户增加项目费用？

有些项目的交付时间对客户至关重要，系统做的再好，超过了上线日期也会变得毫无意义，这个时候就很考验项目经理的组织协调能力了。在此章节，你会了解到怎样争取到内部资源？怎样协调到客户资源？怎样制订可执行的计划？怎样应对常见的风险？

项目的成功有三个要素，质量、时间、成本，而对于乙方来说最重要的是控制成本，否则项目做的再好，公司不盈利也没有任何意义。在此章节，你会了解到怎样建立项目预算及考核流程？怎样建立项目成本核算体系？怎样建立项目成本跟进制度？怎样建立项目止损机制？

很多时候项目团队的资源是有限的，项目成员的素质、能力是不足的。怎样激发每一个人的潜能，提升团队的士气，最大程度发挥团队的战斗力是需要管理技巧的。在此章节，你会了解到怎样把控团队节奏？怎样引入竞争意识？怎样调节团队氛围？

项目实施过程中，与客户打交道是需要技巧的，很多项目的失败不是因为项目团队的能力不行，而是项目经理在处理一些客户问题时犯了错误。在此章节，你会了解到项目经理常犯的错误有哪些？怎样的做法才是正确的？

项目交付的最终目标是验收，验收是分阶段的，每个阶段客户的关注点是不同的，项目经理的工作重点和应对技巧也不同。在此章节，你会了解到每个验收阶段客户的关注点有哪些？有哪些技巧可以推动项目快速验收？

很多项目的失败并不是项目团队本身的问题，而是缘于客户自身的因素，对于这些因素是可以预先判断并采取对应措施的。在此章节，你会了解到项目会有哪些常见风险？在遇到这些问题时应该怎样应对？

对于TO B类软件公司，尤其是偏项目型的公司来说，把项目签下来只是万里长征走完了第一步，能否把项目交付好才是关键，我见过太多的软件公司不是死于没有项目，而是死在了项目交付不了。

怎样做才能把项目交付好，确保公司的可持续经营，是每一个创业者在创业初期就要想清楚的问题。

在这里，我想先从组织架构讲起，跟大家聊一聊怎样组建项目团队。

对一个公司的经营来说，如何把管理效能最大化，是每一个管理者都要考虑的问题，而项目团队作为组织架构的最小单元，其配置是否合理，是影响公司整体管理效能的关键因素。

对于纯做产品的公司，其组织架构是职能型的，没有交付部门；对于纯做项目的公司，其组织架构是项目型的，一个项目就是一个部门。而TO B类软件公司一般都是既有产品又有项目，其组织架构是矩阵型的，职能部门养兵，业务部门用兵，有了项目才会成立项目团队去交付，因此项目团队是个临时性的组织。如图：

【TO B类软件公司的常用组织架构（强矩阵型）】

# 关键要看产品的成熟度。

对于标准化产品的实施，比如财务系统，通常只需要一个实施顾问就可以了。所以金蝶、用友的实施顾问，一个人就可以同时负责几个项目。

      对于既有标准化产品又有个性化开发的项目，实施起来会相对复杂，需要成立项目团队，其基本配置大概如下：

●   项目经理：负责项目整体把控，包括团队的日常管理，客户沟通，需求梳理，原型设计等工作。如果项目小，出于节省成本的考虑，还要兼职数据整理，系统测试等工作。

●   开发工程师：包括前后端的开发，如果有大数据应用还需要有数据开发工程师。负责系统设计、开发等工作。在开发人员中需要有一个技术组长，负责对需求实现的工作量进行评估，制订开发计划，分配开发任务，遇到技术难题时能够带头解决。

        对于完全定制化开发的大型项目，还需要增加以下角色：

●   实施顾问：相当于行业专家，可以帮助项目团队理解客户所在行业的业务特点，梳理不同领域的业务流程；

●   需求分析师：负责协助项目经理整理客户需求，编写需求规格说明书；

●   UI设计师：负责协助项目经理画界面原型。一个好的UI工程师，不仅可以实现界面的友好性，同时也会兼顾到操作的易用性，即UE的工作；

●   系统架构师：负责协助开发组长设计系统架构，搭建数据模型。

●   数据库管理工程师：即DBA，负责数据库的安装、部署、配置等工作；

●   测试工程师：负责系统的测试工作，包括单元测试、集成测试，原型测试，测试用例的编写，测试计划的制订，测试报告的输出，BUG的跟进等。

在这些角色中，除测试工程师外，其它角色不需要全程参与项目，在使用时需把握好使用效率，在满足前置条件的基础上提前做好规划。

项目管理也存在木桶理论，决定管理效能的永远是最短的那块板，所以项目团队的配置要尽可能均衡。

# 一个好的项目经理是项目成功交付的关键因素。

赛意信息科技有限公司董事长张成康先生在跟我分享赛意的成功经验时特别强调了项目经理的重要性，他说到在没有找到合适的项目经理前，即便有项目他也不会接。我对这句话的印象深刻！时至今日赛意早已成为了上市公司。

对于项目经理的人选，历来有两种观点，一种认为应该由业务顾问担任，因为业务顾问可以更好的理解客户需求；一种认为应该由开发顾问担任，因为开发顾问可以更好的实现需求。我认为由哪个角色担任项目经理关键是看产品的成熟度，如果产品成熟度高，开发工作量小，业务顾问会比较合适，反之，则开发顾问会比较合适。

另外，项目经理首先需要的是管理能力，其次才是专业技能，因此在其他条件相差不大时，谁的领导力强谁就更适合担任。

当然，如果一个人既有与客户对接的能力，又有一定的技术功底是最好的，但这样的人很难找，或者即便能找到，成本也很高。

在实际的项目实施中，项目团队会经常出现人员不到位，资源不足的情况，怎么办呢？

# 两种方法，一是内部消化，二是借助客户的力量。

●   内部消化：负可以通过内部补位的方式把工作分配下去。一般来说，项目经理应该是个万金油，除了写代码外，任何岗位都是可以胜任的。而需求或开发人员也能够担任测试工程师的角色，开发人员可以交叉测试，根据测试用例相互测试对方开发的模块。

●   借助客户的力量：项目实施不是单方面的，客户的人也要参与其中。有经验的项目经理一开始就会把客户的人拉进来，一起整理数据，一起参与测试，有些客户有独立的IT部门，具备一定的开发能力，则把这些开发人员全部调动起来，以熟悉系统的名义给他们分派工作，以此来弥补自身资源的不足。而且这样做还有一个好处是可以让客户深度参与，客户参与度越高项目成功的机率也就越大，因为大家都希望自己的工作能够得到别人的认可，不会去轻易否定项目团队的工作成果，这就是人性！