与“老大”一起谈软件行业

“老大”是我很要好的一个朋友，也是一个对于我的职业发展产生过很大影响的一个朋友。上个周末去了千岛湖，顺便给“老大”带了一些枇杷，在送枇杷过去时和他好好地聊了聊。

 

我们俩在软件行业做了都有近十年的时间，分别在全球知名的两个通讯公司工作。在这之前，我俩是UTStarcom的同事，工作在同一个项目组。“老大”现在是公司的一名Manager（“老大”更喜欢Leadership这个词），而我是公司的一名Architect。

 

我俩的谈话总是以“最近怎么样”开始的，而我这次与他谈到了对于现在所在公司的前景的担忧。一方面公司在WiMAX上面并没有达到期望的结果，另一方面，觉得通讯公司在软件的开发方面并没有很深的积累，不少开发方法还是“作坊式”的。当然，这里说到的深是相对的，是相对于那种以软件开发为本的公司，如Microsoft，等。对于“通讯公司在软件的开发方面并没有很深的积累”这一点，“老大”与我有相同的看法。比如，现在的通讯公司大量采用的都是C，除了据我所知Nortel在采用C++和OO开发接入网这一块很有经验。OOP毫无疑问是一个能使应用问题得到更好解决的一种开发方法，当然，要真正的驾驭OO，对于开发人员的要求的确是更加的高。在Cockburn的《OO项目求生法则》中对关于OO开发的风险有很好的阐述，但我想归根到底还是人的问题。

 

我们谈到了项目的管理。“老大”提到他现在所做的项目当中有一部分的代码质量非常的差，只有通过重写才能解决问题，但“老大”的老大的老大似乎并不知道应当让大家这样去做，而是一味的强调“测试！测试！再测试！”。对于这一点，我谈了我的看法“说到底是相关人员其实并不了解软件”。虽然，这些人也在软件行业有八年仍至于十年以上了，但他（她）并没有真正的掌握软件行业的特点，主要存在以下几方面的问题：

 

1）很多Manager在做Management以前都是技术出身，由于做技术期间没有在软件技术上有很深的积累，在做management时，当别人提出一种的确行之有效的方法时，就没有能力去判断是否从长远来看有利于自己的团队和产品，只相信那些能产生一定的数据的方法（比如，代码覆盖率）。在与“老大”谈时，我们打了一个比方：比如，我们建了一座楼，如果这座楼的根基是好的，那么我们可以通过Refactor来“每次装修一个房间”，从而达到最后的“量变产生质变”的效果，在这种情况下，我们可以采用加强测试（如UT - Unit Test）来配合我们的Refactor；反之，如果这座楼的根基有问题，那“每次装修一个房间”能解决问题吗？此时，我想Restructure是更好的一个选择。当然，由于这些人并不明白这些道理，于是使劲的去做UT，那结果一定是：苦了工程师（没钱没生活）又害了产品（失去了重生的机会和用户）。针对这种情况，Manager是应当鼓励restructure呢？还是小的Refactor？Manager真的需要知道吗？还是可以通过向相关的人问一问，怎样做更好。问谁？专家？不。一线工程师会告诉你答案。当然，我们谈话中也持同一观点：如果一个功能模块很烂，但并不经常出问题，或说是不占用大量的资源，在这种情况下即使是根基有问题，我们也不应当马上去Restructure它。“老大”将根基不好的软件比喻成“软件黑�L”，很有新意！

 

2）不相信团队。不相信团队能通过采用新的方法从而改变现状。我想很多的Manager在嘴上说“我相信我的团队”，而内心里其实是不相信团队。为什么呢？其中，有一部分原因是他（她）自己从来就没有通过技术的变化而成功的改变现状的成功经历，因此，对于他（她）来说同意采用新方法就是一次“大冒险”。

 

3）不愿意承担责任和风险。这些人往往Offer都不错，他（她）没有必要让自己去take risk，从而影响自己的“前（钱）途”。这其实是1）和2）所带来的行为结果。

 

4）只关心自己。有些Manager只关心自己，并不关心自己的团队以及自己所负责的产品。至于，团队是否有太多的Overtime，或是士气低下等等，一概视而不见，更不用说产品的未来了。

 

后来，我们也谈到了开发方法，如Agile，SCRUM等等。我的观点是：开发方法的出发点是好的，而且，很多方法的确是行之有效的，但关键在于我们在运用这些开发方法时，有时会“走火入魔”。在很多情况下，如果我们不能很好的把握运用这些方法的时机和分寸，那只能出现以下结果。

 

1）采用了方法论后，发现团队更忙了，但是产出却是更低了，质量也没有得到改善。进而

 

2）宣告这种方法无效。

 

其实，软件行业一直以来就有很多行之有效的方法（但不是终级方法，别忘了No silver bullet!），只是，我们不能很好的去实践和把握运用它们的时机和分寸。比如，现在很多软件开发方法都鼓励UT，但是UT这一概念是在30年前提出的。我们的从业人员对于UT真的有足够的认识和切身的体会吗？除了UT，自动化测试也是很好的一种方法，但我们的测试人员真的觉得它重要吗？

 

在很多的软件书籍中都提到了人的重要性，但软件行业真的是这么认为的吗？从现在状况来看，我相信这一观念还没有深入到从业人员的骨髓中。甚至，不少人还用管理生产的方式来管理软件产品。在《从优秀到卓越》这一书中，作者指出其研究结果显示：先人后事！即先找到合适的人然后再想要做什么。虽然，这书不是针对软件行业的，但我想无论什么行业，其有些共性是相同的。我想“先人后事”在所有行业都通用。