写在24岁

时间过的好快。

犹记得2017年刚毕业的时候,心想着终于解脱了大学的生涯,成为了一名“社会人”的愉悦心情

一晃眼,已经过去了五年的时光

20年初的疫情,开启了漫长的与疫情共存的时间,这几年便像是加速一般,迅捷的从20年跳转到22年

仔细想来,这两年也未曾做过哪些事,20年短暂的入职一家公司后便迅速离去,21年入职一家新的公司,开始承担了更多的责任

其实刚进这家公司的时候,是想着干上半年左右就准备走的,但机缘巧合之下,成为了项目的负责人,开始着手搭建团队,组建人员攻坚项目

这中间还有许多的故事,但那些也都不重要了,重要的是在这家公司我所获得了更大的成长,以前虽然也曾试图从更高的角度去观察自己所负责的项目,但始终未得全貌,这次作为一个项目的负责人,承担着 数十人的团队,看着团队成员的不断成长,项目的进度不断加快,也是有着些许的开心。之前虽然也带过团队,其规模也才3人左右,且当时所处公司流程完善,其实并没有太多发挥的余地,而在这个项目中, 我也实验了自己的许多设想,并加以实践,就最终结果来看,这些设想也都能落地,当然在落地的过程中也不免有些问题,经过及时的调整后也取得了不错的成效。

先说说我对管理的定义,其实从另一种角度而言,管理可分为固定性产出管理与非固定性产出管理。

固定性产出管理,即传统的工厂管理,讲究的是流水线与可替换性,对于员工更多的是追求标准化与固定性产出化,当然也可以使用计件来增加一定量产出。

非固定性产出管理,即艺术类,例如画画,歌曲创作,舞蹈创作,讲究的是时间的不固定性与产出的难以度量化,对于员工而言有着更高的要求。

而软件开发于我而言的定义,其实更多的是偏向于非固定性产出。其主要原因在于代码的不可估量性

从以下几点来阐述我的观点

  1. 代码的产出具有不可估量性 即一个功能的完成与否,无法基于代码的行数,或是代码的功能完成程度来预估具体结束时间,在软件开发的过程中,通常遵守二八法则,即百分之二十的代码需要花费百分之八十的时间
  2. 代码的产出时间无法通过人力来平衡 这一点其实无数的软件工程相关书籍包括各类行业前沿的大佬都已经论证过无数次了,当一个项目将要延期时,通过添加人力并不会使得项目进度提前,反而会使得项目延期时间变得更长,其主要的成本来源于新加入的成员带来的一系列的沟通成本
  3. 代码的质量与难以妥协的工期问题 代码质量和工期往往是不可融合的死对头,领导或客户提出的交付日期,与实际代码产出的工期之间存在着不小的差异,在第一次代码质量崩坏的开始后,代码就变得难以维护从而导致了下一版本的工期变长,而变长的工期往往会遭遇进一步的压缩,使得代码的质量进一步变差,其最终的结果就导致代码无法维护,软件的生命周期终止,这时候往往只能新开项目来规避之前的维护成本

从以上三点可以看出,软件的开发其本质上和艺术产出并没有过多的差异,都具有不确定性与难以量产性

而从另一种角度而言,软件的开发其物理流程上,却又可以与固定性产出管理相结合,其最终交付的产物通常可以按照模块或者是功能点来区分交付进度,就如同汽车上的底盘,发动机等等组件。

之前一直在思考一个问题,为何国内的大多数企业在软件开发行业是如此低效,各类问题层出不穷,以以上三个问题点为例

第一点,代码的产出无法估量,很多开发人员在不合理的工期下压缩了产出的质量,短期内提高了产出的效率,复杂情况下,通常是将写到一半的程序提交测试,再等测试打回的期间来补充功能代码。 第二点,代码的产出具有排他性,即工程师A修改工程师B的代码,需要一定的时间成本,并且由于对业务的不熟悉,需要更多的时间,从而导致压缩更多的产出时间,再循坏到问题1 第三点,代码的功能产出往往受限于不可控的第三方,其原因通常是客户或者业务部门不切实际的想法,从而加快了问题1,2的发生

