很荣幸能在MSRA上邹老师的软件工程课。我选用的教材是《移山之道》。自翻开书起，我就被作者的匠心独运所吸引：以故事贯穿通篇结构，在实战中讲授方法和缘由。书中也包含了很多古文学知识，每每用到恰到好处，只见作者信手拈来，令人叹为观止。这是题外话，我在这里主要是分享一下阅读《移山之道》的时候想到的几个疑惑。
一 如何评价成员的工作
个人觉得这是个很值得讨论的话题，网上也有一些观点，大多是围绕几个方向，比如多劳多得、量化与非量化、区分不同岗位、代码规范等。很多人都有自己的体会，比如“如何评价个人在软件开发团队中的绩效 ”（http://www.cnblogs.com/rosting/archive/2011/09/08/2171605.html），“软件工程 绩效管理
”（http://www.cnblogs.com/xinz/archive/2011/05/01/2033927.html）。
但是我感觉，世界是多变的，人有不同性格，团队的绩效评估方式究竟有多公平？
如果说看任务量，有些人血气方刚，顺手就百行百行的敲代码，可谓日进千里；有些人心若止水，追求精辟，写出来的代码很漂亮，很严谨。 还有时候，成员A的工作比较明确，每分每秒都可以不停的写；成员B的活比较开放，他可能会花50%的时间去思考n中不同的方法，然后选择其中一种。但是，思考是无形的，别人看不到，至少团队以外的人看不到。于是出现下面的情况：在项目的历史记录里面，两个人同样努力的在工作，但是一个人的功劳记录有一大堆，另一个人的只有寥寥几个字。
如果看背景，博士VS本科，老员工VS新人，等等。犯了错误的时候，新员工和老员工得到的评价是一样的吗？学历高的人所作的工作，组评的时候是不是不知不觉中乘了一个大于1的因子？
书中提到“扁鹊的三兄弟”的故事，翻译成白话就是“扁鹊的大哥治病看神色，病没好就治愈了，所以他的名气不出家门；二哥在病人稍微有不适的时候把病治好，所以名气不出巷子；扁鹊治病是当病人严重时，才使用针、汤汁、草药等有副作用的方式，名声反而传遍了各个诸侯国”，其中也有个寓意：一些高水平的程序员，写的程序很好的运作，旁人看来，误以为是他的活太简单，没什么大不了的；一些程序员的工作，被TEST查出很多弊端，然后修改的热火朝天，别人一看，哇，这么复杂的活啊。现实常常这样，评价者不可能很仔细的审查员工的每一个细节。
二 处理分歧
之前看书的时候，记得书中提到“银弹”决定权的讨论，意思是说，每个人有几枚银弹，当遇到意见分歧时，成员可以选择牺牲一枚“银弹”来让团队采纳自己的意见。这个固然很有道理，但是我在想，现实作用是如何的？当你对一个思路、一个新的算法很有信心的时候，因为别人用了银弹所以你必须放弃，你会抱怨“银弹sucks”么？ 它带来负面影响有多少，比如，“被银弹”的人整天盼着对方的方法赶紧失败，或者不积极提供帮助，最终拖累了整个团队。
三 WBS和时间的分配
在我们软件工程项目中，每个人都要对自己的工作划分、预期完成时间（要求一个任务单元在4小时以内）。这个听起来就像把大象塞进冰箱里只需要三步一样简单明了。可同学们的体会，基本是预估！=实际。项目进展中，我们随时可能发现，哎呀，还有一些工作没有考虑进来，于是赶紧添加workitem；或者发现某些items是不需要做的，某些items的时间远远不止4小时...这也许是新手的困惑。但是无论是纵向还是横向划分项目，能有人料事如神的把握每一个细节么？尤其是面对一个创新工程，很多技术需要探讨，需要面对一些未知领域，不确定性就更高了。
以上是我想分享的三个疑惑。读完《移山之道》，疑惑是远远不止这些的，比如其他同学提到的敏捷开发模式的疑问；比如工作时间问题，每周有40小时，出去一些开会讨论、收发邮件、帮同事解决问题等杂七杂八的事情，每周估计有32小时工作，但是逝者如斯夫，对于开发人员来说可能不够用，于是加班加班...于是“码农”出现了。如果有一个方法论，解决这个问题，让“码农”不在加班，那该多好。
好书要多读几遍。我想再读一遍移山后，对很多疑惑的看法肯定会有新的认识。
扫一扫
800
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
