随着越来越多的前端被提上日程，用户对产品体验的要求也越来越高。产品除了具备实用功能外，还必须满足便捷性、美观性、交互性、人性化等一系列要求。运营，谁的产品能先做到这一点，就能赢得用户的青睐。所以这样一来，给前端增加了很多工作量，所以前后端分离是一个趋势，不可能要求后台花很多精力帮我们处理数据，前端的静态效果，以及相关资源的整合。让每个人都做自己擅长的事情。那么问题就暴露了。当前后端能力要求和测试要求不同、不同时，前端会在团队中处于短板，这在中小型公司中非常普遍。因为优质的前端是稀缺资源。突出问题1 前端能力不足问题列表某些特性和难点需求无法在代码中模块化，可维护性不强，修改bug能力和效率受限优化、需求、缺陷、开发不明确不同级别的bug过于粗略，无法综合考虑各种数据情况。操作的容错性不好。其他功能好像都没有问题。解决方案需要前端部门审核。在基础开发中普及模块化开发的基本方法，加强写笔记和团队合作的训练，学会正确给自己分类，把需求和缺陷分类清楚，参考前端整体分类的基础训练和案例分享，并且不要在产品中做相关处理，希望前端应该有基本的处理。想问问其他功能是否做好了自己的事情，是否足够专业。现在只是因为前端的问题暴露了。我们的背景、设计、产品、测试都是无可挑剔的吗？如果是这样，何不淘汰前者，或者去更好的公司寻求更好的待遇和发展空间。突出问题2 要求不明确。首先，不可否认测试可以提供一些优化或者特殊要求，但是如果这个比例远远超过了bug本身的比例，那么这部分就不合理了。应从以下几个角度来避免。产品原型最大程度的明确了产品的细节，包括各种数据、可能的数据情况、意外情况、用户交互、交互效果、数据验证、插件等等。例如：产品不能说这个地方需要轮播图，而应该说这个页面哪里有几个不同规格的轮播图，最大数量，最小数量，播放效果如何，有没有默认图片，跳转链接是什么，图片来源是什么，什么格式等等。测试应该有自己的基本测试标准。不要每次都在没有指导方针的情况下测试所有的需求。尽量避免个性化测试，尽量统一规则，参照原型和需求进行相关测试，默认是如果在产品设计上满足了90%以上的要求，那么这轮测试是符合产品和开发预期的，而不是在测试中直接问70%以上产品没提过的问题或说要做。.项目经理控制整个测试联调过程，确保基本缺陷得到解决，并力争在开发周期内完成具体功能模块的完整上线。下个版本的迭代，不是所有的bug修复。在测试和联调修改的过程中没有周期性的版本概念，一直断断续续的提问，但是所有的问题都没有规律性，相当于过筛子。期望在整体完成功能后，将对模块进行仔细测试。保证模块可用，而不是每个模块都测点，最后每个都有问题不能用。突出问题3 网络版BUG很多，发现了要及时修复严重吗？问题3：我们提到的bug有没有规律性，是无意中发现的还是不可避免的，我们是否经常进行大规模的产品优化，并将其带入开发状态，而不是盲目地不断改变问题4：问题当天会修复，能不能修复，谁来记录改的bug，属于哪个产品版本突出问题四 前端暴露了很多分支，提交了问题1主要责任在在前端2前端做的不好，为什么不让有能力的人去做，或者交给他去做。3、是不是因为很多源码不是前端写的，也让前端背锅？4、项目结构不明显，增加了前端开发和修改的难度。突出问题五 团队协作团队协作需要具备基本的协作常识，互相帮助，如何让彼此更方便高效的协作，建立基本规则，如果不能保证各种个性化的需要，那就很有必要了为其他职能提供最基本的原则性支持。从人员的角度来说，互帮互助，责任要追究，但团队需要互相体谅，分担压力，分担责任。遇到问题要和他沟通，帮助他解决问题。只有最高层的人才是老板，他只关心任务和结果。每个团队的具体成员关心的是如何实现，有什么困难，如果做不到，谁能帮帮我；如果做得好，如何？与他人分享；如果你有能力和经验为别人做点什么。每个职能部门对专业能力的认识不足，导致后续问题很多。因此，职能主管或职能培训是必须的。
