如何稳定项目组前端组员的情绪以及应对措施

687 阅读7分钟

我自己的博客原文

@author: 郭瑞峰

@createTime: 2024/02/07

@updateTime: 2024/02/18

前言

本来在2023年年末写完这篇文章的,但想着大家满脑子都是放假,所以说就延后发布了,毕竟想回家的大家哪会看这类文章嘛。

写这种管理类的文章需要理很多东西,以及还得斟酌一下观点,不然评论区就要开炮了......

注意哈,这个是我的个人经验,并不能代表你能这么玩,所以说请注意哈。

关于情绪

先稳住自己,再稳定团队,最后再说给组员提供情绪价值

咱细说哈,先让自己情绪稳定,再让团队情绪稳定,这个很关键,很重要。先来几个轻松的视频,让各位看官老爷看看什么是情绪稳定

对了,我是说向卷宝,那只猫学习,不是让你学人的哈,人有啥好学的?

情绪稳定才好处理工作。~~对上可以冷静甩锅,~~对下降低了解风险的成本(这个是我个人所感),毕竟相对于劈头盖脸而言,大家会倾向于情绪稳定的人问一下或诉说一些东西,而这里面可能就会有风险;当然如果问的是一些基础问题的话还是建议组员百度一下吧。

ba2467119ccfb13ea4f94bd1a4327df841a286355cf9a5214ca8d64e97c213d9 (1).png

关于加班

没有谁不想玩耍,所以说被抓来加班时火气都大

  1. 注意这个是我在二级国企三年的感觉,做法或者结果是基于我当前状况的,不一定是正解
  2. 让人无偿加班是个雷区,但咱工作不一定能完全避免,若是觉得不合理或者不能理解,直接在评论区说或者教我做人
  3. 你要是有合理的处理办法或者怎样,请在评论区说一下

这个我犹豫了很久,要不要写,即使前面叠甲了,现在还得再叠一次:这个是基于我在二级国企上班三年的感觉,不一定适合其他公司,尤其是外企!

先说一下我的身份牌,基层leader,无权无势,就一个发言权,还只是项目的需求会议、评审会议、研发会议的意见参考。所以说我会安排加班么?我能避免加班么?我能说不么?

若是个人加班就个人加班,大不了晚上去多跑两圈,但,但,但若是得安排下属加班呢?不仅不能说不,还得执行下去,而且属下的怨气优先指向你本人,先**“情绪稳定地接受”吧,再想办法安抚下属以及转移怨气**。

其二就是以身作则,为啥会有这个东西呢?说简单点就是你得走得最晚不管是真有事儿还是没有事儿,都必须走的最晚。有的时候组长/leader催你下班是因为他/她真的想下班,所以说赶紧撤吧,别再加班了,对大家都好。

分享一下两个遇见的加班情况,我结合我自己的情况做出选择,看官也可以根据自身情况说一下自己遇见的加班情况或者发表一下自己的看法:

event overtime.1

  • 事件:业主需要公司五天内提供可行性许可文件
  • 任务:(任务上午发布)今天内必须将集成系统技术书整理成可行性许可文件
  • 其他条件:集成系统技术书和文件相似度高,但内容量多
  • 执行:(写一下你的思路或者你当前职位的操作)

我的处理

  • 执行:
    • 忽视任务:
      • 收益:无
      • 风险:
        • 该项目不会有后续如收益等事项
        • 自己有可能被清场,并且会有相关官司
      • 风险过高,且影响本人月收入
    • 执行任务:
      • 工作分发(文档划分,按模块分配)
      • 先完成的允许休息一会儿,之后继续分配剩余文档
      • 安抚工具(预计120¥):
        • 中午:有食堂,忽略
        • 下午:瑞幸,预计120¥
        • 晚上:有食堂,晚餐忽略

event overtime.2

  • 事件:下周一工程项目进行厂验
  • 任务:周六周日必须解决/关闭所有bug
  • 其他条件:集成系统技术书和文件相似度高,但内容量多
  • 执行:(写一下你的思路或者你当前职位的操作)

我的处理

  • 执行:
    • 执行之前:前端bug量有限,不需要全部人马一起加班,是否通融
      • 收益:
        • 降低组员不满
        • 节约我的安抚费用
      • 风险:
        • 需要配合后端的人员不一定在场
      • 可以实行,提出建议
      • 结果:两人周六上班,两人周日上班,我除外
    • 执行任务:
      • bug已经指向对应人员,无需额外分配
      • 安抚工具(预计220¥):
        • 中午:负一楼水饺,预计120¥
        • 下午:奶茶,预计100¥
        • 晚上:自行安排

99ff27687a0264218a189159791cada62c0d8b2ecd2f3d13281fd6f076287691.png

关于手段(trick)

我讨厌使用手段,也讨厌使用手段的人,现在我成了我自己讨厌的人了

注意了,这也是雷区,这个也是我当上小组长后自己实践来的,不一定适用于所有人!若是觉得不适,欢迎在评论区评论或者教我做人。

所以说我不喜欢当小组长(本来想说leader的,但说基层领导还不如说小组长接地气呢),要用手段,即使我才当了快两年的小组长。先说一下使用手段风险和收益吧:

  • 风险:
    • 被发现后会出现上下信任危机
    • 被发现后个人风评会下降
  • 收益:
    • 成功实施后会稳定当前局势

同样的,分享一下两个手段,看官也可以根据自身情况说一下自己使用手段的情况或者发表一下自己的看法,不胜感激:

event trick.1

  • 事件:手下有个小伙儿尥蹶子了,不想再干当前项目了
  • 手段:(写一下你的思路或者你当前职位的操作)

我的处理

  • 手段:
    • 行动前:
      • 确认隔壁项目组缺前端人员
      • 风险:
        • 缺少一个人力
        • 后续其他人也许也会闹腾
      • 收益:
        • 暂时稳定项目组前端组情绪
      • 稳定为优先级,手段可行
    • 行动:
      • 与项目组PM商里,确定转移
      • 与隔壁项目组PM商里,确认转移
      • 与个人商里,同意转移
      • 结束当前任务后,转移

event trick.2

  • 事件:与现场产品部门确认,30个需求只做18个
  • 手段:(写一下你的思路或者你当前职位的操作)

我的处理

  • 手段:
    • 需要项目组PM和产品一起配合
    • 行动前的计划:
      • 告诉项目组成员,我们有30个新需求
      • 两天后的后续会议动员项目组成员,给PM和产品打气,“希望”他们能砍点需求
      • 会后让产品“告诉好消息”
      • 第一个带头鼓掌
    • 风险:
      • 被上面发现会被批评
      • 利用信息不对等的使用,被发现后会只有你一个人背下所有
    • 收益:
      • 稳定项目组情绪
      • 增加项目组对PM、产品好感
      • 增加在项目组中发言重量
    • 个人判断收益大于风险,可以执行
    • 行动

4d8ffdda9c3058ca9e54c57343aea211ad1629bd14905660a660aa752d7715fb.png

结尾

人就如同忒修斯之船,拆拆补补继续航行。曾经嘲笑他人船只破破烂烂,如今看,就像过去的自己嘲笑现在的自己。不喜欢的样式、不喜欢的方式、不喜欢的东西最后都会为了对抗岁月的斧凿,一点一点地加上去,再一点一点地嵌入船中,最后一点一点忘记它曾经的模样。

d0d0a9badc88da2ae22b872cf333482c68f4f2f583a50151a21a536123fd0fe0.png