那种薪资结构更合理

不愿意就离谱，这个是态度问题吧

我看明白了，你缺一个靠谱的项目经理

管理失职。另外你这员工不干活不辞退留着干嘛？能者可以提拔升职，你这操作属于变相降薪

就这样操作 让别人都跑路比较好

这种不是看绩效或年终来定的嘛

@JKeita 用项目积分作为年终绩效不失为一种办法, 不过绩效太少的话, 没有动力; 绩效太多的话, 就变成了加工资, BOSS 那里不一定同意

变相降薪，很多人都接受不了吧

@h1104350235 打算新人新办法, 老人老办法(老人如果觉得新的薪资标准自己更满意的话, 可以转)

这种方式只能让摸鱼的继续摸，能干活的都跑了。
不如从开发制度和团队规范入手

管理失职。

以前有个领导，广受好评，他和我们说“如果员工没事做，是公司的问题，不是员工的问题”。


扯回话题，真的好难。工作这么多年，也见过好几家公司试图考核码农，最终似乎都没什么好办法。
最好的办法竟然还是“人治”。

“有任务提成, 多劳多得”，这个困难在于，任务和任务的难度，辛劳不同。这样一来，形成“写多少代码赚多少钱”，以后轻松任务抢着做，难点任务，心有怨言，觉得钱给少了。
还有个隐患在于，是否形成变相降薪。给多少工资固然是公司自由，但如果比如市价是 A，变相降薪成 B，最终的后果就是人员流失，劣胜优汰。


真想激励，价钱啊。绩效分层，高的猛加钱，但显然有成本。



因此我觉得，还是用土办法吧，偷懒的谈话，实在不行裁换。

@kop1989 人性都是懒惰的, 干多干少一个样吃大锅饭的结果都是这样.

总不能说当年农村大锅饭是对的, 生产效率不高的主要原因是村干部的威望和管理能力不够

@skyworker #14

1 、软件工程从来就不是“吃大锅饭”。
2 、软件工程是一个脑力劳动，不能够通过客观指标估算工作量。
3 、消极怠工的本质是因为工作氛围下限的不断下探。
4 、“多劳多得”在软件工程里并不存在。

之前看过一个全 remote 的公司的分享。大家平时有时出门的话打个招呼就好了，没有请假不请假的。但是，肯定会有人利用这个。那他们是怎么办的呢？出于保护好人的原则，直接干掉钻空子的人。

可以偶尔开个会让汇报进度

这三条除了 2 以外基本都是项目领导的失职，和写代码的没什么关系。而且就第二条也应该是管理人员分配任务，被分配到的不干那才是另一码事了。

这种搞到最后只会让人待不下去

@kop1989 目前我司的开发流程还比较简单, 每个人单独负责一个 case, 类似 ERP 的实施顾问制度, 只不过更多是用代码切入的方式(UI 设计什么的 toB 软件一般不涉及,简单的组件堆叠和模块定制), 不存在多人"协同团队作战", 没单 case 都是指定人员自己独立完成的

建议全体加薪，让他们自己感到自己不值这个价，然后自己努力工作 /dog

公司是你家的么?

@ge00111 是啊, 我打算好好干, 这辈子就指望在公司养老哪

每周拉起来，大家开个会，把大家手头的工作分享汇报一下。
然后把需要做的工作认真评估，然后放到 todo list 里面，大概估计工作量。每周确定做多少工作就可以了。

知道 hr 是干啥的了吧

薪酬是很大一块内容

按你说的现状，是典型管理人员无能的表现了。
开发和美工本来就就无法量化，一些不懂得管理总是想量化，比如代码写了几行，真得是无语。
你缺一个合格的项目经理或者技术负责人可以很好的了解手下人员工作进度、个人能力并可以合理高效的安排工作内容。
千万不要降底薪，搞得开发和销售一样。花点钱招个项目经理，高效开发。你就不要关注一线开发人员平时干啥了。

很好奇，你不是 boss，你到底是啥职位？
先不去考虑怎么提升自己的管理能力，去瞎操心员工得工资了。

反向绩效最打击积极性了，如果你的想法是让现在的人走，换新的人来接活，可以这么操作。

1 、需要整肃的是管理层。

2 、改变工作氛围，改变一个人是很难的，但是改变一个团队的工作环境会困难少些。

3 、工作是很难量化的，除非到极致也就是 sb 式管理方案，见过最 sb 的是写小时报。每 1 小时简短汇报一次，然后忙于这玩意，工作量更少了，摸鱼更舒服了，然后很快取消了

