本站首页 返回顶部 关于博主

番茄工作法不适合程序开发

最近又有朋友在朋友圈推荐番茄工作法。作为一枚码农,说实话,我很不推荐在软件开发过程中采用番茄工作法。
软件开发是一项精神高度集中的脑力劳动。在编程过程中,需要长时间的专注,稍微地打断一下很有可能得话费很长时间进入打断之前的状态。而番茄工作法以25分钟为单位造成的后果就是刚刚进入状态很快就被打断,严重降低写代码的效率。在工作中,在家上班一天的效率很多时候比在公司上班两天的效率还高,就是因为在家干扰小,容易精力集中。
对于不必长时间专注的工作,可以使用番茄工作法。如果自身很难精力集中,或者做一些枯燥或很难让人精力集中的事情,番茄工作法倒是一个不错的选择,它能很大程度地提高效率。

吃饭与团队满意

–由吃饭想到的

吃完饭回来的时候,团队的一哥们偷偷对我说,“Frank,没想到你会拿自己的award请大家一起吃饭,太令人感动了。”
这哥们继续说,“如果PM都你这样,能处处能为我们着想就好了。”

其实,这哥们没有全面了解我请大家吃饭的原因。让大家开心,只是原因之一。
半年前,公司新成立一个重要性很高的项目组,从各个部门借调人手做这个项目,于是我从原来部门借调出来加入这个临时的项目组。
最近项目刚结束,邀请项目团队的核心成员给原来的部门做了次技术分享,然后申请了一个award,最后用这个award来请大家吃饭。

这不是工作必须的,我为什么要做这么做呢?
作为项目经理,工作目标无非是三个目标:让领导满意、让团队满意、让我自己满意。而我所做的,就是为了实现这三个目标。
怎样让领导满意呢?在这个项目里,按期保质保量完成任务,项目的直属领导满意;让团队成员向我所属的部门做技术分享,让原部门领导知道我的成绩,部门领导也满意。
怎样让团队成员满意呢?在项目过程中,从团队成员的立场思考问题,帮助大家解决问题,与此同时,以请吃饭的方式提高团队的满意度。
怎样让自己满意呢?向领导展现我的个人能力,提高在公司的曝光度,这对以后升职加薪有好处;向团队成员展现我的友好并获取大家的信任,毕竟以后大家有需要帮助的可能。

有感PMI Exam Dev Workshop

有幸参加了PMI协会在上海举办的PMI Exam Development Workshop活动。这是PMI协会第二次在中国举办此活动,上一次是2009年北京。
我第一次参加,感觉收获很多。

我们知道,PMI考试题库中的考题一直在不断地完善中,这就需要不断地淘汰旧题目,引入新题目,这次活动的目的就是补充新考题。整个活动分2个主题:评审已存在的题目和添加新的题目。

第一天下午主要是PMI协会高管的演讲。
第二天工作内容是评审以往的考题。部分考题来自题库中不计入考试分数的题目,部分来自其他PMI Exam Dev Workshop提交的题目。每个题目都会对应到项目开发周期中相应的领域(Domain)和任务(Task),无论是题干,还是选项都有很严格的要求。这种出题的方式对其他行业出考题还是很有借鉴意义的。因为签过协议,在此不方便提及更多题目相关的内容。
第三天工作内容是自己写题目。由于头一天评审过题目,所以基本上已经驾轻就熟了。大家可以参考自己以往的工作经验,项目中碰到的问题或经验,然后写出来。题目完成之后,与其他组相互评审,最后成题。

总结一下:
1.在项目管理方面有些新的感触。一方面来源于第一天PMI协会高管的演讲,另一方面,接下来两天评审题目、写题目,参考资料,讨论问题,相互交流。
2.认识了不少朋友。毕竟,扩展社交圈对个人的发展是很重要的。

余额宝和股市有关系吗?

