工作月报第2月

换换脑子,把这个月的月报写了。上回发月报,有人问我为啥才工作一个月,那是从正式入职开始算的。我在公司都干了一年多啦。

这个月参加了不少培训,我想一想我都经历了什么。看板培训,PM培训,职业能力培训。

注意,本文没什么条理,想到啥说啥,为不好的阅读体验感到抱歉。而且仔细想想也没啥可说的啊..

本文字数:2973

  1. Coding

从本周开始应该就能着手弄一些自动化测试+云端设计的事了,开心。大概1个月前的时候,我被单元测试深深吸引,当时认为一定要搞起来单元测试,但随着代码开发工作的进行,我发现单元测试真的听不好搞的…首先就是基本的功能代码还没跑顺呢,更别说单元测试了,都没法写。而且作为一个前后端都有的系统,我遇到的那些系统故障,很多都是前后端结合在一起才会出现的问题,或者是每个模块作为一个独立模块的输入输出都没有问题,问题出在他们组合在一起的时候,比如执行的先后顺序,读写的冲突等等。

也就是说,感觉很多问题不是说单元的编写质量不行,而是一开始我们对模块和模块之间的一些关系考虑欠妥,或者没有考虑,一些多个模块之间的调用关系是一边编码一边完成的,那么对这种问题,我感觉单元测试也有些无能为力…总之单元测试这事我估计短期之内是弄不成了,因为显然更紧要的事情是系统整体的测试和压力测试。不过幸好我们的模块粒度还都搞的挺小的,输入输出也都比较明确,而且有实实在在的API文档,所以感觉代码质量不是个大问题。

  1. 前端

最近这半个月看了不少前端代码你敢信?React。虽然我现在还写不动React,读也读不太懂,但是照猫画虎改改小功能还是能改的…其实React给我的感觉,也是一个后端系统。就是说React内部也能分为前端和后端,然后React的后端需要增删改查数据的时候,再调用真·后端API。

一点想法,虽然现在前后端分工很明确,但我觉得没有必要说自己“不会前端”或者“不会后端”,都是编程,不一样的地方无非就是语言(比如Golang和JavaScript),思想(比如面向对象和函数式),运行环境(比如Linux和浏览器),没必要都弄的特别懂,但我觉得看一看还是没问题的。有点像游泳和自行车,如果觉得自己不会游泳,觉得自己不会自行车,那必然是真的会不了了。如果一个人学了好几个月的自行车或者游泳,发现自己真的学不会,那我觉得这属于没有办法,但绝大多数情况下是没有尝试,或浅尝辄止。前端后端这种分隔亦如是。如果一个人认定自己是个搞后端的,前端的东西都不感兴趣也不想看,多没意思嘛。

  1. 看板

先说说看板培训。“看板”这个词给我的感觉怪怪的,就是总感觉和“用来看的板子”没啥太大关系,而且Jira系统上,看板的后面还有个(Kanban)。后来在网上查了下,这其实是个日语词,是指一种生产流程管理方法。

说实话,看板方法的思路我没太整明白,只是模模糊糊有一些感觉。培训的时候我们玩了一个看板沙盘模拟经营游戏,游戏给我的感觉有点像CPU流水线的思路:通过给一个工作的不同阶段分配不同的人力、资源,尽可能减少工作的停滞(我理解就是所谓拉式生产中的减少库存),尽可能减少出现工作不饱和的情况,在CPU流水线里就是所谓“stall”,让整体流程的收益最大化。

不过,对应到我的实际工作中,这种看板方法可能作用一般。比如,我认为看板方法比较适合一个大团队,团队里有开发队伍、测试队伍、产品队伍等,一个工作在多个组之间流转时,用这种方法会比较好,如果是一个小组把这些事都干了,用一些方法反而会增加负担,且投入到实践流程方法上的时间得不到足够的收益。也就是说,对于应用瀑布开发模型的团队,可能看板方法会更有用。

话说回来,“看板”这个东西是那种典型的,你在互联网上能够搜索到一些资料,也有不少中文资料,但是就是读不太懂的东西。根据我的经验,一个中文文章的每个字我都认识,但是串在一起就是读不太明白,这很有可能是个翻译来的文章,要么就是我对文章中所涉及到的业务并不太懂。

对于我个人来说,Gitlab的里程碑功能就足够用了。通过里程碑,我可以看到我已经干了哪些工作,还有哪些工作要干,我的同事们在做什么工作、提交了什么代码,里程碑(通常以周或者重大事件为单位)的完成度如何。其实燃尽图是个不错的可视化图表,但是公司的Gitlab版本(社区版)没有燃尽图功能,orz。

