这次主R跨团队项目中犯得错误

思考

发布日期: 2021-07-12

更新日期: 2023-09-17

文章字数: 5.4k

阅读时长: 18 分

阅读次数:

第一次当跨团队项目的主R，涉及3个团队，十三个系统,没什么经验，故而在这里总结一下自己在整个主R过程中所犯的错误。一则锻炼自己的思考能力，二则审视自身的不足，三则希望看到这边文章的人能够当成一个避坑手册。我写的这些并不是复盘，因为复盘需要重新审视目标然后在看整个事情中做的好的点与不好的点。我并不认为我在这次主R的过程中有什么亮点，功过自有他人来评价。但对于过错，我还是要自己梳理一下的。

我组织会议没有提前同与会人员沟通时间，没有提前发出会邀，临时拉人。导致想要就某个问题进行讨论的时候大家没有预留出时间，然后又重新同相关人员确认此问题的沟通时间，浪费了时间。
反思：

要就某个问题要进行讨论的时候，一定要提前与相关同学进行沟通，确认相关人员都什么时候有时间，把时间先确定好。因为人都是有惰性的，只要没人催我就不主动，只要没定下时间来就都默认不紧急，事情就这样浪荡着。所以确定这样一个时间，也其实就是给大家一个约束，只要定了时间，他就会惦记着这件事情，他在安排其他事情的时候就会想着某天某天我还有一个问题需要讨论。而提前发出会邀则是强化这个约束，也是给大家一个提醒，让大家留出时间来安排开会这件事情，不至于忘了。
同大家讨论的时候，一定得在大家都在场的情况或者大部分相关人员都在场的情况下进行讨论。否则有些细节问题可能讨论不清，因为术业有专攻，每个人都只负责自己的一块事情，最了解的也是自己的领域。我们在讨论问题的时候，每个人都会选择自保，会潜意识的减少自己的工作内容，这时候那个没来的同学就会成为众矢之的，所有的问题都可能集中推给不在场的人，这样轻则会使会议进程阻塞，重则导致责任分工不明。因为大家都说这块不是自己的任务，是不在场的谁谁的，需要他来确定，这样针对这个问题我们就很难继续推进下去，因为要推进下去就要没来的那个人确定某事，可他又没来，然后你就会陷入囧境，这个问题只能先放一放，等那个不在场的人来了再继续讨论，于是你不得不在组织一次会议，或者在单独找那个没来的同学去确认这件事情，等你确认这件事情的时候可能又会有很多变数，例如有人会说开会的时候为什么不叫我、不等我！现在才来跟我说。于是你就必须又在几方游说，搞得自己很累，人们也会对你这个主R有意见。
而我们想要约定这个时间，你要一个一个人的问去沟通显然效率不高，这时候我们可以把与会人员拉到一个群里。然后表明会议主题和期望的与会时间，询问大家是否可以参加。

例如明天下午5点在岳阳厅就换开需求进行讨论，主题在于明确系统边界确定设计方案出炉时间。大家都有时间么？

如果可以估算一个大概的时间最好，当然这个并不能很好的估计，估计少了可能开不完，估计多了可能大家都推脱说没有时间了。

例如明天下午5点在岳阳厅就换开需求进行讨论，主题在于明确系统边界确定设计方案出炉时间，大概占用大家1个小时的时间，大家都有时间么？

其实上面这个时间也不光是说给与会同学听的，也是对主R的一个考验。身为主R你能不能清晰的定位你事情的分工，能不能把控会场的节奏。你说了要占用大家1个小时，那你能不能把时间控制在一个小时左右。这也是个约束，身为主R的你就会主动去把控会场的节奏，否则大家都会再那儿漫无目的的讨论，反正也不知道讨论到啥时候，就这样耗着呗。这其实也在潜移默化的锻炼你的抗风险能力和风险把控能力，你细想想是不是？
- 临时拉人参会，甚至打电话说这儿有个关于什么什么的会议，你来一下需要你参加。
  这个问题一来人家有没有时间还不一定，也就牵扯到第一个问题，没有提前沟通好时间。二来，我这么说话也显得不够尊重人，别人会想，怎么其他人开会你都通知了，到我了就召之即来么？（当然这是我自己yy的）。这也暴露出我对主R的这件事情的认识不足，我连这个开个会需要谁参加都考虑不清楚。

我对于时间这块把控的也很不好，定这个开会时间总是拖得很晚。在组织整个部门技术review的时候，尤其在涉及到外部部门的时候，一回儿A说没时间一回儿B说没时间，会议时间一拖再拖。
反思：

