时光荏苒,白驹过隙;转眼之间,来到亚信(电信)PSO团队已经一年有余,期间感慨良多,有痛苦也有欢乐;无论如何,在短暂的调整之后,都要整装待发担负更重的责任和迎接新的挑战;在此总结下自己这一年来的感触(更多的疑问)
1:PSO团队的核心价值是什么?
从来到亚信那天至今,一直都在做计费2.8项目的测试工作,工作之中有的只是不断的测试,我反问自己:“在即将成为亚信一员的时候,你对PSO这个职位了解多少?”
我自己的答案很简单:“知之甚少,不求甚解”
PSO是干嘛的?
负责测试工作吗?(那有专门的QA团队的); 运营维护吗?(貌似鸿程的团队更像运维); 挖掘客户需求拓展亚信业务吗?(这点没看到很多,可能是自己来团队的时间短)。
不清楚自己的职位定位是什么,不清楚自己能给团队带来什么,所以下面的恶性循环发生了:定位不清à迷茫à推卸责任(扯皮推诿)à责任心下降à态度转变。
态度决定一切!
一直以来,自己都把这句箴言奉为圭皋,态度影响了责任心,影响了动力,更是影响到自身的发展。
以什么样的心态和姿态去迎接新的责任和挑战,在团队和自身的发展道路上走的更远更好很值得思考,也请两位老大给些指点…
2:关于工作流程
明确需求à概要设计à详细设计à编码发布à测试回归à修复优化à回归验证à正式上线。
这是一条在很多团队主流的工作流线,每一个阶段都有不同的角色做主角。
亚信的PSO团队中,我们流程是有了,可问题是:在每一个阶段,我们团队中需要参与的角色参与到其中了吗?
我的理解是:
需求是有专门的需求人员跟客户去沟通确认的,需求人员的产出是明确的客户需求。
概要/详细设计是架构师,开发和DBA一起完成的,这个阶段的产出是概要/详细设计文档。
QA/PSO最迟要在详细设计阶段加入进来的(当然,对业务很熟悉的测试人员可以充当需求人员的角色);QA在测试阶段的产出是测试报告和质量报告。
工作中,现场PSO的工作处在QA的测试完成之后,这里我的问题是:PSO在哪个阶段开始参与到项目中?
需求?概要/详细设计?都不是! 这样问题就产生了:PSO通过什么来熟悉需求的?
作为一名现场PSO,实际的工作中我觉得自己熟悉需求的途径很多时候只是QA简单的测试报告;这样很可能造成问题的遗留:开发需求理解不清->QA测不出问题->PSO接手测试(出现两种情况:1同样测不出问题2测出一大堆问题,版本返工)
3:关于知识库
随着团队的发展,我们的业务知识肯定会有很多的积累,我们通过什么方式来管理我们的业务积累呢?专人专模块负责or团队共享?
我的建议是建立我们的知识库,这里分为两大类:业务知识和经典bug&故障。
业务知识库的好处:
1>团队成长,不管是个人的自身成长还是团队的成长,我都觉得知识(业务&技术)的积累很重要;把业务知识团队内分享可以很好的解决工作交接和转换的问题,技术知识的分享很好的提高团队成员的工作效率。
2>新人培养,技术和业务知识库在解决新人培养成本问题上很有利,团队来的新成员,他可以通过技术和业务知识库很快地掌握职位所需要的技能。
经典bug&故障库:
经常看到运行的同学来找PSO说XX出现了故障被扣了故障分,然后就立即着手去排查解决故障。
只是:我们有没有记录故障发生的场景以及解决方案呢?
为什么经过QA和PSO两重测试的程序在生产环境会有问题?
我们完全可以把经典bug和故障积累起来,在PSO的测试工作中若涉及到相关模块就可以着重去模拟那个模块中出现过的bug和故障。
另外:出现故障时,我们PSO可以参考故障库的场景和解决方案很好的去定位故障的原因并且快速地给出解决故障的建议或方案。
4:关于版本控制
昨天聊到这个话题,确实版本混乱的问题在短期内没有很好的解决方案。
我只是觉得:对于任何一个需求我们都可以追本溯源。
一个需求的附加信息很重要:谁提的需求?开发是谁?QA/PSO是谁?程序做了哪些变动?逻辑变成了什么?最后修改时间是什么时候?
当我们把这些附加或备注信息统一起来,这样也许对需求的管理有一定帮助。
昨日酒醉,心血来潮;小弟乱侃,敬请见谅。