上家公司的同事大多就是这样，虽然薪资很丰厚，但我受不了这种环境就离职了
现在这家是互联网公司，忙且充实
可能是我 jian 吧

1.像干好事，成本最低的就是高薪招个技术出身的管理人员，然后下面的开发也别降薪。
拒绝完成任务，态度恶劣的直接开除，每半年\一年有个全员加薪。

2.成本更低的是，摸鱼的直接开或者逼走，让开发环境恶劣，流水招人接锅，项目能跑不出大问题就行；好处是金钱成本低，坏处是 HR 压力大，几年后项目大概率炸，重新开发，循环往复。

可以试试，不过最好先全部 lay off，全部重新招，否则多半很痛苦

为什么是降薪？就不能在原来的基础上加提成吗？

哈哈 我司干过 搞了一季度，又改回原制度

量化就是僵化

如果想让我把一行代码拆成五行写，也能做到。

如果真想弄奖惩机制，也应该是 10k+奖励，而不是 8k+奖励的 2k

代码行数是可以量化你工作量的?

我可以写 20 行的垃圾代码,也可以优化成 10 行的简洁代码,这就叫工作不饱和?

那我天天写垃圾代码

如果是这样 我写的快可以摸鱼吗

@huruwo 如果按照这种模式的, 效率高的话假如一个月前 10 天自己完成了 2 个 case,只想拿 12K 的话, 后面可以摸鱼, 大家都高兴.

量化代码是很不靠谱的事，你需要一个靠谱的项目经理，知道哪个模块大概需要几天的工作量，然后负责在后面催着，然后区分出能干活不摸鱼，能干活摸鱼和不能干活的人，淘汰掉不能干活的人，把他的工资加到其他人身上。一个不能干活的混进了队伍，不及时清出去，别人看这么低效率也能混就跟着混，不想混的看到其他人都在混就想离职，然后部门就衰败了。

@plk403 case 是固定的, 例如这个月就这一单 case, 你写垃圾代码用了 20 天也可以; 高效率的话, 1 天把项目完成了, 后面摸摸鱼也 OK

楼上回复的不是在摸鱼吗?都是上班时间回复的吧

@wxw752 考核是根据员工完成的 "项目"来计算的而不是根据代码行数, 例如一行代码也是完成项目, 10 行代码也是完成项目, 我相信没有人会把一行写成 10 行的

@justrand 你嫌 10 行不够，那你想要多少行我都能给你一秒钟加上。说到底还是他们公司的人摸鱼技能不够高，让 hr 发现了

@skyworker 会不会因为有人做的快了，觉的工作量不够大。立马加大工作量并且开除做的慢的员工。

这是之前的一个流水线故事。老板预定好一个件提成几毛，结果员工越做越快后面收入过万了。老板立马把单个件提成降下来一半然后员工跑路。

@huruwo 任何根据"绩效"发放的薪资制度都有这种可能性, 这就只能靠公司内部的默契, 以及另一方如果觉得对方做的过分, 用脚走人投票来平衡了

@skyworker 还有关于摸鱼的问题
在项目初期 需求多任务重需要快速开发可能不会摸鱼
后面项目稳定 只做维护或者小任务 因为对项目熟悉，快速完成然后摸鱼。
对于这种情况你怎么看。

我寻思你们是不是忘了奖金的本意是干什么的，工资本来就是个保底，按照团队干的事情分奖金包，团内自己内部再继续分，这才是奖金的初衷啊

@huruwo 可能你对 toB 端的软件不熟悉, 每个 B 端企业用户的需求都是独特的, 并且不一样的(主要是流程), 基本上开发的主要工作就是业务流程的重构, 而不是例如应付高并发这样的需求, 一旦高并发解决了,以后就没有什么问题了.

B 端软件的实施过程, 都是流程重构和打通, 并且几乎每个企业的需求都是不一样的.

这就是外包，看谁闲着就派去客户现场出差就好了，然后他就会自己离职的。

@zw1one 开发人员都是在公司的, 不需要出差

开发又不是打字员，以代码行数评估工作量太扯了

程序开发 很难量化啊

按任务分有一个问题，怎么准确的评估每个任务的难度以及耗时，然后给予相应的报酬？比如一般的 CRUD 任务跟优化系统任务是不同难度的东西，它们的任务报酬差额是要体现出它们之间的难度，有些东西虽然也是几百行代码，但可能是要有一定经验以及积累才能写的出来，价格肯定是不一样的

