白癜风是遗传吗 http://m.39.net/pf/a_7653277.html

对软件研发行业而言最好的管理方案——你可以不断尝试去接近它，但永远达不到。

工作量评估方法

1、根据代码行数、质量（后期BUG），规范性判断。

2、根据项目来，看一个项目能带来多少收益，进而给员工发放项目奖。

3、一种可能比较靠谱的绩效评定方法是“经理直接打分”，因为对员工的工作最了解的人就是经理，谁的贡献大，谁的贡献小，一目了然，但是，不用说，这种方法也高度依赖于一个大公无私的经理人。

敏捷开发

敏捷开发强调人作为核心，强调人和人之间的沟通和配合。

有效的工具

源码管理工具（SVN）

项目管理工具

跟踪项目进度，把一个项目拆分成若干块，然后每块拆分成若干个任务，分配给不同的人，并定下一个deadline，能根据各个任务的完成情况绘制甘特图。系统框架和一些比较棘手的部分，会使任务细分工作很容易滞后，我好不容易布置好任务之后情况却发生了变化，任务有变，或直接cancel掉。

bug记录与跟踪工具

issuetrack工具，这种工具大多数是基于web的，开源的很多，配置也并不困难，使用有一定好处，但也不见得有预想中的作用那么大。bug技术与跟踪的工具很有必要推一推，但要养成这么一个使用习惯，还需要诸多方面的努力。

UI设计工具

photoshop、Visio、word。

问题反馈系统

当研发人员遇到问题的时候，就会统一会开技术交流会、专门的培训或1V1沟通，但是很多研发人员就像一群不长记性的人，过去遇到的问题就仿佛没遇到过一样，凡是问题，也不管三七二十一，就直接找架构师，所以需要这样一套问题反馈系统，让研发人员在遇到问题的时候，到上面去搜索答案，然后再提问，架构师或项目管理员根据具体情况将问题标记为处理中，已处理，或关闭等，这是一个不错的主意，一定程度上帮助了构架师减少对研发人员问题的重复处理，但也远非完美，我发现大多时候研发人员依然会习惯性的张口就问，这样的问题反馈系统最多只能算成功了一半。

文件库

我们在不断的做开发，不断地积累知识与技术，可这些东西时间一长就变得凌乱不堪，没有很好地组织起来的知识是没有价值的，于是我们想到了在云平台建文件库，用它来整理公司的文档，这套使用Web技术的知识库能让我们随时随地查看和编辑公司的技术文档，而且还能看到历史版本，看起来很美……大家还没有习惯用它。文件库包含技术文档，编程规范和一些公司内部的文件。需要经常更新，形成一个连贯的知识库。

代码版本控制工具

代码版本控制工具就是必须的，svn属集中式管理，适合在公司内部用，git则是分布式管理，适合开源项目或移动办公，学习曲线相对稍陡。

撰写说明书

没有说明书的产品就称不上是完整的产品，好的说明书外行人可以看懂。

说明书伴随着软件产品功能变动。

开发文档

重点业务逻辑图，以“实用为主”。

开发文档要明白哪些东西有用，对开发起到指导作用，哪些东西写完之后就过时没人再会去看，还有哪些东西要求投入过大而不太现实，总之要以“实用为主”有所取舍。

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

管理的核心是人

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

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

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

要求一个人去做一点事是多么的困难！想办法如何让同事配合自己的工作，需要大量的人与人之间沟通的技巧，让这个任务被同事认为是他自己喜欢做的任务，而不是强加给他的任务。学会如何与人沟通，才是管理的精髓所在。

对于软件研发这个工作的人员管理。

了解每个人的特点

人跟人之间的差距真是太大了，个性，爱好，能力偏向……都有可能完全不同，有些人喜欢接受一项内容详细明确的工作，有些人着喜欢有更多的个人发挥空间的工作；有些人工作快速粗糙，有些人则慢工出细活；有些人善于交流和表述，有些人则言不达意，常常不知所云……充分了解每个人的情况之后才能做出相应的安排。

不要对每件事都亲力亲为

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

不要让团队做设计

人的思想很难统一。

尽量发挥每一个人的潜力

充分信任和激励每个团队中的成员，让他们觉得是为自己做事，而不只是应付工作。这又是一个很大的话题，如何激励一个人？

别轻易招人

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

宽松化管理

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

不涉及到人的管理最多只能称得上是“文案工作”，不管你研究了多少种工具和方法，能起到的作用恐怕也非常有限。

别做没意义的事情

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

预览时标签不可点收录于话题#个上一篇下一篇