华山不再论剑

在商业软件开发中,胜出的往往不是最好的技术和算法,而是最能够满足客户需求的技术和算法。 —- 题记

古有华山论剑,最早出自于金庸老先生的武侠小说《射雕英雄传》,各大武功门派好手聚集华山,一绝高下,争锋天下第一。

1. 新需求

上周因为工作需要,我临时加入一个小组协助他们的工作,这个小组的人技术很强。客户需求是这样的,因为控件本身的性能原因,所以要在UI上面加一个单选框,选中即“显示全部”,否则“显示最新的100条”。当天下午提出新需求,并且需要当天提交软件新版本包。

2. 需求分析

这次客户的新需求的主要矛盾是因为控件对于大容量显示会出现性能瓶颈,所以希望通过“部分显示”解决这个问题。由于这是紧急任务,所以我认为主要解决客户说的主要矛盾,然后会有些细节问题,在客户没有明确说明怎么解决的情况下,由于时间关系,我们应该放在其次的地位上尽量简单的解决。这样不管是对项目本身,可以降低不必要的风险,对客户,可以在规定时间内拿到新版本包。

可是在这项目组中,原来的两位技术比较好的同事就开始华山论剑。首先两位先对什么是“最新的”进行用了一番切磋讨论,是系统中最小的单元最新,还是用户最后的一次行为最新?其中技术最强的那位同事抛出理论“要做一次性就做到最好”,随后开始针对这个需求开始加了些历史记录回滚等附加属性,这些技术方案确实很够先进,而且“在特定概率出现的事件”情况下户体验也得到改进。但是我想到的是,这是商业不是作业,在有限成本下做到最好本身就是一个lose-lose的行为:

对公司来说,客户给了一个做小凳子的钱,我们却给做了一个沙发;

对员工来说,需要额外的工作量去满足本不存在的客户需求,加班会让身心俱疲,尽管良好的技术会提升个人的成就感;

对客户来说,如果项目不能按期交付,而是推迟交付了一个使用频率不大的许多附加功能并不能使客户额外“附加”满意。

所以最后其中一位成员提出来的简单行为,我们两个人当时表示同意。我们实现了客户最需要的功能改进“部分显示”,而且符合效用理论的摒弃了客户在90%的情况下不会经历到,我们需要额外花费很多时间去完成的附加功能点。

3. 代码执行

因为设计的行为简单了,于是我们如期在规定的10:00PM提前3分钟的时候提交了新版本包,完成了所有的改进的开发和测试工作。事实证明,到目前为止,客户还没有对那10%不Perfect的情况产生任何质疑,团队也再没有在这上面有任何的返工。那么我们想到,如果当时做了技术最佳的解决方案,客户他知道吗?他在10%的情况下能感受到吗?他会因为在那时候我们花费很大努力稍微改善的那点用户体验谢谢我们吗?

整个的协助工作做下来,觉得最浪费时间的还是当初的华山论剑。因为技术人员都有脾气,都试图去证明自己的想法是最好的,所以有两个这样的人谁也不服谁的时候,时间的浪费就产生了。他们聚焦于最优化的技术解决方案,而往往忽略了客户其实最想要的不是最好的,而是能够解决他问题的方案。不是说最优化的方案不好,而是要除了技术本身以外,多从项目本身或者商业本身的原因去想想。技术人员当然不可能想这么多,也正是因为这点,项目中的管理人员,决策者不可或缺。

真希望有那么一天,华山不再论剑。少林寺的走进社区教老头老太强身健体,峨眉山派的作为女子防身咨询公司解决了大量单身女性的防骚扰问题。。。。。那样的话,比在华山上比个天下第一有用得多。

故地,重游

13日,从光谷上715到航空路转乘208,开往江大5号门。这条走了4年的路,我再一次熟悉又有些陌生地经历着。

此行一来则是看望一位老教师,二来则是想在自己的校园走走。一年时间已去。。。。。

拜访完老师,趁着夜色,从文理学院,悄然抵达学生宿舍区。特地沿着自己最熟悉的路,慢慢地走,慢慢地看。肩上的书包让我混迹于大学生中,就像刚下自习回来一样。

