第三月月报之团队与leader

正式入职3个月了,正好一个季度,哈。

最近的这一个月的工作内容很聚焦,就是做项目的开发。我除了自己原本就有的后端开发任务外,这个月也开始承担Scrum Master的职责。到底什么是Scrum Master呢?(以下简称SM)

首先说Scrum,这是敏捷开发的一种方法,我们日常的语境中,Scrum≈敏捷。我感觉SM有点像中小学班级中的“课代表”,课代表每天早上负责收大家作业,放学的时候给大家传达老师布置的作业。虽然有一定职责,但还没法跟班干部比,班干部好歹是个正经干部。具体到SM的职责,就是促进敏捷开发过程的推进、管理开发团队信息流转的过程[1]

我之前在想,SM的中文译名应该叫什么。思来想去,感觉没什么合适的译名,大家一般也都直接叫SM。我对“Master”一词的理解是“主人”的意思。比如说,我是“当前开发里程碑的主人,我对这个里程碑负责”。这两天我为了补习开发项目管理的相关知识,看了邹欣老师的《构建之法》的相关章节,发现书中将Scrum Master译作“Scrum大师”,感觉有点喜感。我的微信昵称以前很长一段时间叫做“吃饼大师”,看来我现在已经成大师了,就看什么时候能吃上饼了。

这篇月报的主要内容将是我学习《构建之法》中第17章“人,绩效和职业道德”的摘录和感悟。正值封闭开发开始之前,临阵磨枪,不快也光。这章讲了很多软件开发过程中的“软知识”,对开发项目管理、团队管理相关知识有需求的小伙伴,特别推荐这章,值得一看。实际上,我觉得这本书对于每一个计算机专业的学生来说,都特别值得一看。

首先说领导力。很多文章都在说“Leader”和“Manager”的区别,大意是Leader管理事情,Manager管理人。从这个角度来看,SM是Leader的一种。前两天在朋友圈看到一个文章,讲“无授权领导”,意思是身负Leader的职责,但又没有相应的权力,比如资源调度的权力、行政级别的权力。其实想想也正常,如果所有的权力都调配到位了,那Leader也难免就要成Manager。Leader,领导大家达成团队的目标。

每次说到领导力这事我就挺不安的。我在高中和大学期间,通过参与学生活动、社会活动,体验过一些Leader的角色,尤其是大学中担任班长这个职务。但如果要我说我是否是一个足够ok的leader,我并不这样认为。回顾过往,感觉自己在这方面做得并不是很让自己满意,也不是很让身边的人满意。不过万事总有个开始,宇宙大爆炸有个开始,世世代代世袭的贵族也有个开始,一个人在职业发展的道路上也总有个开始不是?不过我在这方面倒是有自觉有几个优点:首先,我的自信心能普遍维持在较高的水平;其次,一旦我真的想干好一件事,我能对这件事情注入热情,并能将这种热情传播给身边一起共事的人,从打班级球赛的经历能感受到这点。我感觉吧,搞我们程序员这行的人,有时候容易缺少点热情。是好事,冷静使人理智地思考,但总有些时候也需要热情。

领导力

书中提到,在软件团队中,领导力具有几个要素

  • 设定目标
  • 知人善任
  • 带领团队成长
  • 绩效管理

幸好,对于我目前的SM角色,这四点领导力我都不用太过操心。更多需要关注的是第一条,而且我在一定程度上还不用“设定”目标,我更多的是把我的leader设定的目标分解并执行。

书中指出,好的目标具有下面的特点SMART(是5个单词的缩写):

  • 具体的,无二义性的,能描述“成功”是什么样的
  • 能激发团队成员的动机、兴趣、热情
  • 真的能做到吗?即可实现性
  • 和大团队的方向吻合
  • 进度是可以被衡量

这几条好目标的定义对我来说非常重要,这5条中的每一条都是我马上能运用到工作中,并提升我对开发里程碑管理的质量。尤其是“具体的验收标准”,“激发动机”,“进度和衡量”,确实正是我当前对里程碑的目标制定这件事的重大不足之处。

知人善任

书中提到,MBTI人格类型中的“INTJ”类型,在软件工程师所占比例远远大于普通人群中所占的比例。

没错,正是在下。

作者的意思是,要了解团队的成员,了解他们的性格。

作者认为,在一个团队中,领导需要了解一个人的:

  • 知识、专业技能、职业技能,三者合起来称之为“能力”
  • 投入程度,热情,对团队目标的承诺,称为“动力”

我认为,上面提到的“职业技能”这个东西(一些软技能,例如交流能力、自我管理能力、快速学习能力、处理复杂问题的能力),在大学的计算机专业学习中是特别缺乏的。这项技能几乎每个计算机专业毕业生都要在进入职场后自行摸索。好的公司会组织培训,比如我司就对新人都非常不错的入职培训,但是我认为这还不够,这需要在日常的学习、软件项目中主动练习。这似乎不是学校的问题,看起来也不是学生的问题,那倒地是谁的问题呢?令人困惑。

