2023-09-26 创业-迭代0925-制度及管理和文化-反思

摘要:

无论情况完成的如何, 迭代0925已经在昨天强行结束。

相比clickbench的迭代, 这次我保持了全程参与, 对其中种种经历有的让我震惊, 有的让我愤怒, 有的让我愤慨, 回首起来, 颇感唏嘘。

正所谓前事不忘, 后事之师, 必须对过去的经历做认真的反思, 以传承过去的经验和教训, 在下一步行动中避免以往犯的错, 无论是技术上, 管理上, 战略规划上, 还是执行上。

迭代0925概述:

迭代内容:

2023-09-11 mysql-代号m-0930阶段目标-任务列表-记录-CSDN博客

参与迭代的开发者:

1. 丁奇: mysql45讲的作者
2. 李浩: 架构师
3. 我本人: 开发者, 以及代号m项目的奠基者

迭代周期:

1. 从9月11日开始
2. 大老板约定9月20日结束
3. 丁奇以要加个周末加班为理由, 将结束日期延长到9月25日

迭代之后的奖励和惩罚:

1. 未明确提出

迭代0925的完成情况:

一. 本人

1. 一周内已经完成分配下来的任务
2. 又新加了并行控制
3. 也加了一些来自开发和测试的需求, 被我直接回绝

二. 李浩

1. 有难度的任务直接说做不了
2. 能分配下去的任务都分配给实习生去做
3. 自己做了create table like
4. 对于内置函数的不支持, 使用了直接走innodb的做法, 导致内置函数中load数据后查不到mdb的数据

三. 丁奇

1. 无任何代码提交
2. 每天加班到凌晨三点, 但是不见任何产出
3. 说是周末把代码提交上去, 但是说过的话当放屁
4. 发版当前, 以在代码库中测出了新的bug为理由, 拒绝提交代码
5. 在当天发版会议上明确了说了晚上会加班把代码提交, 无任何提交

从项目管理角度:

一. 领导者的角色缺失

1. 此次项目是让丁奇做团队TL, 但是此人无论是心理状态还是技术能力, 都是问题
2. 这就导致此人不但没起到正向作用, 反而起到负面作用
3. 由于这个原因, 上一次的clickbench冲刺整个团队什么产出也没有
4. 为了避免重蹈覆辙, 我开始强行推动

二. 团队监督机制缺失

1. 为了避免李浩和丁奇两个人像clickbench一样不干活, 不得不引入监督机制
2. 每天早上回报进度, 每晚将进度发到迭代群
3. 但是由于缺乏明确的惩罚机制, 所以这俩人有恃无恐, 每次都是糊弄过去

三. 肯干活的人太少, 也没有机制保证人干活

1. 丁奇没提交一行代码, 李浩半混半搪塞
2. 但是提需求提BUG的人却一堆
3. 丁奇为了不干活，还拿我的代码新测出的bug当挡箭牌, 说是分支不稳定, 他不能合并代码

四. 大老板为了维护团队做和事佬

1. 这简直让人寒心, 主要是看到混子还在团队里位居高位, 干活的人却鞭打快牛, 直接让人心寒
2. 另外一个很大的原因是不同位置的人的了解到的信息和思考问题的角度都是不一样的
   1. 站在我的角度那肯定是按产出考虑一切
   2. 但是在全局者的角度, 一方面可能并不知道实际情况, 另一方面为了更大的目标暂时的隐忍
3. 这就是必须创业的原因, 如果身处这种位置, 那么就难保不会被人喂屎

从团队文化角度:

1. 空降高层现象非常严重, 暂且不论这些高层个人能力如何, 但是过几个月就换, 必然有更为深刻的原因
2. 但是这样就导致从高管入职到发现其不能胜任岗位, 需要几个月的时间, 一旦识人不明, 几个月的时间就这么被浪费了, 更可能导致团队毫无产出
3. 丁奇就是在这种背景下做了TL，主要是丁奇在外界的名声, 而非对丁奇能力的了解
4. 但是为了让丁奇在团队中有威信, 作为大老板就必须对丁奇表示支持, 如果丁奇已经暴露了自己的无能,大老板还这么做，就会让人对大老板的用人能力表示怀疑