扫码阅读
手机扫码阅读

ASK MO第37期 | 末位淘汰制下,如何保持与队友的无间隙配合?

56 2024-01-09

正文共:3916字   预计阅读:10分钟

哈喽大家好!

这里是空谈误国,实干兴邦的创新实干派。

我是莫老师????

欢迎来到每周二晚9点的ASK MO时间

SUN

MON

TUE

WED

THU

FRI

SAT

28

29

30

1

2

3

27

ASK MO来到了37期,马上就快到五一劳动节了,终于可以让辛苦半年的我们好好休息放松一下了。不知道大家有什么样的旅行计划?期待我们朋友圈的一波旅行大秀。

好了话不多说,回到我们的ASK MO。

本期话题

• 敏捷迭代下,系统架构开启疯狂打补丁模式

• 说说初入职场,犯过的“傻”

• 末位淘汰制下,如何保持与队友的无间隙配合?

多业务平台敏捷开发,如何进行故事点估算?

• 如何量化与考核团队ROI?

本期提问

问题1

莫导,敏捷适合复杂,多变的项目,是将需求分成多个迭代分期去交付,变更的需求可能会造成系统整体架构设计的调整,调整一多,有时候可能系统架构就开始打补丁的模式了,最后就降低了架构的稳定性或者艺术性,怎么处理这两者的矛盾?

——匿名

出现这个情况,一般有两个原因:

1、只考虑到系统对于当前业务的适应性,没有考虑到系统支撑到未来的一个业务;

2、做了业务规划,但是没有想到业务发展超出我们的预期。

所以,我们在系统的整体架构方面,我们需要有一位架构师去规划能支撑起未来业务发展的系统架构,一般系统架构都是基于业务场景来规划的。比如与产品方面进行沟通,看看现在的业务量是多少。然后做一个估算:

未来业务会发展到什么样的程度?

我们的用户数量会达到现有的几倍?

关键服务目前能满足多少用户同时访问?

两年之后多少用户同时访问系统还能支撑得住?

根据这些数据来设计我们整体的架构,也就是说架构至少能支撑未来两年。在这个架构前提下我们再来去设计我们的产品。

并且每半年我们要思考一个问题,基于我们的业务的发展情况,我们目前的架构是否还能支撑未来两年的发展?如果不行,那我们就要提前开始做一些重构工作。把这个事情提个日程,并告知产品,在每一个迭代当中我们要加入5%到15%的重构功能。

所以这个是个平衡的艺术,既要考虑现有的业务,又要有超前的架构设计。这个责任是要落到系统架构师这边,最好是CTO能够知道并且了解这个事情的重要性,支持并主持系统重构。



问题2

莫老师,你好。看到你发的ASK MO 的问题征集,有一个问题一直想问你。

蛮早的一次在群里,大家聊天的时候,说到同事离职这个事情。你说你刚开始工作的时候,关系好的同事要离职的时候,你都是尽力挽留,会伤感之类的。后来就不会那么“傻”了(不知道有没有记错,当时应该是这么说的)

这两年经手处理了大概几十号同事的离职,从一开始会带有那种情绪,到后来是希望大家能有更好的发展。

一直想问的是,当时你说的“傻”是一种怎么样的状态?现在这个职业阶段,又是怎么看待同事离职这种事情的呢?

——还不够敏捷

“傻”的状态就是自己的代入感太强了,觉得公司就是自己的公司,自己就是这个公司的老板,把员工的离职看成对公司的背叛,对自己的背叛。员工每次的离职都是对自己的伤害,我觉得自己又没有做错什么,哪点对不起你了,你为了那点工资就跳槽到其他公司去,至于吗?我们不是要一起奋斗,一起发展的吗?

后来经过的事情多了之后,包括自己也离职过后,慢慢对这个事情,其实就看开了。其实员工离职,如果有好的地方去,真的不需要挽留。

1、不要把工作看成人生的全部,其实生命当中还有很多美好的事情等着我们去发现,去追求。友情、亲情、爱情,这些比工作本身更有意义,人生苦短,我们要追求的,并不是能挣多少钱,有什么样的体面工作,获得其他人的认同,而是自己的人生是否活出精彩,活得有意义。自己要去追求的同时,不要让别人放弃追求的权利。

