在我看来管理就是怎么样让人尽其才、物尽其用，用最少的资源完成一件事。

软件测试中的物主要就是需求文档、测试用例、测试脚本、Bug报告，为了管理这些物，产生了需求管理、用例管理、配置管理、缺陷管理以及配套的工具，这些工具以后会慢慢融合。

其实，物的管理主要决还是解CRUD（增删改查），放的时候知道往哪放，找的时候知道去哪里找，修改和删除的时候要有记录可追踪可恢复。这些物没感情没思想不需要理解，只要根据人的需要合理安置。

人就不一样了，经常让你觉得无所适从无处安放，怎样在把人当成物一样管理和发挥人的主观能动性之间找到契合点难之又难。做得好的闷着头发大财，做得不好的看着各种方法论这样那样的争论眼冒金星。

到底该如何管好人，或者说如何改进流程呢？我想从建立组织内部的知识库做起是比较好的选择。

建立知识库的主要目的是加强老成员的交流与合作，促使组织的经验与知识显式化，帮助新成员尽快融入团队，尽早上手工作。这些目的本身就与流程改进的目的接近，建立知识库的过程某种程度上就是流程改进的过程，而且又有物作为行为的导向，SCM这么普及大概也是因为CMM2中最容易形成物的原因吧。所以，行之有效的知识库的建立是过程成熟的重要标志。

 

那么如何建立测试知识库呢？每周一问里面讨论过这个http://bbs.51testing.com/thread-120097-1-2.html

我来个总结一下就是：BBS+Blog+Wiki+FileServer

我觉得BBS就是开会，虽然有的单位开会太多太假不好，可是老不开会一潭死水也不好，把会开得有理有趣最好，当然最重要的是有效果。看看BBS在中国的流行程度就知道这种形式蛮适合中国人的。适当管理和引导的内部论坛，肯定能为组织的知识库建设打下良好基础。

Blog就是大会总结，一般开完会都会让大家写个总结啥的，把分散的东西经过自己的加工处理形成自己的，把论坛帖子直接发到Blog当然也行，最好是自己的回复都可以，现在的论坛和Blog的结合还是不太紧密。

Wiki就是总结汇总，经过大家讨论达成共识的总结写入Wiki，作为组织知识库的主要表现形式。不过组织内的Wiki我想可能会是业务知识为主，测试技术方面的还是像51这样的公共论坛来建立比较好，嗯，去建议版提个建议去。

FileServer主要用来存放标准、规范、模板、软件等组织的文档和工具。

当然不一定要采用这些手段，随着技术的发展，以后也可能会产生更好的软件来帮助我们建立知识库，不过促进成员交流与进步，改进组织流程的基本目标是不会变的。

 

觉得我们公司的过程有点乱，管理不太到位，所以这几天看了一些质量管理和过程改进的帖子与文章，说一点自己的理解。
质量管理是为了对外提高产品质量而对内采取的一系列措施和要求，以及随之产生的方法论和辅助工具在管理活动中的指导和应用。
在软件企业中，影响质量最重要的三个因素是人、技术、过程，人与技术紧密相连又难以控制管理，所以最初避重就轻选择了过程改进来提高软件质量。
经过几十年的研究和实践，过程改进取得了很多有效的成果，比如需求管理、配置管理、缺陷管理这些都是过程中的一部分，这些部分各方比较容易达成共识，而且在一系列过程中适于独立并安排专人管理，因此逐渐规范化，为他们服务的工具也逐步完善。在过程改进是提高软件质量主要途径的指导思想下，各个企业不断梳理改进自己的过程，使企业的生产率和产品质量都有了比较大的提高。
但随着过程改进的深入，开发人员被要求做越来越多额外的工作，在他们看来这些工作不仅无助于提高产品质量而且降低了工作效率，CMM等过程改进思想显得老旧沉重成了矛头所向，更能被开发人员接受的敏捷思想呼之即出。我想敏捷只是一个代号，发出了开发人员渴望人性化管理的心声，这就要求管理者更多的考虑管理中人与技术的因素，多思考怎么留住人，而不能过分注重人员会不断流动假设下的过程改进，也就是以人为本。
就我自身的感受来说，我觉得一个过程混乱的组织谈不上什么以人为本，首先要做的应该是理清思路，让自己的过程流利起来。