网站架构团队会议如何实施

根据你的组织文化的需要，ARB会议可以是正式的，也可以是非正式的。我们的经验是，这种会议对产品线工程师、数据库管理员和其他JAD成员来说，都形同挑战，因此我们倾向于非正式的形式。只有当要对功能的架构进行采用或不采用的决策时，才会进行正式的会议；这对于让JAD团队提出经过深思熟虑且报告制作良好的设计来说，应该已经足够了。
无论你决定这种会议应该是正式的还是非正式的，它们都应该具备下列步骤：
●介绍。如果研发组织比较大，那么可能有些JAD成员不认识ARB的成员。
●陈述目的。ARB的某个成员应该陈述本次会议的目的，以便让每个人都理解会议的目标。我们建议，你需要指出ARB是对提出的架构作出判断，而不是对JAD团队的成员进行判断。如果设计把打回，要求进行大大小小的修改，那么不应该把这一决策看作是人身攻击。组织中的每个人都应该把确保T系统应有的管控以及确保系统的可扩展性入自己的日程。
●架构设计报告。JAD团队应该向ARB陈述提出的设计。结构良好的报告应该带领ARB成员从头到尾过一遍JAD的思考过程，从业务需求开始，接下来是权衡决策、替代设计，最后是推荐的设计有哪些优缺点。
●Q&A。ARB应该花时间就设计提出一些问题，澄清报告中模糊不清的地方。
●审议。ARB成员应该让JAD团队离开，对他们提出的设计进行实质性审议。可以采用的形式有很多，如进行初步投票，衡量每个成员的立场，或者选出一个成员，带头进行讨论，在进行投票前，逐条讨论该设计的每个优缺点。
●投票。ARB应该有一个流程来确定某个功能是被批准还是被否决了。我们常常会看到，因为一个成员投了反对票，一个设计就被否決了。可能你会认为要达成全体一致不太可成员。ARB的成员应该一切公司都能或极其艰难，因而采用了34原则。如果情况如此，我们建议你可以重新考虑委员会的且总是与JAD团队过不去的人，并不是为了公司好，应该把他撤出ARB。
●总结。在ARB做出决策后，应该把JAD召集回来，解释自己的决策。这一决策可以是以下四种情况之一:
●批准。这意味着可以按照提案中列出的步骤执行下一步工作了。
●否决。这意味着否决了设计，要求构建全新的设计。不过，这种情况非常罕见。在提出的设计中，总有一些东西是可用的。
●有条件的批准。这意味着批准执行下一步工作，但要求有一些变更。这说明JAD团队不必再重新提交设计给ARB，可以根据提案执行下一步工作了。
●否决组件。这意味着否决了设计的提案，但提出了一些特定的要求，如要求JAD提供更多的信息，或者重新设计某些组件。这是最常见的否决形式，通常ARB的某些成员会要求提供更多信息或修改设计。在这种情况下，JAD需要重新向ARB提交设计，以便在开始开发功能之前，得到ARB最后的批准。
这些步骤可以根据网站设计团队的规模、专业知识和企业文化进行必要的修改。最重要的一点是，与个人好恶和议程(如给团队造成更多工作量的安排)相比，公司利益要被放在首位。以公司利益为重，就能把更多的产品呈现给客户，同时还能保证系统的可扩展性。

相关行业资讯

相关视频推荐