阅读随想（3）：《你的灯亮着吗？——发现问题的真正所在》

第四个问题：这是谁的问题？

当别人能够很好地解决自己的问题的时候，千万不要越俎代庖

如果这是他们的麻烦，就让它成为他们的麻烦

如果某人能够解决这个问题，但是他本人却并不会遇到这一问题时，那么你们首先要做的就是让他也感受到这个问题。

试试换过来指责你自己——即使只有一秒

把问题当作他们的问题——你的灯亮着吗？

如果人们的灯真的亮着，一个小小的提醒可能比你那些复杂的解决方法都更有效

随想：

“不要越俎代庖”，或许是QA应谨循的法则之一，其最高深的功力当是鼓动产品自己解决自己的问题。其中的技巧应当是让产品充分体会到问题的所在，并与产品一起寻找解决方案。单纯依靠流程指责产品这也没做好那也没做好，只会徒惹厌烦，原因很简单，因为体会不到违反流程带来的坏处和后果。好的QA当然要想自己对产品有所益处，亦应该理解流程安排的原因，否则生搬硬套久了，就真的像那无用的监工一样，自己也索然无趣，倒不如写份Checklist扔给产品要求自行检查了事。

也许，无论做什么事，都要让别人觉得自己有用，确实是在为其着想并真心帮助，这“真心”才是背后的关键。只有尊重他人的人才能赢得他人的尊重。昨日，一SE（女孩）打电话给我，急的几乎哭将起来，要我要求我的徒弟事前提供项目的注意事项。连忙安慰了几句，问清楚缘由，原来是徒弟不肯应她的要求提供事先的注意事项而且还颇有伤人的言语，说是这些本来就应该是他们自己做的是他们的水平不够而已。“引导”原就是QA的主要职责之一，何况这个要求并不过份，便叫来徒弟交流了一下，这徒弟其实非常好学，对软工也特别感兴趣，只是似乎有些不太瞧得起开发人员，说话时不太注意容易伤人。其实，SE正是希望把事情做好，所以才会即急且怒，这不正好为QA做好工作提供了大好环境。唉，说来伤感，徒弟这种做法也和目前部门的导向有莫大的关系，准新主管踌躇满志说是要让QA脱离引导只管审计，自己便因和其意见相左，互相大吵了几次，估计是快要在部门里呆不下去，只是因为确实喜欢QA的工作，没有那么斩钉截铁的和老主管明确去向，只是提了要回开发而已。现在部门里，老员工纷纷私下里和老主管提出离开的要求做鸟兽散，新员工也在听了所谓部门专家和准主管的关于QA职业生涯的演说后，陆续开始盘算离开，有一个甚至已经离职，真不知他们在知道新员工离职背后的真正原因会有什么想法。或许我也应该下定决心离开，只是真的喜欢质量工作，舍不得。

“如果人们的灯真的亮着，一个小小的提醒可能比你那些复杂的解决方法都更有效”，如果在每个阶段开始和结束前，QA发给项目组一封短短的提醒邮件，提醒相关的注意事项，自己和别人都轻松，何况有心的话，整理一下每个阶段的提醒邮件，就不用每次都那么麻烦了。说实在的，流程还是非常庞杂的，即使是QA都很难每个细节都记得一清二楚，更何况是忙得不可开交的PL了。一个善意的提醒，付出少，收获大，何乐而不为呢？

想起网上文章最忌讳的转贴却不注明出处的问题，批评抱怨在所难免，不过换个角度看看自己，是否提供了方面他人转贴的手段，比如直接在自己的文章前后帮忙注明作者、来源，转贴者仅仅需要Copy & Paste即可，省去了转贴者自己写明作者、标注来源之苦，划得来。

作者还举了一个例子，很有生活意味和技巧，值得一学：“我的一个朋友，一个丢三落四的一级教授，常常在高级饭店大快朵颐之后，发现自己没带钱。在这种情况下，他只是微笑着看着饭店经理，然后说‘我们有麻烦了’。你能想象如果他说的是‘您有麻烦了’，会有什么后果？或者他说的是‘我有麻烦了’？”

阅读随想（1）：http://blog.csdn.net/KongDong/archive/2006/03/15/624636.aspx

阅读随想（2）：http://blog.csdn.net/KongDong/archive/2006/03/19/628789.aspx

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=655837