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 ]
[
下一页 ]