軟體開發團隊如何做設計審查（二）
如果你覺得文章對你有幫助，請關注微信公眾號「工學」。
今天我們學習第二部分：設計審查（Design Review)。
在許多公司，人們將設計文檔用email發送出來並且詢問其他人的反饋意見，通常沒有什麼人響應。工程師們會把這種沉默當成默認或者無所謂，不了了之的機制就養成了，惡性循環的是，許多工程師從此認為設計文檔沒有價值，最後整個團隊的溝通就崩潰了。這就需要有一套執行設計檢查的流程，就是設計審查（Design review）。
建立基本規則流程
保持良好的組織性是必要的，你需要讓每個人都在45分鐘的時間內保持專註，唯一的辦法就是創建議程並堅持下去。
1.為這次會議選擇一個主持人和會議記錄員，他們應該是中立派，非常擅長溝通的人並有一定的會場控制力，了解技術細節。相對而言，來自工程團隊其他部門的主管工程師就非常適合主持人的角色。
2.在現場審核之前，提前48小時向你想得到反饋的對象發送設計文檔以及問題文檔以獲取問題和評論。在會議開始前約30分鐘，主持人對問題進行分批歸類，如運營，安全，用戶體驗等。
3.把下面列表中的會議規則發送給你的團隊，會議開始簡單地過一遍上述規則來再次強調它們需要被實施。
·每個人都應該在會議之前向問題文檔添加問題，這份文件將成為審查的議程。
·每個人都可以坐下來聽，但除非閱讀了設計文檔，否則會議人員不能在會議中發言。
·會議中，不能幹其他活，如發電子郵件，可以打開筆記本電腦，但只能閱讀設計文檔。
·主持人會持續將內容推進並且可能會要求特定的討論在線下進行。
4.在設計評審過程中，主持人不該作為問題的提出者，而是應當把機會讓提問者自己說出自己的問題。如果某個問題佔用時間過多，或某個回答太冗長，主持人可以打斷他們。
5.會議記錄員負責記下每個達成的共識和決定，而且最好儘可能詳細地記錄下所有內容
6.開放討論
當所有問題都提問完畢，如果還有時間的話，主持人應當留給大家開放討論，提出其他的具體問題，或者提供建議和反饋等。
處理反對意見和異議
設計評審過程中，有時會產生積極的甚至是激烈的爭論，這是很自然的。如果爭論持續時間過長，主持人應該介入和喊停，或由資深的工程師出來維持討論秩序。有時，爭論也是好事情，作用是很神奇的。最嚴苛的批評造就最好的問題預防體系，對於團隊成員也是好的學習機會，包括資歷稍淺的工程師和非工程師們，都能詳細了解到技術方案和利弊權衡取捨的決策過程。
對產品的益處：
從一開始的文檔編寫到設計評審過程，到後面的公開或私下的交流討論，對團隊有許多益處：
·促進整個公司內的交流溝通
·提高對技術基礎架構的理解，特別是對非工程師而言
·對過去完成的和現進行的項目有更好的了解
·設計出更好的功能和產品
·節省時間精力，特別是對更高級崗位的人員而言
對工程師的益處：
提高設計開發工程師的主人翁意識也有許多的益處，培養每個人都在決策流程中有所貢獻，而不是被告知或接受指令要做什麼的氛圍也是設計評審流程意義所在。
讓每位工程師都說出自己的想法，而非僅是那些最常發言或最強勢的。你的團隊中會有很少發表意見的成員，他們其實有很深入的思考，只是沒有表達出來。而設計評審流程，可以讓他們也很自然地參與進來。大多數工程師只是希望自己的意見被聽到。
總結：
在項目中，多花點時間寫設計文檔和做評審，這樣能保證每個人都知道要做什麼，明白有哪些利弊上的權衡和取捨原因。要確保溝通是足夠充分的，特別是要聽取關鍵崗位的工程師的看法，這樣能避免將來產生問題和麻煩。對於大的項目和團隊來說就更是這樣，比如人數在100人以上，必須確保每個人都對細節了解得很清楚才行，你要做的是可能要用數年的系統，花幾周時間把它理清楚，是應該的。
TAG:工學 |