Lei Zhang

Lei Zhang

2022,三餐四季温素有趣。

第一部分 程序员如何练就领导力

  • 第 1 章 从技术思维到领导思维
    • 什么是领导力
    • 人:技术型领导者挑战之源
    • 技术团队需要技术型领导者
    • 技术型领导者之“术”
  • 第 2 章 突破自我,团队制胜的模式
    • 团队制胜六步工作法
    • “六步工作法”第一步——建立亲和与信任
    • “六步工作法”第二步——统一认知
    • “六步工作法”第三步——确定目标
    • “六步工作法”第四步——团队沟通
    • “六步工作法”第五步——规划与实施
    • “六步工作法”第六步——总结反思

需求混乱不堪,排期错综复杂,几乎无法专人专项从 0 到 1 的完成某个迭代开发,总是几条线并行...

业务壮大前太闲,业务壮大后太忙,业务膨胀后太乱,大家纷纷开始抱怨公司业务为先,代码脏乱差,毫无技术沉淀,自己身兼数个迭代亦或是项目,昏天黑地看不到公司的未来,心里一沉,这是黑厂,提桶跑路。

image

很多人都遇到过此种场景,我也遇到过 3 家公司,壮大之后无一例外如此,导致老员工很少,年年都得重新招人重新培养。

我也负责过几家公司的招聘,面试时问应聘者离职原因,80% 的人会吐槽“上家公司管理不行,太乱”...

😂 让我们往返于各个“管理太乱”的公司,无限循环直到退休吧!

所以这到底是人的问题?还是公司的问题?还是市场的问题?

人月神话

在我刚工作的头几年,公司规模小,研发团队 10 人左右。市场给老板需求,老板下发到研发,菜鸟做简单,大佬啃难度,倒也其乐融融。

有了几年开发经验后,我跳槽的几家公司 Team 更大了,分工也更细了,想想这样很美,但实际情况让人直挠头皮...

  • 老板不知道产品质量怎么这么差
  • 产品不知道客户想要什么
  • 研发不知道产品想做成什么
  • 测试不知道研发 Bug 怎么这么多

当时我很好奇,更大的团队、更好的分工,为什么换不来更好质量,在各个论坛和谷歌摸索了几天,网上居然一致推荐《人月神话》

书中很清楚的概述了:软件开发和传统行业不同,软件开发的弊端就是人越多,做的越慢。一个需求从客户嘴里说出,再到老板的传递,产品的转换,研发的理解,经过层层转换,落地实施出来的结果就完全变味了。

所以这些问题,都是沟通的问题。

团队制胜模式

再回到《突破,程序员如何练就领导力》,能通过读一本书就能拥有领导能力当然是不可能的。

所以和《人月神话》一样,我只能从中取经:怎样的“领导力”才是一个引领团队制胜的“领导力”。

建立亲和与信任

这个信任,不是上级亲和下属,下属信任上级,而是整个团队成员之间的相互亲和,相互信任。沟通是影响团队执行力中的最大障碍,提升沟通双方的相互信任程度和相似程度能极好的建立有效连接,大大提升团队的沟通效率。

统一认知

一个项目或需求亦或是小迭代,让团队成员先明白这次任务的愿景、身份、价值。

不是让团队成员先明白做什么,何时开工,何时提测,何时上线。

这点在需求评审初期尤为重要。

确定目标

“以终为始”,任何需求迭代的开始,都需要为团队制定正确的目标,从终点反推起点,梳理中间的可能存在的差异风险,完善实施的蓝图,宁可事先追求尽善尽美,以免亡羊补牢。

其他

团队沟通 规划与实施 总结与反思 这三个模块在第一部分并未细说,暂且跳过。

武汉分公司

武汉分公司到现在快一年了,接下来,结合这一年团队的运作场景,看看我们是否贴合团队制胜模式中的几个大纲吧。

  • 团伙,为某一目的相互组织在一起,达到目的就分手;
  • 团体,为了一个共同的愿景,成员之前往往是按照成员自己的行为标准进行;
  • 团队,互助互利,团结一致为同一目标而奋斗,力求达到 1+1>2 的效果。

所以,咱们武汉分公司现在处于那个级别?当然还只是团体了...

武汉现在近 40 个人的 Team,只有 6 个人是从总部扭转回来,也就是说剩下 85% 的人根本不了解公司是怎样的,只能从每次的评审中大概听到,这个功能哪些别的项目实施过,需要迁移到我们的项目中。

大家上手的都是旧代码,做完新功能,又要填旧 Bug 的坑,长此以往,对灵智或者天虹期望趋近于 0,这就是去年武汉分公司的境况:既不知道团队的目标,也不知道后面的方向

只有我们几个“老油条”,尤其是我,🤔 能大概理解这个项目的意义,以及它各种“难产”的原因。毕竟天虹新零售蒸蒸日上,从 IBM 虎口夺食拿下“永旺”,跨行业做通“甘棠”,底气还是足足的。

团建

虽然去年我们的质量因为种种原因非常稀烂,但是仍然抽空搞了几次团建:户外的、运动的、周五做饭在公司厨艺比赛的,现在每个人都熟悉了起来,大到是不是单身、家里几个小孩,小到加几号汽油,都算知根知底了。

建立亲和与信任 算完成了“生活上”的 30% 吧,剩下工作上的 70% 还需要更多的时间、更多的磨合。

初评+终评+排期

去年刚开始,每个需求都是 P0,复制粘贴的需求文档屡见不鲜,深圳+武汉协同开发各种冲突,评完就做,做完就上线,线上各种问题混乱不堪,也陆陆续续走了一些人。

去年年末前后,开始在需求池中细致化需求等级,初评后排人,排人后终评,终评后再排期,当月能做做,不能做往后排。虽然不是所有都是如此实施的,但情况终归是稍微好了一些。

初评过后,虽然无法让全员统一认知, 但是小组的负责人还是能够统一的。不过我们到现在仍然只能统一“何时开工,何时提测,何时上线”,以及“这个需求本月是否排的上”。

工单事故复盘+文档积累

今年开始,陆续要求做技术输出,线上的工单和事故也开始重视复盘了起来,虽然起到的效果不是很高,但是这也算迈出小小的第一步,深圳也在贡献,武汉的也在贡献,看着 ones 上的文档多了起来。

这一步,和总结与反思 倒是粘上了一点边。

远的不说,起码新人入职之后一些流程规范,现在倒是直接贴几个 ones 地址自己看看即可,不用像去年,我手把手的“帮带”了。

团队合作

工作这么多年,我 99%的时间都是 single fight ,而全书一直在讲的 team work 却是一种奢望。

只有在做甘棠项目的时候,姜森林和叶俊纯让我体会了团队合作的感觉,我们会一起处理动画,一起封装组件库,一起设计MQTT等等,三个大胖子搞了不少好玩意。

team work 在书中是指整个团队拧成一根绳,相互信任和扶持,朝着同一目标努力,这个格局还是大了一些...

而在我的小格局中,能有一小戳人,一起交流技术,一起交流实现,一起解决问题便是团队合作最佳的催化剂,希望今年我也能把武汉前端团队盘活盘透。

掌声送给跟我共事被我坑过的你们!

👏👏👏

编辑此页
最后更新于225 天之前
icon©2022