网上铺天盖地都是：IT团队与业务团队之间是敌人？永远拥有不可调和的矛盾？
我觉得不是这样，虽然IT人员和业务人员的角色、关注的角度不同，看待问题的方式也会有差异，但最终的目标都是共同把问题解决，推进业务顺利开展为企业谋利。既然目标是一致的，那么前进的道路上互相扶持也是必然的。
那么为什么会存在业务与IT的普遍摩擦呢？
很多时候只是双方站的角度不同，互相的理解有偏差导致的摩擦。通过有效的沟通方式、双方在项目中角色的合理参与，可以消除这种摩擦。
首先，讲解一下业务方在整个项目中的关注点吧
公司的一项业务活动会经历如下几个过程：
- 市场调查、分析
- 明确服务对象、需求
- 设计服务的方案（包括资源、合规方面的考量）
- 寻找合作方（上游或下游企业）
- 规划盈利模式
- 设计产品
- 提出需求、在企业内部协调资源（中、后台）
- 实施产品建设（系统开发、合同条款、财务处理、运营计划等）
- 产品上线、运营
- 反馈响应
可以看出前5步都不涉及IT团队的介入，但第6步开始，负责业务的人员就需要和IT团队共通来推进自己的业务计划。
这时的业务人员已经对业务产品的各方面做好了计划，正在筹集、协调资源实施，关注点集中在业务的落地层面上。
最主要关心两方面的问题：
- 多久能落地、上线
- 实施后的效果怎么样（客户体验、合作方体验、产品流程中那些环节会有影响等）
由此看出，业务人员在项目管理中主要会针对这两方面的问题特别关注，所以只要业务人员能充分获得这两方面的信息并理解其中的影响因素（客观原因、外部环境限制等），就能及时调整自己的业务计划，对产品实施结果有一定的预判。
其次，讲一下IT团队在整个项目管理生命周期中扮演的角色
团队中各个角色的关注点如下：
项目经理：关注项目进度、实施风险，制定应对风险的策略，保证项目按计划完成，还需承担与业务人员的沟通窗口角色、及时双向反馈信息。（这个角色对沟通能力、解决问题的能力要求比较高）
业务分析师：关注产品设计中业务流程、拆分实施环节、细化落地方案、编写需求说明书、配合测试人员制定测试方案
架构师：关注业务流程的实施难度，进行方案设计、技术选型，指导开发
开发人员：关注开发任务，进行模块功能开发、单元测试、编写文档
测试人员：理解业务需求、制定测试方案、根据测试重点编写测试案例（敏捷开发方式与瀑布开发方式的侧重点不同）、进行测试活动、对测试结果进行分析，提供”质量分析“报告。
而整个团队共同关注的是 “项目实施的质量”，最终质量是整个IT团队实施的结果，不是某一个人的！（最终质量不过关，前面所做的一切都没有意义啊！）
从这里可以看到，整个IT团队关注的是项目最终的实施质量，项目经理应该对于项目进度要有严格把控，及时与业务沟通，对于可能产生的风险也要与业务共同制定应对风险的策略。敏捷开发模式下还需与业务方沟通缺陷容忍度的指标方案。
对于业务人员最关心的这两个方面，项目经理应这样进行沟通，满足其获取信息的需求
- 多久能落地、上线；
项目经理应根据自身团队的工作饱和度、任务安排、项目的实施难度，给出团队成员综合评估后的计划安排和时间表，及时与业务方沟通。
- 实施后的效果怎么样（客户体验、合作方体验、产品流程中那些环节会有影响等）
项目经理应与业务方沟通存在的风险和已有的推荐解决方案，影响最终实施成果的因素与排除这些因素阻碍的解决方案，让业务人员及时调整自己的业务计划安排。因为业务人员也会根据某些实施中困难和影响因素去寻求其他方面的支持来帮助解决问题，从而顺利推进自己的业务展开。
最后，我总结的项目经理的工作内容如下：
团队管理：分配开发任务、组织团队成员分享自己的开发经验、制定人员培养机制（师傅带徒弟、师傅review代码，徒弟亲子讲解等）
质量管理：掌握团队成员对需求的理解程度、代码质量检查、测试质量的监控、问题汇总与组织解决
进度管理：合理安排任务分工、团队成员工作饱和度管理、跟踪进度
业务管理：处理日常项目流程工作、与业务方保持良好沟通、及时处理上线后的问题反馈
风险管理：识别系统开发中风险问题、制定应对风险措施（供应商是否可靠、是否已存在成熟经验可借鉴、人员流动问题、合规风险等）敏捷开发模式下的缺陷管理。
IT团队和业务团队都需要有责任意识，做到双方都对自己的职责和责任担当有明确认识，这样做事时也会积极主动、互相配合，“摩擦”自然就会减少，甚至消失。
曾经为了保证项目顺利上线投产，通宵加班跟踪准生产验证，遇到关联系统出现问题，影响测试进度。当时的时间紧迫，必须马上制定解决方案。半夜亲自联系相关系统的人员（用电话把人家从被窝里叫起来，打扰人家休息了）排查问题，在分析、讨论后实施解决方案，最后，准生产验证完毕，第二天顺利投产。（责任重于山啊！）
附：行政流程的意义是什么？
经常项目经理为了某个申请跑很多流程，来来回回，一份需求流转到对应的项目经理手中也好经历N多环节，但是，这些流程的繁琐不是为了应付领导、放着看的，而是在流程中让应该知道这件事的人知道，让该审核的人审核，保持业务流程的完整性，承担企业管理的协调职能，保证业务计划在公司内部顺利得到支持。
P.S. 为什么我会对业务方面了解得这么熟悉，这还要“感谢”某个突然跑路的产品经理（连交接期都没有，第二天就直接消失了！消失前请我吃了顿大餐，囧），让我有了去前台看一看的机会（被迫）。也让我能够直面合作方了解其想法，从整个业务计划一开始就参与进行跟踪。再加上之前学过的MBA知识，也有机会在这初次尝试中进行实践（摸石头过河）。