2006年08月_思考管理

12月 11月 10月 09月 08月

原创 CMM公共特性总结对照表

这是两年前对CMM各个公共特性的归类总结，现在刚好做CMMI，发现自己的归类与CMMI的共性实践有类似之处。供大家参考。公共特性 Commitment Ability Mersurment Verification

2006-08-30 17:10:00 1482

转载三词经－与大家共勉

有三种东西必须要控制：情绪、语言和行为有三种做法必须要避免：懒惰、野蛮和嘲讽有三种品质必须要尊敬：坚毅、自尊和仁慈有三种习惯必须要培养：理性、谦恭和好学

2006-08-30 16:16:00 1084

原创软件经理日常工作检查表

作为项目的软件经理，除了可能会承担一部分开发任务外，还需要对软件开发人员的工作的跟踪和检查。本文将软件经理的工作分为每天必须做的、每周必须做的、里程碑要做的和事件驱动的事情，文中列出的也并非是工作的全集，仅是比较重要的工作，供大家参考。1. 每天必须做的工作² 阅读各个小组的工作检查日报，回复和解决日报中的问题；² 跟踪小组的

2006-08-30 16:14:00 3333 1

原创代码自测检查单模板

对代码的质量控制一直是保证最后产品质量见效最快、也是非常关键的环节，我在去年的一个大型项目中，对于代码的控制是基本做到了每日检查，即开发人员在每天完成代码的编写和调试后提交到配置库中的时候要先进行自测检查，自测完成后由组长对代码进行走查。通过后的代码才可以提交BUILD。下面就给出我们的检查单，方便开发人员个人和组长对代码的检查用。

2006-08-30 15:25:00 2962 2

很多项目经理总是要求过程制订的要细化，要把项目管理所有的事情都写出来。而有些做过程的人也是想尽可能把项目的事情都涵盖，其实在过程制订和实际项目管理之间的边界本身就是模糊的，而这块灰色地带就需要项目经理来操控。有人说过程制订好了，项目经理就是想流水线一样照本宣科，一步一步就可以，这是比较理想化的。过程自动化在软件行业还有很长的路要走的，尤其是现在很多管理不成熟的企业，过渡依赖过程是不现实的，当然过渡

2006-08-29 12:57:00 5927 1

原创组织管理体系推广经验之九－从建立规范化的文化开始

规范化的文化说到底是建立一种共识，有了这种共识，规范化的制度、流程才得以顺利执行，缺少这种共识，在我们推行一个体系和制度时就会困难重重，阻力和压力会导致冲突和失败。文化相对于制度，正如道德相对于法律，对于执行来说可以大大降低成本。因此从一开始就以建立共同的共识、最终建立一个规范化的文化为目标，会使得我们的推广行动事半而功倍。想一想，当规范和制度成为一种习惯的时候，我们的“推”行的工作还需要“

2006-08-27 09:37:00 1407

原创组织管理体系推广经验之八－关于量化管理

度量的目的主要是实现精细化的管理、有效地对项目进行控制，对度量数据的分析用于辅助决策、经验积累、有效评估等。但是度量本身就是双刃剑，一方面度量对于精细化管理是必要的前提，另一方面度量体系、度量的执行需要花费大量的人力成本，而且如果没有明确的目标和有效的方法来分析和利用这些数据，度量就又陷于无谓的劳民伤财，成为组织过程的累赘。很多企业的度量陷于盲目，导致了很多负面的影响，进而影响整个组织对

2006-08-27 09:35:00 1336

原创有必要读的三本经书

《道德经》：明白中国人的宇宙观和自然观，与自然打交道的方法《易经》：了解中国人的哲学以及与人打交道的方法《黄帝内经》：了解自己身体的结构，学习养生即与自己打交道的方式。

2006-08-24 11:04:00 1316

原创组织管理体系推广经验之七－解决文档问题

项目组人员抱怨文档太多是一个普遍的现象，甚至有些人把进度的延误归结为写了太多的文档。抱怨文档太多的原因有以下几个：1. 确实是比较多：除了技术方面必须的文档之外，用于管理的、控制的、跟踪记录的、作为报告的、度量分析等文档，文档的工作量增加了管理的成本，同时也增加了项目组的负担；2. 重复劳动比较多：为了针对不同的读者（上级领导、客户等）对同样的内容要按照不同的模板

2006-08-24 08:40:00 1194

原创组织管理体系推广经验之六－工具的推广和体系的培训

这往往会成为项目组乐于接受并主动欢迎的唯一的形式。因为大部分企业把培训作为一种福利或激励手段。而工具的推广一方面使得项目经理和技术人员学习到最新的工具和方法，另一方面也可以提高项目组的成员的工作效率，为他们的日常工作提供方便，减轻日常的繁杂的工作，比如：工作量的填报、收集、问题单的填报、跟踪、各种报告等重复性劳动等。因此在推广组织级的项目管理体系的时候考虑相关的工具的推广是一个很

2006-08-24 08:37:00 1069

原创组织管理体系推广经验之五－如果人没要改变，那么一切都不会改变

