自写的第一篇软件工程文章

建设以人为本的软件企业文化

                                     ——我找到了银弹

 

 

为什么找不到银弹

“没有任何一种单纯的技术或管理上的进展，能够独立地承诺十年内使生产率、可靠性或简洁性获得数量级上的进步。”

“我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证。”

“如果这是事实，那么软件开发总是非常困难的。天生就没有银弹。”

上述几句论述是Brooks在经典名著《人月神话》中的核心观点，Brooks断言软件开发中”No silver bullet”。 1975年到今天刚好30年，30年中软件工程师、管理者们的确是没有找到银弹，难道真的没有银弹？

世界上任何的困难都存在好的解决方法，就像任何一把锁都会有开启它的钥匙一样。软件开发领域也是这样。究竟是什么原因多少年过去了还是没有找到那把钥匙——开启“十年内使生产率、可靠性或简洁性获得数量级上的进步”这样一把锁的钥匙，怎么才能找到软件开发中的银弹呢？

看过《人月神话》的人都应该知道，这本书是一本技术性较强的书，里面对专业性的思想、专业性的技术阐述的非常好，他把“规格化、设计和测试”这些技术问题看成是软件开发法中的困难部分。

的确软件开发是一项技术性很强的工作，但是Brooks的所有论述是在一个前提下进行的——软件开发的“人”都能够做到“最好的自我”。理想与现实差距太大！目前为止大部分的公司或者专业人士在寻找银弹的过程中，依然在犯着同样的错误，这是可以理解的：似乎技术上的问题当然要从技术角度着手，这样的错误也是致命的。

“如果你发现自己关注的是技术而不是社会方面的问题，你就相当于在黑暗的街上丢失了钥匙，却到邻近的另一条街上去寻找。因为“这条街的灯比那条街上的灯更亮一些”。

怎么找到银弹

银弹来自另外一本经典巨著——《人件》。这本书论述的内容涉及到人力资源管理、办公环境、招聘、团队、软件过程多个方面。一个核心思想就是要软件企业建设以人为本的企业文化。

“21世纪什么最贵？人才！！！”——《天下无贼》经典台词。软件产业是一项智力密集型劳动，软件开发的过程是一项非常复杂的脑力劳动也是一项极富创造性和个性化的工作，因此这个领域对人员的要求更高，对人才的渴求更强于其他产业。可以说软件开发人员能否全身心的投入、能否饱满的热情进行软件开发甚至创造、能够负责任的把高质量的产品提交给客户，直接决定了软件开发的生产率、可靠性和简洁性，决定了企业的命运，甚至远远高于技术本身的影响。

如果说《人月神话》关注“软件开发”本身，那么《人件》则更加关注软件开发中的“人”，这本书让苦苦寻求银弹的人们又看到了希望。

 

1．  改善办公环境

按照以前思考问题的习惯，环境一直被认为是一个次要因素。但是软件开发本身的特征决定和对开发人员的高要求决定了我们必须把办公环境提到一个至关重要的高度。

       软件开发是一项复杂的脑力劳动，安静的工作环境，适当的私人空间，透过窗户欣赏到的美景以及个性化的装饰或许更能给人一种自然舒适的感觉，更能让人投入到开发中，激发人的创造性，更容易进入“顺流”的状态，并且不容易被打断。

Google vs Microsoft

    目前大多数的软件公司办公环境都比较差，嘈杂的噪音（每个人既是噪音受害者又是噪音的制造者），狭窄的个人空间，较暗的光线，他人频繁的打搅，电话的“骚扰”等等，很多身处这种环境的人一天8小时工作时间，真正能投入的写点东西的时间很少很少，根本就进入不了“顺流”状态。很多人感慨“还没开始做，就该吃饭了”。这样的反例太多。

