对于程序员来说，什么是一个好的智能目标的例子？

Question

在这个问题之后，我想知道，在程序员的定期评审周期中，福克是否能够提出一些可以被认为是“好”目标的示例？

让我们从维基百科条目中最流行的定义中定义SMART：

• 特定的
• 可测
• 可得
• 相关
• 限时

Answer 1

我逐渐意识到，当人们有需要纠正的缺陷时，最好使用聪明的目标，而在你希望人们成长或从好到伟大的时候，目标就不那么好了。例如，如果有人没有在做时间表，而这对公司不利，因为有时你不得不延迟开发票，那么你可以有一个聪明的目标，比如“在接下来的6周里，至少5周的时间表将在下个星期一早上10点之前完成。”6周后，你有一个正确或错误的时间表；开发人员要么成功了，要么错过了它。要么你已经有了新的习惯，要么你可以决定是否还想雇佣一个不介意推迟开发票的人。也适用于那些有其他坏习惯的人：“在接下来的两周里，至少75%的您的签入都会遵循签入指南(链接到内部文档)。”再说一遍，在那短短的时间结束时，你做了一次很棒的事情。

在我发现这些结构不太有用的地方是当时间框架延长，当你想要的成就是模糊的(学习一门语言，要更有帮助)，或者如果目标没有实现是可以的(你可以重视认证，但是如果某人没有通过测试，你可能不会采取纪律措施)。突然，聪明目标的所有好处都消失了。不要试图将它们用于除纠正措施之外的其他任何事情，它们易于编写，它们帮助开发人员达到预期的水平，并且在时间成熟时很容易测试它们。写它们有困难意味着它们不是实现这个目标的合适工具。

Answer 2

既然我要和我的老板进行一次设定目标的谈话，我想我应该增加几个例子，这些例子与我正在考虑给自己建议的例子相似：

• 在3月31日前将项目X中代码的测试覆盖率提高到至少95%。
• 在4月30日前完成并分发Y项目建筑文件初稿
• 收集架构文档的评审意见，必要时进行更新，并在6月30日前发布文档的v1-0。

我希望在我指定的时间内完成更多的工作(毕竟，它以前总是如此)，而且这项工作可能会对“及时”方面产生特别的影响。这不应该是个问题:应该定期审查目标，以确保它们继续符合“可实现”的标准。我需要确保我的经理都知道-没有人喜欢不愉快的年终惊喜.

Answer 3

如果你销售软件或软件产品.

提高销售额n%.

真的。

如果软件不起作用，你就卖不了多少了。

如果这个软件真的有效的话，你会卖很多的。

(这将让软件人员像鹰派一样监视销售人员，确保他们不会破坏业绩奖金。)

如果您的软件是内部系统：

降低了业务成本n%.

如果新的软件系统需要花费10倍的时间，公司就会为此付出代价。如果新系统运行速度快，防止出错，公司就会省钱。

这种方法似乎适用于销售人员或业务变更流程的副总裁，但实际上，软件开发人员是这两种流程的第一线。

我在这里的基本想法是，试图明确地使员工的报酬结构与公司的最佳结果保持一致。