软件开发的正确思维,聚焦高杠杆活动

作为技术序列的工程师,我时常在想,什么样的角色将会是我五年、十年后所扮演的。目前来说,工作三年有余,在某些公司内,已经可以算是高级甚至是资深工程师。不过,对于我来说,赋予title起的作用,并没有做成一件事兴奋。我时常在好奇,别的工程师的工作方法和我一样吗?我目前的工作方法是最优的了吗?

带着这样的疑问,也关注了硅谷大厂程序员的一些博客,同时也阅读了一些软件开发的经典之作,例如《人月神话》、《大教堂与旧集市》、《程序员修炼之道》等。这些内容都是很好的基础,为我软件开发的职业道路,树立了基本的职业价值观。不过今天,要推荐另外一本书《The Effective Engineer》。本书目前还没有中文版本,作者经历过硅谷的大小厂,Google、Quip、Quora等,从他的角度,总结了一些很有道理的内容。

该书的核心,聚焦在一个杠杆二字。所有活动的目的,都是最大化杠杆的效果。这点和的之前讲的财富38条法则不谋而合。在上次的法则中,同样强调了杠杆的效用。而软件开发领域,本身就是一个高杠杆活动。你开发的软件,可以只供团队内数十人使用,也可以供数以亿计的用户使用。

该系列整体分为三条,咱们逐一拆解。

软件开发的正确思维

聚焦高杠杆活动

作者认为,软件开发的核心:不是用了多么炫酷时髦的技术,不是你懂的技术别人不懂(技术垄断),而是解决业务问题。只是恰巧,工程师的角色定位,让我们能够借助软件程序解决问题。

在这个过程中,去聚焦高杠杆活动,充分发挥软件程序的优势。用杠杆率去衡量自身的产出,有计划地增加杠杆的效率。

例如:有没有方法更快完成项目?有没有方法让项目的作用更大?如果不做这个项目,有没有其他杠杆率更高的项目?

优化学习

这里的核心观点在于,学习是存在复利效应的。无论外界如何变化,一定要掌握自己的学习节奏。寻找能够提供成长的环境,结合工作中的其他人的能力,提升自己的能力。除了工作内容,工作外的技能也应有所精进。

更迭优先级

我们都知道,事情可以根据四象限法则,分为重要紧急、重要不紧急、不重要紧急、不重要不紧急。最后一个能不做就不做,倒数第二个能晚做就晚做。前面两个优先做,重点做。

在这一环节,聚焦能够直接产生价值的地方。如果担心被打扰,则可以设置一个番茄闹钟,以减少场景切换的可能。为了减缓拖延,可通过自我目标设定,自我陈述的方式:”如果,就“来有序安排工作。

在执行上下功夫

投资迭代

在软件开发领域,有一个著名的MVP理论,即最小可行性原型。该方法除了快速验证假设外,也起到快速迭代的作用。迭代越快,我们能学到的就越多。熟练掌握工作,多在迭代上下功夫。

测量指标

没有测量,就没有改进。这是著名管理学理论。在软件开发领域也是如此。当然,衡量程序员的产出,不是靠代码行数或者bug数,而是其实际的产出价值。这也要求我们谨慎地选择衡量指标。理解数字,诚实看待数字。

尽早验证想法

一如前面的MVP原则,我们尽早验证想法,通过迭代减少浪费。如果有必要,我们还可以通过A/B测试,来检验实际效果。

项目评估技巧

大部分时间,我们也会面临项目周期评估的问题。作者建议,在排期中设立回旋余地。拆分项目,设置合理的里程碑。优先处理高风险的事项,能一定程度保证项目如期交付。如果延期不可避免,则也应该对延期时间有个合理的评估。

构建长期价值

实用与质量的平衡

多快好省赶紧上,这种思想也会出现在软件开发领域。这本身与快速迭代并不矛盾,但要注意平衡好开发周期与质量的矛盾。CodeReview、自动化测试,能够一定程度减少出错概率。项目发展过程中的技术债,要得到有效管理。不可一味堆叠需求而忽视技术基建。

减少维护成本

在项目上线的维护过程中,也需要留意维护的成本。开发代码过程中,将错误有效暴露。同时进行链路上的故障演习,合理安排兜底策略,将有效减少维护成本。

投资团队成长

从长远来看,每个人都不可能单兵作战取得巨大的成功,我们需要团队。投资团队成长方面,首先是帮助其他人成功。这可以通过分享自己的经验,写下高质量的文档实现。也可通过CodeReview实现。另一方面,招聘是团队内每个人的责任。招聘高质量的同事,在入职培训和指导方面下功夫,也将获得极大的回报。

小结

以上,是该书的基本框架。总体读下来,对于我还是收益颇多。后续一周,我们将展开讲讲每个环节,结合我自身的工作经历,给读者朋友提供更核心、易懂的理念。

关于作者