看一个正面的例子：迅速崛起的网络巨人——Google。

    Google是一家迅速崛起的互联网服务公司，虽然仅仅起步几年但是已经创造了一个又一个的纳斯达克奇迹，其价值已经相当与6个美国福特公司，让软件巨头如临大敌。前段时间原微软副总裁李开复博士离开微软投向Google，其实在李开复之前Google已经成功挖掘了微软上百名优秀的技术人员。对这些精英人才，Google的什么是吸引他们。

    很多人分析其中的缘由，例如优厚的报酬、被华尔街看好的职业前景、追求互联网的企业精神……看法不一。但是有一点是人们所共识的，也是Google所自豪的。那就是“富有创造性的工作环境”和“像高级托儿所一样的福利体制”。

Google内部享有奢华待遇。公司提供员工免费餐点，早中晚餐全包，而“主厨长”还聘请前知名迷幻乐团Grateful Dead的大厨Charlie Ayers来担任；若要往来于办公室之间，员工可骑乘Segway电动滑板车，或者Green Machine车（一种适合11岁儿童的玩具车）；健身球与M&M's巧克力随处可见，门户玄关处还有数百盏迷幻熔岩灯(lava lamps)；公司里面设有驻诊牙医与家庭医师看诊；请育婴假的员工可照领75%的薪水；婴儿出生后两周内，公司每天补贴50美元当作员工的坐月子津贴；甚至这里还保存替办公大楼或会议室取些怪怪名称的习俗，比如无理数“e”(2.71828)是第二大楼的名称；第三大楼则叫做圆周率“pi”；第四大楼则命名为黄金比率“phi”。  

    相比之下，微软体面而“正经”的员工着装、庞大而严密的组织架构确实有些“老态龙钟”。微软现在和以前的一些雇员抱怨说，微软充斥着14小时的战略会议和无休止的商务评估，专注于PowerPoint幻灯片、劳神的工作评估、成天数以百计的邮件和部门间的激烈冲突，这一切造成的结果是掣肘了产品的设计和延迟了它们产品的发布。

    在《人月神话》中，Brooks提到了软件开发的职业乐趣：创建事务的纯粹快乐；开发对其他人有用的东西的快乐；开发过程体现出魔术般的力量；学习的快乐；工作在易于奴驾的介质上。不难揣测大多数优秀程序员的心理：在物质回报满足一个基本的要求的前提下，更倾心那些能够使他们更加投入的好的环境，激发创造灵感，获得职业乐趣。这也就不难理解原来微软的不少技术人员宁可拿比原来低的工资也要跳到Google去。

    Google的成功就在于它对工作环境的重视，花费如此大的精力、资金来营造这种好的工作环境，那么Google的技术水平如何呢，不直接回答，拿Google earth来作答。

Google earth是2005年刚推出的一款桌面搜索工具，把整个地球放到了每个人的桌面上，让用户坐在电脑前,就可以在名川大山间翱翔,在摩天楼群中俯瞰。这款软件无论在创新思想上还是在技术实现上都有很高的水平。只看它的技术实现，首先一点是要利用3D地图定位技术把最新卫星图片映射到3D地球上；另外一点，也是最令人头痛的一点是存储技术，GE搜索的位置可以精确到地球的每一个角落，问题就是要把地球每个角落都存储在服务器端，那需要多大的空间？按照现在的技术，根本是不可能存储的下的，并且还要保证快速的搜索数据将地图信息传送给用户端，在这个问题的解决上，Google用到了分布计算、并行处理，将卫星地图的信息存储在大量的硬盘里面，而这些硬盘又是分散在不同的地方。就这样Google以它超乎寻常的想象和过硬的技术创造出了Google earth。可见，不必特意的为了提高技术而去提高技术，技术是掌握在人手里的，当人的问题解决以后，好的技术自然会应运而生。

    人们时刻都在提醒自己不要只看眼前，要放眼未来；但是又往往会犯急功近利的错误。

