因为有年度重点项目,团队缺少测试资源,所以临时招聘了一个外包测试(后文用J代指),让产品经理亮亮来带她。
到今天J差不多入职有1个月时间了,亮亮组了个会,一起评审下J做的测试用例。
J展示了其编写的十几个脑图文档,我提出了我的问题,我们为什么要做这个用例,到底准备怎么使用它?
亮亮说,有两点目的,一是因为项目管理的要求,需要这些文档作为项目的一部分归档;第二点是我们准备依托这个文档做测试。
第一点我没意见,第二点更有实际价值,我们一起讨论了如何使用这个文档。很显然,如果准备作为测试用例,并且在测试执行中使用它,那么脑图形式的文档就很不方便了,而且在Review中发现,J的文档明显头重脚轻了,对于不是很关键的页面元素部分,枚举了很多,但对于业务逻辑部分,本来应该突出列示,结果只是以备注的形式少量列举了。
这个文档不管从格式上、以及内容上,都没有太大的价值,而且J的状态表现得也很明显:
-
不够好奇,一个月时间仍然不理解业务,还没入门
-
目标不清,缺少目标感,明显是别人要求什么就做什么,并不清楚要做成什么样子、有什么用
-
缺少互动,J缺少和亮亮的主动反馈,积极性不足
亮亮也发现了这点,所以重新定位了J的工作内容,局限在J擅长的审批检查工作中,重新整理这个方向的文档并按照文档执行测试工作。
会后,我单独约了亮亮聊了一下这个问题:
-
我理解亮亮这一周也比较忙,所以并没有过多关注J的工作,亮亮也主动表示应该多关注
-
我们一起探讨了有关J对于团队的贡献度,其能力和价值,包括后续的安排,亮亮表示通过后续的工作再考评下J的能力
另外,我还表达了2点成长期待:
-
管理是一个高杠杆活动,这点是很多初级管理者所不理解的。做好管理的规划和执行,需要多思考,但执行可能并不需要花特别多的时间,高频、短暂的监督和指导会对结果产生完全不同的影响;
-
亮亮带人不多,带外包同学就是锻炼的机会,作为团队的明星同学,我也想让亮亮多做一些管理锻炼,提升管理能力,为未来承担更重要工作做好准备。这次好坏不重要,能有所收获更重要。