浅谈软件研发管理一个例子计件可行不？CMMI等有效的工具撰写说明书开发文档管理的核心是人别做没意义的事情To 2014

不知不觉间，已经从业十年有余，而今又是一年的年底，想写写总结，最近自己一直在想关于软件研发管理的一些相关的问题，所以写此文做一个概括，许多观点也许并非本人原创，但具体出处我就不去一一考证了。

最好的管理方案就是这么一种东西：你可以不断尝试去接近它，但永远达不到。这么多年的工作下来，我感觉这真是个赤裸裸的真理。这个“真理”不光对软件研发行业适合，对别的行业也适合。

一个例子

公司有一仓库，仓库里有若干员工，需要进行理货、入库、上架、贴标、捡货、出库……等操作，为了鼓励员工积极干活，设计了“计件工资”，给每种操作设置了一个单价，多干多得，看起来很美；但很快就发现员工很会趋利避害，干活就专挑那些性价比高的干，而那些收益不高的活没人愿意干；于是组织管理人员经过N个月的调查和核对，调整各个操作的单价，直到看起来比较合适，尽管还是有些问题，但大致正确了；但仍然有别的问题存在，负责工作分配的仓库主管自己也需要干活，而且通常会给自己安排一些对自己有利的工作，可以多拿计件工资，弄得其他员工很不高兴，于是管理团队又经过N次开会商量决定不让仓库主管直接拿计件工资，仓库主管所干的活将按下属员工的工作量的比例分摊给下属员工，然后仓库主管拿所有下属员工的平均计件工资乘一个系数的“系数工资”，这回够复杂了吧！看起来已经相对公平；但公司发现仓库员工还是不断减少，招来的新人干不了多久就走人，认为这样十分不公平，因为新人的工作效率远远不如老员工，他们干活一样也很累，只是由于熟练度不高，效率低，而现在这种计件分摊的机制对他们很不利，他们拿的很少，而主管也没法分配更多的任务给他们，又经过若干次开会讨论，决定给新员工在试用期内给一种“新人补贴”；接着随着某些操作的熟练度的不断上升或在操作中使用了一些捷径，某工人的计件工资出现了前所未有的高，公司管理层觉得这样很不妥，需要对此操作的单价进行调整，工人就不高兴了，“你们凭什么又不兑现自己的承诺？”，于是多次反复……我还没提到考勤管理，加班管理和饭贴等情况，总而言之，这并非一件容易的事情，而且，更关键的：这么一个“管理”的本身，经过这么长时间的调研和会议，也耗费了公司相当大的一笔资源。不过，话说回来，不管理能行么？

计件可行不？

上面的例子我向你保证100%真实，如果换到软件研发管理去，情况会更加复杂，因为和仓库操作工相比，软件研发是一种“智力密集型”工作，其工作计件十分困难，工作质量更加难以评估，而“计件”以外的工作也是难以估量，所以企图以精确“计件”的方式去管理软件研发团队的，肯定都不能成功。

比如按照产生代码的行数计件？如果那样的话程序员就企图把代码写得烂一点，本来一行可以完成的功能现在分作几行写，这样行不？难道你还要聘一个人专门检查程序员是否多写了不必要的代码？更关键的是代码的质量如何判断？应该用什么标准？你能想到的大概就是测试了，测试出来的bug越多，质量越低，但bug有大有小，难道都要一视同仁？还不算有些bug需要运营了很久之后才被发现的情况，好吧，当你根据bug的严重程度做好加权之后又发现程序员和测试组会串通：“你发现bug直接告诉我，我偷偷改了就是，省得扣我KPI，回头请你吃饭。”于是你又规定测试也得KPI，测试出来的bug越多KPI越高，但这样很不幸把测试跟开发对立了起来，有些问题大家互相推卸，根本得不到很好的解决，不涉及到钱的时候大家都可以表现得很谦虚，但一旦要跟自己有利害关系了，每个人都会挖空心思去提高自己的收益，程序员智商本来就不低，手段方法恐怕只有你想不到的，没有他做不到的。这还没完，由于推行了这种策略，公司里已经没有技术人员愿意去研究新的技术，没人愿意改进自己的工作，因为这些东西都没有被“计件”，于是公司成了一潭死水……接着不管如何改进，机械式的计件方案都不会有什么改观，这是由软件开发工作的特殊性决定的。更惨的是，最后你发现这样“管理”本身还消耗掉了公司相当大一笔资源，直接把这些钱发给程序员的话激励效果可能还更好点。

