请问下，你们的技术组的绩效是怎么定的？

绩效考核的基础是绩效目标，先定绩效目标，简单的说，你这个组织的阶段目标是什么，之后分配到个人，另外组织对个人的还可以制订另外的个人绩效目标（在组织目标之外）

@zhouzm 这个已经有了，就是月目标，月目标定下来了，现在想提高工作积极性，怎么才能定一个能够提高技术组员工作积极性的绩效？或者说在阶段性目标的基础上去重新定制！

归根结底还是取决于主管的主观印象啦。

redmine + git ?

我自己有一套内部使用的技术组打怪系统 ...

怪物可以由任何人提交 ... 可能是 bug 或者 feature ...

怪物分危害大小 ... 但每个人每周最多只能放置两个 EMERGENCY 级别的怪物 ...

每个怪物可以被 assign 到某个固定的人 ... 或者由有空的人自己领来打 ...

打掉怪之后有金币有经验 ... 金币根据怪物级别打怪时间长短和怪物复生率在一定范围内波动 ...

金币可以用来兑换绩效工资 ... 兑换比例根据目前总金币流通数量波动 ...

大体就是这样 ... 总之就是一个以游戏之名结合需求管理与绩效考核的系统 ...

此外因为还有些零食掉落和 DKP 一类的设定 ... 实际使用起来还挺有趣的其实 ...

和楼上一样。分任务，每个任务有个分值。提bug扣分。

@sunyanzi 听起来很有趣哦

说到底还是主管看人,看脸.

@Sunyanzi 你们这套系统开源不？在哪儿下载 ？

@ijse 是自己写的内部系统啦 ... 还没开源 ... 因为感觉还有些细节还需要完善 ...

类似的团队用的小玩意我零零散散写过好多 ... 比如还有团队效率管理和 Knowledge Base 什么的 ...

我惦记着把这些都整合起来再开源呢 ...

目标都确定了，积极性还没起来，要么是奖励不给力（不明确或不公开），要么就是奖励机制可能还存在不合理之处，建议听取一下技术人员自己对考核制度本身的想法。

我想问各位，当bug数与绩效挂钩的时候，测试和开发还能好好做朋友嘛？

@Sunyanzi 这套系统用在开放上也有很多bug吧，首先怪物之间是有相关性的，任何人都可以打怪物对于消灭所有怪物而言效率并不怎么高；怪物（bug&feature）的大小强弱很多时候都是未知的，除非是已经打过的关卡（npc有经验）；接着很多怪物的死亡很难check（因为大多数情况你以为已经死亡了的怪物其实只是奄奄一息）；还有在打怪物的时候的技巧很难判断，有的人只是运气好怪物撞上墙自己死了（太坑爹了，或者说运气好捡到大宝剑［已经写好的库］）；最后需求是变更的，环境（运行环境）也是变化的，导致了很多已经死掉的怪物死灰复燃（好乱啊，到底是谁让怪物死灰复燃的）。

@loveuqian 可以呀 ... 为什么不行 ...

@njutree 这套系统比起 JIRA redmine 之流确实不够严谨 ... 但对于我来说足够用 ...

关于人人可以打怪这个设定 ... 我作为管理者会把野生的怪物指定给某一个人来提升效率 ...

也就是日常任务的感觉 ... 在我没有指定的时候大家自由处理 ...

因为和绩效挂钩 ... 大家就会有抢怪的动力 ... 可以有效避免每个人都在等别人解决怪物的拖沓情况 ...

以及说有些危害程度不高的怪物 ... 一个手不熟的人花了很长时间解决了 ...

虽然从效率角度讲的确不如给一个手熟的人 ... 但从团队成长角度讲我更喜欢每个人都有锻炼的机会 ...

关于怪物的大小强弱 ... bug 还好说 ... 因为打掉之前的某个 feature 产生的 bug 视为怪物复生 ...

复生这个概念我之前也提过 ... 讲故事就是一个大 BOSS 被铲掉之后它的小弟们前来报仇这种感觉 ...

小弟的数量和危害会影响打掉这个 feature 的人得到的金币数量 ... 分给打掉这些小弟的人 ...

如果那个 feature 已经过了确认阶段进入历史了 ... 那么这个 bug 不和原来的 feature 挂钩 ...

这大概就是你说的死灰复燃 ... 不管原来谁写的不管现在谁触发的 ... 都作为新 bug 来放置怪物 ...

如果是纯新 feature ... 难易确实不好判断 ... 现在只能靠我人工 ... 我还没想到更好的处理办法 ...

至于怪物死亡很容易判断 ... 一旦需求方测试通过就是 Mission Accomplished ... 拿经验拿第一笔金币 ...

如果有测试不严谨的地方发现有什么边角细节遗漏也视为怪物复生 ... 放置新怪物下去就好 ...

打怪技巧也是同理 ... 我这套系统是结果导向的 ...

不管一个怪物是自己死掉的还是你费了九牛二虎之力才解决的 ... 只要最后解决了就是你的功劳 ...

系统之外的部分我会说代码写得好与不好等等 ... 人为的控制后续确认阶段的金币给予量 ...

我之前考虑过把系统跟 Sonar 打通来为每次战斗评级 ... 但还没实现 ...

基本就是这样 ... 不知道我有没有描述清楚 ...

@Sunyanzi 这样其实对老是写出bug的人更有利。自己写出来的自己改比别人改要容易。相反那些代码严谨，把bug消灭在未提交之前的人的分会低。

@yxz00 每个角色一出来就有初始金币，如果这个角色产生了 bug ，则会扣除金币，这样下来，如果某人写出的 bug 很多，那么他的金币也就会越来越少。
嗯……也就是说，得有一个金币消耗机制。

@yxz00 这个问题也是很重要的问题
@Sunyanzi 我只想知道这么复杂的系统所带来的收益其实不好说，还有就是需要大量的代码评审，否者会有故意留bug，或者直接只解决当前问题，根本不考虑将来的环境和需求变动（这样的代码健壮性很难保证）；新手解决问题的时候本身就会留下很多bug，很多bug不是简单的跑测试用例就能测出来的。我觉得这套系统只适合熟手做简单机械的项目，不然我觉得你们的项目应该都会在追赶features 和 频繁的debug 中度过（到处都是bug）

@Sunyanzi （星星眼）看到这种游戏设定就好鸡冻是肿么回事 Orz...

@njutree 我觉得这种有情怀的系统只适合有情怀的团队23333~如果团队里面为了高绩效做出诸如故意留bug 等行为的可以审核发现之后直接 T 掉了的感觉- - 大家不太适合一起共事。
新手的话我觉得需要一个成长的过程吧，虽然一开始可能会留下bug，但不会永远都这样的，嗯。。。还是菜鸟的人这样坚信= =

workload + tickets