我不应该等到全部人都ready了才进行review。因为某个系统的设计可能另一个系统根本就不关心，还要强拉人家来听，不说反感但也肯定不会听的。
- 我只需要将相互关联的几个系统的主R拉到一起进行review就可以了，因为相互关联的几个系统其实是一个整体然后中间又有一些矛盾，涉及到一个系统跟一个系统交互的时候，另一个系统的主R一定会关心别人的设计里面是怎么跟我交互的，因为他一定担心别人的设计会使自己的设计变得是不是复杂。一个系统要先调用A在调用B，他一定会要求A把这个过程包装好，而A一定会说我只负责原子的操作，至于业务逻辑你上游自己决定。
- 如果自身强势，就要求与会人员在规定时间参加会议，这条规则轻易不要用，还是本着沟通协调的处事原则。如果自身弱势，则同与会人员沟通协调时间参加会议

我在组织会议的时候节奏把控不好，往往中途就会有人离场。
反思：

我发现会议开始的半小时，大家都会听，因为你会发现大家都盯着大屏幕。会议超过1小时，你会发现有些人开始频繁的看自己的电脑了。会议超过1个半小时，你会听到有人在敲键盘了，会议超过两小时，你会发小敲键盘的声音没有了，开始有人打哈欠了。如果会议超过3小时，一定会有前面发言的人离场的事情发生，他会先离场，然后私下跟你说：我看接下来的讨论跟我没关系了，所以我先走了。所以每次会有最好控制在一小时左右。
我发现在会上总会有几个人是不发言的。这样他的参与感就会很低，可能他就不想参与或者本次会议就跟他没有关系。这是后你得考虑你是不是真的拉错了人，先怀疑一下人生吧，如果真拉错了那就只能抱歉等他自行离开吧。否则你就可以问问他的意见啊，让他发言一下，哪怕说句没意见也行。

关于群里消息的问题，我发现大家回复的都不是很积极。
反思：

这说明我自己没有权威，如果是王兴在群里问问题，你看有人敢不回复么，也可能是我没有给大家留下一个靠谱的印象，大家对于我担任主R这件事没太当回事儿。
还是那句话，人都是有惰性的，有些人可能根本就不关心这个群，看到消息可能也就一点而过，也不会主动回复，我有很多时候也是，群消息是在太多了，很多时候也都是囫囵的扫一眼，不过我看到消息还会回，即使不会立刻回复我也会把他置顶。
这时候可以单敲某个人，让他先回复你，这样别人看到群里有人回复了他也就会回复了。所以你发出去的消息如果想要别人都回复你，要么你是领导，要么就得有一个领头人，只要有人回复了，其他人也会跟着回复。因为好多时候大家都不想当第一个回复的人，尤其是你还不是他上级的时候。

我时间预估不足，没有预留出buffer。有时候期望能周五完成某件事情，但是有人非得拖到下周一。

说话前先说出自己的期望，然后咨询大家是否可以在这个时间点完成。
自己期望的这个时间点一定要留出余地。例如最晚周5，那我们就提周4，预留出1天的时间。这其实就暴露出自己没有风险意识，你排个需求还知道给自己留个buffer呢，在推动这件事情上我就没有做的很好。这个也不是说不诚实，玩儿心眼儿，只要是有风险的事情一定要留有余地，否则真出问题了连个补救都没有。

有时候某人就某事就是不给出你一个具体的时间点，本来你期望大家给出设计需要多少时间，但是系统设计者就是给不出来。

一则有时候某个系统牵扯的确实多，无法当场给出一个评估的时间。包括自己也一样，在过需求评审的时候也没办法知道自己究竟需要多久才能设计好。因为还有好多东西是未知的。
还有一方面，人都想自保，给自己留出一定的时间，不想把自己逼得太紧。这时候就算你想帮他，他也会告你你他需要时间熟悉代码啊，需要调研啊。
那我们退而求其次，既然你给不出具体的时间，那你给一个给出具体时间的时间。你要熟悉，你要调研，好，那你需要多久？这个时间一定得让他给出。
那这个时间他也说不好说，那也不能就这样了，因为如果没有时间约束，这个事情就没办法推进，然后对方也不着急做这件事情。这时候可以留出一天的时间，一天后再询问一下，看看能否给出时间
还给不了，那对不起，直接升级找他的领导反映一下吧。因为事情不能拖着，而你只是个主R，并不是他的领导，主R的职责是把控风险，不是写代码，这时候已经影响后续的发展了，风险有了，自己把控不了，就需要及时暴露出来。

我有时候在两个系统之间成为传声筒

作为主R，一上来大家不知道自己的上下游是谁，这时候有问题大家都回来问你，比如换开标识是应该存在交易侧还是结算侧啊，这时候该是哪个系统的职责就给对方找相应的系统对接人。而不是自己充当中间人，把A的问题传给B,再把B的回答传给A。

我面对人员变动无动于衷，没有风险意识