2、离开的同事,特别是去更好公司的同事,和他们保持联系,他们有更多的资源,说不定什么时候就会用得上。这对现在处于创业期的莫老师而言特别重要,因为谁也说不准你哪天可能自己创业。这个时候你的社会资源就会变得相当有价值了。站在资源交换的角度上来说,请善待每一位离职的同事

举个例子,莫老师有一位下属离职,我领导叫我留他,我压根没有留,因为我知道他去了更好的平台,工资也比现在高很多,推心置腹地和他聊起了天,以自己在大公司的经历,告诉他今后在大公司的发展方向。到现在我还和他联系,当我想了解他们公司情况的时候,他也把他能知道的情况都一一告诉我,这就是很好的资源互换。对于我现在创业是非常有帮助的。

问题3

敏捷需要全团队默契配合,但是单位考核制度是末位淘汰制。一般的说,如果末位淘汰制的话,你最大的敌人,其实是你的队友;这势必会影响到全团队的默契配合,这种矛盾问题应该如何破?

——胖子

1、敏捷需要全团队配合,但是全团队配合是一个理想状态,我们又不是复仇者联盟。就算是他们,也有内部闹崩的时候,所以,在一个团队里面,总可以找到相对不那么配合事情,处于末位的同学;

2、末位淘汰制的考评,又不是当场互相评分,当场淘汰,而是由你的领导给出评价,他出于他的考虑,会决定谁会进行末位淘汰;

3、末位淘汰通常也不是一次性的,在真正实行的时候,通常第一次考评很差,会给出警告,如果再没有改进,才会进行淘汰。其实在这个过程当中,大家已经给了机会。


问题4

背景:公司研发体系是按平台进行划分的,比如说CRM、业务平台、金融平台、ERP平台等等,每个业务平台有研发经理、产品经理、开发、测试、前端;其中前端和测试是共用的;目前有一个跨平台的项目,需要由多个平台进行联调、开发,还包括APP(IOS端、安卓端);

问题:现在这个有多个业务平台进行开发的项目,如何进行故事点估算,因为基准点多个平台无法统一,但是流程又要求要有需求规模估算、团队产能统计,以及项目汇报使用,请问有什么方法可以解决这个问题?

——Wade

跨团队的项目,如果需要进行需求模块估算,那么唯一能解决的问题还是要选择共同的基准点,以求对每个故事都能有统一的故事点估算。这个的确是比单团队估算来得复杂。但是这个是不能避开的一个问题。需要各敏捷团队的SM一起讨论,如何定出来这个基准。

比如对单个表的增删改查设为一个故事点,大家达成一致之后,可以看这样一个需求,有对多少张表进行过这样的操作,在历史工作量的时候,是一个什么情况,就可以大概定出一些功能的故事点来了。


问题5

Scrum PO要对ROI负责,PO应该怎么做ROI分析,团队如何考核PO的ROI做的好与坏,都要数字量化出来吗?

——花花

ROI就是投入产出比,这个通常用钱来量化比较具体,通常我们做一个需求,要投入多少人天的工作量,而我们公司的平均1人天值多少钱,那么这个需求我们可以评估一下,他可以为公司创造多少收入。或引来多少新的客户(客户获取成本可以算出来),或提高效率之后,为公司节省多少人力成本(这个成本也可以按人天计算)。

还有一些无法计算的,比如这个需求可以减少客诉,提升用户体验的。可以计算的我们称之为直接收益,无法计算的我们称之为间接收益,通常在敏捷团队当中,我们优先完成直接收益的需求,再完成间接收益的需求,直接收益里的需求优先级排序就看收益有多少。

最后需求上线之后,PO通过数据分析,分析出本次上线后的收益是否和预估的一致,帮助团队在一次次的迭代当中关注价值,敏捷就是价值驱动的。

老铁,没毛病。


· · ·END· · ·

原文链接: http://mp.weixin.qq.com/s?__biz=MzIxMjM1MjMyNA==&mid=2247484551&idx=1&sn=b7a404d8daab8a709b39571ec9c2fde4&chksm=974628aca031a1ba46cce94259b8626ddb34ee722dad9c68e11cc310dee6c5587dabb818af2d#rd

小文分享

47 篇文章
浏览 1172
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线