• spark
    2020-12-16
    我一般能用计划的30%时间完成我负责的任务,其他时间要么没事干、要么项目的代码都是我在Review,其他兄弟们加班累死累活、延迟交付且质量不高。 我做事的方法: 1.向领导学习(让领导替我想想办法如何完成的快和好):做事前对齐目标,路径。和领导沟通如何更快完成任务,领导的效能至少比我高3倍5倍。这样就算最后完不成,领导也不能说我偷懒和能力问题,我预先把风险和问题和领导沟通清楚了。 2.做事需要经过专业人士的训练才行,训练前后差距可以是10倍的效能。 我一直从CEO角色角度看待我的工作的价值。手里写着代码,脑里思考着业务如何成功,企业如何存活和发展。

    作者回复: 你好,spark 你太棒了,真的很棒,领导应该提拔你才对。

    共 3 条评论
    27
  • 流浪地球
    2020-12-17
    请教乔老师一个问题,文中提到了项目经理在一个项目成败中的重要性,自己感同身受,有个问题是项目经理在一个团队中的职权范围应该是怎样的,或者更直接的说地位应该摆在什么高度。经历过的2个团队 1、pm职权范围极大,在制作人一人之下,对整个团队成员有考核权。但问题是这个角色本身的技术专业度不够深,和技术leader,产品leader很容易产生摩擦,团队成员往往更愿意听命于自己的专业线leader,觉得pm瞎指挥,就是个监工。 2、pm权职范围有限,仅做排期沟通的相关工作,没有考核权,这样他们的威信很低,往往指挥不动人。 这个问题该如何解决比较好,难道一个好的pm一定是一个优秀的产品专家和技术专家吗?谢谢

    作者回复: 你好,流浪地球 实际是靠团队。 在项目启动中,一个项目要明确PM-项目经理,PM-产品经理,架构师,专才,项目启动就是明确各自职责。 从公司层级,项目启动的时候,项目所有人要听PM的安排,PM要充分发挥以上四种角色的专业,一起制定项目的WBS。 所以权力在项目启动的时候赋予了项目经理,项目启动会其中一个最重要的目的是赋予项目经理权力,否则那不是项目经理,而是项目助理。

    
    6
  • Weehua
    2020-12-18
    我作为技术管理者,感受最大的就是项目排期,总是和业务方或者老板博弈。如果坚持自己原定的排期,有些重要需求确实对业务来说很重要(比如双11或双12搞活动),这个时候只能压缩排期,只能加班了,但确实有些需求不符合客观规律,或者如果按时交付但质量不行也经常出现,最后会损害团队声誉,有时候也是各方逼迫的。 我学习之后的感受: 1. 要在专业的方面说出各种限制,提出风险,在全局思维给出合理的建议,和业务一起想办法解决问题,如果只考虑技术而不考虑业务,是不负责任的。让自己变得专业,别人才能相信你。 2. 有时候做业务限制是非常有效的手段,可以在技术架构和实现方面节省很多,比如:业务想查询一个数据报表,大部分情况查询三个月的数据足够了,限制查询时间可以大大提高用户的体验(特别是涉及到精确排重,数据量大的时候),对于大范围的时间查询可以离线或异步进行。

    作者回复: 你好,Weehua 从业务发展出发,和业务一起讨论共赢方案。考虑限制,和业务讨论限制,是对业务更负责任的态度,相信时间会证明自己,业务会理解,双方的信任也会越来越强。

    
    5
  • 子夜枯灯
    2020-12-16
    老乔讲的内容干活满满。化为己用,会是听完课程优先需要考虑怎么落地首要问题。

    作者回复: 你好,子夜枯灯 谢谢,学以致用很重要,都掏钱学习了,一定要用起来

    
    2
  • 术子米德
    2020-12-20
    🤔☕️🤔☕️🤔 有一种限制,也很致命,那就是大家对于项目本身可能遇到的问题的认识,这个认识本身就是一个关键约束 如果遇不到啥大问题,大概率这个项目本身比较平庸;如果这个项目有挑战,那么很多问题就是在项目开展过程里,才会遇到、才开始真正处理到挑战点。这时候往往出现认知不一致的矛盾。 如果大家都认可,这是项目调整引起的问题,由此而导致项目延期,甚至无法继续,那已经是认知很对齐,也是理想情况。 更多时候,大概率的PM会越来越盯紧架构师,直到最终说出来,作为架构师为啥没考虑到这些约束呢? 好了,此时所谓的约束,甚至有点埋怨,又有点甩锅性质的约束,实际上就是刚开始认知不一致的约束埋下的种子。

    作者回复: 你好,术子米德 你提的这个问题的解决,要在管理三板斧的目标对齐解决,如果目标对不起,专业复盘中提的问题都没有根。 专业会变成出现问题时扯皮的资本,根基不稳,一切都没了基础,这也是专栏组织的一个考虑点。

    
    1
  • glutton
    2020-12-16
    乔老师讲的,总能让我有通透的感觉 放在个人成长上,"知不可为"(考虑限制)可能比"知可为"更重要。之前一直忽略了这点。 又值得反复读的一课,感谢乔老师持续输出高质量干货。

    作者回复: 你好,glutton 谢谢,感谢你的陪伴

    
    1
  • 张浩
    2021-07-22
    要深刻理解时间、资源、范围这个铁三角,在限制内做到最好,谢谢乔老师分享。

    作者回复: 你好, 张浩 聚焦,舍弃,人生必修课

    
    
  • 罗小黑
    2021-07-01
    这一课讲到痛点了。我想IT人几乎都有“疯狂赶进度”的经历吧~ 从业务和技术两方面入手,寻找解决办法,有被启发到。感谢老乔

    作者回复: 你好,罗小黑 加油加油

    
    
  • 小白条
    2021-06-25
    项目管理的本质是消除不确定性;项目管理不是为了管,而是为了不管。

    作者回复: 你好,小白条 你get到了要点。

    
    
  • leslie
    2021-03-07
    "交付的领导视角":这个可能是大多数初中级管理者在早期不会去思考的事情,中层其实就是向上理解向下梳理。

    作者回复: 你好,leslie 总结的好。

    
    