这些问题难道国外企业没有吗?还是说只有我们国家的软件行业才会有这些问题 抱着这些问题,我读了“凤凰项目”,“人月神话”,“不拘一格:网飞的自由与责任工作法”等书籍,才发现这些问题其实在国外的软件行业曾经也不断上演过,只是人家总结了许多经验,却鲜有人去学习

以凤凰项目为例,一个处于将死边缘的软件项目,由于企业内部业务团队不切实际的业务需求导致项目不断的延期,人才的梯度建设基本为0,存在一系列的“问题单点化”,经过一系列实际的管理手段后才得以改进。 换而言之国内的企业,大部分软件工程也都存在着许多类似的问题,业务部门给客户提出的不切实际的交付日期与不切实际的业务需求,人员的不断流动,仅有的一两名留任的员工在各处不断的救火,变成了企业的“问题单点”阻塞着整体的交付进度,随之而来的则是漫长的加班,996。软件工程师们更是难以抬头仰望,无法给业务部门提供更好的实际业务建议,进一步强化了其“工具人”的属性

亦或者是灵活的“学习”国外的先进经验,将例如“敏捷开发”等实践成具有国内特色的“敏捷”开发,将需求与产出时间可控的敏捷开发转变为特色性的无需求文档,无原型无设计的”敏捷“开发

以上的这些问题,在软件开发的行业而言,各个企业或多或少的都存在此类的类似问题,而要从根本性上解决问题,企业的管理者们首先需要转变自己的思路,将软件部门视为产出部门而非成本部门,尊重软件生产的客观规律,学习并接受软件工程的不可控性,才能获得较大的进步

再以《不拘一格:网飞的自由与责任工作法》这本书为例,讲述了国外著名流媒体公司”网飞“的人才管理办法,通过一系列方式来保证员工的产出效能与员工的可持续性。值得一提的是,网飞公司作为一个流媒体公司,也曾为软件开源社区做出了巨大的共享,开源了Spring Cloud Netflix这一著名的Java微服务框架

对于企业而言,人才的可持续性其实需要更多的跟进,目前大多数企业仍存留着保持几个核心成员,其他成员流动随意的想法,而从事实来上来说,任何企业的核心人员都无法照顾到所有的代码,一系列核心的业务功能代码都需要团队成员的贡献,如果团队人员的流失率过高,进而就导致了代码质量的失衡,即因为原代码产出的作者不是自己,所以无需讲究代码的质量的想法会极大的影响到团队成员的产出。从项目的远期可持续性来看,这种想法无疑是项目的致命毒药,这就会成为项目失败的一个重要因素。

从实践的角度而言,在这家公司我也实践了自己许多的想法,从不控制团队成员的工作时间,到代码规范的指定。再到发现一系列沟通上的问题并改进与加以解决,例如在项目的初期并没有产品经理来做需求与文档的产出,于是我便作为一名产品经理来做产品的产出与需求的实际需要进行讲述,减少成员间的需求认知差异。再诸如让团队成员自己承诺功能的交付日期,并协助分析其功能的复杂度来保证产出的质量。

从工作的角度而言,不控制团队成员的工作时间实质上是一个较大的挑战,这需要把握好需求的整体复杂度,因为没有了具体的工作时间,则例如每天早晨的例会就无法进行,取而代之的则是利用工具来管控进度,使用一系列的任务卡片,成员完成后便标注卡片完成,用异步的方式来取代早例会这种同步的方式。

从代码的产出质量而言,通过规定代码规范,到使用代码规范检查工具,来确保了团队成员输出的一致性,减少了代码的复杂度,提高了代码的可维护性,保证了代码的质量,同时也为新需求的迭代提升的不小的速度。

从管理的角度而言,我不再是作为一个负责人的角色来承担项目,更多的是做好团队成员的观察者与协助者,观察团队成员的输出性,协助团队成员达成更好的目标,就总体而言,其工作的效率与氛围程度还是有不小的提升

记得之前在知乎上看到的一个很有意思的提问,问的是为什么95后00后都如此难以管理。值得一提的是,在这个团队中,大多数成员都是95后,少数成员是00后,从整体的管理角度而言,反而是更为轻松,这中间的主要原因我认为是尊重他人作为”人“的权力,即允许团队成员有思想,有行动。

