Reload Original PagePrint PageEmail Page

2006年老文《关注软件开发项目中的人》 - 思考IT - 知乎专栏

从1995年我开始带领3个人的软件团队起,到现在也10多年了。一直以来我都在思考,如何才能确保一个软件项目能够顺利,成功的开发完成。而我能够得到的最为重要经验是:“决定一个项目成败的最关键的因素,是人!”

软件是人开发出来的,而且到目前为止,也只可能是人开发出来的。但是,在通常的,对于软件项目、软件工程的讨论中,关于人的讨论,往往被淹没在对于技术、方法、框架、过程等等话题的讨论之中。

这次正好有这样一个机会,可以把我长久以来的思考,整理出来,和大家一起探讨一下,软件开发项目中的人。这篇文章的预定读者,是项目经理,或者再高一级 的 技术部门经理。一个项目组里的人是什么样子,或者最后这些人会变成什么样子,大部分是由这个项目的头是个什么样的人来决定的。

一、选人

每个软件公司都在招人,或者曾经、或者将要招人。但是,有多少软件公司,能够招到自己满意的人才呢?大家都在说现在人才难找。问题在于,有多少软件公司,懂得如何招人呢?当一个人才来你们公司应聘,你们能够发现他,而不是错过他、赶走他吗?

有些公司,根本不知道自己需要什么样的人才,于是就到网上去搜索一把,找来一堆自己都没有看过的题目。然后交给来面试的人做。绝大多数这种问题,要么特 别变态,要么特别刁钻,要么毫无意义,要么只会让人觉得可笑。现在都什么时代了,还要求我们的程序员,拿着一支笔,对着一张纸来做题目?写错了一个字符, 就会被扣分。拜托,现在的Google已经能够查到绝大多数问题的答案了!现在的IDE已经能够发现绝大多数的语法错误了!你们还在出这种遍历二叉树的题 目?

如果你们一定要笔试,请不要出这种毫无意义的编程题行吗?

如果是我来出笔试题,我会通过笔试,考察一个程序员的描述能力,也 就是把一个问题、一件事情,通过一段文字,干净利落的描述出来的能力。比如:请通过纯文字(不含任何UML图),描述一个ATM取款机的人机交互过程,以 及可能出现的异常现象。通过这样的笔试,我可以考察一个应聘者的顺序思维的能力,因为纯文字的描述是线性的,通过线性的文字,描述复杂的事物,需要有一个 整体性的思维,然后才能写出由上而下,层层分解的清晰描述。还可以考察的一点是:有没有错别字,这一点也许有点奇怪,但是,真的有很多程序员,不注意自己 的书写,有没有错别字。这也是严谨性的一部分。

再来说说面试,据说,越是大公司,面试的次数越多。据说,面试一般在笔试之后。据说,面试能够考察很多方面的能力。事实上,大多数面试者并不知道如何面试,他们看起来煞有介事,其实也忐忑得很。

在我看来,面试主要考察的,是两个方面,沟通与表达能力,还有就是一个人的个性。通常我面试别人,都会提同样的一个问题:“说说你最近做过的一个项目, 技术方面的,管理方面的。”我最希望听到的,是一个人带着非常投入的语气,像描述一场战役一样,描述他们所面临的技术挑战和管理挑战。有些人比较专注于技 术,他们对于解决问题很有兴趣,因此描述起自己的那些光荣成绩来,总是很有热情。有些人比较专注于业务,他们会相当细致的分析那些具体的业务逻辑,讲解其 中的复杂之处。有些人比较专注于管理沟通,如何保证项目顺利的完成,他们有很多心得。这些都很好。但是呢,往往也会听到抱怨,比如团队的沟通不好呀,人家 的技术差要他帮忙呀,客户的需求没有逻辑呀,领导的管理比较混乱呀等等等等。还有些人比较注重反省,最近的这个项目,所得所失,他都会认真的、甚至是反复 的去想,去总结。听这些叙述,就可以初步了解一个人:兴趣何在,是否愿意并善于沟通,是不是勇于承担自己的责任,还是动辄怨天尤人?通常,愿意反省自己的 人,都会更快的进步,这是非常难得的优秀品质。

