让业务领导参与软件应用开发并保持可提升项目的成功率；反之则会增加失败风险。

几乎所有的软件项目经理均同意这一点传统观点。然而让高层主管参与软件应用开发—并让其以有意义的方式持续参与则是一个艰苦的过程。项目经理不努力去争取高层管理的注意力，往往很快就放弃。他们绝望地举起双手，把老板的缺席归咎于繁忙的日程表。或更糟的是他们甚至认为自己领导的软件项目的重要程度并不足以争取到高管的时间。

Rothman咨询集团的管理顾问，《伟大管理的秘密（Behind Closed Doors: Secrets of Great Management）》一书的联合作者Johanna Rothman说，太快放弃是个大错误。“如果业务领导不露面的话，就得要求召开会议并询问原因，”Rothman说。确定他们不愿意的根源是非常重要的。“你也许会对他们说的话感到惊讶。”他们的回答可以为如何吸引他们参与指明方向，还能为如何提高软件项目的可视性找出办法，她说。

本问答录针对软件领导寻求业务领导参与应用研发项目时产生的问题提供答案。

寻求业务-IT相适应的努力持续了多久？

按照IT战略专家Thornton May的说法，技术专业人士对IT项目要与组织业务目标相协调的警钟敲了50多年了。在这场对IT与业务相协调的永恒追求中，May说这个想法已呈现出一种“近乎神话”的状态。“当然，完全协调并未出现，其可能性似乎永远也不会有。因为活动的部分实在是太多了。”他相信技术专业人士应当放弃这一追求，相反应专注于与业务领导有效的协作方式上。May建议的其中一项策略是“共进三次午餐”。所谓的午餐会他是这样描述的：

美国中西部的一家中等规模的银行的副总兼技术总监解释说，他做的第一件事是识别出“哪些指标是（业务用户）用来衡量成功的。”每一次有主管受雇用或提拔时，该副总均会与他共进三次午餐。

第一次午餐，副总会与主管讨论企业愿景及其计划用来衡量成功的指标。吃第二顿饭时，副总会聚焦于这些指标如何与现有的IT行动协调，然后两人就未来的提升效能的IT项目进行头脑风暴。而在第三次午饭时，主管会告诉副总IT是如何做的。

Rothman同意，找出对业务端最重要的东西，以及在此基础上向领导提出诉求是个好办法。不过她也指出，对于业务领导的真正问题，软件项目经理不一定就有答案。“他们希望知道何时项目可以完成，投资的回报是什么。”她说：“对于这些问题，项目一开始时你是无法知道答案的。”假装自己知道并非好主意，她补充道：“你可以会试图在这些事情上撒谎，但是请不要这么干。”

缩短IT与业务的协调鸿沟需要哪些技能？

IT软技能，包括创新、分析技能，团队协作及项目管理等，对于吸引业务领导参与到IT项目中去是至关重要的。正如TechTarget的专栏作家Karen Goulart在其文章《为了实现业务协调，CIO展望填补软技能鸿沟》中指出那样，IT人士在各种技术领域都是专家。但是他们往往缺乏必要的技能来更有效地与业务领导协作。

Goulart 文章中提到的CTO John Johnson说，他一度在寻找“能理解问题解决方案而不仅仅是写代码”的软件开发者上遇到困难。文章指出，“批判性思维，以及在对IT如何辅助并影响业务方面拥有广阔视野不仅有帮助，而且必不可少。”

研发早期阶段让领导参与的最好办法是什么？

每一个软件项目都需要一个业务端的拥护者，Rothman说：“如果你没有，就得问问自己，‘我做这个项目是为了什么？’”如果计划的应用并非组织项目组合的一部分，那么整个软件团队做的事情就是在浪费时间，她说。

让你的赞助人参与需求计划是困难的，SearchSoftwareQuality.com 的需求专家Scott Sehlhorst 说。他说，如果你邀请你的赞助人出席计划会他却没有露面，你有几种选择。“最好的选择是试着争取到（那位主管）15分钟的时间。”如果这一点做不到，让主管将产品决策权委派给更有时间或职权更低的他人。接下来，跟赞助人碰头，然后概要展示软件项目的目标与公司目标是如何适应的。这种会议有两个目的：首先，让你的赞助人确认同意你制定的目标。其次，确定赞助人对你的产品是否还有别的期望。“不要什么事情都不干，”Sehlhorst说：“要拿出些东西让那位主管同意或改进。”

Blueprint Software Systems是总部位于多伦多的一家需求软件生产商。该公司的CEO David Nyland说，让主管参与软件项目的难度降低是非常重要的。他提供了这一点建议：“不要给利益攸关方一份600页的文档然后让他同意。”这么长的文档没人能读得下去。更好的办法是只向利益攸关方展示与其直接相关的部分。他还建议采取可视化的办法，只要有可能尽量使用图表而不是文本。

敏捷开发是不是更有利于吸引业务领导参与？

简洁的回答是，是的，因为敏捷在形式上就承认了业务领导在流程中扮演的角色，这是瀑布流软件开发方法论所没有的。也就是说，项目经理必须设法让业务领导参与进来。像短迭代这样的敏捷实践很适合于与业务领导一起协作，Rothman说。她建议迭代的周期不要超过2周。“如果业务领导不喜欢自己看到的东西，扔掉2周做出来的东西你是可以承受的。这正是敏捷的魅力之处。”

通过邀请观看产品演示（一般2周一次），Rothman让业务赞助人参与到她所领导的项目当中。一开始赞助人往往都能出席演示会，但是后面他们的参与会逐渐减少。“如果发生这种情况，找出原因，” Rothman说。假定赞助人总是很忙无法出席是错误的。有可能是他们不喜欢项目的目标。软件专业人士需要提出问题，倾听回答，深入分析，找出赞助人不喜欢的东西，她说。