AichiB7A

新的项目管理模式下我只想躺平,好难受

  •  1
     
  •   AichiB7A · Apr 22, 2025 · 3317 views
    This topic created in 388 days ago, the information mentioned may be changed or developed.

    在新的项目里工作了接近半年,总结了下这边“神奇”的项目管理模式,想看看大家怎么看这种工作模式。

    首先,整个项目管理被拆分成了每六周一个周期的模式,每六周内会保持一周一次发版的进度。整个团队每六周会规划一次未来六周要做的工作。

    之后,工作会被拆分成各个不同的领域,每个领域下,会组成各个不同的小的团队,需要注意的是这个团队并不是根据你的汇报线构成的,根据当前的业务需求,进行拆分重组的。例如,最近六周你和同事 A 一起在项目组甲,但项目组的负责人可能不是你的直线汇报领导。也可能到下一个周期,你和 A 就不在项目组甲了。你和 A 被拆散到了别的项目组中做一些完全和项目组甲中做的无关的事情。

    每个项目组会产生一个负责人,这个负责人可能没有领导经验,但出于业务需要成为负责人,负责这个小组内的信息汇总,进度跟踪等简单管理任务,TA 也会有一些开发/产品任务。这样每个领域下的各个小组就会产生各自的负责人,统一向这个领域内的负责人汇报,逐层汇总。

    这个模式我工作的感触:

    1. 信息冗余严重。一件事情会有各个小组的负责人加上你的直属领导信息间的同步,同时,大量的信息堆积在企业 IM ,而非开单追踪。典型的例子如一个工作会在企业 IM 四五个群内被反复提及,但群里的人并不是一批人。

    2. 几乎所有人考虑的都是眼前六周的事情能不能做完。因为每六周就会检查进度,同时规划下个周期的工作。没几个人说的清楚未来半年内需要干啥,项目会向哪里发展,更不用说未来一年的工作重心。团队包括我领导在内多少有一种“先活过这周”的心态工作,完全不看远期安排(直到周期结束后的规划阶段)

    3. 项目维护成本高。因为这种定期的人员工作内容大调整,可能上个周期里做这部分工作的开发,下个周期就离开做别的了,如果出现问题需要修复或维护,实质上是当前周期被分配到这块的小组去解决的。

    4. 打杂严重。这六周做 A ,下个六周做 B. 最后自己写考核报告发现自己半年都做不出一个完整的东西,全是打杂。

    虽然大家都说大环境很差,不要随意跳槽,更不要裸辞。但在一个让自己每天很沮丧,早上到公司打开电脑就觉得很委屈的工作环境中也是很煎熬的。

    当下的这个六周周期走了一半,中间算上五一假期,六分之一直接没了。看着项目进度已经落后,但我心中已经毫无波澜,甚至有种行将就木的麻木感。

    16 replies    2025-04-24 21:21:15 +08:00
    253874
        1
    253874  
       Apr 22, 2025
    这是要搞敏捷开发吧,对人员管理能力、沟通能力要求比较高
    YJi
        2
    YJi  
       Apr 22, 2025
    看起来是要搞敏捷
    yidinghe
        3
    yidinghe  
       Apr 22, 2025 via Android   ❤️ 2
    既然帖子里没提到代码复审,那么就意味着项目质量完全无法保证:只要能在这个周期内不测出问题能交付,之后就算天崩地裂也不关我的事,于是各种匪夷所思的设计都会出现。
    sillydaddy
        4
    sillydaddy  
       Apr 22, 2025
    这样做的“理由”是什么?

    很多公司管理层做决定,从来不会“解释”所做决定的愿景、目标、可行性,最好的情况也就是“宣传贯彻”一下。但是却总是要求下面的人“汇报”、“总结”、“反省”。这在我看来是典型的权责利不对等。这些管理流程影响到了每一个员工,就应该向他们“解释”、“汇报”具体的缘由、执行情况,并收集反馈,而不是仅仅对一个 BOSS 负责。

    不过我记得 OP 是在微软啊,也是这样么?
    liudewa
        5
    liudewa  
       Apr 22, 2025
    five year plan
    sillydaddy
        6
    sillydaddy  
       Apr 22, 2025
    再解释一下为什么仅仅对 BOSS 负责是不够的:
    权责利对等的基本含义是,使用手中权力所做出的一切决定,都要承担对应的后果和责任。但是很多情况下,使用手中的权力做出某些事情,其引发的影响或损害之大之广,并不是一个简单的去职、辞退就能弥补的,因为损害已经造成了,而且管理层的利益和执行层的利益是不一致的,无论是谁做管理层,都没有理由相信这些损害会对他们产生对等的责任。简而言之,管理层根本无法“补偿”其权力任性造成的损害。
    所以,一个合理的机制就是,制约管理层的权力范围,让他们不能行使那种会造成无法“弥补”损害的权力,这里“弥补”指的是担负责任,通常也就是去职、辞退、剥夺奖金这些手段,这也是对管理层能做到的最大惩罚了。
    AichiB7A
        7
    AichiB7A  
    OP
       Apr 22, 2025   ❤️ 1
    @sillydaddy 是这帮新来的空降微软的搞得管理模式,之前在微软的管理模式不是这样的,就像你说的,他们会给你更多的上下文,告诉你为啥要做。现在则是一路拆分到最后(就像我说的项目组拆分),每个人做那么一点事,几个人加一起也拼不齐上下文。
    现在确实是有很多权责利不对等的情况,更具体的来说甚至很多权限都不放开给到我们,完全是这帮人自己玩自己的,我的直属领导甚至有时都觉得无能为力。我也人微言轻,说不出啥。
    AichiB7A
        8
    AichiB7A  
    OP
       Apr 22, 2025
    @yidinghe 与其说代码复审,不如说留个文档就了事。最大的问题还是周期的规划,只要周期内不出问题,皆大欢喜,庆祝一下就了事。过了周期出了事又跟我何关?
    flmn
        9
    flmn  
       Apr 22, 2025
    这种项目挺好混的,看公司的状态(是否盈利,是否垄断),和个人状态(想舒服,想发财)。
    AichiB7A
        10
    AichiB7A  
    OP
       Apr 23, 2025
    @flmn 能讲讲怎么混吗?如果只是想个人舒服赚点钱的话
    HENQIGUAI
        11
    HENQIGUAI  
       Apr 23, 2025
    只要没有责任心,就不会很难受
    cutecore
        12
    cutecore  
       Apr 23, 2025
    我们两周一个周期才叫扯
    kuhung
        13
    kuhung  
       Apr 23, 2025
    feature team ?看起来你们之前更像是情景管理啊,多好的路子咋不做了。
    xsen
        14
    xsen  
       Apr 24, 2025
    @timeisweapon 敏捷几乎没有一周一发版的,最短起码 2 周,一般一个月一个版本
    yyj08070631
        15
    yyj08070631  
       Apr 24, 2025   ❤️ 1
    每个领域下,会组成各个不同的小的团队,需要注意的是这个团队并不是根据你的汇报线构成的,根据当前的业务需求,进行拆分重组的
    ===================
    这个事情本身看着没什么问题,实线还是技术线,只是会拉项目群

    1.信息冗余严重
    ===================
    这是你们汇报流程的隐性问题,没有人规定项目进度要不要汇报给实线 leader ,汇报周期是什么,所以就导致项目组和实线 leader 都要实时汇报,搞得很累。我理解项目的事情本来就只需要同步项目组,leader 周报跟进一下就够了,这个问题,如果总监知道,应该总监制定相关规定,给经理去落地

    2.几乎所有人考虑的都是眼前六周的事情能不能做完
    3.项目维护成本高
    4.打杂严重
    ===================
    总结下来都是未来规划不明确的问题,这可能是老板或者高管在业务上或者技术上的蓝图不明确,也可能是总监的上传下达出了问题,导致经理和一线都不知道要搞这套项目管理的目的,未来会怎么演化,而总监大概率又疯狂的 pua 经理,导致经理过于焦虑,无法考虑更多,这样传导到一线就产生了你的体验

    总结:大概率是总监的规则设计、传达、沟通方式不到位,小概率是老板或者高管发疯
    AichiB7A
        16
    AichiB7A  
    OP
       Apr 24, 2025
    @yyj08070631 单看小团队这点是挺好。真正参与到这种管理风格前我也期待小团队的方式。

    汇报流程的隐性问题使得一线都在疲于汇报,把事情做的看起来好看,确保大家能“皆大欢喜”。另一方面实线和技术线都可能会参与到解决方案的讨论,给一些自己的“建议”,经常出现一件事情一个人干但是产品经理,实线经理,项目组骨干,项目组负责人四个人各自给”意见“的情况。

    同时,目前这个管理风格是公司高管层上一家公司的项目管理方式,既不是我总监决定,更不是我经理决定。为了推进项目合作,有些交流沟通的摩擦成本(例如权限分配,资源分配等)我经理也解决不了,只能项目组的负责人一个个去聊,还不能保证这些项目组下个周期还在,也不保证下个周期这些人还是负责人。现在只能我们一点点去磨,经理也表现出很多负面情绪,但她又解决不了实际问题。作为 devops ,竟然争取不到运维资源的管理员权限,我也是不知道该说啥好。

    这几天”磨“下来感觉自己心气又少了很多,戾气重了不少,汇报也开始瞎写了。

    最近开始写绩效回顾了,公司的绩效回顾和 OKR 规划却又是半年的周期,回望过去半年自己做的事情散落一地拼凑不出一个完整的故事,展望未来又看不到未来半年的蓝图。就这样吧,可能没有责任心就不会难受。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   2902 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 58ms · UTC 12:02 · PVG 20:02 · LAX 05:02 · JFK 08:02
    ♥ Do have faith in what you're doing.