一、在群成员名单里咋看不见不良成员标的感叹号了
跟你没有关系,是对方网页写的有兼容上的难题。 你用的是mozilla,而对方的网页有多是针对ie开发的,斟酌的不够全面,有些脚本对象你的阅读器解析不了,致使报错…
二、怎样设计给研发人员的激励方案？
小编认为一个经历过技术人员，技术总监，开发经理等岗位，带过纯技术团队和技术产品美术运营混合团队的人，我想说日常指标型考核真的很受开发人员反感。 要看公司类型，创业初期，稳定提高期，还是巨无霸期。 巨无霸期适合标准传统的hr学说，我在朗讯时候，标准平均生产率是一年3000多行c或者不到万行的脚本，你算算你有那么多人不，每月一周审读文档，一周写文档被审读文档，一周编码，一周支持测试和被审读代码和审读别人代码。 所有指标决定可以量化，由于文档缘故返工率极低，bug一个节点部门超过三个就要被大部门通报，写报告解释缘故。 我那时候不抵触，很简单，人家要的是螺丝钉，你拿着高工资做螺丝钉也无所谓，要的是称职而非出彩。 如果是创业初期，人少，交给领导充分放权自在心证，比你HR去管要好。最好就是部门给激励，激励由领导自在分配。 如果是稳定提高期，要开始建立制度，制度和人治并行，这个时期有两种模式： 一般研发有个说法，12个人，如果超过12个人就要拆分至少小组，这样单位大致比较合适。亚马逊CEO的学说叫两个pizza制度，一个团队大致的上限是2个pizza能喂饱。 2. 个人考核制，由经理进行个人表现评分，由专业人士（比如公司内公认的单领域高手）做职业能力评分，基于这个做整个公司层面的奖励制度。直接按照职级和表现评分，综合出奖励大致。很多千人规模的公司采用这种模式。 3. 两项结合：部门奖励来奖励部门表现（部门内的互相催化反应），公司个人考核按照公司指标完成度，综合两项利润部门向部门奖励略倾斜，成本部门向公司个人考核略倾斜。 小编认为啊，研发人员的组成HR有时候讲按照西游记分为孙悟空、猪八戒、沙和尚、小白龙。巨无霸企业需要的是沙和尚，但也有不少猪八戒。创业部门就不该有猪八戒，需要孙悟空、沙和尚、小白龙，孙悟空一个就不错了，要鼓励小白龙成为孙悟空，人治更重要。 提高期的公司，不可避免有猪八戒，每个部门可能都有孙悟空，因此需要的考核和奖励制度要考虑奖励差距要足够大，让孙悟空拿到超过自己期望的，猪八戒甚至很少一点点。还要考虑让小白龙成为孙悟空。 提高期的公司，过分的丛林法则会让新业务的开展变得困难，市场培育期过于难熬以至于这些部门的孙悟空还不如已经稳定的部门的猪八戒收入高，因此一定要平衡这点。
三、请问怎样评价测试效率
简介：企业管理人员在做绩效考核时，怎样对测试团队中成员的测试职业效率予以界定和考评，是个很值得讨论的难题。由于关系到员工的切身利益，因此要做到公平公正，还需要不断的进行探索。 前言：绩效考核和测试人员测试效率两个具体是否需要进行联系？这个是个可以探讨的难题，从员工角度来说，能力强，测试效率高的人是希望纳入绩效考核来证实自己的，然而普通的测试效率稍显低下的人却又不希望纳入考核体系。而且测试人员职业效率本身不是非常好定义和界限。然而从一个公司长远的提高来说，测试团队的能力是需要不断提升的，只有建立了好的绩效考核标准，才能激励员工向好的路线提高，而不至于造成鱼目混珠的现象。在网络上查询了一些资料，引用的同时，也做了一些优缺点分析。当然，评价测试效率只是作为考评的一部分，然而目的不是为了评价一个人的能力怎样，而是为了在这种评价体系上不断提高测试人员的测试能力。让测试人员具有职责心的去进行产品的测试。 一、评价准则 网络上比较通用的见解主要从bug的数量、有效性出发，衍生出各种基于不同环境、阶段、条件下的评价准则。这里列举如下： 1. 发现缺陷的质量： 测试人员最终是为了发现bug，且需要是有效的bug，然而有效bug的质量根据bug的严重程度也会有不同等级的分类。因此发现组内大部分成员认可高质量的bug可以作为一种评价方式。 缺点：bug的质量的衡量该怎样确定。如果A发现了一个崩溃级别的bug，B发现了一个可用性的bug。然而崩溃级别的bug遇到的概率非常小，而可用性的bug却时时刻刻影响着用户。那么不同的人对这两种bug的重要性和质量的认可程度就不一样。 2. 测试的有效性： 如果由于测试人员疏忽错报了bug、自己负责的模块在同一版本中重复报了bug，那么此类bug就应该算作无效的bug。如果无效bug的比例占总bug数（无效+有效）越大，说明测试人员提交的bug有效性越低。当然这里说的疏忽是说明确的疏忽，如果是由于需求文案本身歧义引起的，我们不应该归责与测试人员，不过测试人员有义务在发现这种难题文案时向策划人员确认或者给相关策划人员报bug。 3. 测试组员交叉测试，发现漏测难题数量： 经常是这样，一个测试人员测试结束，修复了全部的缺陷。这个时候，测试的模块和测试人员交叉一下，再测试，很有可能又发现很多难题。这样我们可以对测试发现难题数量，进行统计。这样做，就迫使测试人员认真执行每一轮测试，每次测试都不敢懈怠。 缺点：这种方式对团队协作是否影响？由于指出他人的难题且会影响他人的利益的时候，大多数人会选择不指出难题，也就是所谓的人情。因此在制定这种评价标准的时候，怎样能让团队成员大胆的进行测试而又不影响团队成员的关系，就是管理层和流程上需要讨论的难题了。 4. 线上bug数： 产品上线后，如果用户发现的且在测试机器上能重现的bug数越多。就说明产品测试的越不充分。因此某个人负责的某个模块天然而然成为评价这个人测试质量的标准。 缺点：如果在项目流程非常规范，产品发布等都是由QA来决定的话，那么最后遗漏到客户缺陷的比例数据会比较精确有效。然而如果项目时刻紧、需求变更频繁、产品重构、变大较大、产品发布不受qa本身控制的话，遗漏到线上的bug天然而然就会增多。那么，在这种情况下，怎样来评价这些缺陷。需要有评价体系。且在分模块时，各个模块之间难免有交叉、交互的经过，那么可能介于中间部分的这些功能几许会有遗漏，即使写用例，也不一定能 100%覆盖到。 5. 单位时刻报的bug数： 如果在1的约束下，测试员能保证bug有效性且报的bug数越多的话，就表示此人在不断用心的发现bug。 缺点：bug数只能单纯的从一方面来评价一个人。然而实际经过中，每个人测试的前提是不同的，测试类型、分派测试模块的复杂度、新增功能和回归测试等区别，这些影响都在一定程度上限制了大众发现bug数的几许。
