Meta Pattern, Consulting Pattern Series

no problem can be solved from the same level of consciousness that created it -- albert einstein

模式名稱

Meta Pattern, 元模式 (元模式並不是模式的模式, 而是一種叫做"元"的模式 )

意圖

通過突破/超越問題的當前層次, 在更廣闊的視角下審視問題, 這樣即使面對不熟悉的問題, 也依然可以給出自己的判斷

動機

在客戶現場, 通常出於最大化利用價值的目的, 諮詢師經常被臨時安排參加某個會議, 會見某個團隊, 解決某個突發問題, 並被期望當場給出建議或方案. 很多情況下這些會議,團隊和問題和諮詢師被僱傭並被期望解決的主要問題關係並不大, 因此很多情況下諮詢師是沒有充分準備的. 那麼如何才能給出合適合理的建議呢?

通常有幾種方法.

一是明確說出沒有準備, 需要考慮一下才能回答. 這是可行的, 但毫無疑問會降低客戶滿意度, 並錯過會給客戶帶來改善的機會, 所以除非別無它法, 否則不建議使用.

二是基於自己的經驗給出自己的判斷. 這也是可行的. 但風險是適用性. 任何經驗都有適用情境. 在以往情境下合適的方案在客戶的情境下可能不合適, 尤其是對客戶的問題上下文比較陌生的情況下. 因此在闡述時一定要講清楚自己的情境, 否則客戶會覺得不靠譜, 信任度降低, 並錯過給客戶帶來改善的機會.

三是平時多積累, 多觀察客戶的日常工作, 隨時做好準備. 這無論如何都是要做的, 但不可能覆蓋所有的情況.

我們需要更好的方法

方案

愛因斯坦說過, 我們不可能在產生問題的同一意識層次去解決這個問題. 這意味著我們可以通過尋找比問題高的層次來協助我們更全面的理解問題, 並給出判斷.

舉個例子. 如何來判斷測試案例寫的好壞? 如果你對所測領域不熟, 客戶給你看了團隊現在的測試案例, 並要求你評價.

至少存在兩個比測試案例本身更高的層次, 一個是測試案例的設計, 二是測試策略. 從測試案例的設計來講, 你可以詢問客戶如何保證測試案例的全面性比如是否採用了等價類別邊界值等分析方法, 如何保證測試案例的穩定性比如是否採用了資料驅動的測試方式等. 從測試策略的角度來講, 測試案例是否按某種層次組織? 有沒有優先順序? 不同類型的功能分別用什麼類型的測試覆蓋? 甚至不同類型的測試分別多長時間運行一次?

當你從這些角度來問出問題後, 客戶通常都會受到啟發, 他們也不再局限於糾結單個測試案例的品質, 進而更全面的考慮測試策略等問題.

當使用者請你評價測試策略時怎麼辦? 比測試策略層次更高的是發布策略, 比發布策略層次更高的是商業策略…

效果

• 通常會協助客戶發現更深層次的問題
• 把握不當容易陷入空談. 多積累多思考依然是要做的.

已知應用

• 上面測試案例的例子是一個真實的應用
• 另一個例子是臨時被邀請參加一個完全陌生團隊的回顧會議, 並在會議結束時被要求給出評論. 可以從會議本身的效率以及會議氣氛反應的團隊成熟度等級等角度來評價

Pattern Series:

• CoC: Context over Code, Coaching Pattern Series
• SoS: Story over Solution, Coaching Pattern Series