软件开发行业的效率提升

老板最近给安排了个任务——看看怎么提高大家的“效率”。

先说一下背景。我司是一个软件公司,由一群IT屌丝和个别技术宅组成。我们不算是那种“超级高科技”公司,也不是互联网行业的独角兽。我们从事的是金融业务,主要市场在美国。所以,“稳定”、“准确”是日常工作中的两个最高优先级的指标。

可能因为是金融行业的关系(有其一定的壁垒),包括我自己在内,不少员工在这家公司呆的年数都不少。难免的,会出现一些“疲态”。公司对于“稳定”、“准确”的要求又压过了对于“时间”、“周期”的渴望。使得大家慢慢的形成了一种思维:我们慢慢做,东西好就行。在没有竞争的时期固然可以。可是,那都是小说里的情节。纵使是美国市场,也有不小的新兴企业试图进入这么一个领域。各种创新的玩法层出不穷。在这样一个大背景下,老板觉得是时候需要让大家醒一醒了。

shutterstock_256431850

言归正传。在软件行业里评估“效率”并不简单。尤其是只评估Engineering团队的效率。从公司层面来说,我们可以用(产生的利润/投入的资本)来简单计算,但具体到某一个部门,尤其是一个不产生利润的部门,就必须寻找另外一种或直接或间接的方式。我翻阅了近十年的各类文章,它们描述了在不同的软件行业里(嗯,软件行业也分好多种呢)都采用过哪些来衡量效率的指标。尤其是当越来越多的公司开始使用敏捷开发后,衡量指标的变化。这些指标,有的比较简单,就使用一个值来表示。高则好,低则差。有些会考虑各个因素,是一个多维的综合体。但各个维度的权重有时候随意性又很大。不过这并不一定是坏事,不同的维度权重,反映着公司当时对不同维度的看重程度,这本来就是一个会变的东西。

家家有本难念的经。为了更大程度的符合自己的公司的实际情况,我对各个部门分别做了一个Interview。我问了所有人相同的两个问题:1)你们部门觉得什么可以表示“效率”。2)有什么因素妨碍着你们提高前面提到的“效率”。第一个问题能看出这个团队最看重的是什么。第二个问题不但知道大家的痛点是神,更从侧面反映了第一个问题答案的真实程度。这个访谈的效果非常好。不但收集到了很多不同的答案,也看到的一些大多数团队都共有的问题。

综合大家的反馈结果,我提出以下用来反映效率的两个指标:

Snip20180805_1Snip20180805_2

1)在一个工作周期内(比如一个release)所产出的所有故事点数,除以这个周期内总共消耗的人天数

2)在一个工作周期内(比如一个release)花费在产出有效故事上的时间,除以花费在所有故事上的时间。其中有效故事包括功能实现、功能增强、产品支持、测试、重构、调研。但不包括修bug、技术债、功能重定义。

把这两个指标综合起来看,就是一个Engineering团队的“效率”。他们俩没有权重,两者都需要看。任何一个持续降低都需要调查并改进。

至于如何改进并提升效率,经过分析讨论,我们同样提出一下几个方面:

时间管理:

  1. 记录工作时间分配,追踪人员的日有效工作时间,找出瓶颈
  2. 设置每天“勿打扰”时间段
  3. 统一管理对外(其他团队)支持内容和时间
  4. 安装单机分析工具,统计各个软件的使用比例,来发现时间消耗分布
  5. 进行“时间管理”的培训
  6. 减少书面沟通占比
  7. 减少会议频次,减少每次会议开始后的准备时间,按需调整站会时间
  8. 减少日报、周报要求和范围,尽量在站会中搜集信息

解决依赖:

  1. 找出开发流程中仍然存在的人工干预环节,寻找自动化替代方案
  2. 前置解决开发的环境依赖、权限、测试数据等,追踪相关事件的时间消耗
  3. 需要更及时有效的通知下游当前工作已经完成
  4. 需求前置,在sprint开始前确定需求,跟踪开发开始后需求的变化澄清比例
  5. 减少开发环境对工作流程的影响

