我来教你怎样项目推进。

项目实施是指从项目蓝图确认开始，到项目上线、验收的全过程。为了能够保质保量的完成项目，我们需要制定合理的项目计划，统一规划、科学安排项目计划的有序进行。笔者结合自身在项目中遇到的问题以及常见解决措施，与大家一起讨论、分析如何推进项目。

项目计划

项目工作开展的前提就是明确需求，之后就是要制定相应的项目人天计划。在制定项目人天计划的时候，就需要对项目进行分解，项目分解的意义在于了解项目内部逻辑，明确各集成方面需要提供的数据接口、视图的数量、用途，为后期项目设计做准备。

项目分解通常分为两类，一类是从业务角度分解项目，一类是从数据角度分解项目，这两种分解方式几乎是同时存在于项目中，二者相辅相成却又容易混淆，下面我们来逐一分析一下这两种分解方式。

1 业务分解

业务分解就是将集成的模块根据甲方企业内部业务的实际发生顺序进行分类的过程，比较常见的比如统一用户、单点登录。这种分解的常见特点是功能单一，复用性强，通常由多个系统制定统一的标准来执行。

例如统一用户的核心必然是用户账号、密码的同步，但是由于各个系统内部自身新增用户的限制，比如关联的授权等，不能简单直接的将用户信息同步，进而延伸出将管理的组织、岗位的同步。虽然各个系统的具体要求会不一样，但是总体的需求和基本逻辑应该是相同的，那么这一组信息同步的流程就具有普遍的意义，就可以作为一个功能模块来进行工作分解，然后再针对各个系统做出进一步的分解，这样我们就比较容易得到相对准确的人天估算。

业务分解可以说是项目计划分解的第一步，业务分解并不是一次就能完成，通常对于应用集成或者深度集成是需要进行多次的业务分解，这个需要在实际业务场景中具体分析。

2 数据分解

数据分解是针对已经进行业务分解的模块，在模块内部以数据的形态为边界进行的再次分解。到了数据分解的程度基本就是可以开始项目的概要设计了。

数据分解简单来说就是在一个功能模块内，数据从哪里来，经过了什么样的转换，进入了哪个地方，最后在哪里显示等等。每一次数据的转换最好是有文档说明，这样在将来出现问题时容易快速定位。

数据分解的例子也很多，比如有两个集成方都涉及了合同的管理功能，在集成时需要两个厂家在合同的全周期内互通消息，那么就需要我们从合同的增删改、提交、驳回、再提交、通过，这些常见的节点的进退都需要考虑需要什么样的流程处理，哪些流程可以合并处理，哪些流程可以复用等一系列事宜。

很多时候业务分解与数据分解容易混淆的地方在于，有的业务比较简单，通过一次分解即可实现功能，没有业务与数据的明显界限；有的业务比较复杂，业务包含多个数据线，数据线又贯穿多个业务，这一点只能是自己多加思考，勤于总结，逐渐摸索规律。

3 工作分解

将项目按照业务、数据的形式进行分解之后，就可以做工作分解了。工作分解与之前两种分解最主要的区别是，工作分解本质上是对时间的管理。即按照既定的业务、数据分解的任务模块，规定合适的时间来完成。

时间管理的法则有很多，比较容易掌握的就是四象限法则，就是按照紧急而且重要、重要但是不紧急、紧急但是不重要、不重要也不紧急这四类。然后优先做紧急而重要的事情，之后计划做重要但是不紧急的事情，紧急但是不重要的事情可以安排其他人去做，要轮流安排组员去做，避免让组员产生领导交代的事情都是同等重要必须马上完成的误会。

工作分解之后要进行工作审查，工作审查主要是对工作合理性的审查，包括任务模块先后顺序的审查，耗时合理性的审查。顺序合理性审查主要是依照上面提到的法则为依据，耗时合理性审查则是综合考虑项目难易程度、被集成方的配合程度、项目经理及组员技术等多方面因素，同时要适当留出时间作为应急使用，耗时的合理性审查是衡量一个项目经理能力的基本点。

项目推进

项目计划是保障项目推进的前提条件，项目的具体落实情况才是考验一个项目经理能力的关键。在项目中，笔者最深刻的体会就是你所有的工作都会比你计划的时间更耗时，这个现象出现的原因有很多，比如甲方工作重心转移，比如被集成方不配合，比如对项目工作缺乏预见性，工作安排不合理，甚至可能是停电一类的突发事故，但是最终的结果必然是项目拖期，这是我们不愿意看到的，因此笔者对项目落实有如下看法：

1 多点开发，齐头并进

项目分解之后要综合考虑项目的紧急程度及重要程度，将做好的计划打碎，对紧急而又重要的事情，创造条件也要做，对于其他事情，一旦条件具备立即开始工作。

