请教一个管理方面的问题。

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2696 天前的主题，其中的信息可能已经有所发展或是发生改变。

背景：

公司让我做小组长，主要是负责项目的进度和背锅，也是第一次管理人，因为人数少，我也对小组长的头衔也没看太重。大家一起快乐的码代码才是最重要。平常也玩的比较好。但是在项目上，有个人就是老不配合你(老员工，比我来的早)，比如说:

- "这地方注释为啥不写"
- "写啥注释，都能看的懂"

- "这地方变量名怎么这么写(大小写不规范，加单词拼错)"
- "对啊，就是这样啊，没错啊"
然后我给他谷歌翻译一下，知道自己错了，又说
- "不要在意这些，能看懂就行"

还有很多其他的情况，反正总结一句，老有理。搞到最后还很敷衍的配合你一下，每次搞的都像我没事找事一样。其实问题都不大，扯 b 的时间早解决了。

需求：

特请教 V 友，怎么做能让平常关系融洽，但在某些情况下亦不失威严。已发现的问题有：个人经验不足，魅力不够。

小组长

注释

请教

背锅

27 条回复 • 2017-07-27 09:09:26 +08:00

Tonni

2017-07-26 12:08:03 +08:00

可不可以这样，先根据实际情况写一份开发编码规范，把经常遇到的问题规范化，配合对应的 Linter 在 Travis-CI 之类的工具里面做代码检查，然后使用 Code Review 机制，每个 PR 都要拿到至少 3 个 approval 才可以合并到 master 完成工作，这样可以让大家一起监督。

blankme

2017-07-26 12:10:09 +08:00 via Android

单词拼错还说不要在意，这是故意怼你吧。。

misaka19000

2017-07-26 12:10:36 +08:00 via Android

玩得好归玩得好，该严肃的时候就严肃，对事不对人

Nicoco

2017-07-26 12:11:57 +08:00

你给了他们什么？他们给了你什么？你们双方的付出，能让双方感到公平么？

LeoNG

2017-07-26 12:13:17 +08:00

@Tonni 恩，已经提出了规范，也下发到每个人了，新项目从一开始就有要求了。最近也在对老项目做重构，但是实行起来效果不理想。

LeoNG

2017-07-26 12:14:34 +08:00

@misaka19000 问题就是这样，你认真起来，他们以为你再挑毛病，满不在乎。好失败。。。。

LeoNG

2017-07-26 12:17:06 +08:00

@Nicoco 我能给的就是技术上的帮助支持，正规规范。工作啊，不应该都是要本着对项目负责么。。。双方公平是什么。。。

iislong

2017-07-26 12:56:49 +08:00 via Android

@LeoNG 既有了规范，必须执行起来，执行不到位的后果是怎样，没有后果只有规范是不行的

rason

2017-07-26 13:01:16 +08:00 via iPhone

搞技术的一般比较单纯，只服技术好的。

wingoo

2017-07-26 13:01:21 +08:00

0.需要上级支持
1.代码审核
2.不修改,交给其他人做

LeoNG

2017-07-26 13:02:34 +08:00

@iislong 恩，惩罚措施确实有遗漏。

jrtop

2017-07-26 13:02:49 +08:00 via iPhone

楼主你知道为什么一将功成万骨枯吗？为什么不是千骨、百骨？

JoeZing

2017-07-26 13:20:29 +08:00

1，问题上升，请求你的 leader 来协助，特别是需要在正式的场合上给予你这个小组里的话语权；
2，职责分明，切不可感情用事，对事不对人，需要小组有人来配合你，你来唱黑脸，要树立你的威信，而不是像往日一样跟大家打打闹闹，那是工作之外的事，跟大家明确目标，让大家站在同一战线上，那些不配合的，即使能力再好态度不配合的，把该问题上升给你的上级，让他出面协调，同时再观察..
3，给他施加压力，前提是需要合理，免得被反咬一口，同时你需要稳住你的气势，当 leader 气势和威信是最重要的，有了压力，他自然会坐镇不住，最后还是将问题上升，毕竟你还是个小 leader.

linzhang

2017-07-26 13:22:32 +08:00

参考一楼的建议，1.定规矩、包括对代码的规范，特别的利用好公司原有规定。2.对于你说的这种老油条的员工，就是害群之马，把他弄走，可以协调上级帮你处理，前提是你有人员解决方案（我就遇到这种的，跟他沟通，他不听，非要说有问题，我这不就是跟你沟通解决问题的嘛。连沟通的机会都不给我。。处于团队考虑，申请弄走他）。

abirdcanfly

2017-07-26 13:29:41 +08:00 via iPhone

管理的过程在某个方面来说是收集证据（事实）的过程，证据搜集到一定程度就可以刁人了；另外无伤大雅的事情别经常说别人

bk201

2017-07-26 13:30:35 +08:00

说明别人不服你，你自身水平未得到别人认可。
===
代码风格这种事情，对于刚进公司的可以这样纠正，对于老员工真的是不要纠结这种事情。小组长要带领团队做出让老板叫好的东西来，给团队更多的福利，别人自然会服你，惩罚什么的对于技术不是很烂的老员工都是浮云，你敢做我就敢走。

LeoNG

2017-07-26 13:44:39 +08:00

@bk201 代码风格不是我要抓，我知道代码风格这件事遵循团队的就 ok。但类似：`data`、`dataa`、`dataaa`、`radious (radius)`、`layou (layout)`、`protocoL` 这种的。我是实在看不下去了，所以提出来对老项目做规范。

LeoNG

2017-07-26 13:46:30 +08:00

@abirdcanfly "另外无伤大雅的事情别经常说别人",这个我会注意下。

hcymk2

2017-07-26 13:49:24 +08:00

规范只是自己定的么？有没有经过小组的相关人员讨论，并通过的？

Tonni

2017-07-26 13:51:19 +08:00

> 代码风格不是我要抓，我知道代码风格这件事遵循团队的就 ok。但类似：`data`、`dataa`、`dataaa`、`radious (radius)`、`layou (layout)`、`protocoL` 这种的。我是实在看不下去了，所以提出来对老项目做规范。

这猎奇的命名风格，干脆 var1, var2, fun1, fun2 算了 🐶

bk201

2017-07-26 13:54:42 +08:00

@LeoNG 对于这种果断开了啊，我不信写这种代码的技术能好到哪去。和上面谈谈，然后招人替换。

codermagefox

2017-07-26 14:00:07 +08:00

@LeoNG 你这算啥.同一个变量名,AutoModelID\AutoModelId\autoModelID\Aut0ModelID\autoModelID 都有,正确的应该是 autoModelId.所有带 ID 的都是重灾区,有些人认为是缩写两个都要大写,有些人认为是单词应该一大一小.你知道我一个做前端的碰到这样的接口有多绝望吗