另一种“计件”的方法是根据项目来，看一个项目能带来多少收益，进而给员工发放项目奖。——实在有点不好意思说，我工作超过十年了，尽管大多数公司都提及了“项目奖”，但至今我是一分都没拿到过啊！程序员也不是傻子，大家都清楚，没有明确承诺的“奖”其实就是空头支票，这个大家都一清二楚了。即便你作为管理者，决心去执行项目奖，怕对程序员的激励也很有限，因为很多项目往往都周期很长，收益不那么容易看到，许多人没信心等到那天，即便等到了，项目也不是他一个人做的，别人不用那么积极也照样能搭顺风车拿到项目奖，那自己干嘛那么努力呢？所以着急的恐怕到最后也就项目经理一个人。（参考“智猪博弈”）

一种可能比较靠谱的绩效评定方法是“经理直接打分”，因为对员工的工作最了解的人就是经理，谁的贡献大，谁的贡献小，一目了然，但是，不用说，这种方法也高度依赖于一个大公无私的经理人。也许你想说，那员工的“自我评定”呢？——没用的，只要涉及到钱，不管自己表现有多差，每个人都会厚着脸皮给自己飙满分。

CMMI等

CMMI（软件能力成熟度集成模型）其实就是一套方法论，是为了能够保障软件质量和交付日期而提出来的软件公司的模型。CMMI分为五个级别，第一级最低，只要是家软件公司就可以“骄傲”地说“通过了CMMI Level 1”，如果能达到最高的CMMI Level 5，那就相当的牛逼了，理论上如此。

我接触CMMI是在2004年，那时候我在一家做对日外包项目的公司当程序员，我的上司对我的评价并不高，他一直认为我代码质量差，工作不行，其实主要的原因是有一次我登录到服务器上不小心重新保存了一个文件，内容虽然没有任何改变，但文件的时间戳变了，日本方面就抓住了这条“小辫子”，我的上司估计因此受到了比较严肃的批评，所以我的日子也开始不好过了……那时候公司正好在推CMMI，于是他把我分配到了CMMI组，我有些不乐意，我自己最喜欢的事情就是技术，直接接触代码，但这么一来，却有些同事对我羡慕嫉妒恨啊，心想这小子功绩平平，咋被分配去做管理了呢？

事实上，这种“管理”一点都不好玩，培训、开会、整文档就成了工作的主要内容，一大群人参加的会议，能有什么效率呢？一份功能简单的代码，就得对应上好几份繁冗的文档，如此般繁琐的流程，哪有什么创造性可言呢？只见大家对此怨声载道。不久后我离开了那里，那以后我一直都不认为CMMI是什么帮助企业改进的良丹妙药，它过于“学院派”，虽说“源于实践”，可又有些“不切实际”，最关键的是：这种方法论往往走着走着就把手段本身当成了目的，这样的管理，开销实在太大了。

后来，我一直想着如何不按照CMMI的方法去做，能否将它简化简化再简化，却又能保证软件质量，同时让软件开发的工作变得有趣，而不是把手段当成了目的。当然了，想这个的人大把了，而且他们已经提出了完备的理论体系，即“敏捷开发”，敏捷开发强调人作为核心，强调人和人之间的沟通和配合，我还专门弄了本书看，但遗憾的是，这一切依然过于“理论化”，上面的东西头头是道，不容驳斥，但到具体怎么做的时候，那真是一种“拔剑四顾心茫然”的感觉啊，我渐渐觉得，不涉及到如何具体操作的方法论都“不实际”，不具备“可操作性”。