什么是有思想,有行动,这一点其实很难定义。我对于招聘的标准并非简单的代码水平或者是所谓的框架掌握的熟练度,我也很少去问例如HashMap,多线程这一类的所谓”八股文“,我更多的是通过一些简单的技术问题,来从侧面考察面试者的”自我驱动“性,即提出一个”问题“,要求面试者给出解决方案,再从中提出一系列的问题,来考察面试者是否有自我驱动的能力

如何定义自我驱动呢,这个其实我认为比较简单,即一个问题从提出到解决,是否有经过思考,是否有思考过更好的解决方案,即使面对未知的问题,是否有能力解决

以一个常见的面试初级工程师的机试题为例

给定一个Base64后的字符串,将该字符串解码并转为List打印,再将其用Java8 新特性Stream流进行从大到小排序并打印

这个问题涉及了以下几个问题,什么是Base64,Base64如何解码,解码后的字符串如何转为一个List,如何使用新特性进行排序

大多数初级工程师并没有了解过这些,而我的要求则是在15分钟内通过百度来完成此机试题就算通过,同时也考察了面试者在面试过程中的代码产出质量

那什么是尊重他人作为”人“的权力呢,举一个非常简单的例子

团队出去团建,有两种选择,一种是去野营,一种是去吃饭

现在你作为负责人,你更倾向于去野营,但团队更倾向于吃饭时,你有两种选择

  1. 提出建议去野营,同时让大家自由选择,并表示尊重大家的意见
  2. 让大家自由选择,并表示尊重大家的意见

选择1,当你和团队没有较多的信任感时,其实大家都会选择”尊重“你的选择 选择2,引导并让团队相信你会尊重他们的选择,让大家无顾虑的发表自己的看法

可能有人会表示怀疑,不就是一个简单的团建吗,我作为负责人为什么不能先发表自己的想法呢

这里我说另外一个例子

在团队组建初期,我需要忙于人员招聘与面试,因此写代码的时间仅限于中午午休的两个小时,与此同时新来的两个小伙伴在写了一上午代码后,中午依旧还在写代码

一次两次后,我就产生了疑问,于是便问他们,为什么中午不睡午觉还在继续写代码,经过几次询问之后才得知,他们俩看我中午没休息还在写代码,不好意思去睡午觉

这样的例子在《不拘一格:网飞的自由与责任工作法》书中亦有提到,网飞实行的是任意时间都可请假的制度,即你可以在任意的时间提出休假并执行,这一制度实施下去之后,结果公司的请假率并没有增加,问及深层次的原因后,基层人员看着上级领导没有请假,便也不敢请假,上级领导看上一级领导亦然,于是便开始要求各个部门的领导进行任意时间的休假,这一制度才得以正确的实施,基层人员才敢于在任意时间申请休假

从人性的角度而言,领导的示范作用存在的极大的影响力,如果领导都无法正确实施具体措施,要求员工达到某一目的是难以完成的

再举个例子,一个知乎上比较有趣的问题 《为什么公司永远都问不到员工离职的真实原因?》 https://www.zhihu.com/question/493844417/answer/2241701624

参见上面的回答,其实很简单,如何为团队打造可信的环境,什么是可信的环境,即员工提出的问题能够被正视,被解决。如果团队做不到这一点,则其内核是分崩离析的,自然而然的产出就会变得更低。

说完了工作,再说说生活

今天24岁了,虚岁25岁,2月提出了离职,离职原因其实挺复杂的,当然和老板只是说自己想回老家发展了,二月底正式离职,这段时间基本上都放在自己的知识体系的整理上了。对于工作的角度而言,还是期望能找到一个简单与高效的团队,在一个方向深度耕耘3-5年,从而形成自己的最佳核心竞争力,虽然前五年锻炼了自己不少的复合能力,但就某一方向而言,还需要不断的挖掘,今年打算开始考高级架构师的证书,作为能力的一些补充,同时还是希望花上一到两个月的时间里,寻找到合适且靠谱的团队去做一些更有深层竞争力的事情。

另外关于博客最近开始也会不断更新,侧重点还是技术方向上的内容,输出内容其实是对自己的知识体系的整理,这块之前由于工作繁忙放下了很长的一段时间,最近开始要加强这块的内容,把自己所学的内容进行一个汇总与串联。

今天就先到这里了,就这样!