赋能团队:

  1. 明确每个人的职责,PGM和Mgr更多的分担团员成员的非开发方面的任务
  2. 加强代码审核,单测,文档频次和质量
  3. 减少不必要的状态询问,设定好优先级,让团队自我管理
  4. 及时告知项目变化,以及相应的原因和影响
  5. 定期分析bug产生原因,追踪bug率
  6. 明确以地域区分的ownership,减少跨区域沟通频率和时间,建设local团队
  7. 协调QA和开发的比例
  8. 建立check list来缩短相关项目的配置准备执行时间
  9. 优先寻找本地资源,寻求local团队的帮助
  10. 建立入职培训计划,指导新员工半年内掌握绝大部分工作知识
  11. 相关人员进行轮岗来扩充业务能力和知识面

其他:

  1. 检查环境舒适程度(灯光,通风,气味,温度,噪音)
  2. 适当增加隔断,减少噪音
  3. 拆分更小的milestone,提高每个milestone的交付成功率
  4. 在项目级别做re-work分析,了解需求变化对交付时间和消耗产生的影响
  5. 标准化交付点数统计方法,使得同一团队可持续统计比较

其中提到的很多点,都可以广泛运用在各个公司里。但需要公司上上下下各部门的配合。现在的软件开发,是一个很工程化的东西。就像一条流水线,所要交付的功能在其上不断流转。任何一个步骤没有跟上总体的速度,都会成为大家的瓶颈。提升效率不是一个部门可以做到的事情,局部优化固然重要,从整体的流程上进行改造,配以合适的工具和规则,才能更大的发挥出各个团队的潜能,最终提升“效率”。

Advertisements

《我不是药神》

这是豆瓣上的一部9分热片,也是一部没有好莱坞特效的国产剧情电影,更是一个反映人心之善的故事。该片由真实故事改编,虽然和真实事件不完全相像,但都反映了同一个问题:在救人与违法之间,我们会选择救人。

p2519070834

普通中年男子程勇(徐峥 饰)经营着一家保健品店,失意又失婚。不速之客吕受益(王传君 饰)的到来,让他开辟了一条去印度买药做“代购”的新事业,虽然困难重重,但他在这条“买药之路”上发现了商机,一发不可收拾地做起了治疗慢粒白血病的印度仿制药独家代理商。赚钱的同时,他也认识了几个病患及家属,为救女儿被迫做舞女的思慧(谭卓 饰)、说一口流利“神父腔”英语的刘牧师(杨新鸣 饰),以及脾气暴烈的“黄毛”(章杰 饰),几个人合伙做起了生意,利润倍增的同时也危机四伏。程勇昔日的小舅子曹警官(周一围 饰)奉命调查仿制药的源头,假药贩子张长林(王砚辉 饰)和瑞士正牌医药代表(李乃文 饰)也对其虎视眈眈,生意逐渐变成了一场关于救赎的拉锯战。

大家都生过病,也可能都有过家人因病而离开我们的经历。当病痛袭来,金钱的地位会被放低。任何家庭,只要还有一点能力,都愿意为病患倾其所有。但如果倾其所有之后,发现依然只是杯水车薪,那种无助,是无法想象的。片中近4万一瓶的抗癌药,每月要吃一瓶,一年就是48万。48万只能换来一年的生命延续,相信会有不少家庭无法承受,以至于最终屈服于病魔。每每想到这里,总觉得我们太过渺小。觉得自己软弱无力,无法保护对自己最重要的那些人。

辩证的来看,抗癌药物的高价是有其道理的。一种新药的研发,短则十来年,长则几十年。期间的资本投入异常巨大。新药研制成功的几率只有万分之一,研发经费高达数亿美金。但它的市场确实那么“小”。药品公司不是国家企业,更不是慈善机构。巨额的投入是要有巨额的回报才行的。由此看来,4万一瓶或许真是合理的价格。如果它真按“成本价”(也就是材料价格)卖到500的时候,公司就不会有资金做其他药物的研发。生产线会停产,公司会倒闭。到时候药就没人生产了。众多病人一样只能……等死。

但4万一瓶的药,又确实不是谁都吃得起的。上海还好,把房卖了还能吃上个十来年。那内地城市患者呢?他们的命一样是命,同样的值得拯救。

把药价降下来,降低到公司可以继续发展,并且绝大多数百姓可以接受的程度,才是最终的解决方案。国家把部分癌症治疗药物加入到医保目录就是非常正确的做法。在加入目录的同时,降低关税,普及重疾保险,一样值得推广。

我是比较早开始就给家庭成员配置重疾险的。先从我开始,逐步到我太太以及孩子。每年上万的支出不算小数,但也完全承受的起。而其可以让我放心去花钱,不用担心一旦患上重疾之后的费用问题。也不至于一生病就要卖房子。