改善工作环境产生的效果是显著的。一方面可以为公司的员工提供优异的工作环境使他们全身心投入，把精力放到技术难题而不必为一些琐碎小事所干扰，正如李开复在南大演说时所讲：Google就是要员工们感觉在自己家里办公，例如他们可以带上自己的宠物到公司，在公司他们可以享受到大师级厨师的手艺。在这样的环境下工作，员工能够把更多的精力用到技术上，能够更快的进入到“顺流”的状态，这种公司的E－因子肯定会高出一般公司很多，即使达不到0.9，0.7，0.8是很容易达到的，环境的改善使真正工作的时间（不被打扰的时间）越来越接近体力出勤的时间。相比之下，环境差的公司的E－因子在零的位置徘徊，好一些的情况也是0.3、0.4。并且，E－因子＝不被打扰的时间 / 体力出勤的时间，在计算的过程中考虑的是不被打扰的时间而没有考虑开发人员处于“顺流”状态的时间，处于“顺流”状态的工作效率显然要比“不被打扰的时间”高很多，在好的环境里面可以更快的进入“顺流”状态，而一般的公司里面，即使坐在那里“不被打扰”进入“顺流”状态也很慢。这样算来，Google公司员工的工作效率要比工作环境一般或者环境很差的公司员工的工作效率高出很多倍。

另一方面，可以更好的吸收优秀人才。就像《人件》里，作者所表达的一个观点：从长远的角度来看，让工作空间安静、宽敞和有私人空间有助于你现在的人把工作做的更好也有助于你吸引和留住更好的人才。的确如此，在同样的物质报酬下，哪怕是低一些，优秀的开发人员也往往会选择安静的环境、宽敞的个人空间、家一样的办公室，在这里他们可以将他们的才能施展出来，得到职业乐趣，同时又可以更快地提高自身的水平。

      

为什么项目会延期

软件开发中最令人困扰的难题就是项目进度滞后,延期提交. 人月神话中Brooks将其解释为编程人员的乐观主义,在进行进度安排时是基于这样一个假设:一切都将运行良好,没一项任务仅花费它所 “应该”花费的时间.这样的解释不是没有道理的,但是不得不说Brooks对此的解释是一个次要的原因, 我想他忽略掉了一个关键的因素——工作环境.

工作环境才是项目延期的根源. 当然项目延期的直接原因仍然是开发人员的乐观主义所导致。不同的是进度安排是基于这样一个乐观假设：体力出勤时间 = 不被打扰时间,也就是E-因子等于1,更有甚者以为体力出勤时间=“顺流” 状态工作时间。

管理者在进行项目估算时，脑海总会浮现出一副员工们积极、投入的工作场景，每个人来到公司就一直在认真的忙自己的工作，全身心的投入，似乎一坐到电脑前就已经进入“顺流”状态了，管理者往往假定员工们是在这样的状态下工作，相应的估算项目完成的时间（当然Brooks关于程序员乐观主义的论述也是合理的，但应该不是关键的）。在项目开始以后，理想与现实的差距才真正体现出来，身处糟糕的办公环境，开发很难投入到工作中，狭窄的空间、嘈杂的噪音、手机电话的铃声，每个人是这种环境的受害者，同时也在干扰着别人。他们迟迟进入不了状态，真正工作的时间可能远远低于体力出勤时间，相应地，进度安排的时间也就远远低于项目实际花费的时间。如果把E－因子的计算公式中“不被打扰时间”和“体力出勤时间”拿到项目的进度安排上，那么项目实际花费的时间就是所有开发人员在某个项目上的体力出勤时间，其中每个人真正投入到项目的时间应该是非常接近开工前对项目的估算时间。   

所以，单单解决工作环境的问题，人狼出现的可能性就大大减小了。

 

2．             重新认识团队

“团队”这个词每个人再也熟悉不过了，在体育竞技类活动中用的非常频繁，几乎每个公司－无论大小，都将其纳入到企业文化中，但是究竟怎样组成的一个群体才算是一个合格的团队，才发挥出应有的团队精神？

