【为基层减负，目标导向，创造更多价值】主题的云平台中心匿名问卷调查

测试人员管理比较混乱，

1、每个需求都要求多少时间内完成，开发提测后测试人员不受开发部门管理，很多依赖特性无法安排导致其他需求又被延期

2、测试部门安排任务不和对应开发部门进行沟通，直接把人安排走导致测试进度落后，需求无法按期完成

3、排工和周报问题，理想是开发经理、测试经理分开管理但现实一直都是开发经理包揽了全部，建议测试排工和周报全部分开，开发只关注开发进度，测试关注测试进度，对测试开发部门并没有权力管理，无法有效提升测试进度

4、建议测试人员按部门独立化，形成测试池有测试经理承接任务进行分配并汇报测试进度，且需求完成时间拆分开发完成时间和测试完成时间

5、测试不接收也需要算积压时间，很多开发需要在一个解决方案处理发布都是有依赖的

guest_jXsbOOo3Oy 09-27 09:16

感谢反馈，建议喊上测试经理、刘琴，一起沟通一下，解决问题。 周国庆

提交 取消

任丽霞 作者 09-04 15:48

感谢反馈意见，已经安排了开发和测试协作的专题讨论计划；

提交 取消

非常感谢各位匿名或实名反馈的战友宝贵的意见反馈，意见和建议都收到了，我们会梳理并逐个整理出解决方案并逐步落地；

大家如果还有意见或建议，可以邮件反馈或直接反馈到部长或分管副总或直达魏总，这样反馈会收到的比较及时，该文章下也可以继续反馈，只是可能我们收到的不太及时。

效能平台打开各个页面都很慢，非常浪费时间。

建议表单只加载关键信息，其他信息在打开后静默加载，或者在需要的时候再加载

关于开发排工问题，之前的设计方向是任务驱动行动，现在看看咱们还是这种形式，已经演变成了钉钉淹没行动、相互催促行动

拿最简单的特性排工来说，特性中有个任务叫设计，不知道领导们将此怎么定义，一个特性若是需要设计说明它就是不好干的，要不逻辑复杂要不技术待验证，排工之初就要估算所有工时这现实吗

效能平台开发的功能太随意，

1、一种恨不得一个页面放下所有功能，一种就是需要来回点击好几处才能完成功能

2、再就是设计问题，往往就按最低要求开发上线了，全是文本输入，咱们是科技公司内部使用系统就这真的是太low

需求响应阶段就需要预估开发和测试工时吗，不是应该先响应再需求分析、概要设计，才能预估工时吗

希望搜集日常工作中发现的平台上使用不便的功能，统一提需求优化，避免大家在日常工作中由于功能不便导致的沟通成本和运维工作，使研发人员能够专注研发

再补充一些：

1、还有部分单据流转依赖定时任务，有时候调整了不生效，状态没法流转，紧急问题处理的时候会比较麻烦

2、新老界面调整后很多功能入口不知道在哪里或丢失，比如特性的挂起后重新打开，老界面通过按钮点击，新界面改为了审批流程

3、现在很多限制规则太隐形化不知道如何操作，莫名其妙的卡点后需要仔细取找到底哪里有问题，定位贼麻烦

1、流程上

1.1 今年增加项目管理，旨在做好成本管控，成本是任何商业机构最关注得指标之一，没什么问题，但是涉及到团队排工的诸多方面都很麻烦，在紧急需求多的情况下，往往都是开发先行，状态流转在后，很难做排工与计划，偶尔也会有开发完了状态没流转完，没办法提测的情况，实际的研发数据与收集到的数据也不准，实际运转流程与工具流程不太契合。

建议：项目管理与研发管控分离，弱相关，研发开启入口归为2个，状态正常流转完，或者添加开启研发按钮，开启研发后对后续开发流程不再有影响

1.2 开发与测试排工，目前团队排工基本上都是针对特性或需求的整体目标进行设置多数由开发经理进行排工，现在开发测试分离会导致目标不一致，很多时候预期要交付的最后会因为测试计划调整不得不延期或修改进度，开发经理相对被动，同时还会有一个问题，就是开发带来的代码管控成本较高，因为现在测试资源紧张，不得不放缓开发进度，很多时候同一个项目开发了好几个特性，不得不拉好几个开发分支，还要合并，再来紧急需求又要查看合并代码非常繁琐容易出错，而且还会因为测试考核测试周期，不得不开发完了代码放着不能签入提测，开发管理成本提高

建议：开发目标与测试目标彻底分离，开发人员按特性及开发顺序提测，测试按资源池排工，按顺序测试，紧急单子单独沟通提高优先级，降低管理成本

2、工具上

2.1、菜单内容浓缩删减，目前新版菜单内容太多太杂，且有滚动条（无滚动条常用我可以靠肌肉记忆大体知道常用位置，有滚动条导致无固定位置，每次都要查看寻找），用户友好度不高，例如：bug工作项和项目库bug为啥要两个菜单，为什么排工不能按bug排工还要单独设置工作项，而且还得手工创建关闭，再例如各个看板能否合并，再比如项目管理和项目变更，我的理解变更不就是管理的内容之一吗。

2.2、系统需求、产品特性等信息太多太杂，信息密度太高，通常流转状态时需要跳着设置，而且内部有规则，哪里不对了后边不让填，我还得细看哪里不对再调回去看看哪个有问题在调整（通常在时间设置上），但是大部分信息我都不太关系且没用，比如特性的基础信息项和详细信息项有啥区别，我感觉没啥区别，只是内容不同而已，再或者备注、详情、工作量详情等大部分不需要填的信息占的板块最大，非常显眼，实际有用的属性需要在各个排版里仔细寻找，还有测试计划里，真的要展示功能测试、性能测试、安全测试、破坏性测试及其每个项目下的设计人、执行人、时间啥的吗，占用大量篇幅，我感觉这块内容完全可以被具体排工代替，排工部分已经在团队排工中设置了是否就可以不要了，自定义信息更是没用过，看着定位跟团队排工差不多

建议：做减法，拆分视角，不同视角关注什么信息、操作的连贯性，取最小集合信息展示

2.3 文件列表维护，这块一直都是开发最容易犯错的地方，多一个文件少一个文件的，很容易忘，而且长时间不改之后再去维护都忘了挂在哪个服务下面了

建议：CI编译后，理论上不同解决方案下的排除基础组件的dll都是服务文件，能否自动化处理，不要再手工维护，成本高代价大

2.4 元数据管理，元数据可以被复制和克隆，正常开发人员没有权限需要架构师操作，这本身没什么问题，但是架构师操作完之后最后修改人是架构师，别人编辑不了。。这。。

2.5 一键提测发布流程中的补丁文件管理，调整顺序或删除都是单项选择，标准产品子系统包一次生成几十个补丁文件，需要操作删除的时候，需要选择一个删除一个，不让多选

效能平台频繁更新，但是每次都比之前操作更复杂，更难用，更拉长排工投入的时间

效能平台性能太差，一个页面卡两秒我就想放弃使用

关于该问卷调查，大家可以匿名以评论形式反馈，我们会把大家评论反馈内容收集整理，也可以邮件形式反馈，这种形式反馈的，也只有邮件接收人会知道邮件发送人是谁，但也仅用于意见收集和整理，不会对第三人提供反馈人信息，这个请大家放心，就像安全问题反馈一样，都是仅限于唯一的对接人知道反馈人是谁，没有对外或第三人公布过反馈人信息。