人力资源管理
对于书中人力资源管理这部分的内容，我感触颇深。本科时我曾连续两年代表学校参加全国大学生机器人大赛RoboMaster，第一年是作为普通的队员参加，第二年是作为管理人员之一参加。团队中正式队员35人， 再加上顾问、预备队员、指导老师，是一只近50人的庞大队伍，在这一年的开发与团队管理中，我几乎把书中提到的各种管理问题都遇到了一遍。在垫付了超过20万的资金以及无数的精力和时间后，我们仍然在小组赛就被淘汰了。赛后我们忍痛开了总结会，队长（队长为了比赛甚至放弃了考研）以及作为项目管理的我，不得不向大家道歉，因为我们只做到了一个技术人员，没有做好一个管理者。
团队的计划表，其中黄色表示未能按时完成的任务
绝大多数失败项目中，没有一个是因单纯的技术问题而导致的
绝大多数失败的项目，都与“人”有关，比如人与人之间低效的沟通、人员的流失、过大的工作压力等等。与其他工程不同的是，软件工程是一类偏脑力劳动的工程。
程序员大多有点偏执，有的人可能会花很长的时间去思考一种算法，花一个晚上去设计一个接口的定义，甚至是花数个小时的时间去想一个变量的命名(我在机器人队的一个搭档就是这种人)。管理这样一群人是非常困难的，特别是在质量与时间的权衡上。任何一个软件项目，在它彻底结束或上线之前，都很难准确的描述到底达到了一个怎样的完成度。比如一个项目完成了预计功能中80%的功能，剩下20%的功能却可能还需要花费更多的时间。所以管理人员的一大难题是如何估算项目的产能，避免给程序员太大的压力或者工作量过少。
书中有一个有趣的统计，比较各种估算方法给产能带来的影响，结果是：
相比于管理人员的估算，程序员给出的估算对应的产能会高一点。若二者一起做估算，对应的产能处于二者之间。
而聘用了第三方系统分析师的调查显示，系统分析师给出的产能数量又远远超出了程序员自身的产能估计。这个也很好解释，因为系统分析师往往有富有经验的程序员担任，他们对系统中存在的坑有大致的了解，但是他们对实际进行开发的程序员的能力可能会有一个错误的估计，因为程序员的水平真的很难度量，这就造成了这种结果。
该研究最后给出了一个更有趣的数据，再没有进行任何评估的项目中，实际产能远远超出了以上的各种估计，这从另一个方面证明了老板不给任何时间压力（“你们昨晚了告诉我一声就行”）的项目产能最高。但是这种做法的风险无疑是巨大的，除非老板对自己的程序员有充分的了解和信任，否则一旦有不合格的程序员混入这样的项目，将会使整个项目失控。
办公环境
办公环境真的很容易影响程序员的开发效率，有的时候需要一个人安静的思考，有的时候又需要和队友方便的沟通。其实这部分我与书中的想法有点不同，如果非要在封闭式与开放式办公中做选择，我会选择开放式。但如果有得选，我希望是一个小团队一间的办公室，因为我希望能在保持基本的社交作用和节省交流成本的同时，也能间歇的提供一个安静的、利于思考的环境。在学校的时候，我喜欢在夜深人静的时候一个人默默的写代码，也喜欢在研讨室、实验室里与同学们大声讨论各种技术问题（所以我几乎不会去教室或图书馆写代码）。大三时在参加一个比赛的时候，我们团队三人先是在一个实验室里合作开发，讨论各种架构、接口的设计，在基本上确定了任务需求之后，我们各自在寝室疯狂加班，我最终连续肝了接近60个小时，写完了前端的代码和100多页的文档，顺便剪了一个宣传视频。我怕觉得很有意思的是我们在机器人队中的开发环境，由于场地有限，我们在各自的寝室写完大致的代码后，到实验室盘腿坐在机器人旁边进行各种调试，有时会一调就是一个晚上。但是由于人员众多，场地很快就变得十分凌乱，对于写代码的同学来说还好，机械组的同学就常常把时间浪费在了找各种螺丝、扳手上。在深刻体验了这种环境的弊端之后，痛定思痛，新一届的队员们自己购买了桌椅、柜子，对各种工具分门别类的存放起来。
整理之前的工作室环境
比赛时半夜两点拍摄的正在宾馆干活的队友们
最后也顺便祝愿新的一届队员们能取得一个满意的成绩！
点击量：1110
