網站架構團隊會議如何實施

根據你的組織文化的需要，ARB會議可以是正式的，也可以是非正式的。我們的經驗是，這種會議對產品線工程師、數據庫管理員和其他JAD成員來說，都形同挑戰，因此我們傾向于非正式的形式。只有當要對功能的架構進行采用或不采用的決策時，才會進行正式的會議；這對于讓JAD團隊提出經過深思熟慮且報告制作良好的設計來說，應該已經足夠了。
無論你決定這種會議應該是正式的還是非正式的，它們都應該具備下列步驟：
●介紹。如果研發組織比較大，那么可能有些JAD成員不認識ARB的成員。
●陳述目的。ARB的某個成員應該陳述本次會議的目的，以便讓每個人都理解會議的目標。我們建議，你需要指出ARB是對提出的架構作出判斷，而不是對JAD團隊的成員進行判斷。如果設計把打回，要求進行大大小小的修改，那么不應該把這一決策看作是人身攻擊。組織中的每個人都應該把確保T系統應有的管控以及確保系統的可擴展性入自己的日程。
●架構設計報告。JAD團隊應該向ARB陳述提出的設計。結構良好的報告應該帶領ARB成員從頭到尾過一遍JAD的思考過程，從業務需求開始，接下來是權衡決策、替代設計，最后是推薦的設計有哪些優缺點。
●Q&A。ARB應該花時間就設計提出一些問題，澄清報告中模糊不清的地方。
●審議。ARB成員應該讓JAD團隊離開，對他們提出的設計進行實質性審議?？梢圆捎玫男问接泻芏?，如進行初步投票，衡量每個成員的立場，或者選出一個成員，帶頭進行討論，在進行投票前，逐條討論該設計的每個優缺點。
●投票。ARB應該有一個流程來確定某個功能是被批準還是被否決了。我們常常會看到，因為一個成員投了反對票，一個設計就被否決了?？赡苣銜J為要達成全體一致不太可成員。ARB的成員應該一切公司都能或極其艱難，因而采用了34原則。如果情況如此，我們建議你可以重新考慮委員會的且總是與JAD團隊過不去的人，并不是為了公司好，應該把他撤出ARB。
●總結。在ARB做出決策后，應該把JAD召集回來，解釋自己的決策。這一決策可以是以下四種情況之一:
●批準。這意味著可以按照提案中列出的步驟執行下一步工作了。
●否決。這意味著否決了設計，要求構建全新的設計。不過，這種情況非常罕見。在提出的設計中，總有一些東西是可用的。
●有條件的批準。這意味著批準執行下一步工作，但要求有一些變更。這說明JAD團隊不必再重新提交設計給ARB，可以根據提案執行下一步工作了。
●否決組件。這意味著否決了設計的提案，但提出了一些特定的要求，如要求JAD提供更多的信息，或者重新設計某些組件。這是最常見的否決形式，通常ARB的某些成員會要求提供更多信息或修改設計。在這種情況下，JAD需要重新向ARB提交設計，以便在開始開發功能之前，得到ARB最后的批準。
這些步驟可以根據網站設計團隊的規模、專業知識和企業文化進行必要的修改。最重要的一點是，與個人好惡和議程(如給團隊造成更多工作量的安排)相比，公司利益要被放在首位。以公司利益為重，就能把更多的產品呈現給客戶，同時還能保證系統的可擴展性。