有效的工具

做上技术管理的职位之后，我尝试推过一系列的工具，以此来提高我们的开发质量和效率。现在总结回来，除了源码管理工具（SVN）推得算比较成功之外，别的基本上都失败了，下面我一一道来。

项目管理工具

用于跟踪项目进度，但得人工填写，把一个项目拆分成若干块，然后每块拆分成若干个任务，分配给不同的人，并定下一个deadline，工具甚至能根据各个任务的完成情况绘制甘特图，对，我曾尝试过微软的project，用这种工具的好处是感觉项目就在自己的“掌控中”，但这仅仅是感觉而已。工具本身是为了通用性设计的，所以好些地方并不符合我们的特殊要求，得我们自己去改，而我们没有那么多的时间和精力，我除了安排任务之外，还要编写相当一部分的代码，主要是系统框架和一些比较棘手的部分，所以任务细分这个工作往往很滞后，我好不容易布置好任务之后情况却发生了变化，任务有变，或直接cancel掉，所有这些都需要我上去手工编辑，然后等其他人确认，大家都觉得这样很麻烦，多此一举，貌似没有这样的“项目管理工具”我们日子也都过得好好的，唯一最想要的可能就是老板，他一直很想知道我们具体的进度，尽管他不关心我们到底实在写代码还是在画画，而大家对此却并不怎么配合，渐渐地我也觉得这工具对我们用处不大，这玩意儿就是得手工去操作，去记流水账，为的只是一个“一切尽在掌握中”的错觉。

bug记录与跟踪工具

测试者向开发者最快地反映问题的方法当然是直接喊话，但这样最大的问题是没有记录，于是后来用文本文件记录，再后来用excel，但这些单机工具不利于共享，接着自然而言就想到一些issue track工具，这种工具大多数是基于web的，开源的很多，配置也并不困难，我们使用了一段时间，觉得有一定好处，但也不见得有预想中的作用那么大，我分析原因下来主要是团队较小，加上我们的项目变化过快，工具用起来显得有些不便，大多数程序的问题总是能在第一时间修正而无须记录，大家都这么想。我个人倒是觉得bug技术与跟踪的工具还是有必要推一推的，但要养成这么一个使用习惯，还需要诸多方面的努力。

UML建模工具

我用得最多的是数据库模型关系图、类关系图和时序图，我得说UML是很好的东西，我尝试过不少UML建模的工具，但这些工具大多都仅限于我个人使用，极少用于团队交流，原因是要学习这些工具的使用是得花上一些时间的，像类关系图这种东西，甚至看起来没有直接的代码那么直观，另一个很重要的原因还是跟前面所说的一样，变化过快，你好不容易画好了图，他们马上说要加上一个字段，代码直接就改好了，你图到底改还是不改？最快捷的方法当然是直接修改代码，然后上线一个新版本，用最快的时间把东西改出来，老板和用户是最高兴的了。所以UML这种东西我们利用率并不高，只用了数据库建模这一块，因为数据库的结构不像源代码那样直接有版本管理工具，我们为了对其进行控制，还需要这么折腾一下。

UI设计工具

我曾经说过，UI是最难做的东西，因为谁都能直接看得到，夸张点说，不管是老板还是扫地阿姨，谁都能对UI提出一套自己的见解并可能插上一手。我尝试过用不同的工具来画界面，比如photoshop，可以画出相当漂亮的界面，但花费时间过长，Visio也是不错的，但不管用什么，总是得面临这么一个问题：改动，频繁的改动！他们要变了，你的设计图改不改？改嘛需要花费很多时间，不改嘛，设计就相当于白费了。我后来发觉用word居然也能把界面描述清楚，而且word改起来比photoshop或visio简单得多，还自带了不同版本的比较功能，知道每次变了些什么内容，太棒了，如果word能行为什么不用word？实在word描述不清楚的界面，再用visio或者photoshop来画好了。

问题反馈系统