关注余额宝也有一段时间了。
前段时间A股一路下跌,而余额宝的利率一路上行。我就开始胡思乱想,年底银行缺钱,只好提高利率吸引储蓄。同样的理由导致余额宝这类货币基金的利率也高高在上。难道是这个缘故致使股市大量资金流出,从而导致股市一路走低?那月初开始余额宝的利率不断下降,是否有资金流向股市呢,这预示着A股即将见底反弹?
余额宝这类货币基金和股市是否存在这样的关系:余额宝利率涨,则股市跌;利率跌,则股市涨。

大胆假设,小心求证。
要印证我的想法,先从余额宝和股市的数据着手吧。
于是从网上找最近半年来余额宝的收益走势图和沪深两市的股指数据,数据来源如下:

把数据整理好,然后生成line chart,相信应该能从chart的走势看出点名堂。
生成chart之前,我猜,沪深股市是联动的,所以它们的走势应该大致差不多吧。呵呵,生成的line chart印证了我的想法,这哥俩指数的队形保持得相当好。

上证指数与深证成指

那余额宝和股市的关系呢,二者的涨跌关系如我所料的相反吗?在生成chart时,我准备把chart的primary axis设为余额宝的万份收益,从小到大;把chart的secondary axis设为上证指数,从大到小。如果猜测正确的话,那它们在line chart中的走势即使没有上证指数和深圳成指那么一致,应该大致上不会相差太远吧?
于是,根据数据我生成了如下line chart。

余额宝与上证指数

从6月30日到9月30日的数据感觉有些杂乱无章,9月30日之后的数据好像走势有点类似。它们到底是有关系呢,还是有关系呢?如果没有一定的标准,仅仅用肉眼来判别人走势是否一致,是不是太牵强?肿么办捏?值得庆幸的是,一个同事告诉我,有现成的算法来计算两组数据之间的关联程度,在Wikipedia上,可以找到Pearson product-moment correlation coefficient算法:

cor公式

这种算法用来计算两组数据之间的线性相关程度。计算结果是-1到1之间。如果结果越接近0,那它们的相关性就越小;越接近-1或1,相关性就越大。
同事还告诉我,在自然科学的统计中,如果超过0.7,那就认为相关性很大;对于社会科学,因为参杂了太多的认为因素在内,如果超过0.6,就认为相关性比较大了。
让人振奋的是,有一种称之为R的统计工具,内嵌了很多统计算法,只需要调用cor()函数就能得到我要的结果。实在太好了,我不必重新发明轮子。

到官方网站http://www.r-project.org/下载R,安装。
分别把余额宝、上证指数、深圳成指的数据输出到3个文件中,然后通过scan()导入到三个变量中。
调用cor函数,把上证指数和深证成指代进去,得到结果0.945。嗯,意料之中,相关性非常大。
把上证指数和余额宝的万份收益代进去试试看吧。汗,结果让我大吃一惊,竟然是-0.135。这个结果实在太令人沮丧了!

从图形上来看,9月30日之后的数据似乎走势差不多,它们还是有关系的吧?要不要代进去试试看?可这是一组我刻意选择的样本,即使相关性大,似乎也不能说明它们有关系吧?别想那么多,还是先试试看。
如我所料,上证指数和深证成指的相关性是0.975。
上证指数和余额宝的相关性仍旧是很低的-0.136。汗,看走眼了,看来它们本就是貌合神离的两个,没法凑成一对的!

好吧,是我想多了。令人失望的-0.135和-0.136,基本上证明了我的猜想纯粹是扯淡,二者没有线性相关。