不知道从什么时候起,精武鸭脖进驻学校食堂和周边小贩,新鲜。同时一切是那么的熟悉,虽然过了将近一年,可是小商小贩们的神态依然保持着一年前的样子。从三号食堂,走向四号食堂,路过豆豆水吧,不知道那里的绿豆沙还是不是很好喝。穿过小操场,寥寥几个人在黑夜中打着篮球,路边的小商贩又多了几家副食。不过走到四号食堂的中心区,却又是那个卖书的大嫂,那个配钥匙的锁匠。从中国银行ATM机后面穿过去,便来到了更熟悉的生活区。北9楼下的小贩们,还是那些熟悉的面孔,还是那些熟悉的陈设。特意来到5号食堂,这个食堂是感情最深的食堂,虽然菜很不好吃,但是这却是个有故事的地方。特意看了看那张餐桌,餐桌还在,不过曾经在那餐桌上的人却不可能再次在此相聚。走出5号食堂,抬头,619亮着灯,但我已经不能上去,那里不在属于我。沿着去自习的路,穿过校园的林荫道,来到J05。这里除了自习和上课,再有的印象就是学生会。看到一块展板,博客网页设计大赛,落款是物信团委。不知道学生会网络部去哪里了,也不知道这次的博客网页设计大赛和当年的博客文化大赛差别在哪里。来到英才广场,赫然发现图书馆和行政楼都被灯光笼罩,也发现小卖部居然也进驻了图书馆,不过在图书馆上自习的同学们应该和当年的我们一样刻苦努力了。渐渐穿过文科楼群,来到校门口,宵夜的摊点已经将正门口铺满。等车,来车,上车,离开。再见,江大。

 

这次,体会到的只是种种细节,总体格局不变,但不变中又有微妙变化。同样的建筑和场景经历着一代又一代的新鲜面孔,那些曾经在这里发生的故事已经蒙上灰尘。我们在羡慕校园人年轻的同时,也敞开胸怀地说:职场见。

软件开发中的角色扮演

商业软件开发并不是只有一个编程的人,而是可以分为不同的角色。

不同的软件公司因为规模大小性质各不相同,所以围绕软件的角色也各不相同。这就好比在重点学校里面分级很明确,每科有个老师,每个年级每个班级都有各自的老师,也有主任书记校长支持角色。而在电影《一个都不能少》级别的学校里面,往往一个老师兼职从语文教到体育,年级从一年级到六年级。类似的说,一个大型的软件外包企业,外资企业,往往分工明确细致,每个人像螺丝钉一样在一起工作,让整个大机器得以运转。而在一个小型创业企业里面,往往一个人从接触客户,到开发产品到交付产品一条龙走完,整个产品周期就一个人,甚至几个产品周期就一个人。

所以解释角色要针对性。远的不说,就拿我们的项目组来举例。我们项目组可以说一共有5种角色,开发(DEV),测试(QA),质量监督(SQA),技术主管(Tech-Lead),开发经理(SDM)。

1. 开发 (DEV)
编程能力 ★★★★★
业务认知 ★★☆
沟通能力 ★★☆
管理能力 N/A
全局观     N/A

开发就是大家经常说的编程的人。工作主要是写代码,其次是跟团队成员客户沟通。前后者比例大概是7:3的关系。开发是整个软件开发团队当中的最重要的角色之一,道理很简单,产品出自于他们的亲手。说到开发,大家的印象就是整天呆在电脑面前,目光呆滞,头发凌乱的计算机人士。确实,整天和计算机打交道的人的确容易变成这样,因为开发首要解决的问题就是如何用技术能力去解决客户的需求,而不是自己的形象怎么样。事实上这种情况在现代中得到很大改善,很多IT人士都很注重自身形象。

具体的工作不仅要写代码用算法实现业务逻辑,更要有程序设计的思想,大到整个的程序框架,小到某个小模块的扩展性兼容性,都是在开发真正写代码之前着重要考虑的方面。