当用户遇到问题的时候，就给我们打电话或发Email，他们就像一群不长记性的人，过去遇到的问题就仿佛没遇到过一样，凡是问题，也不管三七二十一，就直接找我们，所以这么一套问题反馈系统就应运而生了，让用户在遇到问题的时候，到上面去搜索答案，然后再提问，我们根据具体情况将问题标记为处理中，已处理，或关闭等，这是一个不错的主意，一定程度上帮助了我们减少对用户问题的重复处理，但也远非完美，我发现大多时候用户依然会无脑地提出如“系统无法使用，急急急”等不知所云的问题，这样的问题反馈系统最多只能算成功了一半。

WIKI知识库

我们在不断的做开发，不断地积累知识与技术，可这些东西时间一长就变得凌乱不堪，没有很好地组织起来的知识是没有价值的，于是我想到了WIKI，用它来整理公司的文档，这套使用Web技术的知识库能让我们随时随地查看和编辑公司的技术文档，而且还能看到历史版本，看起来很美……可实践证明了，这似乎不太可行，一来WIKI的使用门槛稍微有点高，大家都用不太好，二来大家都没有这个动力去使用它，养不成这样的习惯，外加一个原因就是面对变动频繁的东西，WIKI用起来还是有些不方便。所以后来WIKI上的东西基本上都是我写的，有技术文档，编程规范和一些公司内部的文件。由于更新内容不多，难形成一个连贯的知识库，所以后来用得越来越少，基本上是荒废了。

员工交流平台

这个东西其实不是我推的，但也把它列一列吧。公司HR部门有人提出弄这么一个论坛作为员工交流平台，于是让我们搭建，这个并不是太难的事情，都有现成的，我们直接Discuz。头先几个月大家都上去注册了自己的ID，还有不少人上去发帖，发布一些活动啥的，但很快人气剧降，直到荒废无人再用。这种交流平台在很多大的公司都有，如阿里的“内网”，人气还很旺，大家热衷于利用这么一个交流平台，对企业文化氛围起到了一个相当积极的推进作用，而这种方式对我们却不可行，这很大程度上取决于老板，在我们老板眼中，业绩才是最重要的，别的都靠边站，他根本不可能到这么一个论坛来跟大家交流，疲于应付业绩的员工也无心谈论别的事，推不成功，那是理所当然的了。

代码版本控制工具

如今主流的也就两种，一是svn，另一是git，别的都是异类，svn是我在公司推得最成功的工具，之前用的是sourcesafe，一个连微软自己都不用的东西，开发者们整天叫嚷最多的就是：“那个谁，把代码签入一下。”尽管svn的使用很简单，但我还是破费周折才让大伙们走上正轨，如果前面提到的那些工具都并非是必须的，那么代码版本控制工具就是必须的，svn属集中式管理，适合在公司内部用，git则是分布式管理，适合开源项目或移动办公，学习曲线相对稍陡。

最后我不得不声明一下，我推这些工具的失败并不意味着这些工具没用，每种工具都有适合它使用的场所，而每家公司都有其特定的环境，脱离环境谈工具是没什么意义的，这只是我的经验。用一句话概括——什么工具行之有效，就使用什么工具。

撰写说明书

我想说的是：这些东西用户根本就不会看。

当今社会信息泛滥，人们生活越来越快餐化，能静下来看书的人越来越少了，大家看新闻也是只看一下标题，内容嘛扫几眼就不看了，看不了那么多，除非真是自己很感兴趣的，认真写博客的人也越来越少，进而换成了“微博”，上面充斥了各种吸引你眼球的段子……还有，你试想现在还有那个手机App会带上一份“说明文档”？换句话说，需要看说明书才能用的App，谁会去用？

曾经我也认为，没有说明书的产品就称不上是完整的产品，可我们现在还需要写一本用户根本不会看的说明书吗？

另外，说明书的坏处还在于软件产品功能频繁变动时候，它往往没有跟上，这样的说明书作用就更加小了，有时还会误导人（如果有人还去认真读它的话）。

