在敏捷项目中，产品负责人往往被看做是业务和IT联系首要保障的人。但对于有效的IT业务整合，仅有产品负责人是不够的。来自业务、需求和组织的供应方的人们，做些什么可以提高IT和业务整合的效果呢？

 

趋势包括向更少的部门集中化，通过共享服务中心实现专业化，以及更加注重IT管理。采用两种团队：产品开发团队——面向供应链，专注于业务价值和项目范围；服务开发团队——面向组件，专注于质量和跨项目范围的重用性。团队使用多个backlogs以管理他们的工作并与其他团队协作。一套基于精益思想的问题，可以用来决定哪些架构文档是必须的，以及何时需要它们：

 

谁需要这个文档？

为什么他/她需要这个文档？

对他/她来说这个文档的价值是什么？

文档丢了会怎么样？

不同类型的架构文档有不同的用处。领域架构用来做长期规划，项目开始的时候架构文档支撑项目初始化。在迭代期间使用解决方案架构以及控制架构和变更管理。

 

这些就是为什么需求、供应和业务作为合作伙伴不配合的原因：

 

用户被称作客户，而不是同事

没有把供应方当做业务伙伴

有许多偏见，且没有足够的自信

 

不同的利益相关人可以参考相应建议提高业务IT整合的效果。业务要意识到他们应该关注自动化，并且业务人员应该钻研自动化流程以及尽量不要反对IT。对来自需求方的利益相关人，当现实和理论不符时应该去拜访执行单位，亲眼查看现状，因为现状与理论总是有偏差的，需求方还应该在制作产品规格时让真正的用户参与，不要认为IT是很困难的事情。对于供应方的利益相关人，邀请产品负责人之外的用户参加演示会以及产品规格会议，并专注于简单的说明。

 

对于业务IT整合，建立在平等上的合作是最重要的。要把业务现实有效地融入到IT解决方案中，需要让思路脱离固有的模型和预定义的模式。