降薪，还是集体降薪，对团队的打击可是非常大的，能干活都可能开始不干活了，而且最后致头部人员流失。

不如裁几个尾部人员，可以集中工作量，确立威信，驱逐害群之马。

然后再确定好职级和晋升途径，给干活的人一些甜头，给大家的工作有个盼头。

笑死我了，工地搬砖这么搞没问题，越是复杂脑力劳动这么搞越难。

好歹只是个定制开发，这要是技术探索，数据挖掘这类活该怎么办？

总不能站在背后用鞭子抽？

什么情况下他们效率会高？干脆也别雇他们了，把活按量按时发包给他们好了：干完自己玩去，没活也不给钱，这样可好？

软件开发者的工作量化是很难的，强行量化只能让真正干活的人接受不了束缚选择离开，反而是混子还会有无数种方法继续混下去。建议考虑 2 楼的意见，加强团队管理

想起个老故事
花了十天，只写了十行代码，但这该写的十行代码，没二十年经验是找不出来的

古德哈特定律：当一个措施本身成为目标时，它就不再是一个好的措施。
你用代码行数来算？我一分钟能诹出 200 行无效代码。还记得那个内核错别字大师吗？
因此，你需要测量产生的效益，唯一的测量方式是（由谁？）测量效益本身。对，这里的由谁测量是个问题，而且是个有启发性的问题。社会如何测量一件事的价值并给予人们反馈？市场。市场是层叠的。你从 ABCD 那里买来原料，生产出商品后卖给 WXYZ，WXYZ 通过一般等价物，反馈给你你的输出值多少钱，你再次传递到 ABCD 那里，他们的工作值多少钱。所以，真正意义上有用的测量是在公司内部将工作重新市场化。由一名员工提起项目（粒度化可以很细，比如一项改进措施），在粗糙的审议通过后，分配一定量预算，该员工自动形成项目管理者，由其在公司内招人实现之，完成之后获得的效益再由其分配。中间消耗的一切公司资源均作预算抵消。
实际上有看到说有公司不完全地实现了这一想法，并且效果很好，但我实在不记得是在哪看到的了。最可能是阮一峰。

安排工作任务时，制定任务时间计划表，按时间表推进工作进度；根据效率和结果，可奖可罚；平时无事养着，有事全力以赴；很容易就能解决第一点摸鱼偷懒的问题。

第二、第三，加钱 和 利益挂钩；不然还真以为公司是我家了

你一个很大的误区就是以代码当工作。
软件工程师的作用是解决问题而不是写了多少代码。
举个不恰当的例子，装修砸墙你要看他砸好了多少而不是挥了几下锤子。

@11wangyaoda 其实你举得"装修"的例子很合适, 每个开发工程师都是独自负责一个装修的 case 的, 不管他挥了几下锤子, 最后都是按照这个装修工程结束后算绩效成绩的, 而不是按照挥锤子的次数

@xiangyuecn 还是拿"装修"举例子, 每个工程师接到"装修"工作后, 需要自己来衡量工作进度和安排, 不可能每个装修项目到了, 都需要管理人员去现场看下预估几号到几号做什么事情, 开发人员自己其实就是"项目经理".

问题在于, 假如装修公司雇佣的"项目经理"都是固定薪资的话, 一个月做几个装修项目跟薪资没有关系, 那么在人性懒惰的前提下, 拖工时 /不想接项目都是肯定存在的问题, 指望装修公司管理人员的威严和管理能力, 都是不靠谱的.

然后大家都去抢简单的体力活，业务复杂的东西没人愿意做

@llb123 业务复杂的项目, 负责任务分发的管理人员可以适当的提高绩效分数

@skyworker
#64 拿装修说事儿的话，拿劣质材料和优质材料去做的区别你们要考虑吗？反正表面看起来都一样，使用下来也都差不多，也许半年后发现墙面掉粉（软件卡顿），这怎么算呢？
#66 如果你们“负责任务分发的管理人员”，能知道“提高绩效分数”的“适当”标准是什么，你们就不会有现在的问题了！

说实话，与其在 V 站问网友，不如用这个时间去学习互联网管理课程。大多管理课程虽然是大而空的，但是人家总结的点是没有多年经验难以发现的。

降薪 人就没了

那你要不要试试我前东家的项目？ meri.co

他们国区的网址是这个 https://www.merico.cn/