该供应商编写的技术底漆已经被网络世界编辑，以消除产品推广，但读者应该注意到它可能会倾向于提交者的做法。有个足球雷竞技app
虽然我的联合创始人和我在商学院，我们看到它是第一手多么痛苦和令人沮丧的参与，从商业方面的应用程序开发过程。于是我们开始着手改进IT和业务之间做出根本的发展速度更快，同时确保项目的成功合作，更简单。
以下是成功的IT/商业合作的七个关键。
1.专注于业务问题，而不是客户所设想的解决方案。顾客对什么是可能的看法往往是由它们都使用过的工具或技术的限制。换句话说，他们可能会认为是做一些可能不是在所有的最佳方式的最佳途径。
理解业务问题并设计最佳解决方案是业务工程师的责任——我们用这个术语来指精通业务但对技术有一定亲和力的非专业开发人员。业务工程师在这方面处于独特的地位，因为他们对业务和平台的能力有着深刻的理解。
+也在网络世界有个足球雷竞技app更快的计算机性能的目标，内存联盟+
这是由以前的工具盒装在客户端的一个例子是一个大型的健康保险公司。他们试图解决的业务问题是一个自动化的方式从客户收集信息。他们设想的解决方案是分配和收集Excel工作表 - 仅仅是因为他们并没有意识到这将是多么容易建立的客户，也依赖于他们现有的后端系统特定的基于Web的界面。通过添加用户角色，安全规则和优化的形式，高品质的界面是专为成本的一小部分，并导致更多的可扩展性和用户友好的解决方案相比，Excel的替代品。
2.根据用户故事而不是专业划分工作。The latter is a more traditional way of approaching application development, where specific team members each focus on specific technical areas, such as database/data model, UI, etc. This isn’t the most efficient way to work because business engineers can typically complete 80% to 100% of the work themselves, with the exception of some very technical topics (such as styling or integration).
相反，将根据专业的任务，项目工作应根据用户故事来划分，争球或敏捷开发方法的一个术语来指代特定功能或片在最终用户的日常语言写成的功能（一种格式是“作为一个<角色>，我想<目标/欲望>，使<好处>”）。这些故事应该由一个或多个业务工程师作为一个整体进行开发。这样一来，每一个企业的工程师开发了一个完整的工作片的每个功能冲刺，而不是某一活动的工作。在这个过程中，他们能够更好地专注于业务解决方案（见点＃1），并提供最佳的解决方案，与简单地完成他/她分配的任务。其结果是更好的软件和快乐的最终用户。
我们经常看到新的合作伙伴或客户试图用旧的方式分配任务，因为这是他们一直以来的工作方式——正如我们都知道的那样，旧的习惯很难改掉。我们的一个外包合作伙伴很早就采用了这种方法，而且最初的进展没有预期的那么好。不同任务之间所需的知识转移和文档创建了大量开销和噪音，从而导致低生产率和缺乏业务敏捷性。一旦每个业务工程师完全拥有某个领域内的用户故事，我们就会看到生产力和质量的显著提高。此外，对应用程序功能方面的知识和理解显著增加，从而产生更好的协作和工作软件。
3.提供工作演示或原型每个冲刺。系统的设计可以是一个非常抽象的锻炼。两个人可以从字面上坐在同一个房间里好几个小时，我认为他们在谈论同样的事情，但在现实中是完全不同的页面。这就是为什么它的关键，显示工作的功能（无论是演示或原型），每个冲刺中。演示/原型应该用于验证的要求和假设（有意或无意制造）因为需求或其他因素发生了变化，讨论可能出现的变化。变化甚至可以在或以显示企业的利益相关者将有什么样的影响的会议结束时实现。
通过展示工作的功能验证主要假设的过程是在项目的早期阶段尤为重要。时间越长，你等待验证业务需求，更大的潜力断开和更多的时间和你需要修正方向努力。
在一个拥有200万成员的教会的大型项目中，教会的志愿者指定了一个新的应用程序的功能要求。一旦业务工程师实现了将一个人搬到另一个地址的流程，志愿者们就会问:“我们如何一次将整个家庭搬到另一个地址?”“这个重要的反馈强调了这样一个事实，即家庭的概念在功能需求中没有得到适当的处理。通过提供原型，缺失的需求在两周内被识别出来，客户能够采取必要的措施嵌入到系统中。
4.实现每天的“走进式”工作时间，以验证假设并与业务同步。有一些技术可以让您快速开发新的应用程序和功能。无论预先的需求有多精确，都不可避免地会出现需求冲突、业务工程师不理解某些东西、有问题或设想做某件事的不同方式的情况。如果是这样的话，他们可能会开始做出一些假设，而这些假设最终需要被重新修改或彻底抛弃。
因此，重要的是要确保有一个机会，每天为开发者与商家进行互动，交流想法和验证的假设。这可以被视为对企业的应变但实际上并非如此。当开发人员在工作现场，这可以迅速午餐或休息期间进行。换句话说，它可以装配到商业用户的日程，创造几乎没有任何负担或中断。而这快速检查将节省返工的道路。
我们发现，当他们的输入被立即投入产品，企业用户越来越多的积极性和热情。他们意识到这是值得花时间和精力，他们开始做一个精神上的商业案例，为自己花时间与开发。很多时候，在态度的变化是从一次会议到下一个显而易见的。在第二次或第三次会议上，他们已经从不愿参加者愿意和热情的拥护者了。
5.型号复杂的业务规则和形式一起与商家联系。有可能有时每天的“走在”时间是不够的，而需要开发人员和业务用户之间更密切的协作和知识共享。在这种情况下，有技术，非常适合以促进跨职能的结对编程，其中企业用户 - 而不是编写需求文档的传统工艺 - 与企业配对的工程师共同开发复杂的业务规则和形式。
如果你仔细想想，这几乎是不可能设想所有可能的情况或情况前面。因此，一旦的功能的应用程序或片用传统方法开发的，则必须以验证是否显影剂正确地理解要求，这导致大的和冗长的测试程序。
这可以通过业务工程师和业务用户一起对应用程序建模来避免。虽然一次性的会话是一个很好的起点，但是许多客户通过在项目持续期间将开发团队实际地定位在业务中，从而将其提升到下一个层次，促进了持续的对话和协作。业务工程师可以停下来询问关于不同场景的问题，帮助当场识别并解决任何误解或问题，而不是等待几周或几个月，直到应用程序已经构建好。这种工作方式使您的团队能够更快地构建正确的产品。
一个很好的例子是，开发一个网站监测应用程序作为其临床试验过程的一部分，一家制药公司。由于公司的过程是如此独特，需要与企业广泛互动。因此，开发团队坐在一起的业务，并与企业主直接合作，构建应用程序，没有详细的规格了前面。该应用程序在时间和成本的一小部分交付比选择：一种现成的，现成的临床试验管理系统（CTMS），这将给予他们什么比赛了。
6.最终用户测试（UAT期间）的紧密协作。用户验收测试（UAT）是典型的开发周期中的最后一个，但重要的阶段。虽然事情可能会从技术的角度工作，也不能保证它会从商业角度看“工作”，以便UAT作为由企业最终验证。传统上，虽然UAT是一个很大的开销，如创建门票，把它们设计发布等的正式程序
UAT评估可以当场做出，而不必遵循一个正式的，耗时的过程。通过与最终用户测试团队紧密合作，业务工程师可以识别和动态立即修复的小问题。改变通常实现的如此之快，测试团队往往能够测试固定应用/功能他们甚至已经能创造出票前。这种方法简化，提高了bug修复和一般与更好的反馈，而为，最终用户体验测试的进度。
7.实现反馈循环以捕获最终用户的反馈。最终用户的数量总是比你用（包括业务代表）工作的项目团队更大。因此，以方便终端用户的反馈，以确定哪些是不负责构建软件的小团体内已知的那些细节或问题是很重要的。
我们面临的挑战是，传统上，已经出现了较大的障碍，提供反馈：复杂的票务系统，笨重的电子表格，或在黑洞最终的电子邮件。此外，它往往很难为最终用户解释清楚他们在做什么，以及他们从应用程序的预期。同时，像“它不能正常工作”的反馈是无用的谁需要各种后续上下文问题开发商。
通过在每个应用程序中包含一个反馈按钮，有一种技术可以帮助解决这些问题。通过简单的单击，最终用户可以提供反馈，自动捕获上下文(哪个用户、浏览器、表单等等)，并将其包含在提交给开发团队的用户故事中。它们都是同一个平台的一部分——不需要额外的系统、流程或实现——因此用户的反馈会立即提交给相关的开发团队，并且可以很容易地进行审查和处理。
让我们面对它:对软件质量的感知很大程度上与较小的语义元素有关:输入字段的顺序，适当的标题，等等。因为这些变化需要几分钟的时间来实现和部署，所以它们是快速的胜利，可以帮助您从软件中获得更多的价值，同时使终端用户更加热情。
结论
尽管所有的讨论，还有IT和业务之间存在明显的脱节。按照IT治理协会，组织50％没有任何正式的结构与业务战略的IT投资。同时，CIO杂志调查显示，项目的71％会失败，因为穷人的业务需求管理。
是时候让It /业务合作发生了，而不是仅仅谈论它和经历另一个项目失败。通过采纳上述7个原则，应用程序可以提供更快、更便宜和更成功的结果。