人力资源管理

对于书中人力资源管理这部分的内容,我感触颇深。本科时我曾连续两年代表学校参加全国大学生机器人大赛RoboMaster,第一年是作为普通的队员参加,第二年是作为管理人员之一参加。团队中正式队员35人, 再加上顾问、预备队员、指导老师,是一只近50人的庞大队伍,在这一年的开发与团队管理中,我几乎把书中提到的各种管理问题都遇到了一遍。在垫付了超过20万的资金以及无数的精力和时间后,我们仍然在小组赛就被淘汰了。赛后我们忍痛开了总结会,队长(队长为了比赛甚至放弃了考研)以及作为项目管理的我,不得不向大家道歉,因为我们只做到了一个技术人员,没有做好一个管理者。

团队的计划表,其中黄色表示未能按时完成的任务

绝大多数失败项目中,没有一个是因单纯的技术问题而导致的

绝大多数失败的项目,都与“人”有关,比如人与人之间低效的沟通、人员的流失、过大的工作压力等等。与其他工程不同的是,软件工程是一类偏脑力劳动的工程。

程序员大多有点偏执,有的人可能会花很长的时间去思考一种算法,花一个晚上去设计一个接口的定义,甚至是花数个小时的时间去想一个变量的命名(我在机器人队的一个搭档就是这种人)。管理这样一群人是非常困难的,特别是在质量与时间的权衡上。任何一个软件项目,在它彻底结束或上线之前,都很难准确的描述到底达到了一个怎样的完成度。比如一个项目完成了预计功能中80%的功能,剩下20%的功能却可能还需要花费更多的时间。所以管理人员的一大难题是如何估算项目的产能,避免给程序员太大的压力或者工作量过少。

书中有一个有趣的统计,比较各种估算方法给产能带来的影响,结果是:

相比于管理人员的估算,程序员给出的估算对应的产能会高一点。若二者一起做估算,对应的产能处于二者之间。

而聘用了第三方系统分析师的调查显示,系统分析师给出的产能数量又远远超出了程序员自身的产能估计。这个也很好解释,因为系统分析师往往有富有经验的程序员担任,他们对系统中存在的坑有大致的了解,但是他们对实际进行开发的程序员的能力可能会有一个错误的估计,因为程序员的水平真的很难度量,这就造成了这种结果。

该研究最后给出了一个更有趣的数据,再没有进行任何评估的项目中,实际产能远远超出了以上的各种估计,这从另一个方面证明了老板不给任何时间压力(“你们昨晚了告诉我一声就行”)的项目产能最高。但是这种做法的风险无疑是巨大的,除非老板对自己的程序员有充分的了解和信任,否则一旦有不合格的程序员混入这样的项目,将会使整个项目失控。

办公环境

办公环境真的很容易影响程序员的开发效率,有的时候需要一个人安静的思考,有的时候又需要和队友方便的沟通。其实这部分我与书中的想法有点不同,如果非要在封闭式与开放式办公中做选择,我会选择开放式。但如果有得选,我希望是一个小团队一间的办公室,因为我希望能在保持基本的社交作用和节省交流成本的同时,也能间歇的提供一个安静的、利于思考的环境。在学校的时候,我喜欢在夜深人静的时候一个人默默的写代码,也喜欢在研讨室、实验室里与同学们大声讨论各种技术问题(所以我几乎不会去教室或图书馆写代码)。大三时在参加一个比赛的时候,我们团队三人先是在一个实验室里合作开发,讨论各种架构、接口的设计,在基本上确定了任务需求之后,我们各自在寝室疯狂加班,我最终连续肝了接近60个小时,写完了前端的代码和100多页的文档,顺便剪了一个宣传视频。我怕觉得很有意思的是我们在机器人队中的开发环境,由于场地有限,我们在各自的寝室写完大致的代码后,到实验室盘腿坐在机器人旁边进行各种调试,有时会一调就是一个晚上。但是由于人员众多,场地很快就变得十分凌乱,对于写代码的同学来说还好,机械组的同学就常常把时间浪费在了找各种螺丝、扳手上。在深刻体验了这种环境的弊端之后,痛定思痛,新一届的队员们自己购买了桌椅、柜子,对各种工具分门别类的存放起来。

整理之前的工作室环境   

比赛时半夜两点拍摄的正在宾馆干活的队友们

最后也顺便祝愿新的一届队员们能取得一个满意的成绩!

点击量:59


发表评论

电子邮件地址不会被公开。 必填项已用*标注