笔试、面试。其实都不足以全面的了解一个人,前者容易受困于标准答案,后者容易被当时的谈话氛 围所左右。而我最推崇的判断一个程序的水平的方式,是看代码。给他几天的时间,让他去了解一个以前从来没有涉足过的技术领域,然后写一个简单的demo交 上来。这样我可以考察他的:

快速学习的能力:一个全新的领域,能够在多少时间里初步掌握。

在开发速度与功能设计方面的权衡的能力:完全由他自己决定开发什么功能,什么时侯开发完成可以交给我。

代码的编写能力:代码是否好懂,这是一个重要的考察点。

以及编程的严谨性:是不是没有bug,或者足够少。

说得不客气一些,大多数公司,根本没有这样的能力,来以这样的方式招聘程序员。因为他们负责招聘的人,已经好多年都不写,不看代码了。更不要说分辨代码质量的高低了。

二、看人与用人

没有一个办法,能够保证招到合格的员工。哪怕是像我这样,通过代码来考察程序员,也难免走眼。所以,才会有通行的试用期 制度。在试用期间,公司需要仔细的观察已经招聘进来的员工,是否达到要求,有没有看走眼?我遇到过许许多多的程序员,人与人之间的差别真是太大了。在这里 就简单聊聊我所见识到的不同类型的程序员吧。

1、独当一面型

在我的开发生涯中,曾经有幸与这样的同事一起共事过,他们能够搞定一切,不但快,而且好。他们能够完成任务,而且往往比 要求的做得更多,考虑得也更多。合理的要求,他们都会坚决的执行,而不合理的要求,他们也不会一味的盲从。就像三国里说的:“卧龙、凤雏,得一而可以安天 下。”基本上这样的人才是可遇而不可求的。这样的人才该怎么用?分配的任务,越是有挑战性,他们就越是喜欢。然后尽一切可能,保证他们心情舒畅,不受无聊 的干扰,专心做事就行了。

2、胜任愉快型

这一类程序员,更加懂得生活,他们能够完成给定的任务,不多,也不少,不快,也不慢。因为生活可不仅仅是编程那么枯燥的 事情,还有许多值得花时间去玩玩弄弄的东西。那些没有眼光的老板,光看到他们准点下班,甚至晚来早走,却没有发现他们已经搞定了工作,早就不想蜷缩在电脑 面前了。要用这样的人,其实挺难的,尤其是当你想榨取人家更多的剩余价值的时候,会遭到顽强的抵抗。合理的,可持续的“使用”,才是双赢的方案。

3、信心不足型

这类程序员其实相当的罕见,大多数我所遇到的程序员,都非常的自信,甚至过分自信的都不少。难得遇到过几个信心不足的,水平其实都挺不错的,反倒总觉得自己无法胜任手头的工作。遇到这样的朋友,通常还是以鼓励为主,实在不行,也就只能放弃了。

4、任劳任怨型

每一个团队,都需要有一个或者一些这样的“老黄牛”。一个项目组里个个都是天才,不见得就是什么好事。软件项目开发,总 会有很多琐碎的,点点滴滴的小事,得有人愿意干。有些时候,项目组会受气受委屈,得有人情绪平和,不冲动、抱怨。总之,要想培养出一种成熟、稳健的团队文 化,这样的员工,就会必不可少。问题在于,老黄牛可能会能力不足,还可能会倚老卖老,这个时候,就需要权衡利弊了。

5、夸夸其谈型

他们很关心趋势、潮流、技术走向、最新名词,该听说过的,他们肯定都听说过。说起来也是头头是道。模式啊、框架啊、架构 啊,也是张嘴就来。但是大多数他嘴里的技术,却根本没有深入的了解和思考,经不起深入的追问。不过这种人,也是人才,不过不适合开发程序,而是去做售前工 程师之类的工作。要能够唬住用户,正是他们所擅长的。

6、快枪手型