自我安慰一下吧,说不定二者之间存在着某种我不知道的曲线相关性;或许二者的相关性在时间上有一定的滞后;也或许二者有一定程度的联系,只是并不占主导因素,被其他的因素给湮没,从而导致让他们看起来关系不那么大;也或许是样本太少,很难体现他们的相关性;也或许是余额宝在成立之初,各种因素太多,它的走势并不是货币基金走势的真实体现;也或许… 算了,不必找太多借口。总之,在个人能力范围之内,从现有的数据来看,我只能得出二者没有关系的结论。
以后学点经济学的知识再进一步研究,至于今天,还是洗洗睡吧。:(

以上部分完成于2014.01.24,以下部分为2014.01.27新增。
多谢Jerry的提醒,在处理数据之前,应该先剔除干扰点。
在R中,通过plot()函数,我得到了余额宝的数据分布图,如下:

余额宝数据范围

很显然,绝大部分数据都集中在0.8到2之间,唯一有个数据达到了3.6037。查看了下历史数据,在3.6037这个数据之前,连续2天没有数据更新。严重怀疑这个3.6037是3天数据的总和。于是,剔除这个干扰数据之后重新计算。
上证和余额宝的相关性为-0.315,从余额宝成立至今到现在,看起来应该没有相关性。
2013.09.30到2014.01.21的上证指数和余额宝的相关性为-0.749,应该是有相关性。
当然,由于后者是我刻意选择的数据,加之样本数目太小,很难断定它们就是相关的。继续观察吧。

人机交互中错误信息的显示

中午去招行取钱。插卡,输密码,输金额,然后出来一张凭条,却没有出钱。凭条上写着响应码:55,TxCode:01。屏幕上没有任何错误信息。

我的疑问来了,钱没取到,那钱扣了吗?由于ATM机上无法查询交易记录,我只好通过手机银行查询了交易记录。查到今天没有取钱操作,这时我才放心,取钱失败,钱没有扣掉。

事后,在网络的帮助下,我查到响应码来自银联,55意味着交易被拒绝,原因是“Incorrect personal identification number”。

假设一下,如果没有手机银行,当时我会怎么做呢?打95555,告诉客服事情的经过,然后客服会根据凭条上的响应码告诉我原因和结果。这样,问题也能得到解决。

事情能变得简单一些吗?本质上,这是人机交互中一个易用性的问题,如果交易失败,触摸屏上弹出“交易失败”对话框,与此同时打印凭条。凭条上“响应码”改成“交易结果”,并在备注栏中附上失败的原因,至此,事情得到完结局。这样我的担心就没有必要了,既不必通过手机银行查询交易记录,也不必打95555。方便客户的同时,也减轻客服的工作量。

要实现这样的功能并不难。在原有的系统中,有个变量reponseCode,用来存储响应码的值。现在,我们需要添加2个变量:一个reponseMsg变量,用来存储信息;一个map,用来存储所有reponseCode和reponseMsg的映射关系。其中map的key是reponseCode,value是reponseMsg。所有的responseCode和它对应的reponseMsg是已知的,可以在使用前初始化。当用户进行某些操作后,后端返回reponseCode,可以通过map获取相应的reponseMsg,显示给用户看。reponseCode用来处理逻辑,reponseMsg显示给用户看。至此,我们的方案完全实现。

当然,对于原来的行为,设计者可以宣称:“我们就是这样设计的,它是期望中的行为。如果你不懂响应码的意思,那是因为你对我们的系统还不够熟悉。”设计者这么想也说得过去,但人机交互界面是给用户使用的。站在用户的角度,如果花很少的时间就能熟悉系统,出现问题不需要外界帮助就能解决;站在开发者的角度,实现这样的功能所需要的工作量几乎可以忽略不计。那么我们有什么理由不这么做呢?

在设计人机交互界面时,有条基本准则:错误信息应该以人能够都懂的方式显示出来,最好能让用户知道错误的原因,如何解决。

很简单的道理,但这种问题也很常见。即便是以易用性见长的微软,这种问题也偶有出现。前不久买了台Surface,到手后系统更新,提示错误,告诉我一个错误代码,我google,最终在微软的官方网站上查到错误原因是“系统升级之前应该同步时间”。如果在告诉我错误代码的同时,告知错误原因,哪怕是给个URL,链接到官网上错误原因的网页,也比一个光秃秃的错误代码有用吧。

做了多年的GUI开发,有些感慨,GUI是人机交互的纽带,用户对产品的第一印象往往取决于看得见的GUI。一方面,GUI开发有很多需要改善的地方,另一方面对GUI却不重视。对此,身在其中往往却很无力。

写这篇文章的目的,并非想贬损什么。权当相互探讨吧,欢迎拍砖。