我们简单讨论过JAD的结构和机制。现在我们可以更加详细地探讨它了。JAD是一个合作的设计流程，在这个流程中，开发某些新的重要功能或者修改架构所需的所有软件开发资源都会相互合作，定义出一个符合公司的架构设计原则和最佳实践的设计，用来满足业务单元的需求。这组软件开发资源由负责最终编码的软件开发工程师、架构师、至少一个或者多个运营人员以及根据需求可选的产品经理、项目经理和质量保证工程师构成。如前所述，这些人各自独特的知识、视角、经验和目标都会彼此互补，使他们达到一种平衡。虽然运营工

我们简单讨论过JAD的结构和机制。现在我们可以更加详细地探讨它了。JAD是一个合作的设计流程，在这个流程中，开发某些新的重要功能或者修改架构所需的所有软件开发资源都会相互合作，定义出一个符合公司的架构设计原则和最佳实践的设计，用来满足业务单元的需求。这组软件开发资源由负责最终编码的软件开发工程师、架构师、至少一个或者多个运营人员以及根据需求可选的产品经理、项目经理和质量保证工程师构成。如前所述，这些人各自独特的知识、视角、经验和目标都会彼此互补，使他们达到一种平衡。虽然运营工程师现在的目标是设计一个满足业务需求的功能，但他依然保留原先的目标，即维持可用性。这样有助于确保他会对部署到生产环境的东西一直保持警醒。



由于每个技术团队都参与进来了，所以会对硬件、软件、中间设备进行权衡，并会对是构建新的系统还是采购进行权衡，这样有助于缩减产品上市的时间、开发软件的成本以及运营的成本，提高整体质量。由于有运营团队的服务，软件开发工程师通常不会关注硬件。因此，如果让软件开发工程师设计-一个存储图像的功能(参见信息看板中的例子)，而工程师却没有关于能够使用以及应该使用的存储设备的知识，那么这种设计注定不能满足需求，不会是经济有效或是可扩展的。但将可扩展性作为共同目标就可以确保扩展文化渗透到每个团队，并当发生问题或危机时，由于每个团队都是责任人，他们会同心协力来解决问题。

JAD方法并不仅局限于瀑布式开发方法，即产品的一个开发阶段必须发生在另一个阶段之前。JAD能够且已经成功地与各种类型的开发方法结合使用了，如迭代式开发方法或敏捷开发方法，在其中，每当对产品功能有了更多了解时，规格说明书、设计和开发都会被修订。每当一个设计被修改了或附加了新内容，JAD就会被调用，帮助完成它。架构的类型也不会妨碍使用JAD。无论是传统的三层Web架构，还是面向服务的架构，或者只是一个单一应用，软件开发工程师、运营人员和架构师都会合作得到一个更好的设计，毕竟由团队制定出的解决方案一定比个人制定出的好。团队成员的背景越多元化，得到的解决方案就越全面。

JAD实际上的结构非常不正式。在给新功能指派了团队后，其中一个人要负责协调设计会议；如果团队中有软件开发工程师或项目经理，通常由他们担任这个角色。通常会有多次设计会议，根据成员们的日程安排，这样的会议会持续个或多个小时。 对于非常复杂的功能，应该针对该功能的不同组件安排多个设计会议。例如，安排一个会议重点讨论数据库，然后安排另一个会议重点讨论缓存服务器。

通常，这些微信小程序设计会议都是从讨论该功能的背景和业务需求人手。在这个阶段，最好由产品经理进行介绍，然后随时对团队成员提出的问题进行澄清。讨论过产品需求后，最好回顾一下与这个设计领域相关的架构设计原则。接下来，可以让团队展开头脑风暴，提出各种解决方案，这样通常会得到几个不同的解决方案。它们会在会议结束时被记录下来，然后发送给相关人员，供他们在下一次会议之前认真考虑一下这些解决方案。通常，需要安排一个或两个会议，就这个功能的最佳设计方案达成一致。最后的设计会被记录下来，形成文档，报告给ARB。