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: