如果说有什么亮点的话，那就是数据验证的方式，通过数据结果来对能力条目进行筛选，有的能明确区分出绩优和绩平，但是有的却出现了倒挂现象。
那就是在让业务部门研讨的时候，采用的是在线形式，首先我还从来没做过焦点，再有就是在线的方式也从来没有做过的，所以不算是真正的焦点，充其量也就是一个研讨的组织过程，或者是我来主持的研讨，比如会让他们讨论现在从数据结果中与本序列的岗位职责相对应的能力要求是什么。第一次管理序列的时候还是让客户那边的人主持的，后面几场我感觉能控场了，我的主持作用才发挥出来。
所以，我觉得越是总结越是觉得其实全都是做的不到位的地方，这不是拿出来专门让人挑毛病的吗。
关于数据验证的方式，第一次是有必要的，对于但是第一次的结果也是让人很难接受，尤其是研发人员再创新的维度上竟然倒挂，这一点让客户也很意外，为什么我们这边的研发竟然不需要创新，其实说起来，他们这边的创新也是在一定的框架内做的改进，不算是完全的创新，如果问到他们领导，什么是绩优人员的评价标准，很多人都是听话出活，尤其是能耐得住寂寞，如果真的是那些很有想法的人，不一定能留得住很久。所以也反映了他们自己在绩效评价方面需要改进的地方，尤其是明确一下什么是真正的绩效优秀。
从项目总结来看，再做类似的项目需要注意的问题是：
1.对于使用自评方式来评价能力的测评工具千万不要轻易使用数据验证的方法，如果用的话也不要用两次，不然真的是烦死人了。
2.在项目验证中需要提前做好对客户的教育，首先是样本选择要严把关，不能因为人员不足或者样本不足造成数据偏差，也显得自己不专业
3.这是针对一个岗位序列的模型构建，与岗位的不同在于，关键挑战是范围比较广德，因为同一个序列的岗位含有不同的类型，比如研发岗位有的还需要很强的沟通协调能力，有的技术序列并不是，还需要坐冷板凳，甚至还要对于薪酬不要那么关注，这从能力来说可能就不太好对应了。
4.为了减少未来使用过程中的难度，需要引导客户在确立序列的模型时，需要根据使用场景来确定到底是几个能力模型还是可以统一为一套，所以在讨论的时候会有意引导客户在这方面的统一。
网友评论