现在的编程不像以前打孔式编程那么艰涩,大厂商开发的强大的编程工具(IDE)让编程事半功倍。然而技术在变简单的同时,客户需求又在日趋复杂化。而技术就是为了实现业务逻辑,将业务逻辑抽象建模用计算机程序的方式表现出来,所以一个不懂业务逻辑的开发不会了解模块和模块之间如何协同工作,这便给工作带来很大的局限性。而如果一个开发只关注每个模块之内的细节实现,那在现实中便不是一个好开发,至少不是一个好用的开发。

沟通方面,开发需要和测试,技术主管,开发经理,甚至客户方面沟通,所以必要的沟通能力还是很需要的。现在的软件不再是一个人在战斗,在团队作战中,开发有时需要和测试讨论“某个软件Bug(缺陷)是不是Bug”,有时需要和技术主管讨论客户的某个需求到底是要实现什么内容,有时需要和开发经理讨论项目的进度是否需要推迟。

就开发的工作本身而言,是不太需要管理能力和全局观的,如果能够做好编程的工作之外,这两方面也比较强,可能就离升职加薪不远了。

2. 测试(QA)
编程能力 ★★☆
业务认知 ★★★★
沟通能力 ★★★
管理能力 N/A
全局观    ★☆

任何一个产品都需要测试,就好比制造业中如果生产了一批电灯,我们不能听制灯师傅说信得过而信得过,而得通过一系列模拟用户的行为来对电灯进行测试,指标合格后方可出厂投入市场。

软件测试也一样,需要对开发者开发出来的模块,产品进行全方位的测试。
原则是“做正确的事”,让客户需求功能得到满足。
基本做事方法就是模拟客户的一切日常行为,包括一些极其变态的行为,考验软件在各个方面的情况下的可用性和稳定性。而这些“日常行为”便称之为测试用例(Test case),一个好的QA会设计出一套可以覆盖所有检查点(check point),又不重叠的测试用例,这套功底可以参考MECE方法。既然如此,QA就需要对整个软件的业务相当熟悉,因为她(他)要知道在某个用户行为下,软件是否做出了正确的反应。

既然是模拟用户行为,那么QA就需要去手动“跑”测试用例。当一个系统很大的时候,测试用例极其多,光用手点一遍是非常耗费时间和人力的,所以QA可以做自动化测试。所谓自动化,便是QA编写一些脚本代码,让计算机帮助去实现一些人为的行为,而不用自己手动点。所以这就需要QA做有一些代码编写能力。

测试方面有个重要的概念是黑盒测试和白盒测试。简单的说,黑盒测试就是在软件界面上用手点,不管后面的代码写得怎么样,只要我点击某个按钮或者其他元件的时候,结果是我想要的就OK。所以叫“黑盒”,意思是看不到“里面的代码”。而白盒测试就是要直接审阅(review)代码,通过看代码发现业务逻辑,代码效率,后台数据操作等等,可以说比黑盒测试要细致得多,当然成本可能也更多。所以叫“白盒”,意思是透明的盒子,可以看到里面的代码。所以,白盒测试是需要QA有一定的编程能力的。

沟通方面,QA经常要和DEV讨论Bug(软件缺陷),Bug的意思是本应该有的功能却没有做到的功能。对于某些比较似是而非的Bug, 怎么能够让开发者心服口服地承认并去修复往往需要花费一番口舌。而这些Bug往往是根据不同的人的价值观认定是不是Bug,所以合理地传递价值观也是QA的一个基本素质。现实的一个案例是,公司某QA“传递价值观”能力极强,于是被拉去做市场去了。除此之外,QA还要经常和技术主管沟通,熟悉客户需求。

全局观是因为QA要做集成测试,这样需要对产品本身有个全局的观念。比如产品有个用户管理系统和订单管理系统,那么对于“删除一个用户”的行为,用户的订单会怎么处理?这便是一个全局观的意识。往往一个好的QA在这点上可以帮用户想到很多用户没想到的东西。

3. 质量监督(SQA)
编程能力 N/A
业务认知 ★
沟通能力 ★★★☆
管理能力 ★★★
全局观     ★★☆