我最初就是个快枪手,能够快速的完成主线功能,但是却从来不考虑例外情况。完成了给定的功能需求,但是代码却只有我自己才 能看懂(1天之内)。新的技术, 我也是很快就能上手,“Hello World”转眼就能跑出来。但是要再进一步深入专研,我的兴致就不高了。一个团队有一个这样快枪手,真是要非常的小心,才能用好。你可以分派给他各种类 型的任务,但最好不要给他太关键的功能点。因为究竟会不会出bug,他是无法保证的。要花更多的时间,并且更加频繁的检查他的工作,以确保他不仅仅是完成 了表面工作。更为重要的是,要不断的敲打他,督促他,逼他更加用心,努力提高。一个快枪手,也是有可能成长为独当一面的将才的。

7、狙击手型
狙击手是很难被考量他的工作效率的。他们一般都非常的沉得住气。最困难的技术问题,一般是由他们来解决的,最难发现和解决的bug,一般是由他们来搞定的。像这种高难度的活,基本上你不能给他们限制时间,信任他们,把最困难的事交给他们吧。

8、特种兵型
特种兵与狙击手比较容易混淆。 区别在于,特种兵喜欢搞自己的一套,而不愿意服从大局。他们真的能够完成任务,但是不太会考虑跟其他团队成员的配合。特立独行的性格,也使得他们相当的难以管理。所以,如果不是非“他”不可,那还是不要招进来的好。

9、一无是处型
莫文蔚有一首歌唱得很好:“你讲也讲不听、听又听不懂、懂也不会做、你做又做不好”。我不得不承认,我真的遇到过这样的程序员,基本上,我们都应该相信,有些程序员,其实是入错了行。

三、防人
有一句老话说得好:“害人之心不可有,防人之心不可无。”做项目要成功,总要考虑各种各样的风险,并且能够预先防范。其中最重要的风险,同样是来自于人的。要确保项目成功顺利,就要懂得防人!

1、时刻提醒自己
项目是由项目经理来带领的,所以,一个项目的成败,归根结底,该由项目经理来负责。那么,在考虑项目风险的时候,作为一个项目经理,很重要的一个准备工 作,就是考虑自己:我的长处在哪里?缺点是哪些?如果由于我自己的缺点,会给项目造成重大风险,那么,这些需要警觉的可能性,有哪些?我是不是一个比较情 绪化的人,会不会在做判断,下决定时,受到各种情绪的左右?
比如说,我的长处是解决各种突发的问题,但是不太能够坚持进行规范化的管理。有可能导致的问题就是:在一段时间内,我可能会沉迷于解决有趣的技术问题,而忘记了去把握整个项目的进度情况。这就会给整个项目,带来巨大的风险。

2、准确的估计别人的能力
这个前面也提过,速度快的程序员,会给人一种假象,就是效率非常高,能力非常强,容易让人对他比较放心。如果是一个夸夸其谈的快枪手,就尤其危险。同样 的,如果低估一个程序员的能力,也有可能引起心理的反感,毕竟被人轻视、看低,总不是一件好事情。更加重要的原因是,在分配任务的时候,应该量才而用,分 配给这个人的工作,无论过少或者过多,对于项目来说,都是不利的。

3、预防各种消极心态
每个人都有可能变成消极怠工者、刺头,似乎突然之间,他们就不肯好好的干活了。原因是多种多样的,项目太紧,压力太大;公司的激励机制出了问题,员工感到 不公平;项目需求变动过于剧烈,让人无所适从;办公室政治,小道消息满天飞;对于项目经理的管理能力与技术能力表示不满;已经打算跳槽,最近就快提出辞职 了;或者其他各种个人原因。
作为一个项目的管理者,尤其要不断的锻炼提升自己的“察言观色” 的能力,能够尽早的发现程序员的情绪变化与心态反应,才能够采取针对性的措施。这自然是一门非常深的学问,我自己也仅仅是知道该在这方面多下功夫提高。大 多数技术人员出身的管理者,真的很少有人擅长这个方面,这也是不少项目,管得不好的重要原因。