作者根据能力和动力,构建了一个二维的4象限,这里就不赘述了。总之,我们每个人都应该朝着“高动力”、“高能力”的方向努力,即便我们绝大多数人在刚进入职场的时候,都是“高动力”、“低能力”。

带领团队成长

这节讲的是一个软件团队的不同发展阶段。

从书中的描述在看,我所在项目的团队处于最开始的“萌芽阶段”和“磨合阶段”之间。对于萌芽阶段的团队,领导需要带领团队弄清楚五个奠基团队基础的问题

  1. 目的:我们为何存在?我们交付什么样的产品?我们将来会成为什么样子?
  2. 原则:我们该怎样工作?有哪些不能讨价还价的底线?
  3. 优先级:面临选择时,应该怎样做决定?
  4. 计划:把产品的各个阶段、交付内容协调好。
  5. 人员:谁负责什么,谁不负责什么。

看到这段文字,我体验到了“如获至宝”的感觉。对于我们的项目团队来说,特别需要明确一些事情,把一些东西内化到大家的心里,这样虽然大家是一个个独立的人,但在项目的推进上我们能逐渐融合为一个能使出合力的巨人。

另外书中提到,领导要鼓励积极、公开的信息流动,例如Wiki页面、公开的邮件组、公开的项目进度、技术交流等,这也正是我一直以来大力倡导的。除了作者提到的这些,我还希望代码对项目成员来说也是非常透明的,每个人都有权利Review同事的代码,并有权发表评论。出于项目效率的考量,代码Merge Request的权限会归拢到SM这里,但是每个人对代码发言的热情和权利是我希望去保障的。因为我认为,这样的代码环境,才能保持代码仓库的简单、清爽,合并进来的都是富有责任心的代码。代码腐化这件事真的是太常见了,要是没人管这些事,软件系统的熵增也是不可避免的事情,要引入外部的能量(人的精力,用于Code Review、代码重构等)。“促进信息公开透明是防止腐败的良方”,我想是一个道理。

绩效管理

幸好我还不用操心这种事。我想过这个问题,我觉得在最理想的情况下(也意味着不可能实现),如果每个人对自己的打分是完全客观的,那绩效评估就只需要自评就好了。比如张三认为自己今年绩效只能打个C,然后他羞愧难当,自己辞职了。当然这是不可能的。

可是如果上面定了指标,一定要安排20%的“C”,这又会造成一个问题:如果所有人都干得不错怎么办?一定要把ok的人评为C吗?我觉得这样是否是个办法:如果团队的KPI/OKR完成了,那就不需要一定评出20%的C,但如果绩效没有完成,该评还是要评。一个公司中,一定会有一些团队非常优秀,队伍中的每个人都很OK,但从科学的概率上来讲,绝大多数团队都是普通团队,很可能有绩效后20%的C员工。如果公司强行让所有团队都评出后20%的C,一定会有误伤,但公司也许能接受这种误伤。就好比是招聘时把简历根据学校进行筛选,一定会“误伤”一些学校不好,但是技术很牛逼的人。但是作为公司来说,从概率的角度出发,肯定是能够承受这种损失。

总之书中举例了若干种不靠谱的绩效评估方法,比如看代码提交行数、比资历、大锅饭等。

我觉得呢,最好的办法就是早日实现共产主义。一个公司如果赚大钱,大家的钱都够花,分钱的事就都好商量。

萝卜与白菜

萝卜与白菜是作者写的一个软件开发的小故事。我就摘录一句话:

萝卜做事很快,代码提交速度非常快…由于萝卜的设计有缺陷,导致模块非常复杂,萝卜也成了唯一了解其模块的开发人员。项目最后阶段,几乎都是萝卜工作做得最晚,把最后几个缺陷给修复了。领导们说:有问题,找萝卜!

自我反省,不要成为萝卜这样的程序员。

职业道德

学医的小伙伴应该都念过希波克拉底誓言?不知道你们是不是真的有个正经八板的宣誓环节,感觉还挺神圣的呢。其实软件工程师也有个道德誓言,是IEEE/ACM发布的《软件工程师职业道德规范和标准》。内容挺有意思,摘录两条:

3.10 确保项目的程序和文档经过足够的测试、调试和复审。

3.11 确保项目文档齐全,包括所有发现的问题和解决的方法。

惊出一身冷汗,似乎已经走在了软件工程师道德沦丧的路上。回头是岸,回头是岸。

受过很好训练的狗

这章最后引用了爱因斯坦的话,用来说明为何要讲人、绩效和职业道德的事。学好专业够不够呢,为啥要扯这么多呢?

用专业知识教育人是不够的。通过专业教育,他可以成为一种有用的机器,但是不能成为一个和谐发展的人。他必须获得对美和道德上的善恶鲜明的辨别力。否则,他——连同他的专业知识——就更像一条受过很好训练的狗,而不像一个和谐发展的人。…

——爱因斯坦

首先,订一个小目标,可以先成为一个受过很好训练的人。

[1] https://whatis.techtarget.com/definition/scrum-master