对于某个系统中途换了产品、换了开发，我没有采取任何措施，以为会按照以前一样一如既往的发展。但实际在后期问题就开始暴露出来了，各种没有确认和明确的问题接踵而至，导致工时估计不准。
其实中间换人是一个风险极高的事情，我以后需要重视，当然这种事情一般很难遇到，因为往往我们都是锁死在一个项目里面的，人员一般都很稳定。如果换人了，交接工作能不能做好，之前遇到的坑是不是得在重新踩一遍，不说全部踩一遍，至少50%吧，有些问题是不是得重复解释第二遍，但这也是我们必须要耽误的时间，否则后续的事情更难推进。
这个时候应该敦促他们之间做好交接，虽然我自己做不了什么，但是可以尽到我的周知义务，至于他们能不能交接好那是他们的事情，但是他们能不能很好的交接就是你的事情。

我在“推动”这件事情上其实投入还是不足的
反思

可能因为自己也忙吧，不过这只是个借口。我也不明白我为什么总是不愿意去推动某些事情。
这个事情还没有想好改怎么在推动事情的发展上有什么技巧。

我前期还是依赖bill太多

凡是开会必拉bill，凡是争议必请bill拍板。这两个凡是要不得。
一开始没有经验，比较胆怯，怕自己说不明白理解不了。这时候还是锻炼一下自己的脸皮吧。
对于争议，自己不敢轻易拍板，因为自己没有全局观，也是怕自己说错了。这时候还是锻炼一下自己的业务熟悉能力吧。
后期看柳鸿也是自己推进迁移的事情，就很少找bill出面，跟在后面偷偷看了一下人家是怎么组织会议以及推进的，学习了不少

我在会上期望大家提前暴露风险，但是不应轻易的因为风险给加工时。

我往往会在会上问一句，大家觉得有没有风险，有没有需要加工时的？这时候只要没有人提加工时还好，一旦开了一个先河，后续你就等着其他系统也要求加工时吧。
所以对于风险肯定是要提前暴露的，但是工时还是不要轻易地答应的好。所以就不要问那句话：有没有需要加工时。如果真的需要加工时了，会有人主动给你提的。
一延期，后续所有的计划都会打乱，联调时间需要重新协调，QA进入时间需要重新协调，产品验收时间需要重新协调，上线时间需要重新沟通等等都要重新搞。排期是一件很头疼的事情。

我前期在设计过程中，总希望每个系统都去了解他们的实现和设计

作为主R的职责是把控风险控制节奏，而不是实际的深入每个系统去设计和开发，各个系统有各自的主R，不要试图挑战他们的权威。
这样做你也不可能全部了解清楚，费时费事费力，好在bill及时阻止了我，把我及时拉回正轨，各自系统由各自系统的主R去设计，系统之间的交互有各自系统的主R去沟通，我要做的就是让他们找到对应的人。

我有时候做事不制定标准，导致无法验收

比如写上线文档，写成什么样子才算好呢。因为我一开始也没有指定标准，只是周知大家要写上线文档和回滚方案。但是大家都是简单的写一下，其实根本没有可执行性。有些人的文档里就三行，根本超不过100个字去，什么打包、上线就完了，也是无语了，也可能真的是人家的发布就很简单吧。
标准有不能太复杂，太复杂别人就会不停的询问你该怎么写。
不见得所有人都能按照你的标准执行，因为你根本没有决定处罚权，只有周知义务，所以大家不一定会听你的。
- 这个时候可以说其要害，如果不怎么干，就有可能出什么问题，遇到问题追责的时候就要怎么样，人一旦遇到跟自己责任挂钩的时候，就算不愿意也得掂量一下后果。

我做事不懂拒绝
单元测试不重视

现在我们的单元测试往往都是为了完成增量行覆盖率而写，很少考虑业务逻辑，我自己有时候也投机取巧，这是不可取的。
Mock框架固然好用，但我感觉我教会大家后大家都开始不管三七二十一开始一顿Mock，而且用的不亦乐乎，当总感觉写了很多没有营养的单元测试。

心中没谱，没有全局观

作为主R我没有全局意识，因为我同时还有开发三个系统：发票系统、调整项系统、还有CSG系统，还有后面的发票平台也得我来搞，就局限在这几个系统了，而对整体的系统交互没有一个全局观，不过后来逐渐有了。

后期跟进不足，没有用心

发票平台这块明知有问题但还是妥协了，放任问题就这样。
中途发票平台这块的代码由于原来的开发同学调岗，代码写的也不认真了，虽然代码不是我写的我只负责上线，但发现问题发现沟通无果后我也就佛系了，爱咋地咋地。我明知有问题，但还是建议残血上线，说明我责任心还是有欠缺，以后千万不能这样
后期对发票平台的代码跟进不及时，虽然代码不是我写的，但是交接到我这儿了，就应该搞懂并维护好后续的工作。
好在后来我还是良心发现，选择了修复