所以如何开发一个不需要说明书的产品，就成了我的目标。对于消费类的App来说，似乎不是太难，开发者可以在界面中加入一些即时提示来帮助用户使用，还可以配备简短的使用教程，让用户在第一次运行App的时候快速入门。但企业应用就没那么幸运了，因为其最大的障碍其实是复杂的业务逻辑，这些东西无法用简单的一点提示就能说清楚，其中涉及的概念术语又多，说明书又没人愿意看，所以实施和培训几乎是必须的。这看起来对企业应用来说也理所当然。

说明书其实也并非全没用，有说明书，说明你的产品够“完整”，至少看起来如此。如果你足够强势，你就可以对客户吼道：“这问题说明书上有，自己看！”另外就是在培训完了之后洒脱地把说明书往桌子上一扔：“我今天讲的东西说明书上都有。”尽管后面还是没人会去看，有啥问题照样会找上你，他们甚至连程序提示什么都不会去看。

开发文档

我开门见山直接地说了吧，开发文档的最大问题和前面所提到的那一大堆工具所面临的一个问题一样：就是很难及时跟上变化。

如果要让开发文档跟得上代码的变化，那就得花费相当大的人力去维护它。为什么不是代码跟着开发文档变？因为每次要改动的时候都很急，如果大家稍微有点懒的话，文档也就没去改，还有的时候变化太大，相当于要重写许多文档内容，工作量太大了，来不及。而开发文档这个东西是用来指导开发的，开发一完成就基本没人再去看它，久而久之，文档和代码越走越远。

我回想起许多年前我负责的一个项目，一开始在写代码之前大家整理了不少文档，可弄到最后我发现最有用的文档只有我画的一张业务逻辑图，任何时候对业务有疑问就可以看看那张图，问题大多能迎刃而解，而密密麻麻的文字没人愿意再去看。所以之后我一直奉行着“实用为主”的这么一种策略，没用的东西就不去做。开发文档我认为也应该如此，要明白哪些东西有用，对开发起到指导作用，哪些东西写完之后就过时没人再会去看，还有哪些东西要求投入过大而不太现实，总之要以“实用为主”有所取舍。

当然了，有些项目是开发中间件的，开发出来的东西是给别的程序员用的，那配套的开发文档就很重要，这个必须作为产品不可或缺的一部分，认认真真整理。

管理的核心是人

不涉及到人的管理就不是真正的管理，最多只能叫做“文案工作”。

上面这句话如果我没记错的话，来自于过去我看的一本书——《最后期限》，需要说《最后期限》这本书是相当好的一本书，可以把它当作《人月神话》这本书的附加读本，它以一个虚构的故事来阐述软件管理是怎么一回事，十分生动。

后来我渐渐觉得，软件研发的管理，其实就是如何充分发挥每个人的才智的方法。人才是主角，所以那些文案工作根本就是次要的，最终一切的一切不都是靠人吗？

如何发挥一个人的最大的能力呢？当然就是让他去做自己喜欢做的事。

我曾感慨，要求一个人去做一点事是多么的困难！比如有次想让公司的美工把图改小一点，他认为他原先做的正好合适，如果觉得大了，那肯定是我的问题而不是他的，他还能搬出一大堆理由，技术上来说图不能轻易改变尺寸，因为调整尺寸会让图片内容走样，总之是不行的，我有些恼火，于是自己打开photoshop把图改了，当然，也许结果你也猜到了，我这样做引起了他更大的反感，“图是我设计的，凭啥你说改就改呢？那以后图我也不做了。”是不是这种道理？想办法如何让同事配合自己的工作，需要大量的人与人之间沟通的技巧，让这个任务被同事认为是他自己喜欢做的任务，而不是强加给他的任务。学会如何与人沟通，才是管理的精髓所在，而我一向做得不够好。

说到人的管理，这是一个很大的话题，我感觉自己能力不足以将这个话题讲得有多全面和深入，这方面有很多书。我现在只能谈谈个人对于软件研发这个工作的人员管理的一些粗浅见解。

了解每个人的特点