之前跟同事们有过一些敏捷开发方法的讨论,我们一致认为,工具是服务于人的,只有人先敏捷起来,才能使用敏捷开发工具、从敏捷开发方法中收益。要是人没有相应的意识,整啥方法都会显得无力。

  1. PM

PM = 产品经理。

两天在成都的PM培训,围绕着“需求”这个点展开。听了听还是很有启发,尤其是第一天的培训,从宏观的角度讲需求这件事,收获很多想法。

我觉得,做好一个产品经理呢,一个很重要的能力就是在开发者和使用者之间自由地切换,也就是需要具有同理心、换位思考的能力。尤其是在确定需求的这个环节。当然了我并没做过产品经理,所以这都是我瞎猜的,欢迎大家拍砖。

举个例子,昨天晚上和牛畅去看电影,电影院的座位挺高级,可以扫码按摩。其中,19元60分钟那档很划算,而且还能送优惠券,但如果想购买这档,就必须收优惠券;想收优惠券,就必须用手机注册。在输入手机号后点击“发送验证码”时,系统弹出了一个提示,“余额不足”。你说这个“余额不足”的提示,是给消费者看的呢,还是给开发者看的呢?我作为一个开发者,我能想象这也许是因为商家的第三方短信API欠费了,开发者在开发的时候为了方便,会把这些信息打到前台显示。那对于一个消费者来说,他能不能够理解这个“余额不足”是什么意思?微信钱包余额不足了吗?这就很令人困惑。

如果这个产品有产品经理的话,我觉得这个提示就是一个失误。其实我们现在做的产品,我仔细琢磨了一下,也有这种问题。有些报错信息,你说不好是给开发者看的,还是给用户看的。尤其是,如果用户看到了一个报错信息,你期望他下一步做出什么行为?是给技术支持反馈?还是查看帮助文档?还是重启机器?一个交互上好的产品,不能让用户产生茫然无措的感觉,这是我的想法。

回到需求这件事上来,讲师还讲了很多跟客户交流需求的方法。比如说,你问客户这个功能您想不想要,客户八成说想要。如果这样下去,需求就会越来越膨胀。令客户满意的不会是一大堆平庸的功能,而是一两个能够真正解决他的痛点需求的功能。

讲师还列举了一个数字,说是软件系统的绝大多数缺陷,都是在需求阶段就已经引入的了。仔细想想我觉得挺有道理。感觉有点像一个混沌系统,越早引入的因素,在后期可能产生越大的影响。咱们倒着想想,一个产品在部署运维阶段,程序运行在Linux、英特尔的CPU这些非常可靠的东西上边;程序员的水平有高有低,在代码编写阶段,如果有约束和边界都非常清晰的文档,编写的程序的质量,还能有数量级级别的差距不成?而且也都依赖于Goland、Go语言编译器这种非常可靠的东西。再往前推,到软件的需求分析、设计阶段,这个阶段最需要依赖的东西是什么呢?…我觉得是人的大脑。因为最原始的需求可能只是客户的一句话、一个想法。一个“码农”,也许能把模块从详细设计翻译成可运行的代码,但把需求翻译为概要设计乃至详细设计的过程,应该是比较难的、比较依靠人的能力的。

最近在看《人人都是产品经理》,看完后再分享分享自己对于产品的想法。这本书的作者在写成本书时,不过工作4年而已。

  1. 职业能力

也是两天的培训,一件事情给我的印象最深。根据一个自评问卷,我是全场唯一一个面对“关键对话”时,倾向于采用“语言暴力”的人(其他小伙伴们都是“沉默”类型)。关键对话的定义是:1. 事关重大 2. 情绪激烈 3. 意见不合 的对话。

想想也不奇怪,跟我共事过的小伙伴,应该都能感觉的出来我是一个在“关键对话”面前非常主动,但是容易丧失耐心的人。有什么可着急的呢?…对吧,其实也没啥可着急的。而且我这个人有一个非常大的缺点,就是我太容易过度自信,对一件事情的判断,即便我大脑皮层没什么想法,但我在潜意识中容易认定我一定是对的(当然打脸的情况居多)。畅所欲言而又不失谦逊,是我努力发展的方向。自信不是什么坏事,我在成长的过程中(尤其是最近这几年吧),因为自信的性格收获了很多…总之还是要踏实一点。

培训中还讲到一些其他的职业技能,发邮件、Excel、PPT啥的,别的不知道反正我PPT是比较弱渣,我喜欢站在台上讲,我不喜欢太复杂的PPT,如果是我讲课的话,其实我就不爱用PPT。吴军的得到专栏中专门讲了很多大学和职场的话题,有些文章我反复看了很多遍,收获很大。有些东西也落实到平时的工作中去了,一定是有收获的。

产品能干的事太多了,一个一个来吧,每一个都很有挑战。

2018年9月10日