实践证明，在企业实施和推广一个组织级的项目管理体系的阻力来自公司内部、公司外部。（公司外部的因素涉及到整个行业的发展、市场因素和客户因素，在此不做描述，本文重点对企业内部的因素做分析。）因为体系的实施，需要的是组织内部的人员的工作方式和管理的改变，这种改变影响最大的就是技术和管理人员。有人说：如果人没要改变，那么一切都不会改变。因此要想获得组织级体系的实施的成功，改变体系的主体人是最直接、最

2006-08-24 08:35:00 1151

转载可怜的微软与项目管理经典图解

可怜的微软与项目管理经典图解Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1105836

2006-08-24 08:24:00 906

原创员工离职的原因

在《周一清晨的领导课》中有一节是讨论员工离职从根本上说是领导的责任。我非常认同这点。今天翻看微软一个绩效管理的培训的PPT，其中一句是说人为什么会离开？答案是：“人们离开的一个重要原因是无效的管理”。感觉有道理！

2006-08-23 18:19:00 1221

原创测试用例容易遗漏的内容

大家在编写测试用例的时候往往把输入数据、操作步骤、输出、结果、以及一些过程信息等都包含很全，但是往往忽略掉对执行该测试的检查点，这些检查点往往是测试用例设计和编写的人的经验或对被测对象的深入的理解基础上，很多检查内容参加我写的测试检查点的文章。因此我建议在描述操作步骤的时候还要把检查点列上去，如下：VP即时Verifacation Point: VP1（重点检查点）：每个列表列出的

2006-08-19 09:48:00 1639

原创组织管理体系推广经验之四－适用性带来的阻力

一个新的方法和模型，总是会有人提出负面的问题，就如NAH症结（Not Applicable Here），对于一个新的方法体系，大家都觉得有道理，但是具体到一个组织、一个项目实施过程中，总是能找出消极的理由来说明这个方法在这儿是不合适的、是不适用的。大家坚信这个方法或理论对于其他的组织和单位是适用的，但是到了自己头上，往往想到的是它有哪些缺陷和不适用，对它们的优点视而不见，总是用过于批判的眼

2006-08-18 10:26:00 1183

原创组织管理体系推广经验之三－项目管理体系的投资与回报分析

建立和实施项目管理体系，对企业带来哪些利益？这也是个典型的问题，任何企业的经营管理层都会对自己企业的投入能得到什么回报最为关心。因为对于企业来说，赚取最大利润是最重要的。如果企业的管理者反对或者不愿意进行某件事情，那么他就会问做这件事情会给企业带来什么经济上的效益。如果作为PMO的成员，当在遇到这样的问题时，必须小心回答，因为这将成为你工作上很大的阻力和压力。关于组织级项目管理会给企

2006-08-18 10:24:00 2496

原创组织管理体系推广经验之二－软件项目为什么有了PM和PMO还需要SQA？

这个问题似乎很多人都对此有疑问，既然项目经理是项目的直接责任人，他负责整个项目的TQC。那么为什么还需要专职的SQA来保证项目的质量呢？回答这个问题，先让我们看一下东西方的制度和文化的不同。西方的文化强调分权、量化，这与西方的制度也有很大的关系。在他们的管理哲学中强调，不是不相信当事人，而是必须是制度来保证独立的第三方来对工作进行检查，验证。不论CMM还是ISO9001，都是我们引进的西方的

2006-08-18 10:22:00 1906

原创组织管理体系推广经验之一－为什么需要PMO？

PMO（Project Management Office）一般称为项目管理办公室、项目管理中心或者项目管理部。PMO是提高组织管理成熟度的核心部门，它根据业界最佳实践和公认的项目管理知识体系，并结合企业自身的业务和行业特点，结合企业的商业目标，负责为本组织量身定制项目管理流程、培养项目管理人力资源、建立项目管理信息系统、对具体项目提供管理指导、帮助组织开展多项目管理等，以此确保项目成功率的

2006-08-18 10:19:00 2738

原创组织管理体系推广经验之零－前言

1 前言目前国内IT公司的企业管理越来越以项目为核心，而且项目不仅仅是单一的软件项目或者系统集成项目，往往各种类型的项目并存，或者同一个客户、同一个合同要分解为若干个不同类型的项目来执行和实施，甚至要根据客户的要求来组织和管理这些项目。这样就产生了一个问题，就是如何在组织层次管理这些不同类型、不同规模、不同领域的项目，因此在组织层次建立一个组织级项目管理体系来适应这

2006-08-18 10:14:00 1381

原创代替测试用例的检查表－但不要作为偷懒的借口

2004年底在大连出差的时候，帮一个项目做测试，顺便写下这个检查表，这个检查表对测试的初学者积累经验比较有用，实际对于有经验的测试人员尤其对于测试业务管理信息系统，基本上大量的测试不需要再编写测试用例，当然对业务流程、复杂逻辑还是要设计详细的测试用例的。如果你测试的系统是有大量人机交互的业务管理信息系统，而且你又比较懒惰，那就可以使用这个检查表检查了。因此我总结了这类系统中常用的测试的检

2006-08-18 09:40:00 1978