标签 博客 下的文章

制定绩效目标的几个重要因素

本文是笔者发表在《程序员》杂志2012年11期上的那篇“制定绩效目标的几个重要因素”文章的完整版。

软件开发是一种创造性的工作,这种工作的成果具有不确定性且很难量化,因此经理们在给员工制定绩效目标时多没有统一标准(即便有也不一定准确,而且在一定程度上还可能会扼杀创造性),所采用的方法也是五花八门。不过即便如此,经理们也没有放弃寻找一种更为适合软件开发领域绩效目标制定的方法。笔者也是其中一份子,在这里我将就如何制定出合理的绩效目标,与大家分享一下我的工作实践。

一般来说,一个绩效目标从无到有再到达成,至少包含三个关键阶段:准备、制定与实施。若单从绩效目标的制定来说,我们至少需要做好准备和制定这两个阶段的工作。

 

准备

在与员工进行绩效目标制定之前,经理们应该做足准备工作,这些工作将直接影响到绩效目标制定的优劣。这些准备工作至少包括:

 

* 深入理解组织全局目标

个体绩效目标的制定是为组织内全局目标的达成而服务的。作为经理,自己应该首先对组织的全局目标做好深入的理解,要弄清楚全局目标的内容、自己所带团队的负责范围以及达成该目标的各种约束,如时间、人员以及其他资源配备等。

 

* 明确绩效目标制定的目的和意义

为每位员工制定绩效目标到底为了啥?对于这个问题经理们自己首先要做到心中有数。对组织而言,个体绩效目标是全局目标分解后的最基本单元,个人的绩效目标达成是全局目标达成的必要条件;对个体而言,绩效目标的达成过程也是自身知识和技能得以提升的过程;对于经理们而言,通过为员工制定有挑战性的绩效目标来发现和充分挖掘个体的潜力,通过观察员工在达成绩效目标过程中的表现,还可以进一步甄别员工的优劣。

 

* 工作目标初步分解

在与员工进行绩效目标制定之前,经理们应先做好工作目标的初步分解。将团队所承担的大目标分解为员工个体所能承担的小目标。这方面有很多成熟的方法可以借鉴,这里不赘述。

 

* 因人施任

工作有难易之分,人也有优秀与平庸之别。在与员工制定绩效目标前,经理们应该首先根据自己所掌握的情况对下属员工进行分类。有些人适合挑战高度和极限,而有些人却只能按部就班做一些事务性的工作。因此是否能够做到因人施任对于后续绩效目标制定是否合理以及能否顺利达成影响重大。

 

制定

做足上述准备工作后,经理们就可以坐下来与员工逐一制定合理的绩效目标了。何为合理的绩效目标?这是个见仁见智的问题。笔者认为一个合理的绩效目标至少应包含如下几个关键属性。

 

* 明确

绩效目标中应该包含明确的工作内容、职责范围以及时间约束;明确绩效目标达成的条件;明确实施过程中所能得到的各种支持;明确目标的达成程度与绩效的关系:何种情况为优秀、良好、一般或未达成(不及格)

 

* 适配

经理们制定绩效目标可不是为了“刁难”员工,因此工作目标应与员工能力和意愿适配,才能最大程度上发挥出员工的潜力。

 

* 共识

在前期准备中,经理们已经做了初步的工作目标分解以及人选甄别准备工作,但这仅仅是经理们的“一厢情愿”。合理的绩效目标是需要经理与员工共同讨论、理解、认同并最终达成共识的,否则纯粹行政命令式的目标指派很难称得上“合理”,目标达成的效果也会大打折扣,很可能影响到组织全局目标的达成。

 

* 分阶段

虽说合理的目标应该是利于员工达成的,但往往因能力有限以及一些不确定因素等原因,我们无法对目标作出精确的估计,因此将绩效目标划分为若干个阶段将更有利于对员工的绩效目标达成情况进行跟踪、反馈、辅导和及时修正。

 

* 挑战

前面说过制定绩效目标的一个重要目的就是帮助员工在目标达成过程中做到自我提升,因此一个合理的绩效目标是应该具备一定挑战性的,否则员工每次都做同等难度或相似的工作,提升的幅度就会有限,导致成长缓慢。但绩效目标带来的挑战性也要适度,过于困难的目标将导致能力上的不适配,从而导致目标无法按预期达成。

buildc 0.2.0版本发布

buildc的演进先后经历了构建管理安装包工程管理两个阶段。其中buildc的构建管理功能在项目中应用较早,目前相对稳定可靠。但其支持的安装包工程是直到最近才被大家所正式使用的。不出意料,大家在使用过程发现了一些问题,于是我们也是边用边改。

目前一个setup工程一般具有类似如下源码组织结构:

distributions/
setup.cfg
src/
    – README
    – app/
    – conf/
    – deps/
    – layout.cfg
    – others/
    – scripts/
    – setup.py

按照最初的设计,deps目录下会存放一些目标程序运行时依赖的库、工具等。但就一些细节并未考虑清楚,比如如果一个程序需要在两个平台(linux和solaris)上运行,那deps下的依赖库应该如何存放?

就这个问题一线的人员在设计setup工程时采用的策略是将某个库的所有平台版本都手工放到deps下,以instantclient这个oracle的客户端库来说,就形成了如下结构:

deps/
    – instantclient/
        – 10.2.0.5.0/
            – x86_64_linux/
                – lib/
            – x86_64_solaris/
                – lib/

这样一来安装包制作完后size非常的大,不便于存储和传输。另外手工copy依赖库显然不够专业。打包过程是buildc来完成的,而buildc是拥 有全部依赖库的存储位置、版本等信息的。于是我们就这个问题做了改进,让buildc 0.2.0支持将依赖的第三方库根据目标程序运行平台类别自动打包到最终的安装包中。

也就是说,如果你是为x86-64 linux平台做的安装包,最终安装包中的目录结构会是:

deps/
    – instantclient/
        – 10.2.0.5.0/
            – x86_64_linux/
                – lib/

而这一切仅需通过配置完成。在setup工程顶层目录的setup.cfg文件中,我们增加了一个新配置项,用于描述目标程序运行时依赖哪些第三方库,这些库将被打包到安装包中,并部署到目标主机上去。

配置的格式如下:

dependences = [
    ("instantclient", "10.2.0.5.0", ["libclntsh.so", "libclntsh.so.10.1", "libnnz10.so"]), # 打包指定的库文件
    #("instantclient", "10.2.0.5.0", []), # 打包instantclient/10.2.0.5.0下所有的库文件
    #("instantclient", "10.2.0.5.0"),     # 打包instantclient/10.2.0.5.0下所有的库文件
]

通过例子可以看出dependences中的元素支持三种形式配置,可以指定打包的库文件,也可以将库目录整体打包。

BTW,buildc自从发布以来一直没有user guide,好消息是项目组的小兄弟wtz1989227已经在wiki上建立了buildc_user_guide页面,后续他会逐步完善这个guide的。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats