这是一个创建于 3051 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景：
公司让我做小组长，主要是负责项目的进度和背锅，也是第一次管理人，因为人数少，我也对小组长的头衔也没看太重。大家一起快乐的码代码才是最重要。平常也玩的比较好。但是在项目上，有个人就是不配合你(老员工，比我来的早)，比如说:
- "这地方注释为啥不写"
- "写啥注释，都能看的懂"
- "这地方变量名怎么这么写(大小写不规范，加单词拼错)"
- "对啊，就是这样啊，没错啊"
然后我给他谷歌翻译一下，知道自己错了，又说
- "不要在意这些，能看懂就行"
还有很多其他的情况，反正总结一句，老有理。搞到最后还很敷衍的配合你一下，每次搞的都像我没事找事一样。其实问题都不大，扯 b 的时间早解决了。
需求：
特请教 V 友，怎么做能让平常关系融洽，但在某些情况下亦不失威严。已发现的问题有：个人经验不足，魅力不够。
公司让我做小组长，主要是负责项目的进度和背锅，也是第一次管理人，因为人数少，我也对小组长的头衔也没看太重。大家一起快乐的码代码才是最重要。平常也玩的比较好。但是在项目上，有个人就是不配合你(老员工，比我来的早)，比如说:
- "这地方注释为啥不写"
- "写啥注释，都能看的懂"
- "这地方变量名怎么这么写(大小写不规范，加单词拼错)"
- "对啊，就是这样啊，没错啊"
然后我给他谷歌翻译一下，知道自己错了，又说
- "不要在意这些，能看懂就行"
还有很多其他的情况，反正总结一句，老有理。搞到最后还很敷衍的配合你一下，每次搞的都像我没事找事一样。其实问题都不大，扯 b 的时间早解决了。
需求：
特请教 V 友，怎么做能让平常关系融洽，但在某些情况下亦不失威严。已发现的问题有：个人经验不足，魅力不够。
 | 1 Tonni 2017-07-26 12:08:03 +08:00  1 可不可以这样，先根据实际情况写一份开发编码规范，把经常遇到的问题规范化，配合对应的 Linter 在 Travis-CI 之类的工具里面做代码检查，然后使用 Code Review 机制，每个 PR 都要拿到至少 3 个 approval 才可以合并到 master 完成工作，这样可以让大家一起监督。 |
 | 2 blankme 2017-07-26 12:10:09 +08:00 via Android 单词拼错还说不要在意，这是故意怼你吧。。 |
 | 3 misaka19000 2017-07-26 12:10:36 +08:00 via Android 玩得好归玩得好，该严肃的时候就严肃，对事不对人 |
 | 4 Nicoco 2017-07-26 12:11:57 +08:00 你给了他们什么？他们给了你什么？你们双方的付出，能让双方感到公平么？ |
 | 5 LeoNG OP @Tonni 恩，已经提出了规范，也下发到每个人了，新项目从一开始就有要求了。最近也在对老项目做重构，但是实行起来效果不理想。 |
| 6 LeoNG OP @misaka19000 问题就是这样，你认真起来，他们以为你再挑毛病，满不在乎。好失败。。。。 |
 | 9 rason 2017-07-26 13:01:16 +08:00 via iPhone 搞技术的一般比较单纯，只服技术好的。 |
 | 10 wingoo 2017-07-26 13:01:21 +08:00 0.需要上级支持 1.代码审核 2.不修改,交给其他人做 |
 | 12 jrtop 2017-07-26 13:02:49 +08:00 via iPhone 楼主你知道为什么一将功成万骨枯吗？为什么不是千骨、百骨？ |
 | 13 JoeZing 2017-07-26 13:20:29 +08:00 1，问题上升，请求你的 leader 来协助，特别是需要在正式的场合上给予你这个小组里的话语权； 2，职责分明，切不可感情用事，对事不对人，需要小组有人来配合你，你来唱黑脸，要树立你的威信，而不是像往日一样跟大家打打闹闹，那是工作之外的事，跟大家明确目标，让大家站在同一战线上，那些不配合的，即使能力再好态度不配合的，把该问题上升给你的上级，让他出面协调，同时再观察.. 3，给他施加压力，前提是需要合理，免得被反咬一口，同时你需要稳住你的气势，当 leader 气势和威信是最重要的，有了压力，他自然会坐镇不住，最后还是将问题上升，毕竟你还是个小 leader. |
 | 14 linzhang 2017-07-26 13:22:32 +08:00 参考一楼的建议，1.定规矩、包括对代码的规范，特别的利用好公司原有规定。2.对于你说的这种老油条的员工，就是害群之马，把他弄走，可以协调上级帮你处理，前提是你有人员解决方案（我就遇到这种的，跟他沟通，他不听，非要说有问题，我这不就是跟你沟通解决问题的嘛。连沟通的机会都不给我。。处于团队考虑，申请弄走他）。 |
 | 15 abirdcanfly 2017-07-26 13:29:41 +08:00 via iPhone 管理的过程在某个方面来说是收集证据（事实）的过程，证据搜集到一定程度就可以刁人了；另外无伤大雅的事情别经常说别人 |
 | 16 bk201 2017-07-26 13:30:35 +08:00 说明别人不服你，你自身水平未得到别人认可。 === 代码风格这种事情，对于刚进公司的可以这样纠正，对于老员工真的是不要纠结这种事情。小组长要带领团队做出让老板叫好的东西来，给团队更多的福利，别人自然会服你，惩罚什么的对于技术不是很烂的老员工都是浮云，你敢做我就敢走。 |
| 17 LeoNG OP @bk201 代码风格不是我要抓，我知道代码风格这件事遵循团队的就 ok。但类似：`data`、`dataa`、`dataaa`、`radious (radius)`、`layou (layout)`、`protocoL` 这种的。我是实在看不下去了，所以提出来对老项目做规范。 |
| 18 LeoNG OP @abirdcanfly "另外无伤大雅的事情别经常说别人",这个我会注意下。 |
 | 19 hcymk2 2017-07-26 13:49:24 +08:00 规范只是自己定的么？有没有经过小组的相关人员讨论，并通过的？ |
| 20 Tonni 2017-07-26 13:51:19 +08:00 > 代码风格不是我要抓，我知道代码风格这件事遵循团队的就 ok。但类似：`data`、`dataa`、`dataaa`、`radious (radius)`、`layou (layout)`、`protocoL` 这种的。我是实在看不下去了，所以提出来对老项目做规范。 这猎奇的命名风格，干脆 var1, var2, fun1, fun2 算了 |
 | 22 codermagefox 2017-07-26 14:00:07 +08:00 @LeoNG 你这算啥.同一个变量名,AutoModelID\AutoModelId\autoModelID\Aut0ModelID\autoModelID 都有,正确的应该是 autoModelId.所有带 ID 的都是重灾区,有些人认为是缩写两个都要大写,有些人认为是单词应该一大一小.你知道我一个做前端的碰到这样的接口有多绝望吗 |
 | 23 Ironsongming 2017-07-26 16:02:49 +08:00 一看 lz 就没管过人，你还问为啥为啥，你凶他一回，然后让他自己解释，他自己就圆不回来了 |
| 24 Ironsongming 2017-07-26 16:19:21 +08:00 关系融洽的话，除非你有恩于他，不然这种心里不平衡的员工，你说再多也没用 |
 | 25 dy1778299755 2017-07-26 22:17:11 +08:00 via iPhone @wingoo 标准的程序员回复 |
 | 26 lalalafq 2017-07-27 09:08:57 +08:00 在这种情况下，一定要坚持你合理的地方。lz |
| 27 lalalafq 2017-07-27 09:09:26 +08:00 @Ironsongming 23 楼说的有道理。 |
Select Language