4、预防机密外泄
项目的代码、文档、计划等等,都是公司的重要资产,如果被竞争对手获得,就会给项目和公司带来巨大的风险。有些公司对此采取了非常极端的措施,比如不准上 网,不准带移动存储设备,不准收发E-Mail等等。还有些公司,利用技术手段监控员工的网络通讯情况。还有大多数公司,都会跟员工签订一份或合理、或无 理的《保密协议》。
对于这个问题,我是这么看的:
任何预防泄密的措施,都会给员工带来不信任的感觉,这样的感觉,永远都不会好。所以,真正要想办法,花大力气留住的,是人的心,而不是那些代码。不过更加 现实一点来说,一份合情、合理、合法的《保密协议》,还是很有必要的。至于其他监控、断网的措施,除非一个公司大到像中兴那样,否则还是不要采用的好。毕 竟你一个小公司,不能给人家大公司的待遇和保障,倒是让人家饱尝大公司的煎熬,凭什么呀?

5、预防人员离职
项目组关键成员的突然离职,往往是一个项目失败的重要原因。
有一次我在和当时那家公司的老板吵架。他当时在批评我,文档写得不够详细。我就顶了他一句:“写得不够详细,不是还可以问我的吗?”。
他接着说:“那要是你明天离职了呢?”。
我也接着顶:“通常的公司,都会规定离职通知时间的呀,重要的人员离职,都要提前一个月通知,并做好交接工作的嘛!”
他当时也在气头上,就说:“那你要是明天被车撞死了呢?”
这么说下去,自然是相对无言,不欢而散。不过这个对话,其实凸显了一个公司管理层真实存在的担忧心理,究竟该如何预防人员的突然离职?从我的经验来说,有 两个主要的方法可以尝试,一个是结对编程,使得项目中的任何一个知识点,都不会只有一个人掌握。另一个是我曾经写过的一篇Blog,叫做《软件开发文档的 持续集成》,其中心思想,就是尽可能的使得项目的文档,能够跟随项目一起生长,尽可能的使得已知的知识被写下来。

四、项目组之外的重要人物
项目要成功,项目组之外的人,也要很当心啊。

1、Stakeholder
这是项目管理中的一个专有名词,一般被翻译为:干系人;利益相关者;利害关系者;风险承担者;共 同利益负责者;受益人。简单的理解,就是那些于项目成败有关系的人。他们关心项目的成败,是出于自身的利益。因此,出发点往往是善意的。当然,他们或者高 高在上,或者一窍不通,或者自作聪明,或者自以为是,或者关心则乱,或者颐指气使。总之,难免会有让人气闷的时候。这个时候,重要的还是在于调整自己的心 态,要常常提醒自己,心态要积极,要正面,要立足于解决问题而不是制造问题。

2、老板是最后负责的那个人
无论成败,赚钱的是他,亏本的也是他。所以,不要总觉得老板不近情理,他肯定是希望你的项目能够成功的。作为项目经理,要相信老板不是你的敌人,更不要把老板真正变成你的敌人。要耐心的告诉他项目的实际情况,以赢得老板的信任与支持,这才是上策。

3、用户只需要懂得业务,不需要懂得技术
很少有用户,同时还是技术方面的行家,所以他们往往不知道该如何提出自己的需求,如果技术人员与业务人员之间,无法相互理解和沟通,项目就会非常的难以开 展。归根结底,用户没有义务理解你们的技术是怎么回事,而且,他们还是最终付钱的那个人。所以,尊重用户,尊重他们的需求,尊重他们的智力,是一个非常重 要的心理建设工作。

4、部门利益与公司政治
公司里不会只有你这一个项目组,总会有其他的部门,有其他的人员,既不是你的上司,也不归你管辖。但是,一不当心,他们就可能会给你的项目制造麻烦。所 ::...


免责声明:
当前网页内容, 由 大妈 ZoomQuiet 使用工具: ScrapBook :: Firefox Extension 人工从互联网中收集并分享;
内容版权归原作者所有;
本人对内容的有效性/合法性不承担任何强制性责任.
若有不妥, 欢迎评注提醒:

或是邮件反馈可也:
askdama[AT]googlegroups.com


点击注册~> 获得 100$ 体验券: DigitalOcean Referral Badge

订阅 substack 体验古早写作:


关注公众号, 持续获得相关各种嗯哼:
zoomquiet


自怼圈/年度番新

DU22.4
关于 ~ DebugUself with DAMA ;-)
粤ICP备18025058号-1
公安备案号: 44049002000656 ...::