一、日常问题
1）补充产品文档
刚开始，大家都没怎么在意这个需求，但是在执行时才发现有许多细节没有考虑到。
这次遇到的问题，产品也不知道，前端写代码时，一点点给产品传递信息。
于是，我就找到产品，希望她们能帮忙补充下两张举报页面的产品文档。
在我看来，这些都可以商榷，只要业务方认可，那么就可以作为一次优化需求。
即使挂在她们名下，不能推进的话，也只是个装饰品，所以也我就没提，让她们自己安排，我这只是个建议。
2）项目推进
也就是说获利方仅仅是我们组，对其他组可能是增加工作量。
例如将还使用 jQuery 的项目更新成基于 Vue 或 React 的项目。
此时就需要测试组出人来做验收，项目太老可能都没产品文档，测试用例更是没有，一切从零开始。
这类技术迁移的优先级在公司看来，是并不高的，所以经常没有测试资源支持。
前者的话，其实挺难的，他们肯定经常有事的，这个时候，就得我来主动推。
这样的话，大家互帮互助，他们才会愿意协助你，所以，日常时间还是得打点好关系。
后者契机的话，最简单的就是将其和自己的核心指标挂钩。
例如这次有个页面出现大量的慢响应，这个页面最近正好在做技术栈升级，但是提测后，拖了 4 个月没人测试。
也就是说，接口慢响应的监控转移到他们组，那就需要两端的协作。
这种项目推进还是很讲究方式方法的，没那么容易都按自己的节奏来。
3）需求文档的优化
但我发现，这个需求评审的效果并不难达到预期，甚至可以说很多人在开会之前，都还没读过需求。
产品文档写的其实很详细，包括需求背景、需求目标和需求内容。
但是我发现，因为写的很细，所以在首次阅读时，吸收率并不高，一看到大段文字，就有点劝退。
可能是种种原因，久而久之，就造成在需求评审前只会听需求，而不是读需求。
快速阅读需求文档，并能对需求有个大概的了解，有了一遍了解后，再去阅读相关细节。
我就把这个意见给了产品经理，并且和她们说，可以先让我们组做试验，如果效果好，再推广出去。
另一个向产品提的优化建议是应急备案。
所以页面异常就持续了 1 个多小时，好在此功能用的人并不多，并且也没有造成经济损失。
像我们 Web 组，之前长期在做对内以及活动，所以基本上就不会考虑什么应急备案。
当然，在我们团队内部，也会注意应急备案的问题，提早给自己想后路，免得到时候因为某个问题造成了巨大的损失。
二、工作优化
1）测试用例
而是搜集一套比较通用的网页测试用例，对网页进行一次比较系统性的自测。
不会出现什么网页打不开，或者某处报错，导致测试无法推进下去，严重影响整个流程。
整体
- 页面在不同分辨率或不同浏览器中是否正确显示
- 页面特殊效果（如自定义字体、动画）是否正确显示
- 页面元素（如文字、图形等）是否正确显示
- 页面元素（如表单控件、超连接等）的外形、位置是否正确
- 页面元素基本功能（如点击、跳转等）是否实现
功能
- 数据初始化是否正确
- 数据处理是否正确
- 数据存储是否正确
- 是否对其他功能有影响
- 如果影响其他功能，系统能否作出正确的响应
2）协作优化
然后这是一张网页，唤起是在网页中，支付功能由客户端完成，订单接口由服务端完成。
然后两端就僵持住了，直到第二天，事情推到了我这里才知道有这么回事儿。我在思考这件事时，发现了两个问题。
其实很多时候都需要组员的反馈，例如前几天，一个组员向我抱怨说服务端给我们的接口格式经常不一样。
了解下来，大部分情况下，其实都可以统一。其实，每周我们都有例会，经常会在会议上讨论碰到的问题。
第二个问题是关于技术评审，技术评审的初衷是希望在开发之前，将技术问题都抛出来，但是目前有些组的成员并不上心。
但其实并不是这样，的确，他们不需要改代码，但是服务端做了大量的代码修改，并且涉及到支付，更是应该将各种细节都关注到。
费了些口舌后，才愿意配合，前提是让测试先支付，遇到问题再叫他们。
事后，特地找了服务端的组长讨论此问题，听下来就是此人做事一向不太认真，在不影响进度的前提下，他也无可奈何。
3）历史活动
我们团队会定期将历史页面存档，其实就是在构建时忽略存档的活动目录，为了加快构建速度。
现在想想，可以做点优化，计划在测试环境放开页面，因为他们只是想看下页面的呈现，至于其中的数据，并不关心。
思来想去，决定在当前短链管理中，增加个上传截图的功能。
第二个好处是，改造成本非常低，半个小时就修改好，马上投入使用。