Open zw334 opened 4 years ago
Q1：我现在遇到的问题，项目的问题有的临时能解决，有的是偶发的，有的是需要资源到位才能解决的。自始至终捋了大表，每周过问题大表，但是明显大家对于已知的问题内心是排斥的，对于问题TOP前几的解决，总感觉是自己本职工作之外的工作。做好了不加分，做不好赖在手里。所以很鸡肋。有更好的规则或技巧分享不？ A1：加强持续性跟进 A2：开除一个就知道了，这不就是考核不清么，清不掉大问题整体部门扣绩效，解决问题的时候算贡献占比，就都老实了 Q2：这个目前可能不适用团队。团队现在几乎996，人员复用，满岗饱和。一部分大家排斥的原因是，因为活儿太多了。从我的角度，在这种高压情况下，团队关注点 顾及不过来问题的处理。有考核有激励，但就还是顾不过来。 A1：先不提考核，先说优先级，明显这些问题优先级都是低的，大家满负荷去做高优先级的内容了，当然没人关注这个了 Q3：但是又想推动，不能让问题束之高阁，如何操作？这里面很多问题都是那种线上 jvm 、gc这种，需要多方面排查，分析，一下子不一定有思路的老大难问题。也有规则，问题不能挂超过一个月。但是落到底，执行上还是不太给力，这种不确定老大难问题堆的多了，看着大家都烦恼。 A1：大家包含哪些人？（产品 开发 测试）产品定优先级，纳入统一需求管理， A2：高压状态如果没有奖，最终就会变成超高速造bug，将来是还不完的技术债。能让团队高压状态下保证质量的两大法宝，现在的钱和远期的钱。 A3：老大难，可以专门抽一个人解决。大家手里都有自己的事情 是不会愿意碰老大难的，不然 要费很大精力，本来手里的事情还做不完。这是一个定位的问题，有些员工更愿意做技术， 找一两个技术比较好的，偏架构师角色，解决老大难的过程 也是一个提高自己的过程。年终考核的时候 除了业务产出，也看技术产出，如果公司考核不考虑这些，那没人愿意接也可以理解 A4：容易激化矛盾，老板不这么看，老板只能觉得你们交付的就是这么些，我看不到你们能创造更多价值。主要还是上面能不能想清楚的事，实际情况是，有这个意愿的员工不会留在那里自虐啊，系统问题是最恶心的。对于自己的团队而言，还是每个月得做一次根因，争取找到现有问题不需要加人的解决方案 A5：为什么要替别人擦屁股？让别人去新项目做更有价值的事？修问题没啥价值的 Q4：特别挠头，在问题识别暴露方面我们做的很好。问题基本不会丢，也会有人做初步的分析。但是就是落实到解决这一环，落不下去。我在想对于问题跟进，执行落地上有没有好的办法？ A1： 价值优先级排序，研发团队的问题，天天骂业务需求没价值，其实自己想做的也没有价值。 A2：解决这环找到负责人，让他汇报。程序员延期没有感觉的，负责人却不会和老板说忙啊什么的。直接组专项会议，拉大老板，确认研发的负责人，他会有办法解决的。总监级就是要解决问题的， 如果负责人这种态度，底下人这样不足为奇。 A3：系统问题，不是简单地人能解决的，积重难返的时候，大头看不清很正常，不愿意听也是常态，有作为想法的中间层很难作为。 A4：要我会选择 支持研发团队的做法，因为做了根本没价值。 自上而下都认为没有价值，何必去解决。居然是老大难问题，那就不是问题，不要把研发团队的人力浪费在没有意义、低价值的事情上。 A5：不值得就拖着吧，值得就加入目标绩效，优先级放最高 A6：你和业务需求的价值比较一下，有价值要专门安排资源，想大家短期顺手做掉，谁不都会接。不要感觉有价值，优化后，能给业务带来多少价值，效率改善多少，你能出个报告吗？ Q5：第一，有没有那种对于老大难问题的跟进比较好的工具+方法的结合？第二，人员饱和状态下，如何推进重要不紧急事宜的推进？ A1：你不去设法阻塞紧急不重要的事，就永远饱和啊，回到问题一了，只有你认为重要。 A2：这种事情 压到开发手里 很容易负能量。 A3：重要不紧急的事有2个解决方案：1、团队里有上进心的人额外做了 2、等变成重要且紧急的时候就可以做了 A4：游说 慈善家，给出点自己的时间和爱心， 还是有可能的，然尔，现在的软件改造不是某个人能搞定的，还有一堆质量保障的工作要做。开发完了也不能上线。 A5：你要把自己当做是内部销售，老板需求什么，团队需求什么，你自己需求什么，顺着需求来，逆势搞不定的。 A6：996的话，好多问题都爆发出来了，还是得先解决996的问题 A7：这种问题一般都会影响用户体验，比如时常oom，宕机等。我们之前的经验是定义企业故障级别，这种一般是p0级，配合kpi，要求这样的问题必须当天解决。这个对团队的压强很大，所以解决都很及时。但是有时因为团队的能力所限不可能都解决了，但是解决一个通常会解决一大片问题，难题都是有关联性的。有个实际的例子。之前接手一家公司产品技术团队，jira上有700多bugs。为了让团队解决技术债，规定每个星期每个团队必须解决30个bugs。从优先级高的开始，到年底都归零了。
Q1：我现在遇到的问题，项目的问题有的临时能解决，有的是偶发的，有的是需要资源到位才能解决的。自始至终捋了大表，每周过问题大表，但是明显大家对于已知的问题内心是排斥的，对于问题TOP前几的解决，总感觉是自己本职工作之外的工作。做好了不加分，做不好赖在手里。所以很鸡肋。有更好的规则或技巧分享不？ A1：加强持续性跟进 A2：开除一个就知道了，这不就是考核不清么，清不掉大问题整体部门扣绩效，解决问题的时候算贡献占比，就都老实了 Q2：这个目前可能不适用团队。团队现在几乎996，人员复用，满岗饱和。一部分大家排斥的原因是，因为活儿太多了。从我的角度，在这种高压情况下，团队关注点 顾及不过来问题的处理。有考核有激励，但就还是顾不过来。 A1：先不提考核，先说优先级，明显这些问题优先级都是低的，大家满负荷去做高优先级的内容了，当然没人关注这个了 Q3：但是又想推动，不能让问题束之高阁，如何操作？这里面很多问题都是那种线上 jvm 、gc这种，需要多方面排查，分析，一下子不一定有思路的老大难问题。也有规则，问题不能挂超过一个月。但是落到底，执行上还是不太给力，这种不确定老大难问题堆的多了，看着大家都烦恼。 A1：大家包含哪些人？（产品 开发 测试）产品定优先级，纳入统一需求管理， A2：高压状态如果没有奖，最终就会变成超高速造bug，将来是还不完的技术债。能让团队高压状态下保证质量的两大法宝，现在的钱和远期的钱。 A3：老大难，可以专门抽一个人解决。大家手里都有自己的事情 是不会愿意碰老大难的，不然 要费很大精力，本来手里的事情还做不完。这是一个定位的问题，有些员工更愿意做技术， 找一两个技术比较好的，偏架构师角色，解决老大难的过程 也是一个提高自己的过程。年终考核的时候 除了业务产出，也看技术产出，如果公司考核不考虑这些，那没人愿意接也可以理解 A4：容易激化矛盾，老板不这么看，老板只能觉得你们交付的就是这么些，我看不到你们能创造更多价值。主要还是上面能不能想清楚的事，实际情况是，有这个意愿的员工不会留在那里自虐啊，系统问题是最恶心的。对于自己的团队而言，还是每个月得做一次根因，争取找到现有问题不需要加人的解决方案 A5：为什么要替别人擦屁股？让别人去新项目做更有价值的事？修问题没啥价值的 Q4：特别挠头，在问题识别暴露方面我们做的很好。问题基本不会丢，也会有人做初步的分析。但是就是落实到解决这一环，落不下去。我在想对于问题跟进，执行落地上有没有好的办法？ A1： 价值优先级排序，研发团队的问题，天天骂业务需求没价值，其实自己想做的也没有价值。 A2：解决这环找到负责人，让他汇报。程序员延期没有感觉的，负责人却不会和老板说忙啊什么的。直接组专项会议，拉大老板，确认研发的负责人，他会有办法解决的。总监级就是要解决问题的， 如果负责人这种态度，底下人这样不足为奇。 A3：系统问题，不是简单地人能解决的，积重难返的时候，大头看不清很正常，不愿意听也是常态，有作为想法的中间层很难作为。 A4：要我会选择 支持研发团队的做法，因为做了根本没价值。 自上而下都认为没有价值，何必去解决。居然是老大难问题，那就不是问题，不要把研发团队的人力浪费在没有意义、低价值的事情上。 A5：不值得就拖着吧，值得就加入目标绩效，优先级放最高 A6：你和业务需求的价值比较一下，有价值要专门安排资源，想大家短期顺手做掉，谁不都会接。不要感觉有价值，优化后，能给业务带来多少价值，效率改善多少，你能出个报告吗？ Q5：第一，有没有那种对于老大难问题的跟进比较好的工具+方法的结合？第二，人员饱和状态下，如何推进重要不紧急事宜的推进？ A1：你不去设法阻塞紧急不重要的事，就永远饱和啊，回到问题一了，只有你认为重要。 A2：这种事情 压到开发手里 很容易负能量。 A3：重要不紧急的事有2个解决方案：1、团队里有上进心的人额外做了 2、等变成重要且紧急的时候就可以做了 A4：游说 慈善家，给出点自己的时间和爱心， 还是有可能的，然尔，现在的软件改造不是某个人能搞定的，还有一堆质量保障的工作要做。开发完了也不能上线。 A5：你要把自己当做是内部销售，老板需求什么，团队需求什么，你自己需求什么，顺着需求来，逆势搞不定的。 A6：996的话，好多问题都爆发出来了，还是得先解决996的问题 A7：这种问题一般都会影响用户体验，比如时常oom，宕机等。我们之前的经验是定义企业故障级别，这种一般是p0级，配合kpi，要求这样的问题必须当天解决。这个对团队的压强很大，所以解决都很及时。但是有时因为团队的能力所限不可能都解决了，但是解决一个通常会解决一大片问题，难题都是有关联性的。有个实际的例子。之前接手一家公司产品技术团队，jira上有700多bugs。为了让团队解决技术债，规定每个星期每个团队必须解决30个bugs。从优先级高的开始，到年底都归零了。