1700489163
1700489164
Deborah Gordon博士编写了Benner著作中的一章内容。在这一章中,她概述了过分依赖护理专业形式模型所造成的一些危害。根据我们行业的特殊性,我重新诠释了她的见解,但是即便是Gordon博士的原文,听起来也会让你觉得非常熟悉。
1700489165
1700489166
混淆模型和现实
1700489167
1700489168
模型不是现实,但是很容易混淆这两个概念。有一个关于年轻项目经理的老故事:团队里的高级程序员宣布她怀孕了并将在项目期间分娩,这位经理抗议道:“这不在项目计划中。”
1700489169
1700489170
低估不能形式化的特性
1700489171
1700489172
良好的问题解决能力对我们的工作很重要,但解决问题是一件很难形式化的事情。例如,你应该坐下来思考问题多长时间?10分钟?一天?一周?你无法对创造力和发明限定时间,因而,你也无法建立相应的技术。即使希望团队拥有这些特性,你仍可能发现管理部门根本不会重视它们——仅仅是因为这些特性无法形式化。
1700489173
1700489174
规定违背个人自主性的行为
1700489175
1700489176
你不希望一群猴子敲打键盘编写代码。你需要能思考、负责任的开发人员。对形式模型的过度依赖往往会鼓励羊群行为〔18〕而贬低个人创造力〔19〕。
1700489177
1700489178
偏袒新手,从而疏远了经验丰富的员工
1700489179
1700489180
这是一个非常危险的副作用。针对新手创建一套工作方法,对经验丰富的团队成员来说,你会建立一个恶劣的工作环境,他们会直接离开你的团队或组织。
1700489181
1700489182
阐明太多细节
1700489183
1700489184
阐明太多细节会适得其反。这会引发一种称为无限倒退(infinite regress)的问题:一旦你详细解释了一系列假设,你就提前暴露了本应简单提出的下一个层次的假设。如此下去,只会带来恶性循环。
1700489185
1700489186
把复杂局势过于简单化
1700489187
1700489188
Rational统一过程(和一些新方法)的早期支持者坚持声称,你需要做的仅仅就是“按部就班”。一些极限编程的支持者坚称你需要做的就是“只要遵循这12——不,等一下,也许是13种——实践方法”,然后所有问题都可以解决。这两种观点都是错误的。每个项目、每种情况都比那更复杂。每当有人开始说“你需要做的仅仅是……”或者“只需要做这个……”,他们十之八九错了。
1700489189
1700489190
追求过度一致
1700489191
1700489192
同样的标准不可能放之四海而皆准。上一个项目里最管用的东西对当前这个项目来说可能是一场灾难。就算Eclipse能提供给Bob和Alice巨大的生产力,它也有可能会毁掉Carol和Ted。后者宁愿选择IntelliJ或者TextMate或者vi〔20〕。
1700489193
1700489194
忽视情境的细微差别
1700489195
1700489196
形式方法针对典型情况,而不是特殊情况。但是,“典型”真的会发生吗?情境对专业表现至关重要,而形式方法往往会在它们的公式中丢掉情境的细微差别(它们不得不如此;否则,它们得花费数千页纸来描述早晨如何喝到咖啡)。
1700489197
1700489198
在遵从规则和自行判断之间犹豫
1700489199
1700489200
什么时候适合打破规则?任何时候?永远不能?还是介于两者之间?你如何知道?
1700489201
1700489202
故弄玄虚
1700489203
1700489204
语言表达如果过于口号化,它就会变得微不足道,并最终完全失去意义(例如,“我们是一个以客户为中心的组织!”)。敏捷方法正因为这个问题很快失去效力。
1700489205
1700489206
形式方法有其他优点和用途,但是在实现这些目标时不起作用。虽然它可能有助于为较低技能水平的人建立基准规则,但是判断力是无法取代的。随着判断力增强,对于规则的依赖必须放宽,伴随着严格的制度执行。
1700489207
1700489208
诀窍6
1700489209
1700489210
如果你需要创造力、直觉或者独创能力,避免使用形式方法。
1700489211
1700489212
不要屈服于工具或者模型的虚假权威。没有什么可以替代思考。
[
上一页 ]
[ :1.700489163e+09 ]
[
下一页 ]