之前对团队的理解太过局限、不够全面，认为团队就是一个群体，群体成员为了完成一个共同的目标聚在一起，相互配合，取长补短，彼此学习，患难与共。

这种观念没有错误，但是太局限，甚至没有领会到团队存在的真正意义。

对团队的一个最新认识：培养胶冻团队的形成。

“一个团队的目的不是达到目标而是向目标看齐”。在一个好的团队里，队员有着同一个目标，他们之间相互需求、互相依赖是一个企业基本的学习单位，也是最基本的一个相互依赖的单位。如果一个团队成为一个胶冻团队，形象一点说就是团队进入了“顺流”状态。这样的团队，团队成员对金钱、阶层、晋升职位都放在非常次要的地位，他们已经完全进入了状态，享受团队工作所带来的乐趣：他人的认可；合作中的理解、交流；对团队产品的自豪感；学习他人 和 教授他人的乐趣。

其实团队的概念是以人为本的另一种形式。胶冻团队就像处于一个处于“顺流”状态的个体，里面的每一个成员可以更加投入地开发，沉浸在开发的乐趣中，更富有创造性、积极性。这种团队的形成必然会产生1 ＋ 1  >  2的效果，开发出效率更高、质量更好的软件。

 

3．  用头脑开发软件

软件产业是一项智力密集型劳动，软件开发的过程是一项非常复杂的脑力劳动。很显然从事软件开发的每个开发者都在进行较大的脑力劳动。但是问题是软件开发的管理者，或者说项目经理在负责完成某项任务时，有没有冷静、理智的思考一下整个任务，对方法进行深思熟虑的揣摩。答案往往是否定的，他们往往是那种有着吉士汉堡观念的人，总是倾向于把工作推向100％的干的方式。

无论要做的事情有多大，必须学会花更少的时间工作和花更多的时间思考工作本身。正如《人件》中所说，“一个在不可能的给定时间内要完成的项目，恰恰需要抽出时间来频繁地召开头脑风暴会，甚至组织一次项目组聚餐或者其他诸如如此类的事情，以帮助个人融入高效的整体”。软件开发是由人来发挥自己的才能、创造力完成的，在做事情之前理智的规划，而不是盲目的蛮干，可以使整个项目处于控制之下，更重要的是可以使开发者从容地、正常地发挥，不至于乱了分寸，或机械地完成开发工作。

一种说法是：“程序员是吃青春饭的”。为什么？是软件开发本身的特点决定？似乎合理，因为人随着年龄的增长，做技术难免要受到影响，但是这些影响其实微乎其微。关键的问题不在程序员，而在于管理者，在于在拿到任务后的做事方式。通常情况是这样的，拿到任务后，稍微一考虑任务重，压力大，马上开始工作，以至于出现“我们还没有时间来考虑这项工作，只有时间来做这项工作”这种可笑的做法。如此下去，肯定是效率不高、质量又差，为了赶进度加班加点这些做法似乎成了救命的稻草。年轻的程序员有着好的身体，没有家庭的负担，似乎更有优势，年老的程序员越来越吃不消。但这样的开发是虽然仍然在从事脑力劳动，其实是一种“机械的脑力劳动”，没有真正的用头脑开发，更像是在拼体力。

好的管理者应该培养自己的员工成为会工作、更会生活的人，而不是成为工作狂。

Brooks在《人月神话》中将软件开发活动分为根本任务和次要任务,根本任务打造由抽象软件实体构成的复杂概念结构;次要任务: 使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言.其实这两方面都是在技术层面上的改进，而技术是由人发挥创造力才产生的，所以解决人的问题才是根本问题。因此，把建设以人为本的企业文化作为根本任务，把技术层面的改进作为次要任务或许才是一个更加理性也是更加有前途的划分。这才是我们苦苦寻求的银弹，否则“除非次要任务占了所有工作的9/10，否则即使全部次要任务的时间缩减到零，也不会给生产率带来数量级上的提高.”