前言:
本篇博客内容来源自:极客时间课程《10x程序员工作法》处于学习记录。将个人认为比较重要的知识点进行摘抄记录。有兴趣的同学去极客时间学习完整课程。
一、 精益创业:产品经理不靠谱,你该怎么办?
精益创业到底说的是什么呢?其实很简单。我们不是要面向不确定性创造新事物吗?既然是不确 定的,那你唯一能做的事情就是“试”。
怎么试呢?试就要有试的方法。精益创业的方法论里,提出“开发(build)- 测量(measure)- 认知(learn)”这样一个反馈循环。就是说,当你有了一个新的想法(idea)时,就把想法开发成产品(code)投入市场,然后,收集数据(data)获取反馈,看看前面的想法是不是靠谱。
精益创业提出一个非常重要的概念,最小可行产品,也就是许多人口中的 MVP(Minimum Viable Product)。简言之,少花钱,多办事。
精益创业提供给我们的是一个做产品的思考框架,我们能够接触到的大多数产品都可以放在这个框架内思考。
一句话总结:
默认所有需求都不做,直到弄清楚为什么要做这件事。
二、 解决了很多技术问题,为什么你依然在”坑”里?
你在项目里打杂,你只能关注到一个具体的任务,而项目主力心目中是整个系统。虽然写的代码都一样,但你看到的是树木,人家看到的是森林,他更能从全局思考。
跳出程序员角色思维,扩大自己工作的上下文
虽然我不是项目主力,但不妨碍我去更深入地了解系统全貌;虽然我不是项目负责人,但不妨碍我去了解系统与其他组的接口;同样,虽然我不是项目经理,但我可以去了解一下项目经理是怎样管理项目的;虽然我不是产品经理,但了解一个产品的设计方法对我来说也是有帮助的。
当你对软件开发的全生命周期都有了认识之后,你看到的就不再是一个点了,而是一条线。
现在你知道为什么你的工作总能让老板挑出毛病了吧!没错,工作的上下文不同,看到的维度差异很大。单一维度的思考,在多维度思考者的眼里几乎就是漏洞百出的。
程序员总喜欢用技术去解决一切问题,但很多令人寝食难安的问题其实根本不是问题。之所以找不出更简单的解决方案,很多时候原因在于程序员被自己的思考局限住了。
不同角色工作真正的差异在于上下文的差异。在一个局部上下文难以解决的问题,换到另外一个上下文甚至是可以不解决的。所以说无论单点有多努力也只是局部优化,很难达到最优的效果。
想把工作做好,就需要不断扩大自己工作的上下文,多了解一下别人的工作逻辑是什么样的,认识软件开发的全生命周期。扩大自己的上下文,除了能对自己当前的工作效率提高有帮助,对自己的职业生涯也是有好处的。随着你看到的世界越来越宽广,得到的机会也就越来越多。
一句话总结:
扩大自己工作的上下文,别把自己局限在一个程序员的角色上。
三、 为什么说做事之前要先进行推演?
结果是重要的,然而、通向结果的路径才是更重要的。
对比我们的工作,多数情况下,即便目标清晰,路径却是模糊的。所以,不同的人有不同的处理方式。有些人是走到哪算哪,然后再看;有些人则是先推演一下路径,看看能走到什么程度。
- 在做一个产品之前,先来推演一下这个产品如何推广,通过什么途径推广给什么样的人;
- 在做技术改进之前,先来考虑一下上线是怎样一个过程,为可能出现的问题准备预案;
- 在设计一个产品特性之前,先来考虑数据由谁提供,完整的流程是什么样的。
在软件开发过程中,我们就假设软件已经就绪,看就绪之后,要做哪些事情,比如,如何上线、如何推广等等,这样的推演过程会帮我们发现前期准备的不足之处,进一步丰富我们的工作计划。为了不让我们总在“最后一公里”摔跟头,前期的推演是不可或缺的,也是想让团队进入有条不紊状态的前提。
一句话总结:
在动手做一件事之前,先推演一番。
四、 你的工作可以使用数字衡量吗?
一些人说,自己靠直觉就能把事情做好,其实这是一种误解,因为那种所谓的直觉,通常是一种洞见(Insight),洞见很大程度上依赖于一个人在一个领域长期的沉淀和积累,而这其实是某种意义上的大数据。
结合着“以终为始”的思考,如果我们可以在一开始,就设计好测量工作有效性的指标,那么就可以更有目的性地去工作了。
而如果我们习惯了用数字去思考,就可以在很多方面让数字帮助我们。我举了几个小例子,比如:基于数据进行技术决策、预先设定系统指标,以及发现系统中的问题等等。希望你也可以把数字思维带到你的日常工作中。
一句话总结:
问一下自己,我的工作是不是可以用数字衡量
五、迭代0:启动开发之前,你应该准备什么?
所谓迭代 0,就是在迭代 1 之前的一个迭代,所以,我们可以把它理解成开发的准备阶段。
根据我的经验,对比这个清单,大多数新项目都在一项或几项上准备得不够充分。即便你做的不是一个从头开始的项目,对照这个清单,也会发现项目在某些项上的欠缺,可以有针对性地做一些补充。
一句话总结:
设计你的迭代 0 清单,给自己的项目做体检。
总结:
在这个模块中,我们学习到了一些行业最佳实践。
- DoD,确定好完成的定义,减少团队内部的理解不一致。
- 用户故事,细化出有价值的需求。
- 持续集成,通过尽早集成,减少改动量,降低集成的难度。
- 精益创业,减少过度开发不确定性产品带来的浪费。
- 迭代 0,在项目开始之前,做好一些基础准备。
还学习到一些重要的思维转变。
- 任何事物都要经过两次创造:一次是在头脑中的创造,也就是智力上的或者第一次创造(Mental/First Creation),然后才是付诸实践,也就是实际的构建或第二次创造(Physical/Second Creation)。
- 在更大的上下文内发现自己的“终”。
- 通过推演,找到通往“终”的路径。
- 用可度量的“数字”定义自己的“终”。