大家回去后在推广的过程中碰到的最大问题是什么？
我现在还在给开发部的员工做简单培训呢，就已经碰到很多问题了。幸亏我还是有一定准备的。现在已经把底层的开发人员说服通了，阻力反而是来自开发部的领导层。大家说说各自的感受，如何？ 开发部的领导为什么反对？能说说吗？ 当然是担心他们的活太多了罗。因为光一个需求规格说明书就会要他们老命。 对开发人员的要求，可以根据公司的具体情况作裁减，关键要找到平衡点，这是很重要的。 嘿嘿嘿，
我们公司开发人员倒是挺积极的。因为资料不全、信息混乱是我们开发部的老大难问题，所以，我一说可以通过文件评审来整理资料、共享信息时他们都挺支持的。
我们公司高层也很支持的，因为前面邀请他们来听了第一节课（关于软件开发测试流程的课），而且已经公开要求大家好好学习和应用了
倒是开发部领导层，很是说风凉话的。这个倒没什么很大关系，因为公司高层会去做他们工作的。
我是觉得会出现这样的局面，比较有意思。同时也觉得奇怪，为什么我能说动开发人员和公司高层，反而是我的直接上司，我却不能有效的影响他们的观念？ 从每个角色的利益作分析。开发部领导更多地考虑产品的进度和如何把项目完成，不关心产品的过程，而注重产品的结果。
开发人员希望文档规范，这样自己也可以得到规范的训练，对以后的个人发展很有好处。
测试人员希望文档规范，这样测试工作可以更有效、更顺利地开展。
产品的质量改进过程，关键要得到最高领导层的认可，并且大力推广，否则，很难推行的。
个人观点，欢迎讨论。 一般来说，确实如此！我觉得我之所以会遇到这么一种情况，主要还是与人的自私心理有关。
如果说开发部领导还没有意识到这么做有利于提高开发进度及质量，这是不可能的。
因为今天上午我与软件部主管闲聊到需求规格说明书的事情时，他一开始还是牢骚满腹的样子，等到我暗示他可以把部分工作以包干的方式分派给手下人去做时，他很快就改变态度，下午我就发现他在派活了…… 我估计用不了多久，其他开发部领导就会受他影响的。
虽然注重产品的结果，但更关心的是自己不能干太多的活。----这就是我得出的结论。哈！ 知道我最近在忙什么吗？我在忙着写需求规格书，我培训回来的直接效应是我开始写需求规格书了，因为开发部的人太忙了，我写完需求规格书之后，要写测试计划和测试方案.测试用例..... 悲哀呀，不过也是一种锻炼。^_^ 从开发转来测试，锻炼出来之后不知道会不会再转回去做开发^_^ 做什么不要紧，重要的是把事情做好，自己有提高。 TO snake:怎么你来写需求规格书啦？
我回来后第一件事就是教我们小组的人如何做需求评审，然后，要求她们采用评审的方法来检查所有进入测试组的文档，然后把评审记录发给所有的领导... ...一下子就把测试开始前，就有需求不清楚这个严重问题暴露在领导面前了。我再重点强调了这个问题对测试工作的影响程度，不由领导们不重视。
在领导们讨论如何解决这个大问题时，我才提出建议，说我们测试小组的人员愿意协助相关人员来补充文档。
我是觉得，写需求规格书的事情由测试人员来做是做不好的，非得督促开发人员来做不可。
个人意见，仅供参考。大家认为如何？ 至于开发人员为何会这么忙，有可能也是因为需求不清楚才导致设计变更太多呢。
反正，我在我们公司看到是这样的。开发人员往往要改来改去的，一个领导一种说法，具体编程的人员不得不反复修改。 有的时候（当客户也是第一次做这样的业务，他们也并不理解业务流程的时候）需求甚至是在开发的过程中逐步的明确和完善的，在这过程中我们要不断的引导客户让他们觉得：噢...我们要做的系统原来是这样的。
呵呵，这就是我接触过的唯一一个项目，可能是个别情况^__^||| 还好，公司目前上下统一思想在规范，各种文档也在陆续整理。
没有需求文档是很麻烦的一件事情，因为测试过程中可能发现软件设计结构上的BUG、逻辑BUG、还有很多很难重现的BUG，当你把这些BUG提交上去以后，很难得到有效解决，因为缺少一个标准，开发人员可以说就是这样的，而实际上怎样才是正确的大家都不知道。（自主产品）
页:
[1]