如果说QA的作用是确保“做正确的事”,那么SQA的作用就是确保“正确的做事”。
通常SQA是不会直接参与软件开发的工作中,而是通过在一旁监督软件开发的过程,然后把监测的结果反馈给软件开发团队。

既然是监督过程,所以SQA经常是流程化的代名词。流程是外企当中比较看重的东西,从每天的Daily report, 到每周的weekly meeting,从什么时候把当天的结果存到服务器上,到为什么团队出现重大事故,几乎都会有SQA的参与。所以在前期制定一个符合项目的流程是SQA的必然工作。项目运行过程中,所有项目流程规定的点所涉及到的邮件都要CC一份给SQA。

当SQA通过流程观察项目的运行情况的时候,必然会收集到很多数据(包括刚才提到的邮件)。SQA会对这些数据进行统计归纳,然后总结出规律和报告直接递交给总监(Director)。鉴于此,SQA在我们公司地位还是很高的。

SQA还会不定期对开发团队进行个人的face to face面对面一对一沟通,名字叫Audit,中文翻译过来类似叫审计。
这种行为更针对“人”的评估,而不再是产品。因为产品的好坏决定于人的好坏。

4. 技术主管(Tech-Lead)
编程能力 ★★★★☆
业务认知 ★★★★★
沟通能力 ★★★★☆
管理能力 ★★★★
全局观     ★★★★

技术主管在我们公司往往就是一个项目的负责人。最主要的工作莫过于软件架构设计,客户需求沟通,技术难点解决和内部团队管理。

技术主管,名字便告诉了大家技术功底一定要很牛,在我们公司经常是一些工作了2-3年以上的软件工程师或者高级软件工程师担当。虽然技术很牛,不过实际上直接参与软件开发的还是DEV(开发者),技术主管只是在比较高的一层面进行协调,所以直接代码编程很少。但是遇到了技术障碍DEV无法克服的时候,技术主管一定要及时站出来做一个Problem solver。

技术主管的日常主要工作就是和客户沟通,熟悉需求,然后把业务需求转换成软件需求给DEV去做。所以技术主管对业务逻辑要相当的熟悉,在整个项目角色中,对业务最熟悉的除了客户就是技术主管。所以技术主管起到了一个衔接的作用,沟通起了客户和开发,连接起了现实的业务需求和虚拟的软件实现。这一切,对技术主管的沟通能力的要求就很高了。

软件团队不是一直和谐的,有时会出现某个模块的接口和另外一个模块的接口衔接不上,有时会出现一个人的工作被另外一个人的工作Block(中断)了,有时也会出现某个DEV总是不买某个QA的账等等,所有的这一切,从技术到人本身,都在时时考验一个技术主管的管理水平。

5. 开发经理(SDM)
编程能力 ★★★☆
业务认知 ★★★★☆
沟通能力 ★★★★★
管理能力 ★★★★★
全局观     ★★★★★

软件开发经理是一般软件项目中执行层面上的最高职位了。其主要作用是项目的进度控制,客户高层沟通,甚至到项目预算控制。

软件开发经理的编程功底要看具体人而定,在我们公司软件开发经理一般都是技术出身,5-8年的工作经验或软件行业的资历。在具体的项目中,几乎不参与任何代码的编写和设计工作。前期的项目计划(Project Plan),中期的项目进度管理和客户需求管理,到后期的项目交付,所有的工作都是软件开发经理和客户主要要沟通的东西。

业务方面,软件开发经理对业务认知的能力是非常强悍的,因为资历深的人对很多陌生的业务嗅觉和认知要比其他人强。不过在实际中,业务需求方面大部分工作给技术主管做了,所以软件开发经理主要关注于项目总体,对细节不太关注了。

软件开发经理还有个重要的作用便是在软件项目过程中,积极地调动项目内外的资源。简单的说,把合适的人放在合适的位置上。当团队出现无法解决的问题时,软件开发经理会想方设法从外部获取资源帮助团队渡过难关。

总的说了这么多,只是为了从宏观层面解释下这些角色的作用,目的是让新手大概的了解下这些角色的作用,以便今后在工作中将自己放在合适的角色以及和其他角色合作中心里有个准备。