根據你的組織文化的需要，ARB會(huì )議可以是正式的，也可以是非正式的。我們的經(jīng)驗是，這種會(huì )議對產(chǎn)品線(xiàn)工程師、數據庫管理員和其他JAD成員來(lái)說(shuō)，都形同挑戰，因此我們傾向于非正式的形式。只有當要對功能的架構進(jìn)行采用或不采用的決策時(shí)，才會(huì )進(jìn)行正式的會(huì )議；這對于讓JAD團隊提出經(jīng)過(guò)深思熟慮且報告制作良好的設計來(lái)說(shuō)，應該已經(jīng)足夠了。



無(wú)論你決定這種會(huì )議應該是正式的還是非正式的，它們都應該具備下列步驟：
 
●介紹。如果研發(fā)組織比較大，那么可能有些JAD成員不認識ARB的成員。

●陳述目的。ARB的某個(gè)成員應該陳述本次會(huì )議的目的，以便讓每個(gè)人都理解會(huì )議的目標。我們建議，你需要指出ARB是對提出的架構作出判斷，而不是對JAD團隊的成員進(jìn)行判斷。如果設計把打回，要求進(jìn)行大大小小的修改，那么不應該把這一決策看作是人身攻擊。組織中的每個(gè)人都應該把確保T系統應有的管控以及確保系統的可擴展性入自己的日程。
 
●架構設計報告。JAD團隊應該向ARB陳述提出的設計。結構良好的報告應該帶領(lǐng)ARB成員從頭到尾過(guò)一遍JAD的思考過(guò)程，從業(yè)務(wù)需求開(kāi)始，接下來(lái)是權衡決策、替代設計，最后是推薦的設計有哪些優(yōu)缺點(diǎn)。

●Q&A。ARB應該花時(shí)間就設計提出一些問(wèn)題，澄清報告中模糊不清的地方。

●審議。ARB成員應該讓JAD團隊離開(kāi)，對他們提出的設計進(jìn)行實(shí)質(zhì)性審議?？梢圆捎玫男问接泻芏?，如進(jìn)行初步投票，衡量每個(gè)成員的立場(chǎng)，或者選出一個(gè)成員，帶頭進(jìn)行討論，在進(jìn)行投票前，逐條討論該設計的每個(gè)優(yōu)缺點(diǎn)。

●投票。ARB應該有一個(gè)流程來(lái)確定某個(gè)功能是被批準還是被否決了。我們常常會(huì )看到，因為一個(gè)成員投了反對票，一個(gè)設計就被否決了?？赡苣銜?huì )認為要達成全體一致不太可成員。ARB的成員應該一切公司都能或極其艱難，因而采用了34原則。如果情況如此，我們建議你可以重新考慮委員會(huì )的且總是與JAD團隊過(guò)不去的人，并不是為了公司好，應該把他撤出ARB。

●總結。在A(yíng)RB做出決策后，應該把JAD召集回來(lái)，解釋自己的決策。這一決策可以是以下四種情況之一:

●批準。這意味著(zhù)可以按照提案中列出的步驟執行下一步工作了。

●否決。這意味著(zhù)否決了設計，要求構建全新的設計。不過(guò)，這種情況非常罕見(jiàn)。在提出的設計中，總有一些東西是可用的。

●有條件的批準。這意味著(zhù)批準執行下一步工作，但要求有一些變更。這說(shuō)明JAD團隊不必再重新提交設計給ARB，可以根據提案執行下一步工作了。
 
●否決組件。這意味著(zhù)否決了設計的提案，但提出了一些特定的要求，如要求JAD提供更多的信息，或者重新設計某些組件。這是最常見(jiàn)的否決形式，通常ARB的某些成員會(huì )要求提供更多信息或修改設計。在這種情況下，JAD需要重新向ARB提交設計，以便在開(kāi)始開(kāi)發(fā)功能之前，得到ARB最后的批準。

這些步驟可以根據網(wǎng)站設計團隊的規模、專(zhuān)業(yè)知識和企業(yè)文化進(jìn)行必要的修改。最重要的一點(diǎn)是，與個(gè)人好惡和議程(如給團隊造成更多工作量的安排)相比，公司利益要被放在首位。以公司利益為重，就能把更多的產(chǎn)品呈現給客戶(hù)，同時(shí)還能保證系統的可擴展性。