mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
37 lines
3.7 KiB
Markdown
37 lines
3.7 KiB
Markdown
为什么计量 IT 的生产力如此具有挑战性？
|
||
===========================
|
||
|
||
|
||
|
||
在某些行业里，人们可以根据一些测量标准判定一个人的生产力。比如，如果你是一个零件制造商，可以通过一个月你能够制造的零件数量来确定你的生产效率。如果你在客户服务中心工作，你解答了多少个客户来电，你的平均解答时间都会成为评判你的生产效率的依据。这些都是相当简单的案例，但即便你是一位医生，也可以通过你主刀的临床手术次数或者一个月你确诊的患者数量来确定你的生产效率。无论这些评判标准正确与否，但它们提供了一个通用的方法来评断一个人在给定时间内的执行能力。
|
||
|
||
然而在 IT 这方面，通过上述方法来衡量一个人的生产力是不可能的，因为 IT 有太多的变化性。比如，通过一个开发者编写的代码行数来衡量开发者所用的时间看起来很诱人。但是，编程的语言很大程度上能影响到根据这种方法得到的结论。因为一种编程语言的一行代码比用其他编程语言编写所花费的时间和难度可能会明显的多或少。
|
||
|
||
它总是这样不可捉摸吗？多年以前，你可能听说过或者经历过根据功能点来衡量 IT 工作人员的生产效率。这些措施是针对开发者们能够创建的关键特征来衡量开发者的生产效率的。但这种方法在今天也变得逐渐难以实施，开发者经常将可能已有的逻辑封装进内部，比如，按供应商来整合功能点。这使得仅仅是基于功能点的数目来估量生产效率难度加大。
|
||
|
||
这两个例子能够阐述为什么当我们 CIO 之间谈论 IT 生产效率的时候有时会引起争论。考虑以下这个假想中的谈话：
|
||
|
||
> IT leader：“天啊，我想这些开发者一定很厉害。”
|
||
> HR：“真的假的，他们做了什么？”
|
||
> IT leader：“他们做了个相当好的应用。”
|
||
> HR：“好吧，那他们比那些做了 10 个应用的开发者更好吗”
|
||
> IT leader：“这要看你怎么理解 ‘更好’。”
|
||
|
||
这个对话比较有代表性。当我们处于上述的这种交谈时，这里面有太多的主观因素导致我们很难回答这个问题。当我们用一种有意义的方法来测试 IT 的效率时，类似上述谈话的这种问题仅仅是冰山一角。这不仅仅使谈话更加困难－它还会使 CIO 们很难展示他们的团队在商业上的价值。
|
||
|
||
确实这不是一个新出现的问题。我已经花费差不多 30 年的时间来思考这个问题。我得出的结论是我们真的不应该在谈论 IT 的生产效率这件事上面相互烦扰－因为我们永远不可能有结论。
|
||
|
||
我认为我们需要在改变这种对话同时停止根据生产能力和成本来谈论 IT 的生产效率，将目光集中于衡量 IT 的整体商业价值上。重申一下，这个过程不会很容易。商业价值的实现是一件困难的事情。但如果 CIO 们能够和商业人员合作来解决这个问题，就可以将实际价值变的更加科学而非一种艺术形式。
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://enterprisersproject.com/article/2016/8/why-measuring-it-productivity-so-challenging
|
||
|
||
作者：[Anil Cheriyan][a]
|
||
译者：[LemonDemo](https://github.com/LemonDemo) [WangYueScream](https://github.com/WangYueScream)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]: https://enterprisersproject.com/user/anil-cheriyan
|