人跟人之间的差距真是太大了，个性，爱好，能力偏向……都有可能完全不同，有些人喜欢接受一项内容详细明确的工作，有些人着喜欢有更多的个人发挥空间的工作；有些人工作快速粗糙，有些人则慢工出细活；有些人善于交流和表述，有些人则言不达意，常常不知所云……充分了解每个人的情况之后才能做出相应的安排。如我上文中提到的我的经理安排我到CMMI组就是个错误，他不了解我对技术的热爱和对那些充满僚气的会议的厌恶。

不要对每件事都亲力亲为

诸葛亮就是个很好的反面例子，细致入微，事必躬亲，最后把自己给累死了，团队还不见得管理得有多好。更值得去做的事情其实是培训团队成员，这样才能把自己解放出来，有时间去想些别的事情，或专注于项目的某一块，千万别把自己想得有多万能，人的能力再强，时间和精力也是有限的。

不要让团队做设计

参考：《再谈软件开发中的合作》。

尽量发挥每一个人的潜力

充分信任和激励每个团队中的成员，让他们觉得是为自己做事，而不只是应付工作。这又是一个很大的话题，如何激励一个人？我建议去看看《软件随想录》中的第一部分——人员管理。这本书貌似没有中文电子版，我这里没法摘录太多内容，英文够好的话可以直接去作者的blog去找找，或者像我这样直接买一本纸张书，你肯定不会后悔。

别轻易招人

根据Brooks（《人月神话》的作者）法则，往一个已经延误的项目中添加人手，只能带来更多的延误。软件研发这事情绝不是1+1=2那么简单，软件研发的工作没办法划分为毫不相关的小任务，然后让不同的人无须沟通和交流就能准确执行，所以大多数时候，想通过招人来解决项目延误的问题都是不太可行的。只有在业务扩大，真正出现人手不足的时候才能招人。

宽松化管理

相不相信，其实一个开发人员，能够高效地工作的时间一天不会超过三小时，其余的时间都是低效的，如果从上班开始，除了午餐时间，从头到尾都在聚精会神地写代码，恐怕到下班的时候脸都会发青，这是受人的精力所限，无关工作态度，所以我认为高效地将工作完成比拖沓地加班加点更有意义。除了完成工作，一个技术人员的最重要的事情恐怕就是能看到自己的长进，工作本身当然会带来长进，但也不是全部，还得有时间去探索一些自己半熟悉的领域，这样才能真正提高自己，如果团队上下都培养出了这种主动地提高自己的水平，又反过来不断改进自己的工作的“技术氛围”，那这必定是个高效而有活力的团队。

也许我说的这些都没太大意义，因为人的管理往往不受我们技术人员所控，老板看到谁加班就认为谁积极，是好员工，老板也不会去了解代码的质量多高多低。但，还是那句话，不涉及到人的管理最多只能称得上是“文案工作”，不管你研究了多少种工具和方法，能起到的作用恐怕也非常有限。

别做没意义的事情

最后，别做没意义的事情，如果可以的话……这是什么意思？因为有很多没意义的事情是上头强加的，你不得不做，但如果你能做决定的话，那就别浪费这个时间了。我以前有家公司，有一次开会的时候一个高级经理提了这么一个建议，就是要写“工作时间”，所谓“工作时间”就是你在这一周里在一个项目中花了多少小时，这个建议被采纳并一直执行下去，不久后那高级经理离职了，而我还继续一直忍受着这该死的错误的决定。很长一段时间里，其实我们的项目一直处于半停滞中，我们并没有把所有的时间都放在项目里，有时候去协助别的员工解决一些问题，有时候维护和整理历史代码，甚至有时候在修理机器……这些工作算在哪个项目里？真真正正我负责的立了项的项目只有一个，叫“PRS2”，所以我每个“工作时间”都只好写着“PRS2 40小时”——这样其实毫无意义。

To 2014

本文应该是我2013年最后一篇博文，再过几天新年就要到来，其实一年并没有想像中的长，有时候时间就是那么弹指一瞬间即过，希望自己的所作所为更加有意义，Hello，2014。