在工作中要注重沟通协助，对于重点事宜要反复督促、及时沟通，作为项目经理要及时掌握员工的进度以及心理动态。我们相信人有主观能动性，但是人也有惰性，发现进度不对，及时查找问题，发现问题要及时暴露出来，一旦拖延下去，很容易把小事拖成大事，大事拖成事故。

2 稳中求进，沟通先行

开展工作之前一定要注意沟通交流，这里的沟通交流至少包括三个层面的意思，一是与甲方的交流，及时汇报工作进度以及需要配合的事宜，二是与涉及的集成商交流，需求调研阶段的交流一般是由产品经理负责，而进入实际开发阶段通常是由程序员负责，中间的信息传递容易有变差，这时我们需要再次沟通交流。三是与公司本部交流，主要是针对工作注意事项，当前集成工作容易出现的问题给出指导性意见。

在实际工作中，沟通交流是头等大事，互相之间了解进度，明确需求和开发思路，在保证工程不返工的情况下，进度通常不会太慢。

3 反复推演，迭代推进

如果项目经理素质基本过硬，有足够的责任心，上述两点还是比较容易达到的，此时就需要注意迭代的问题，就是说我们的工作不是一次性完成的，在完成某一块工作的时候，不但要考虑后续工作，更重要的是回到起点，重新梳理工作计划，考虑其他工作是否有适合开展的，最好保证同时有两、三个工作项并发进行。这样才能争取时间，保证项目周期。

风险管控

在实际项目中总会有风险出现，常见的风险有返工导致项目拖期、开发中遇到了难以攻克的技术点、被集成方的不配合、甲方需求无限蔓延等情况。笔者结合自身项目中出现的现象与大家一起讨论。

1 项目拖期

项目拖期是风险管理最常见的一种风险，项目拖期的原因有很多，在这里我们只谈一种原因就是返工。返工顾名思义就是功能实现不符合甲方要求，甚至无法实现而导致的推倒重做的现象，这种现象不但耗费工时，同时也严重打击团队士气。

避免返工首先要确保项目经理自身技术过硬，设计合理，如果做不到，在设计时要集思广益，可以让后方协助给出参考意见。其次如果发现有功能无法实现的可能，那么要及时采取成熟的技术方案作为后备，及早做好适应性调试。

2 技术难点

在项目中，由于各个系统开发语言、技术、甚至是风格的不一致，难免会出现一些技术上需要攻关的地方，这个时候要谨记一点，量力而行。项目经理要对自己及队员的水平有一个明确的认识，对于略高于自己团队水平，或者可以通过网络等渠道获取丰富资源的技术点，可以自行攻关，这也是磨练队伍的一个重要环节。如果发现技术攻关比较耗时而且难度颇高，要及时联系后发，请求技术支持，不要逞强，尤其是涉及测试量比较大的改动，最好不要在项目内进行。

3 推动阻力

在项目推进过程中，用户、厂商的消极抵触也是比较常见的风险。对此笔者的建议是尽早联系甲方，我们做集成工作通常面临都是体量比较大的单位，一个项目的确定都不是一个人、一个部门可以决定的，既然项目可以正常开展，那么必然是群体博弈的结果。所以这类问题还是尽早告知甲方，请求甲方协助解决是比较好的方法。

同时在沟通协助期间，可以对一些既定的、准备性质的工作提前开展，这样可以确保在沟通结束后快速开展工作。

心得总结

以上是笔者对项目推进工作的总结和看法，项目的推进是一项细致而又繁琐的工作，从工作的计划分解开始，直到项目验收结束。沟通、协调、总结、推演始终贯穿在项目生命周期，工作始于计划，将项目详细完整的分解到位才能确保项目的顺利开展。合理的工作安排，良好的沟通协作能够保障在项目顺利开展的过程中降低项目风险，实际项目的周期通常会比较长，迭代式的推进可以保障项目在实施过程中不至于出现虎头蛇尾的现象，在项目中要勤于总结，对工作内容要做好相关记录，不论是将来备查还是回顾，都有着重要意义。

另外笔者还有一些想法想与大家分享。古语说见贤思齐焉，见不贤而内自省也，一味的闭门造车不是成长的好方法，项目是最好的老师，多去做项目，多去接触一些高水平的人是自我综合水平提高的最好方式。同时，在推进项目的同时不要忘记人才的培养，一个项目的成功与否并不完全取决于项目的完成情况，自身的提高、团队的磨合、后续人才的培养也是通过项目实现的，因此在抓项目进度的同时，适当放开一些时间去培养合适的人，也是一件很必要的事情。