其实我更希望国家的医保政策能有所调整。从保小保轻,逐步调整为保大保重。现在医保对小病轻病覆盖面很广。看个感冒自己花不了多少钱。但重疾之症却不在保内。病患往往因病至穷,并且拖累一整个家庭。如果能逐步去除对小病的保障,同时引导大家多锻炼,多养生,并且用价格杠杆让大家觉得生小病“不划算”。或许能从一定程度上增强国民体质,使更多人有更健康的身体。而将大病纳入医保,可以保证不会因病至穷,家破人亡。

我相信国家有国家的计划和方案,一定比我想的更全面更周到。希望我们不要再有病痛。有病有的治,有病治得起。

人与人,心交心

本来想把标题写成:如何处理与有着不同性格和背景的人的日常沟通的几点想法。结果发现既拗口,也显得不够高大上。由此,有了现在这个标题:人与人,心交心。

现代化的企业中,已经很少能看到单打独斗闯天下的场景了。尤其是在大企业、集团化的项目过程中。那既然要合作,就会遇到不同的人。既然会遇到不同的人,就会遇到不同的性格。既然有不同的性格,就必然有冲突。这是铁定的规律,逃避不了,唯有正面。在与人沟通中,有两点是我觉得最重要的的:一是守信,二是尊重。

先来说一下守信。在工作中,一旦我们对别人做出了“承诺”,别人就会根据我们的承诺去做相应的安排。项目上包括发布时间、任务安排、人员调配等。如果我们没能把握住自己,随口一说,随性而做,那么这对自己,对别人都是不负责任的。道理很简单,能做到其实有挑战。因为在日常工作中,有太多的环境因素影响着你的工作进度、影响着你的心情、影响着你的时间安排。很多时候即时你想严守诺言,也并不一定能顺利做大。但我们发现这种情况屡次出现,我们就需要对自己的“承诺”多加小心了。

放到具体的IT项目中来说,当我们去接Story的时候,我们是不是清楚这些Story的上下游Dependency?是不是确定PO所写的AC已经足够清楚?能不能瞬间构思出技术方案?这些其实都会影响我们最终是不是可以按时按质的交付。某些时候,我们会一拍脑袋:“行,没问题”。这其实就是把自己的信誉交给了命运,从此脱离了我们的掌控。如果我们能花足够的时间(如果有的话)把方方面面都了解清楚再做,这样能有更好的把控,也有更大的可能兑现自己的承诺。唯有我们能严守承诺,才能让自己变成一个“可以依靠”的人。

不过,当我们被别人的承诺所阻碍,怎么办?很遗憾,这种事情每天都会发生。而且很多时候我们无能为力。我们需要根据自己的经验,在给出我们的“承诺”之前,考虑到可能被阻碍的概率和程度。久而久之,大家就会对各种情况能更有把握。当然,偶尔翻一下船还是可能的,只要自己尽力了,也不用太过在意。

第二点是“尊重”。指的是尊重对方这个“个体”。尊重对方是个“人”,有血有肉有情绪。不单是“对方”,“自己”也是这样。某些人性格迥异,习惯以与我们不同的方式说话、工作、干活。不过,既然大家都在一个团队里面,都为了同一个项目努力,我们就应该尊重那样的一个个体。明白对方也是在贡献自己的力量,虽然用的方式有些不同。有些人线条比较粗,一会落下这个,一会忘了那个。但如果这个人思维比较活跃,能跳出固有的思路,或许其能在我们意想不到的地方做出很大的贡献。有些人非常在意细节,甚至有些吹毛求疵。通常这类人沟通起来比较累,可能需要花较多的时间反复讨论某一个很小的点。但也正是这种人,更有可能把事情做的面面俱到。活儿不怕细嘛。有些人说话比较直接,听起来或许觉得有些“冲”。这类人大家都不太喜欢,不过如果让他来处理一些tough的外部需求,或许能让你有意外的惊喜。

需要注意的是,“尊重”不等同于“纵容”。我们可以忽视那些由于个性所导致的小问题,但不能放任任何对团队有负面影响的举动。当沟通或者合作上出现小冲突的时候,左手,应该尽自己最大努力,确保项目的正常进行。右手,应该及时沟通,并适时上报。

