-
国内项目中可以采用的软件工程手段
2008-04-09 17:55:54
国内项目中可以采用的软件工程手段
CSDN 10jqkA（原作）
关键字 软件工程 CCB 开发
前言
为更好地开发软件，必须在项目组中引入一些软件工程手段和方法。本文试讨论了无论公司情况如何，一个项目经理都应该可以在项目组中实行的一些手段和方法；当然，公司情况良好则有更加可行的、更多的方法可以选择；这里只讨论了最差情况下可以采用的方法。
本文按照最简单的瀑布模式的各个阶段分别列举了一些方法，在其他模式中应该也可以采用。
需求阶段
需求的管理应该是贯穿整个开发过程。在这个阶段，可以采用的方法有：
** CCB(变更控制委员会)
建立CCB（change control board）是需求管理的前提，否则需求管理将成为一句空话。
CCB必须包含客户方的决策人士，项目经理，项目经理的领导，关键设计人员，测试负责人，SQA.等，以5-7人左右为宜。
需求确认，发生变更等活动必须由CCB以会议形式批准。
CCB对整个项目有最高权力（不仅负责需求变更，还负责听取项目经理汇报、关键中间工作产品评审等重要决策）
** 需求评审，纳入基线
原始需求必须形成文档，被CCB评审，然后纳入基线管理，所有变更都需要CCB评审。
该评审一般步骤：
1. 项目经理提出被评审对象，指出受影响、被牵涉对象，评估影响（主要是带来的规模、工作量、成本），提出计划和计划执行人，举出可能风险；
2. CCB来决定是否同意或要求项目经理修改上述项；
3. 之后，项目经理提交执行情况汇报。
4. 最后，CCB指定代表或由SQA进行核实。
如果变更过小，过多，可以进行周汇总评审。
项目计划阶段
项目计划是开发的指导或脚本，事实上，在每一个阶段开始时，都应该重新、小范围修订一下计划。
** 选择合适的软件开发生命周期
关于生命周期的选择上，一直有而且会有很多争议。目前，国内运用最多的是纯瀑布生命周期；本人的看法是：一定有更好的选择，但这是一个最安全、最少在实际中有争议的选择。
选择合适的生命周期的要点是：一定要有选择原因的陈述—本项目的特点，团队特点，开发特点和公司或部门的特点；该问题必须事先在项目组中、CCB内被讨论过并得到一定认可。
** 划分阶段--小里程碑
根据选定的生命周期模型，考虑到可以投入的人员，各个开发阶段就呼之欲出了。每个阶段的结束一定是一个里程碑。如果里程碑超过一个月，那么应该在每经过一个月左右选择合适的点作为小里程碑。
每达到一个里程碑时，项目经理应该提交本阶段工作报告，一般应该包括：
1. 本阶段活动统计和估计的数值和它们差异的原因
2. 工作产品完成情况
3. 需求变更情况统计
4. 问题及其解决情况的统计
5. 总结优点和缺点，指出对下一步工作的影响
CCB听取该报告并评价该阶段工作。
小里程碑可以防止项目失控，使项目经理、项目组和其上的管理层能够正确认识到项目进展情况，并能协助项目开展、出谋划策，项目可视化好；避免项目发生大问题。
** 决定工作产品和含中间工作产品
在最混乱的项目中，工作产品和中间工作产品都没有被明确定义，或者可以朝令夕改，随意添加或去除产品。决定工作产品和中间工作产品，是为了确定各个产品的重要性，计算其上的工作量以合理地投入足够的、合适人员来开发它。
** 项目工作分解
一般是将系统分解成模块甚至更细，要分多细由项目经理或分析员根据实际对项目产品的认识和人力、进度的压力而定；一个忠告：开始做的细、做的认真，以后的工作都会相应容易很多。
一般人只分解产品。实际上，管理工作也应该分解的，而且也比较容易作。
** 估计
估计常常被忽略掉，因为估计的结果往往会严重超出预算，让人大吃一惊。而到了最后，结果又往往接近当初估计的数字。
估计应该每个阶段作为更新计划的一部分进行一次，每个新的估计都会更加准确。
估计应该选取有经验的人士参与，应该选择合适的方法
估计的结果应该用于指导编制下一阶段的计划，即使不被正式接受，项目组也不应该忘记这些数字，时刻作为参照。
** 明确职责—团队建设
根据项目特点和人员特点，应该选择合适的模式来组建团队进行开发，每个人都应该有明确的责任和工作。
最低限度，每个人都应该有明确的责任和工作。
** 约定沟通方式、渠道
建立沟通渠道这一条可以不成文，但要成规矩。沟通渠道应该开放，畅通。为每个人指定汇报的领导、汇报的周期、汇报的方式和越级汇报的领导、条件和方式。
建议在项目中开展项目日志，周报制度，具体的方式方法可以参考PSP,TSP。该制度的要点是：日志首先是对自己负责，不能作为评价员工的依据，它是属于成员“开放的隐私“。如果要求每天填满8小时工作，这样的日志没有任何意义；事实上，在本人的项目组中，根据日志，一般没有人每周投入工作的时间超过35小时，平均只有28小时左右—当然，你依然可以看到他们每天都很忙碌的样子，有时还有加班呢。
周例会制度是本文推荐最有可行性的软件开发管理手段。每周用1-1.5小时左右，每个人简要汇报本周工作和下周计划的工作，工作中的问题和难点，这时，他会得到整个项目组的建议和帮助；项目经理可以印证了解到的项目进展情况；团队气氛由此加强。如果还有很多富余的时间，项目组可以讨论一下开发技术、技巧，进行一些技术交流。
总之，沟通不足是软件开发中很大的问题，而且越是大项目就越严重。
** 约定开发纪律、规范
没有规矩，不成方圆。项目组一定要有一些纪律，不能完全依靠自律。
这方面，有公司文化、氛围积淀为基础是最好，否则就应该制订一些规矩了。
这也是保持团队的重要组成部分。
至于开发规范，根据项目不同而有所不同，要点是：必须有，哪怕不完美！
而且，应该开诚布公，尽早公示。
** 风险估计和预备应对计划
风险估计应该每个阶段都进行一次，一般是根据风险列表，大家一起来估计。
其实也是让大家充分认识到项目的处境和潜在的困难。
这件事，做了总比不做好。
** CCB评审项目计划
项目计划必须得到CCB会议形式的认可，否则一定会有问题！
设计阶段
** 周期性内部评审和走查
在这个阶段，周期性内部评审和走查的目的更多是为了交流，检查模块间是否能够协作、是否有矛盾和遗漏，作为平时非正式沟通的一个强有力的补充，大家取长补短，集思广益，几个人的脑袋总比一个脑袋强；第二个目的是质量控制。第三个目的才是控制进度。
根据上述特点，评审自然应该采用会议方式，也许会有人觉得冗长、拖沓，浪费了一些人不必要的时间；但是该方式的效费比非常好，是值得的；至于组织会议的人，一般是项目经理，应该多动脑子，调动大家的积极性。有人会提出使用checklist的方式，本人的经验是：该方式削弱了沟通量，而且需要良好的制度的支持，否则容易走形式。
** 项目跟踪
项目计划制订后，项目跟踪工作就要开始了。跟踪表应该每周填写，这样项目中的问题会被及时发现；而且最好不要用project跟踪，而是自己制作一张或寻找合适的软件。一般是根据项目计划制订，有下列内容：任务包，计划的规模、工作量、进度，实际的规模、工作量、进度，二者的误差以及原因分析。
任务包完成的百分比应该如何填？本人的标准是：如果只是听成员汇报，没有100%完成的都是0%，是0-100原则；听了成员汇报，自己简单察看过工作产品的，是0-50-100原则；仔细检查过的，可以参照成员的汇报，按0-25-50-75-100原则填写。如果一个5工作日的工作包，上边写着完成43%，那是一点意义也没有的。
项目跟踪的结果用于分析项目进展情况，里程碑报告，务必真实。
** 变更控制
变更控制的具体手段请参照需求阶段的原则。在本阶段，一般只是开发人员发现需求不合理，或相互设计矛盾而要求变更。一些非基线变更的控制不需要那么严格，意思是不需要CCB评审，但项目经理要根据实际情况决定是否召集项目组内相关人员的评审。
同时，应该在这个阶段让大家养成遵守变更规定的习惯。
编码阶段
** 重新进行工作估计，有必要时修订计划
进入到编码阶段，对项目的认识已经非常清晰了。根据设计，甚至可以计算出未来的代码行数。重新进行工作估计，可以更好地分配人员到合适各人技术特点和兴趣的方面，提高项目组的积极性；同时，可以使管理层清晰认识到项目进展的真实情况，做出正确的决定或避免他们做出错误的决定。
** 标准制订和培训
编码的标准在现在已经逐渐趋向统一，但是仍然有必要在项目组中推行或制订编码标准。
统一的编码标准，可以使项目组内可以容易地互相协助、交流，为走查、测试等工作奠定良好的基础。
编码标准制订后，首先要进行项目组内培训。不过与其说是培训，不如说是讨论和统一认识，建立未来强制执行和检查的前提。（不教而诛谓为虐，教而后诛谓为化）
** 周期性走查
根据经验和一些统计数字，走查的效果要优于测试。
走查要以统一的编码标准为基础，反过来，统一的编码标准也是通过走查而在项目组中建立起来的。本人的经验是：开始时，安排每周2次走查，每次1小时，只检查一个人的一个功能，重点是编码标准，其次是BUG；大家可以通过走查学习他人的优良风格，改正自己的不足；两周后整个项目组基本上风格就统一了，这之后就应该把重点放在程序功能上，其次是BUG。
** 周创建或日创建
** 项目跟踪
项目跟踪在本阶段较容易，因为量化的东西比较多，虚的东西比较少。基本方法与上个阶段相同。通过跟踪，已经可以看出那些模块在上个阶段没有设计好。
跟踪要有分析，分析有了结果要有行动。
** 变更控制
在这个阶段，一般是开发人员在实现时发现一些设计错误而要求变更；这时，就要求项目经理严格把关，与设计人员、开发人员一起研究是否真的需要变更，还是实现者没有领会设计者的意图。如果需要变更，则要谨慎地研究影响范围，评估损失。
在这个阶段的中、后期，随着部分产品逐渐成形，客户会提出变更要求；此时要注意原则，同时要搞好关系，当然，首先是原则—CCB同意。
** 版本控制
事实上，版本控制在项目一开始时就应该展开，但未必所有的项目组都能够做到，能做好的就更加寥寥无几了。但在编码阶段，则最好要进行版本控制了，良好的控制机制可以减少很多无用功，甚至避免一些灾难。
良好的版本控制不是来自好的版本控制工具软件，而是版本变更控制的制度以及因此形成的良好习惯。建立一个成文的规定或规范并保证它的实行，才能使版本控制不流于形式。
如果进行了版本控制，则建议推行MISRA Rule 10-- 不得残留被注释掉的废代码。
常用的版本控制工具有VSS,CVS,rational套件中的clearcase也很好，只是会用会配置的人不多；UNIX下开发时，它自带的SCCS也是很好用的。
测试阶段
** 制订返工标准和重申纪律
一个糟糕的程序总是会不断地被要求修改，测试工作大部分是由少数几个程序或个别程序员完成的程序引起的。不断地修改的产品无论改多少次都不会变成好产品。
因此，应该制订程序返工标准，一个可以参照的值是15BUG/1000Line。达到了这个标准，直接删除该程序，要求程序员重写；新程序再次达到这个标准时，就换人。而且，应该严格执行这条规定—前提是：该规定在编码阶段就通知了大家。
** 日创建
测试阶段的日创建简直是被迫进行的，特别是在初期；否则测试简直进行不下去。
但是注意不要丧失原则，为了赶进度破坏了版本控制。
** 变更控制
测试阶段是客户提出变更最多的时候，注意不要丧失原则，要坚持CCB评审。必要的变更是必须进行的，但是要仔细评估其影响。匆匆进行的变更既破坏了规矩，也往往破坏了产品。记住一句名言：如果厨师做菜的时间长了，那是因为他想把菜做的更好。
** 版本控制
如果在这个阶段没有一个良好的版本控制行动的话，测试工作一定会有一种混乱的感觉；而且，这是日创建的前提。
** 项目跟踪
项目跟踪在这个阶段是最困难的。因为事情往往琐碎而且交织在一起。项目经理既当裁判，又作记分员，还要是教练、队长，必要时还要亲自上阵。一个好的产品，在测试阶段一定不会一团糟的。
但是，需要坚持项目跟踪；积累这个阶段的数据，才能真正评价项目、项目组每个成员、项目采用的技术（包括管理技术）优点和缺点，为公司、个人积累起经验。所以，虽然这个时候项目经理很忙、很累、有很多重要的事情要处理，但还是应该坚持项目跟踪。
项目收尾
项目收尾时应该进行项目总结，主要是评价项目产品、采用的技术、管理方法、优势、缺点和项目组每个成员。
通过项目跟踪获得的数据可以作为评价的基础，但是不能做量化的评定（分级或者打分），只能是定性的评价—一个尽量详尽的文字说明。总结的目的是面向未来的新项目，而不是惩戒某些人，定量的评价对于下一个全新的任务基本上没有任何帮助。
如何能够正确地评价和使用人，依然是一个管理学难题。 -
[转贴]绩效管理误区：你知道多少？
2008-04-08 16:36:17
绩效管理误区：你知道多少？
注重关键指标的考核，考核不仅是对指标、结果的考核，更应该对工作过程工作中的表现行为进行考核，绩效考核更多应该是偏向激励，实施以后应该保持薪金的总体水平没有大幅变动，绩效好的员工的薪金一定比以前高才是成功的绩效管理等等，相信读者对作者的观点会有很多的认同。随着人在企业中的地位的不断上升，人力资源管理进一步成为企业管理中的关键。绩效管理作为整个企业激励体制的基础，也当之无愧地成为了人力资源管理的关键。但在这个关键领域，却存在着不少的误区。
误区一：绩效管理的目的是扣减绩效工资
当绩效管理遭遇中国老板时，的确有不少相逢恨晚的场景发生。其中一个版本就是——“啊！我终于遇到你了。我的员工整天说我肆意扣减他们的工资，但有了你，我就能‘科学合理’地扣减他们的工资了。”别以为这只是个笑话。在实际操作中，这样的情况是屡见不鲜——绩效工资的“顶”是触手可及，而“底”则是深不可测。
绩效管理的目的是在持续提升员工能力水平的基础上，使其持续地改进绩效，从而提升企业的绩效。从这个意义上来说，绩效管理更多是偏向于激励性的，它对企业带来的效益，是来源于整体绩效提升而带来的“开源”功能，而并非克扣员工工资而带来的“节流”作用。
诚然，绩效管理不能一味地追求激励，它也要从惩罚中体现一种组织的文化取向。但在奖惩设计时，必须遵循“对等原则”——效绩工资“顶”和“底”的设计必须是对等的，如果下不封底，那必须要做到上不封顶。
另外，在一般情况下，在实施绩效管理的前后，应该努力保持薪金的总体水平没有大幅度的变动，而绩效好的员工的薪金一定要比以前高，这样才能起到激励作用。
误区二：关键绩效指标确立错误
关键绩效指标的确立，是企业绩效管理的第一步。然而很多企业，从第一步开始就迈错了。很多企业的关键绩效指标是凭空想象出来的，好一点的企业则是把著名企业的关键绩效指标体系“克隆”过来。这就为企业绩效管理种下了“苦种”，以后结出来的必然是“苦果”。
关键绩效指标确立要视企业具体情况而定。关键绩效指标中“关键”二字对于不同的企业，必然有不同的定义，即使同一企业，在不同的时期，也会有不同的含义。企业在关键绩效指标的提取工作中必须注意以下两个方面：
首先要保证关键指标与年度规划保持一致。如果一个新产品将在本年度推出，并要达到一定的销售额以实现公司的战略布局，那么销售人员的新产品销售额或新产品销售比重将是一个关键指标，尽管新产品的总体销售额还只占公司销售收入的很小一部分。
第二要保证员工对关键绩效指标的认同。关键绩效指标不是定下来了，压下去，就会达到效果。说到底，指标是一个行为导向的工具。要真正产生行为导向的意义，就必须使员工对指标理解和认同。适当地让员工参与关键绩效指标的制定过程，会增加员工对关键指标体系的认同度。
误区三：过分地追求全面的指标体系
有些企业为了不遗漏工作，把所有的工作尽可能多的指标都罗列出来，并进行考核或评价。但是这么做，往往事与愿违。指标多了，就必然要降低每个指标的权重，对于那些关键绩效指标来说是相当危险的。因为，面对如此之多的指标，员工很可能无法照顾到每一项指标，在各项指标上都取得较好的业绩。在无法全面完成的情况下，员工很可能会舍弃一、二个实现难度比较大的指标，而这些指标就有可能是关键绩效指标。
因此，企业万万不可过分地追求全面，应依据20/80原则，对重要的、并且少量的指标进行考核或评价，实现真正的对关键绩效指标的考核。一般情况下，一个岗位最多不要超过8个指标，每个指标的权重不要小于5%。在大多数企业里，指标不超过5个，每个指标权重不小于10%，可能更具有可操作性。
误区四：量化管理的滥用
很多企业都下了很大力气来量化各岗位的工作，希望制作出量化程度比较高，甚至是全部量化的绩效管理指标体系来。我曾见到过这样的指标——“文件归档率”、“工作流程文件化比率”等等，看起来工作的确是量化了，可是量化了又会怎么样呢？我们花多少人力、时间来取得这些数据呢？当一个人的工作可能需要8个人去考核或评价，那这套考核体系还符合最基本的经济规律吗？
同时需要注意的是，管理下属的绩效，绝对不只是对指标、对结果的考核，还必须对下属在开展工作中的行为表现、工作过程进行评价并反馈。过程的评估会更有效地达到绩效管理的目的，及时发现问题，改进工作流程，帮助员工提升技能，以持续提高绩效。因此，在绩效管理中采用一些非量化的指标，不仅可以提高绩效管理的可操作性，还能通过绩效管理，不断地提升各层级管理者的领导技能。
作者：隋绍民
-
[转贴]怎样对研发人员进行绩效考核？
2008-04-08 16:26:08
[转贴]怎样对研发人员进行绩效考核？
2007-05-30 17:54:34 / 个人分类：绩效考核
怎样对研发人员进行绩效考核？
随着市场竞争的日趋激烈，现代企业对研发活动越来越重视。对研发人员实施科学、合理、公正的考核， 已成为绩效考核工作的一个重点。但是由于研发人员的工作与一般的生产工人、操作人员相比具有复杂性、创造性，因而在考核实施上存在一定的难度，使得对研发人员的绩效评估、考核成为困扰企业人力资源部的一大难题。如何解决这一难题，本文对此进行初步探讨。一、研发人员绩效考核的原则
研发人员是企业技术创新的土体，他们的工作成果直接影响着企业的效益和竞争力。对于研发人员的绩效考核应遵循以—厂原则：
(一)结果考核与行为考核相结合，以结果考核为主
对于研发人员来说，在考核中如果过于强调对行为的考核，会带来一系列的错误导向。因为如果过于强调行为，员工会更关心做事的方式，而不是做事的结果。在现实中，我们经常碰到这样的情况：一个不准时开会、从不加班加点、不注意搞好人际关系的研发人员却能够为企业设计新的工艺，为企业节省巨额资金、取得数项专利、在很有声望的杂志上发表论文、被特邀做学术报告等；另一个研发人员与他相反，行为上循规蹈矩，完全符合考核的要求，但没有什么实际的贡献。假如过于重视行为评价，后者的得分会高于前者，你觉得合理吗?当然，行为指标也是需要考虑的考核指标，但对于研发的整体业绩来说就不那么重要了。
(二)外评与内评相结合，以外评为主
内部评价，包括进度、预算等评估是必要的，但过分强调内部评价是很危险的，因为内评很可能不太关心研发对企业的实际价值。内部评价作为企业内部的质量控制工具是很重要的。但是，评价的目的应该强调外评。外评非常重要，作用比较大，比如说用新工艺设计带来的收益来衡量研发的效果。
(三)价值评估与产出评估相结合，以价值评估为主
只对研发产出进行评估是不够的，必须对研发为企业带来的价值进行评估，即研发效果的评价。赢利性是企业的本质特征，企业不会容许研发经理只用如下指标进行考核：拟订了多少研究方案、发表了多少论文、做了多少设计、设计出了多少产品、做了多少次展示、获得了多少专利、完成了多少项目……研发的效果更重要地体现在新产品的开发、成本降低、销售量上升、产品改进、市场占有率等方面。
(四)评价系统要尽量客观
在评价研发业绩时，数量是非常客观的指标，但是，质量和成本数据往往是十分主观的。尽管不可能用十分客观的方式测评质量，但在设计评价过程时可以尽量减少主观性。一个比较简单的方法是尽可能用外在的数据来评价研发业绩的质量。比如说，如果你想估计产品改进的价值，你可以请工程和制造人员来估计，而不是让研发部门经理来估计他们成绩的价值。
二、研发人员绩效考核的流程
考核的流程通常包括绩效目标设定、绩效评价、绩效反馈与沟通、绩效改进等环节，循环进行。
(一)设定绩效目标
1．目标设定原则
设立绩效目标着重贯彻三个原则。
其一，导向原则。
依据企业总体目标和部门目标，层层分解，设立个人目标。其二，SMART原则。即目标要具体(Specific)、可衡量(Measurable)、可达到(Attainable)、相关的(Relevant)、有时间限定(Time-based)。
其三，目标数量适中原则。目标不要太多，最多6—8个。
2．目标的设定
对研发人员来说，一般要设定业绩目标和能力发展目标，业绩目标由项目团队目标分解到个人，能力发展目标则要研发人员根据高绩效研发人员的能力要求，结合个人兴趣来制订个人的能力发展目标，在掌握的技术、完成工作效率、解决客户问题能力等方面制定相应目标，并制定达到该目标应采取的行动计划。然后由上级根据企业目标进行认可。
（二)绩效考核指标体系的设计
1．设计的原则
考核研发人员的首要原则是考核指标必须紧密结合企业战略，
如果企业的竞争策略是先于竞争对手推出新产品，
就可以把上市时间(time to market)或产品开发周期作为首要的考核指标：
如果企业的竞争策略在于低成本，则把产品成本作为首要要素。第二个原则是研发部门、研发小组和研发个人的考核指标必须息息相关，是由上而下的指标分解过程而形成的体系。
第三是根据研发策略，平衡好长期性与短期性指标、绩效指标与行为指标之间的关系。2．指标体系
(1)业绩指标
企业的研发人员主要分为项目经理、开发人员、测试人员等，对不同的研发人员，业绩考核的指标有所区别。
项目经理的业绩指标主要有：新产品开发周期、技术评审合格率、项目计划完成率、项目费用控制、客户满意度、团队士气指数等；
开发人员的业绩指标主要有：项目计划完成率、项目流程、规范符合度、设计的可生产性、设计成本降低率等；
测试人员的业绩指标主要有：测试问题解决率、运行质量、计划完成率、开发过程规范符合度等。(2)行为指标
对于研发人员工作行为的评估，可以从主动性、服从性、责任心、协作精神、工作合理性、纪律性等方面进行考评。
(3)能力指标
可细分为
业务知识、业务技能、计划能力、判断能力、解决问题能力、应变能力、人际技能、理解能力、学习能力、创新能力和领导控制能力
(这项能力及以下能力适用于部门经理上的管理人员)、决策能力、指导帮助下属能力、组织能力、员工管理能力等。考核的目的不同，考核所采用的指标体系也有所区别。
如果要考评研发人员过去特定—段时间的工作表现，
且考核结果将用于加薪、发放奖金、红利等奖励，考评指标体系主要为业绩指标和行为指标；
如果考核目的为员工前程发展，且考核结果将用于教育培训、能力开发、升迁、调动等人力资源规划与配置，
考核指标体系应包括业绩指标、能力指标和行为指标。各指标之间的权重也因考评重点不同而相应变化。(三)绩效评估
1．考核方式和方法
对研发人员的考核一般可由人力资源部来组织，由自评和上级评相结合。
自评：就年初和年中设定的各项能力目标进行白评，由员工对过去一定时间内能力实现的程度进行评估。
他评：由该员工的部门经理对员工的工作进行评估，主要对该研发人员在过去一定时期内所从事的一定任务，按照绩效标准对绩效考核的各项指标进行考评。
综合评分：根据以上研发人员自评和部门主管评定的两项得分进行加权，最终得出该研发人员绩效评分，这可以较为客观地反映该员工本年度内的绩效。
对于考核方法，大多数企业在实践中都是将几种评价方法综合使用，如目标管理法和行为锚定法等。
2．考核周期
产品的研究开发过程是一项历时漫长的工作，因而对研发人员的考核周期相对来说比较长，
可根据项目周期来定，但最长不超过—年。(四)持续沟通与绩效反馈
研发人员可以说是企业的核心员工，
对企业的生存与发展具有极其重要的作用。
经常与研发人员进行沟通，了解他们的心理动态十分必要。
如一家软件企业的研发副总去检查项目工作时，看了一名测试工程师的报告后，严肃地批评：“你的测试报告不及格。
”两个月后该测试工程师离职了。
后来该工程师给企业写了一封信，吐露了他离职的原因一仅是研发副总的一句批评。
研发副总颇为后悔地说： “我对他的批评只是道出了实情，但如果事后我对他的进步予以表扬、鼓励，事情完全会是另外的样子。”
可见，绩效的沟通、辅导及反馈十分重要。沟通贯穿整个绩效考核的全过程，而不只是在某个时点、某个环节—卜交换信息，首先，在绩效目标的设定过程中，研发部门主管要与研发人员进行沟通，让员工明确部门目标，帮助他们根据部门目标确立自身目标。其次，对研发人员的考核指标和标准的确定，应该和研发部门的主管以及研发人员进行共同讨论，获取考评人与被考评人的认同。然后，在绩效评估结束后，上级要把考核结果及时反馈给下级，并与下级进行沟通，以避免黑箱操作，同时有利于下级改进工作。
(五)绩效改进指导
绩效评价结果反馈给员工后，如果不进行绩效改进和提高的指导，这种反馈就失去了意义。
绩效改进指导主要帮助员工分析绩效不足的原因或改进提高的机会，帮助员工寻求解决的办法，
并制定绩效改进的目标、个人发展目标和相应的行动计划，纳入下一阶段的绩效目标中，从而进入下一轮的绩效考核循环。
-
项目进度计划延期的分析【转】
2008-01-24 18:01:32
项目进度计划延期的分析【转】
项目进度计划延期的分析
以下仅为一家之言，言辞、分析不周之处，敬请原谅！！
在我个人看来，在众多公司的项目中，项目的进度估计虽然具有一定的依据，也参照了一定的依据，包括经验，也遵循了一定的流程，但是还是存在许多不足之处。
除了用户方的原因（在此不做讨论），在我看来主要问题出于以下几点：
1 软件开发计划制定中的几个问题
1.1 详细设计不彻底
详细设计的不彻底，导致开发计划制定后执行的空洞，从而无法真正实现计划的实现和监控，大多的情况是在不断的弥补，或者进度的追赶，从导致代码的质量无法保证，甚至亦无法保证功能的实现。
1.1.1 详细的设计的不足
很多开发人员在接到开发任务后，担心不能及时完成任务，在匆忙做完了概要设计（其实此时的概要设计可能根本不能满足需要），以没有时间为借口，直接进入到编码阶段，没有对软件系统进行更为详细的设计，从而导致了对开发中出现的问题没有做出相应的应对措施。而且在出现问题后，对问题认识的不足（包括担心问题的出现会使自己的技能被别人否定等），和解决方法的缺乏，从而导致了问题的堆积和时间的流失，到最后使得项目的进度不得不发生了延迟。
众多公司的项目和产品中普遍存在这个问题。
1.1.2 详细设计应该达到的地步
详细设计应该能够达到一个这样的地步，比如，在一个模块所需要实现的功能基础上，对此模块再次进行的详细设计，以至不可再分，甚至可以细化到可以实现的某一个具体的函数、类、属性等之上。而且不遗漏细节！
比如页面设计
可以以页面为单位进行详细设计，从而细化到每个页面大概需要实现的基本要素，包括多少个按钮、列表框、输入框等，以及每个页面中的功能点，包括需要连接的数据库等。这样每个页面的具体时间就能准确的确定，并被执行。且需要做出一个网页的设计图样，共项目评审使用。
比如图形制作
可以以每幅图为单位进行详细设计，从而可以细化到每个可能需要实现的基本要素，包括道路等各项图形要素，以及功能点等。这样每副图形制作的具体时间就能准确的确定，并被执行。
亦可以做评审使用。
1.1.3 重物的称量
试想，我们需要称量一个重物，如果没有磅秤，只有弹簧称，那么我们只能将此重物进行分割，方能知道此重物的重量，而且需要保证在分割的过程中没有损耗。否则就需要进行一个定量的、适度的估算，比如百分比等，以弥补分割过程的损耗。
在这个比喻中，我们把重物看成是个项目，分割重物的人是项目经理或系统分析人员，称量的人则是实施开发的人员，分割过程则是项目开发过程。
如果在分割重物的人，没有具备分割的能力，重物的重量将会远远偏离其实际目标。
如果称量重物的人，没有具备称量的能力，重物的重量也会偏离其实际目标，只不过相对于分割重物的人的不称职，离目标可能会近些。
1.1.4 西瓜籽的计算
有时候我们开发项目的过程也想一个计算西瓜籽的过程。
看下面的过程，根据西瓜向阳一面多籽的特性，确立西瓜的中心线，然后将西瓜籽分解成阳面、阴面的两部分，再根据中心线与阳面、阴面的距离，将西瓜进行多次分块，直到我们能够较容易得数出西瓜中的西瓜籽。这样我们可以对所有的西瓜块进行分类，这样就能够很快的得出西瓜籽的数量。如果我们对西瓜的结构很是了解，那么即使有些误差，但也会相差无几。
在这里，西瓜是我们需要建立的系统，西瓜籽是我们所需要实现的功能，西瓜籽的数目则是我们的时间，对西瓜的分块和分类则是我们的进度安排。
而我们只有采用科学的方法，才能快捷的获得一个较为准确的项目进度计划。
另外，还有一个含义，就是如果想要知道西瓜籽的数量，我们必须切开西瓜，才能知道。
而且分得越细越准确。
具体所需要分的块数也取决于西瓜的大小和切西瓜的人的经验。
1.2 开发技能的估计不足
开发技能的不足也经常阻止了计划的顺利执行。
1.2.1 非项目小组成员
在很多项目进行开发之前，项目组成员采纳项目评审小组意见的时候，非项目小组成员并非真正、彻底的了解该项目的实际内容，或者了解不彻底，因此他们的经验和意见使得项目组在决定项目将要使用到的开发工具和技术的时候容易估计不足，也可能导致项目的进度延期。
1.2.2 掌握的新技术和技能
在项目中，项目组成员如果不能满足对工具的熟练程度，那么项目的开发计划是需要及时跟进的。如果进度不能如期进行，或者开发人员在额定的时间内，掌握的新技术和技能不能满足要求，需要重新且及时的进行分析。
1.2.3 开发人员技能汇报
如果不及时跟进开发人员技能的掌握程度，而且直接开发人员也不及时进行汇报，将会导致项目进度延期的无法抗拒。
不仅仅技能不满足要求时沟通不够，也有其他方面的沟通不足，也会导致项目的进度也可能受到影响。
1.3 关键技术分析不透彻
在一个项目中，如果对关键技术分析不够透彻，用一种模糊的观点，抱着试试看的心态，也可能导致项目计划执行难度较大。
这个与“详细设计不彻底”有些相通之处，但不完全相同。
比如，yyyyy项目，它就存在一个对关键技术分析不透彻的问题，也存在“详细设计不彻底”的问题。因此，拟定的计划是模糊的，不可执行的。
开发人员凭着自己的经验和智慧，解决开发当中遇到的问题。
1.4 开发经验总结不足
对于同样的一个项目，同样的一个功能，在进行多次的复用后，其技术应该已经较为成熟，其功能的实现也应该较为容易，出错率也应该较低，我们进度应该比较有把握，但事实情况并非如此！
那我想，也许是我们对开发的经验总结不够！
我们是否可以做一个这样的统计：
在一个我们现有的项目开发过程中，我们进行了多长时间的编码工作，其中没有任何修改操作的时间为多长，因为用户需求的更改而导致的代码修改时间为多长，因为设计的修改而导致的代码修改时间为多长，因为功能实现的错误而进行的代码修改时间为多长。
如下表，进行一些数据的统计。
所有时间的综合 在没有进行修改的情况下项目所花费的时间 引起代码修改的原因 用户需求更改的情况下项目所花费的时间 设计发生修改的情况下项目所花费的时间 功能实现的错误的情况下项目所花费的时间 测试发现
错误的情况下项目所花费的时间
花费的时间
也可以做出图表。
从这样一些统计和总结中，也许我们可以看出，我们进度的延期最主要的因素是什么；除了客户因素之外，我们还可以做那些努力；我们不可忽略的因素是什么。
2 软件过程调整
根据以上的分析，我们可以对软件过程进行适当调整，尤其是针对开发中采用C/A/S结构的系统，从而来改变我们增强需求获取的目的性，而且需求获取也会变得较为明显和容易。
对公司已经经历过的软件过程进行分析从而决定在下一个项目中将要采用的软件过程。例如，对采用B/A/S结构的系统可以采用直接从界面和数据进行概要设计的方式，并以此来计算页面设计时间和数据库设计时间。而对于
其中所需要实现的其他的功能，则在每个界面当中进行详细设计，此时对每一个功能实现所需要的时间进行估算，这样就能够计算出整个项目的一个较为可靠的时间，根据用户的需要和需求功能实现的关联就能对项目进度有一个适度的安排。
这样在概要设计中，主要对界面和数据库设计进行评估；而在详细设计中对功能的设计和实现进行评估。
3 市场人员交流的技巧
我并不知道市场人员在交流的时候使用了什么样的技巧，但是市场人员的营销技巧和交流技巧确实对我们在争取项目的主动权上有着至关重要的作用。
如果能够充分掌握开发人员的相关因素和公司现状，那么在前期获得客户沟通、需求获取、和项目的时间把握等上，后期的产品交付、验收等问题上，都可以获得一定的余地！
在这儿要需要说明！
不管你是公司的技术人员，还是市场人员，与用户交流的时候，你就是一个与用户在进行交流的市场人员，同理，不管是懂技术的客户，还是不懂技术的客户，他都是提供用户需求的客户！
市场人员交流是需要一定的技巧的，而掌握这些技巧就需要市场人员掌握相关技能。
对于技能和技巧的掌握，没有人天生就会，只有不停的进行锻炼，并经过相关的培训和实践。
思考以下几个问题：
为什么用户需求总是在发生变化？是我们不理解用户的需求吗？还是我们低估了用户？还是我们分析不到位？
如果用户的需求超出了我们的期望值，我们处理好了吗？我们是在敷衍，还是继续努力，让用户理解我们？
我们获得的与开发人员所需要的需求差别在哪里？我们了解我们的开发人员及其所拥有的技能？
不尽之处，多多！ 请您点拨—— -
（转）关于过程及过程改进的经典比喻三则
2008-01-24 17:44:45
关于过程及过程改进的经典比喻三则
过程改进的目标是寻求制度和灵活的恰当平衡，其中制度乃是灵活之本。 以下三则比喻可以给我们很好的启示：-
比喻一：树木 一棵树在1米高的地方分叉叫灌木，在十米高的地方分叉，才可以成长为乔木。 比喻一告诉我们，灵活性是基于一定的规则之上的，过分强调灵活性，企业就只能在低水平上重复（灌木）。在一定规则之上应用灵活性，企业才可以成长壮大（乔木）。
-
比喻二：火炉 冬天，没有火炉会冷，有了火炉，我们常常感觉不到它的存在，它只是在默默地发着热。但是千万别触摸它，否则会挨烫。此外，火炉对人是公平的。 比喻二告诉我们，规则（火炉）是不可缺少的，它给我们带来利益（温暖），一旦适应了以后，我们甚至感觉不到它的存在，但是我们不能触犯它，否则会被惩罚。
-
比喻三：交通 如果没有交通规则，道路一定会拥堵一团，对谁都没好处；有了交通规则，大家“有时”感到不方便，但最终人人都可以到达其目的地。比喻三告诉我们，制度有时候会牺牲局部和短期利益，但是对整体和长期发展是有利的。 旧的文化是否兼容新体系？旧的价值观是否支持新体系？旧的典型是否代表新体系？多数情况下，答案恐怕是值得质疑的
-
-
（转）用TestDirector的测试管理的流程
2008-01-17 10:08:35
用TestDirector的测试管理的流程 作者：快速测试 TestDirector的测试管理包括如下四个阶段： 需求定义（Specify Requirements）：分析应用程序并确定测试需求。 测试计划（Plan Tests）：基于测试需求，建立测试计划。 测试执行（Execute Tests）：创建测试集（Test Set）并执行测试。 缺陷跟踪（Track Defects）：报告程序中产生的缺陷并跟踪缺陷修复的全过程。 贯穿测试的每一个阶段，你能够通过产生详细的报告和图标对数据进行分析。 1.2需求定义（Specify Requirements）
分析应用程序并确定测试需求。 定义测试范围（Define Testing Scope）：检查应用程序文档，并确定测试范围——测试目的、目标和策略。 创建需求（Create Requirements）：创建需求树（Requirements Tree），并确定它涵盖所有的测试需求。 描述需求（Detail Requirements）：为“需求树”中的每一个需求主题建立了一个详细的目录，并描述每一个需求，给它分配一个优先级，如有必要的话还可以加上附件。 分析需求（Analyze Requirements）：产生报告和图表来帮助你分析测试需求，并检查需求以确保它们在你的测试范围内。 1.3测试计划（Planning Tests）
基于已定义的测试需求，创建相应的测试计划。 定义测试策略（Define Testing Strategy）：检查应用程序、系统环境和测试资源，并确认测试目标。 定义测试主题（Define Test Subject）：将应用程序基于模块和功能进行划分，并对应到各个测试单元或主题，构建测试计划树（Test Plan Tree）。 定义测试（Define Tests）：定义每个模块的测试类型，并为每一个测试添加基本的说明。 创建需求覆盖（Create Requirements Coverage）：将每一个测试与测试需求进行连接。 设计测试步骤（Design Test Steps）：对于每一个测试，先决定其要进行的测试类型（手动测试和自动测试），若准备进行手动测试，需要为其在测试计划树上添加相应的测试步骤（Test Steps）。测试步骤描述测试的详细操作、检查点和每个测试的预期结果。 自动测试（Automate Tests）：对于要进行自动测试的部分，应该利用MI、自己或第三方的测试工具来创建测试脚本。 分析测试计划（Analyze Test Plan）：产生报告和图表来帮助你分析测试计划数据，并检查所有测试以确保它们满足你的测试目标。 1.4测试执行（Running Tests）
创建测试集（Test Set）并执行测试。 创建测试集（Create Test Sets）：在你的工程中定义不同的测试组来达到各种不同的测试目标，他们可能包括，举个例子，在一个应用程序中测试一个新的应用版本或是一个特殊的功能。并确定每个测试集都包括了哪些测试。 确定进度表（Schedule Runs）：为测试执行制定时间表，并为测试员分配任务。 运行测试（Run Tests）：自动或手动执行每一个测试集。 分析测试结果（Analyze Test Results）：查看测试结果并确保应用程序缺陷已经被发现。生成的报告和图表可以帮助你分析这些结果。 1.5缺陷跟踪（Tracking Defects）
报告程序中产生的缺陷并跟踪缺陷修复的全过程。 添加缺陷（Add Defects）：报告程序测试中发现的新的缺陷。在测试过程中的任何阶段，质量保证人员、开发者、项目经理和最终用户都能添加缺陷。 检查新缺陷（Review New Defects）：检查新的缺陷，并确定哪些缺陷应该被修复。 修复打开的缺陷（Repair Open Defects）：修复那些你决定要修复的缺陷。 测试新构建（Test New Build）：测试应用程序的新构建，重复上面的过程，直到缺陷被修复。分析缺陷数据（Analyze Defect Data）：产生报告和图表来帮助你分析缺陷修复过程，并帮助你决定什么时候发布该产品。
-
做QA后的一些感想
2007-12-24 17:40:30
已经做QA一个多月，这段时间也看了好多与QA相关的一些知识及帖子。知道要想做好QA，必须掌握很多的知识，刚做这一行，真的是不知所措，好怕做的不好，不知该如何开展QA的工作。
以前只知道CMMI是软件能力成熟度集成模型，对于其它的就不知道了。通过这段时间的学习，知道了CMMI主要是为了软件更加的成熟，使项目能按计划实施，提高产品质量、加快进度、降低成本，为企业带来更多的收益。
