王辉的博客

是什么让我对未知世界始终充满热情?

0%

我们约好的是十二点见面,后来被推迟了,因为他要见客户。中午饭没能在一起吃,下午两点和他见着了,在分别了三年之后。

我们是老乡,都生在河南商丘。也是在法国求学时的校友,他读博士,我攻工程师。他自己动手作过馒头,从和面,发面,揉馒头,到下蒸锅,确实有一手。后来他学成回国了,带回去了一个媳妇,在法国认识的北京妞。走的时候,他把蒸锅留给了我。我学完直接留在法国工作了。

后来,从朋友圈里得知他创业了。我又找到了他。因为我也有一颗不安的心,即使工作三年之后的我已经过上了小康生活。

两点多见着他的时候,他的面庞依旧是那么的棱角分明。此刻的棱角分明,已不是青春小说里俊美男生式的棱角分明,而是经历过风雨雕琢后的分明。略高的颧骨,加上头上冒出的几撮白发,不禁让我想到沙漠中经受风蚀的石头,几分凉意侵入心中。他的穿着很朴素,要不是知道,我万万不会把他和电视里光鲜亮丽的CEO联想在一起。

他把我们带到了大厦后的星巴克咖啡馆里。我要了杯咖啡,他只点了一杯白水。三年,可以发生很多事情在一个人身上,也可以只简简单单的让他老三岁。不知不觉聊了三个小时,听完他创业的故事,我觉得他的白开水比咖啡浓。

后来,到了大厦的十五楼,他们的办公室,地方不大,四五十平米的样子,摆满了办公桌。进门的时候,大家纷纷把目光投向了我,我看到的是一群年轻并且富有朝气的面孔。一一握手后,我给他们讲了一些我工作中学到的知识和总结的经验。他们听的很认真,不少人拿着小本做着笔记。可以感受到他们学习的积极性。

讲完,大家所有人到楼下吃了西少爷,来自西安的快餐,豆花加肉夹馍。吃完饭,七点了,他们又陆陆续续回到了办公室,赶任务。

我又和他聊了许久,他讲到了他遇到的困难,高高的股份,低低的工资,家人对他的不解,商场的黑暗,技术上的困惑,招人留人的烦恼,管理上的摸索,国外国内的落差。但他很坚定,千难万苦,不曾动摇。

这就是我看到的一个创业者,一个可敬的创业者

工作了四年以后,我升职为高级软件工程师。这里的升职不是管理上的提升,其实我现在只需要管好我自己,而是对一个软件工程师成熟度的认可。一个高级工程师,较之一个刚毕业的新手而言,他应该能够独立的推进一个项目,从技术,到和其他组的交流协作,都能够独当一面。我最近遇到的一个难题,就是如何和产品经理有效的协作来保证项目的进度。后来学习到一个秘诀,就是要别人的承诺。

具体的故事,是这样发生的。我和项目经理,一起制定使用者剧本(user story),会议结束的时候,我们分了工。我的项目经理,要先在这些剧本里,加入验收测试,然后,我再预估它们的复杂度。换句话说,我的任务依赖着他的,他做不完,我就起不了步。

当天下午,大家很高心的散会了。第二天,我问他测试写明白了吗。他说他明天给我,我说好吧。可第三天,依旧没写好。我问他,他又说再等一天。三天过去了,剧本没写好,没测试,我没开工。

后来我的上司看到了,略有不爽,他说,怎么都第四天了,还没有开工。我当时想辩解,说不是我的错,因为我得等别人的活完了才能开始自己的,我是被别人耽误了。后来想辩解也没有意义,特别是这种推卸责任的辩解更没有意义。我的产品经理,当时也意识到自己确实没做好,在第四天,他写了测试。

后来,我找到了老板,高级高级工程师,问他我在这种情况下,应该怎么办?他给我讲了一下他作为新手时犯的错误,也给我说了一个解决办法。