在互相尊重的情况下,在大家都会理解对方可能有情绪、可能有困惑的时候,都会自然而然的“为对方着想”。当遇到问题的时候,会去想着:“这人今天是不是遇到什么事了,才会表现的如此这般”。当然,我们很难要求团队里的每一个人都能做到这些,但我们自己应该要努力做到最好。我一直相信,如果我们真心对人,总是能够得到相应的回报。

这就是标题所说的:人与人,心交心。

白手起家做个项目,真不容易

项目名称和具体内容就不说了,毕竟还没有发布。这是我在公司里和大家一起合作的一个非公司业务的项目。大家也是因为志同道合,愿意奉献自己的业余时间来做这件事情。就这样,在得到公司老大赞助云服务器和几杯饮料的情况下,大家去年年底开始撸起袖子干了。

在分析需求时觉得应该不是个复杂的项目,而且当时我们团队有10多个开发、2个PO、1个PGM,还有人帮忙打理服务器(相当于IT了)。于是打算2个月出POC,第三个月内测,第四个月上线。好吧,我承认自己太年轻,太幼稚了。现在已经4个月过去了,一半的功能还没做完,内测上线更是遥遥无期了。好在大家还在慢慢的做,没有放弃。

为什么挺好的想法,实际实施的时候差距那么大?看来要是自己创业去做这个项目的话,会死的很惨。想了一下,原因有下几点:

在我看来,最重要的原因是大家的工作时间和工作量不稳定,时常一个礼拜过去了,没有什么进展。当然这其中有些客观原因。比如我们不能在上班时间做,晚上回去或者周末的话很多同学有老有小的,也需要照顾。一些同学在做了一段时间后由于空闲时间有限,只能退出项目。到现在,只剩下4个开发和4个QA。人数的减少很大的拖慢了进度。拖累进展的还有下面一个因素。

服务器超级不稳定。我们一开始租用了2台阿里云的机器,虽然配置不高,但本着省一点是一点的态度,先用了再说。本想一个做QA,一个做PROD,结果现在2个都做了QA,分别部署了服务端和客户端。在开始的阶段,遇到最多的问题就是机器连不上,服务没有响应,有时候连代码都拉不下来(Git Server也放在那个机器上)。因为装的是Windows系统(我司90%是微软粉),他们RDP上去后就占着进程,时常需要别人踢下来才可以。有几次连Admin都连不上了,只能重启机器。

刚开始开发的时候遇到的另外一个问题是端口被占用。由于微软系的同学在那个机器上又装了套TFS,一些特定的端口被它无情的占用,我们只能为Web和API开其他端口。但后来发现使用的代码控件有限制,只能用80或者8080端口,逼得我们只能分别把他们部署在2台机器上。

遇到的第四个问题是客户端的技术方案。由于这次没有Native App的开发人员,我们一开始打算用微信小程序来做。结果发现小程序对于开发人员资质限制很大。作为公司开发,必须上传营业执照,进行公对公转账来验明正身。但这点对我们来说很难做到。(网上有皮包公司可以帮你绕开这个限制,但我们还是不想走歪门邪道)。小程序第二个限制是在访问网络服务时,必须使用域名,不能用IP地址。但要拿到域名,我们需要去做备案等程序性的东西。我们当时没有人,也没有经验去做这个。加上小程序的众多大坑小坑,最终我们放弃了这个方案。

我们有位同学当时对Weex非常感兴趣,就想用这个框架来试试。本着“大家开心就好”的态度,我们决定试试。然而,我们发现这就是跳出一个坑,却跌进了另一个。Weex里也有着无数的限制和坑。我们只能慢慢踩,慢慢填。目前我们还没有完全搞定的有摄像头和手机的自动化部署。

说到前端,另一个问题是我们没有UX。本来想可以依赖程序员自己对设计的品味和要求,但实际上大家的品味和要求是不一样的,很难协调,也很难让大家满意。现在我们一个会画画的QA在帮忙做图,开始慢慢统一了起来。

最后一个问题,其实也是最大的一个问题是业务模式。由于一些特殊原因,我们的业务模式也没有确定下来。也就是说,我们现在做的那么多事情,最后是不是真的能用上,还真不好说。但相关利益方在我们没有POC之前不和我们谈模式。伤透脑筋了。

