浅谈软件研发管理

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

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

一个例子

公司有一仓库，仓库里有若干员工，须要进行理货、入库、上架、贴标、捡货、出库……等操做，为了鼓励员工积极干活，设计了“计件工资”，给每种操做设置了一个单价，多干多得，看起来很美；但很快就发现员工很会趋利避害，干活就专挑那些性价比高的干，而那些收益不高的活没人愿意干；因而组织管理人员通过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。