软件开发的人文关怀

jopen 12年前

  几年前,我从温伯格的《技术领导之路》中学到一点:技术人员往往更喜欢和机器打交道,因为他们“认为”自己更适合和机器打交道;但是,优秀的技术人员必须(也必然)具备好的沟通能力。所以,温伯格鼓励各位技术人员多加练习和其他人打交道的能力。温伯格的这个观点我是非常赞成的,好的技术人员一定需要“勇敢”面对他人,不能被“自实现的预言”局限在机器的世界里。

  不过我也发现,“技术人员(当然我主要说的是软件开发人员)不适合跟人打交道”的负面影响不止于此,它还成了一种刻板印象(stereotype),进而影响到开发团队之外的人。这个问题其实很严重,它会导致其他人和开发人员沟通时自觉或者不自觉地切换到“和机器沟通”的模式上来,比如单纯依赖邮件而避免见面沟通,比如“你只管这么做出来就好了,别管我用来干什么”。以面向机器的模式来与人沟通,结果往往是完整的项目(而不是狭义的“软件项目”)割裂开来,皆不欢喜。

  这种情况我一直在思考,究其原因,一方面是组织不够完善,另一方面,软件开发也缺少人文关怀——软件可以没有活力,而软件开发却不能没有活力;程序可以像机器一样,程序员却不能像机器一样。要改变这种状态,就应当增添更多的人文关怀(这里要多解释一点,“人文”其实也可以叫“人性”,它与“文” 并没有太多关系,只是“人性主义”约定俗成翻译成了“人文主义”而已),把开发人员当成活生生的人,而不是视为程序或者工具。

  当然,做到这一点并不容易,因为许多人印象里,软件开发人员就是“闷瓜”(充其量是“闷骚”),不好捉摸也不好打交道,那么干脆把他们当成工具来对待好了,“人性化”这样高难度的处理还是免谈为妙。但是事情并没有这么简单,因为不善于沟通,并不意味着开发人员不在乎人文关怀,想法,绝大多数人内心其实是愿意接受而且认可这些关怀的。只是因为许多开发人员不善于表达,因此并没有太多资料研究和论述软件开发中的人文关怀(或者开发人员真正在乎的人文关怀),所以这个话题值得一说。

  按照我的经验,以下几个方面都是软件开发人员比较在乎,而往往被其他人所忽视的,所以要增加软件开发的人文关怀,不妨多注意。

  第一,开发环境。这里说的“开发环境”不是指的 IDE,而是开发人员所使用的软硬件。这类设备是大多数开发人员唯一的生产工具,它们的好坏直接决定了开发人员的生产效率。可惜,许多人似乎并不理解这一点,很多公司只给开发人员配备普通的办公电脑,于是开发人员也只能贡献出普通办公人员水平的程序。目前来看,硬件上有比较大的内存(8G 以上),多台显示器(最好其中一台可以很方便地旋转),有用起来顺手的键盘鼠标(这点非常重要),软件上有无障碍访问 Google 的线路,健全开放的代码库等等,应该是必须的配备。提供这些条件,一方面可以切实提高工作效率,另一方面,可以大大改善开发人员工作的心情。后一点看起来无关紧要,却体现出对开发人员的尊重,其影响甚至超过前一点。

  第二,内部交流。我见过许多开发人员,即便是与旁边或者对面的同事交流,也不愿意说话,而喜欢在 IM 上打字,这样的效率非常低,更厉害的是造成隔膜——上班时间都没话说,下班时间就更没话说了,想要形成有凝聚力、配合默契的团队,就始终只能是美好的愿望了。所以,日常工作中一定要鼓励面对面的交流,(尤其是多人参与的讨论,可以专门安排地方交流),以逐渐形成面对面交流的行为习惯。不少开发人员即便自己比较闷,内心也不排斥甚至渴望活跃热烈的工作气氛。我曾经遇到过一名水平不错的程序员,他虽然不擅言辞,却不喜欢大公司内“死气沉沉”的技术部,更愿意呆在人人都愿意说话,人人有话说的小团队。现在,我们部门的开发人员经常会为了一些问题三五成群地交流,并不影响其他人的工作,这种气氛还很受大家喜欢。这些例子都说明,对开发人员而言,当面对话其实是非常必要也非常合适的交流方式。

  第三,工作意义。我曾说,程序员职业素养的体现之一就是对业务的了解。现实中,确实有不少一些程序员对业务不够了解,不过程序员对业务没有足够的热情只是一方面原因,另一方面,业务部门不愿意让程序员详细了解也是常见的情况。许多公司的业务部门需要开发力量时,既不描述项目的背景,也不介绍项目的意义,只生硬地扔过来几份文档(而且很多是粗制滥造的文档),就完成了对接。究其原因,有时候是这些人将程序员视作简单的“码农”,认为他们不需要了解业务,只需要写代码即可;也有写时候是因为程序员思维比较严谨,遵守逻辑,而不少业务部门的人缺乏这类训练,表达想法和需求时如不够严谨细致,更习惯“看一步算一步”的野路子。前一种情况是态度上的不尊重,后一种则是能力上的欠缺(或懒惰)。但无论是哪种情况,都会给开发人员造成非常不好的影响,最终结果就是项目的支离破碎,大家都龟缩在自己的地盘上,“铁路公安,各管一段”。其实按照我的经验,绝大多数开发人员并不排斥理解自己所开发的软件的实际应用和意义,以此为基础,大多数人甚至有兴趣去提出改进方案,这其实是非常好的状态,其前提是,需要为给程序员提供足够多的空间和机会去理解自己工作的意义,而不仅仅是告诉他们“你只管这么做就好了,别问我为什么这么做”。

  第四,个人成长。“一个人要怎样才愿意呆在一家公司?”一位前辈告诉我的是:如果这个人觉得公司有前途,自己也有前途,就会呆下来。这个答案我非常认可。但是在实际工作中,后一个“有前途”往往被忽略了。在软件开发中这个问题更严重。一方面,开发人员经常被视为生产代码的机器,大家只关注他提交的程序,而不关注他是如何提交程序的,在工作中有什么收获;另一方面,很多开发人员对于前途常有持续的焦虑,又得不到解决。常见的结果就是开发任务显得冷冰冰、硬邦邦,开发人员也感觉自己做的都是简单重复劳动,产生倦意甚至抗拒情绪(我知道许多人会说,要想成为一名好的开发人员,就应当在简单重复劳动中精益求精。这个道理确实没错,但也需要有合适的切入点,换句话说,应当让开发人员认可精益求精的价值,并真切体会到它带来的好处)。其实,有许多开发人员对自己的未来是有所打算的,比如有些人可能希望更了解业务,有些人希望更深入钻研技术。技术团队的领导平时应当能抽时间了解这些设想(如果能加以建议或指点就更好了),在安排新工作时有所照顾和侧重,这样,开发人员就可以感觉到自己的成长,觉得自己的工作是有前途的,工作起来也更有积极性。

  许多年前我读到董乐山先生翻译的《西方人文主义传统》,心里从此深深打上了“人文主义”的烙印(也由此知道了“人文主义”其实和“文”没什么关系)。经过这些年来的工作和思考,我又认定软件开发和其它工作并没有迥异的差别,既然其它行业可以提倡人文关怀,引入更多的人性化因素,软件开发也可以这么做。因为软件开发的特殊性,找到开发人员认可的“人文关怀”可能难度更大一些,但并非不可能,而且相当有意义。