经历的种种问题,才发现原来做一个产品真的没那么简单。自己固然有着N多年做技术做产品的经验,但真的白手起家,全靠自己来做,还是有着各种困难,各种意外和各种挑战。这个项目给了我一个机会去以一种低成本的方式体验人家创业的痛苦,真是难得。小伙伴们还在不断努力,也为他们加油。

简单总结一下经验吧:

  1. 租用的服务器配置还是要高一些,带宽要大一些,否则和影响效率。
  2. 最好别用Windows系统,不稳定,最大连接数也有限制。
  3. 项目管理相关的应用,不要部署在环境上,尽量保证一个干净的环境。任务管理可以用现成的网络服务,代码直接交给GitHub是最好的。
  4. 前端框架要选好,能用Native开发的就别用其他框架了。
  5. 业务模式一定要事先确认,否则可能都是无用功。
  6. 公司内部如果有机会孵化小项目,是个很好的机会。免去了很多自己创业的风险,也有一些团队做后勤保障(这点很重要啊)。

聊聊微软和苹果的新硬件

上周接连两天,微软和苹果接手拉手的开了两场发布会,发布了各自最新的产品和技术。作为一个伪硬件控,不由得想对他们俩的新硬件产品说两句。

先说说微软的吧。亮点最集中的就是Surface Studio了。发布会后,好评如潮。这款产品确实超出了大家对微软的预期:这货这次怎么就“硬”起来了呢。其实微软一直有个硬件部门,以前做键盘鼠标,小打小闹一下。后来做平板,做SB。这次出个“大号的平板”也不算是个非常让人奇怪的决定吧。虽然我比较喜欢苹果的电脑,但说实话Surface Studio样子还是不错的(那个支架除外)。薄薄的机身,大幅度的倾斜角,漂亮的屏幕。从美观角度来说,当其成下图展示姿态时,可以打10分。

surface_studio_overview_3_videopanel_v3

很多人拿Surface Studio对标苹果的iMac。从硬件配置,做工和设计来说,他俩确实不相上下(当然,还是要排除那个底座)。但由于他们不是一个操作系统,很难去说哪个更好。他们各自有各自的用户群,有各自的粉丝。得益于Surface Studio的一个神奇的配件,让他成为绘图设计领域又一相当有市场占有潜力的设备。那就是Surface Dial。这个可以随意摆放在屏幕上并围绕其周围准确的显示出快捷菜单的东西,让生产力一下子增加了不少。而且它颜值也高啊,就是不知道手感怎么样。不能吸附在屏幕上算是一个减分项,期望下一代能有所改进。

Surface Studio Dial microsoft

总体来说,微软这次很“硬”的产品发布确实让我眼前一亮,能结合自己的操作系统,推出相应的硬件产品并在设计和使用上更加时尚,使的微软在众多码农心目中的形象大为改观。

再来聊聊苹果。我虽然不是苹果粉,但确实对苹果产品喜爱有佳。其中一个很大的原因是因为我是外貌协会的老会员了。苹果产品的设计和美观度一直是其他对手所追赶和对标的对象。无论是他的桌面电脑还是笔记本电脑,单就颜值来说,我还不认为目前有任何对手。3年前发布的“新款”iMac,对于上周才发布的Surface Studio来说一点也不显得落伍和老旧。

这次苹果发布会的重头戏当然是N年没更新的Macbook Pro了。推出了更薄、更小、更轻的新一代产品。顺便也验证了坊间关于Touch Bar的传闻。Touch Bar这个概念虽然不是苹果第一次想出来的,但苹果对其的创新确实又进了一步。在还没有看到真机的情况下,无法得知该条的亮度和使用手感。不过在一个小小的“条”上放置太多的功能让我觉得可能存在一些学习成本。而且该条的位置离触摸板稍远,如果使用的是鼠标的话会比较难以方便的使用上面的功能或者快捷键。估计需要有一段时间的摸索和实践。

macbook_touchbar

这次让我有点担心的是那2排小而密集的音箱孔。我个人非常喜欢苹果早代13寸Macbook Pro使用的反射式传声的设计。它把音箱很好的隐藏了起来。这一排排小孔让我都不敢在电脑旁边放杯水。另外一个“担心”就是我现在所有的转接口都不能用了。苹果这是逼着大家不断的买各种各样的线缆和转接口啊。要吐槽的当然还有那键盘。好在我一般都用外接键盘,这个不谈也罢。

好了。先说这些吧。