在他是新手的时候,如果他依赖的人太慢,我老板就自己替他人把活做了。这样进度会有,但不是长久之计。首先,替他人把活做了,僭越了不说,到时候万一你做的并不是人家的本意,之后还得重头再来,特别是这种产品经理写验收测试的活,程序员一定要让他们从产品,从用户的角度来写测试,不能以程序员对产品的理解去写。其次,即便替人做的好,可自己的精力毕竟有限,不能作为长久的打算。

所以不可取,那么什么可取呢?回到我的经历中来,第一天,大家高兴散会的时候,不能就那么散了,而要问清楚,你什么时候能给我一个满意的答复,我们需要对方的一个承诺。承诺的远近并不是问题。远了,说明他有优先级更高的事情要做,要么,我不能干等,要么,我们把问题上传给决策者来重新讨论优先级。近了,更好。承诺的重要性在于明确各方的责任点和责任段,是为了更有效的交流,不至于把时间用在等待里。

技术负债,指的是为了实现客户的某个需求,而做出的一种短期见效快,长期有伤害的,在技术层面的决定。更通俗的讲,就是坐在代码面前,只顾现在,不管将来。代码满足了客户的需求,却写的很糟很乱,为以后进一步开发新功能,做了一个坑人的铺垫。

上面讲的是技术负债的大概意思,下面讲以一个亲身经历的故事,想说明的是,技术负债,如果你当时不还的话,一旦错过了那个村,以后就很难再找到那个店,想还就难了。

出于不能透露公司秘密的目的,我就只笼统的说一下,(其实和模拟金融产品的收益与亏损有关,;p)。那是一个规模挺大的开发,引入了不少新功能,用了基本一年的时间。出于模块复用的原则,也就是不再造车轮的原则,我们最大限度的重用了原有的模块。由于原有模块的使用情景和新功能的情景大有差别,在重用之前,我们先改了原有的,使它从不可以被重用改善到可以用。说实话,改的有点牵强。

新功能实现了之后,客户很开心。可我们,总感觉有些地方不太对,略加分析,发现,两个不同情景下的模块有不少共同之处,其实当初应该再往前走一步,把共同的部分隔离出来,写一个更加抽象的模块。把确实存在差异的部分放在不同的模块里。

我现在说的听起来容易,其实做抽象没那么显而易见。这要求你,从更深次的角度去分析两个不同的问题,融会贯通,找到它们的共同点。抽象,在编程的各种能力中,处于一个很靠前的地位。

问题发现了,可我们却作难了。为什么?因为新功能已经交付了,客户也很满意。你现在非得给客户说,能不能再给我两万块钱,让我好好抽象一下。哈哈,你不是在搞笑吧?给你钱让你抽象?!你抽不抽的好是一方面,万一把原有的东西也破坏了,你这不是让人家客户抽搐吗。

其实我们的客户不是那种不懂开发油盐不进的客户,他们也知道,现如今不抽,以后再开发新功能的时候可能就会更难。可是既然新功能好用,他们又有很多其他方面还没实现的想法要做,他们更倾向于立即着手于其他的项目,等以后有时间了,也有闲钱了,再让我们搞那些很抽象的工作。

可你仔细想想,谁会有时间,谁会有闲钱?所以技术负债,就像打尖住店一样,过了那个村,就没那个店了。

真的就没有解决方法了吗?我思来想去,结论是没有什么神奇的方法可以解决所有的问题。

你可能会说,留在那个村,别走,解决完问题,再走不就行了吗。我同意这个观点,留在那里不走可以,前提是你给客户预先说好,你需要多少时间,多少预算,才能把问题解决的好。可实际情况呢,很多潜在的问题,在项目初期很难被发现,很多问题都是在实践的过程中发现的。敏捷开发,有利于解决类似的问题。但是越是到后期,和技术负债相关的请求,就会越难被接受,因为的他们的投入产出比小,风险大。更糟糕的情况是,有一些东西,是需要事后的消化,后知后觉的,就像我上面遇到的情况一样。

设计重要,前期周全的设计更是重中之重。小的负债一定要在它的萌芽阶段就消灭掉,越早越容易说服别人。

谢谢您逗留阅读,我是热情洋溢的程序员,王辉。