一、日常问题

1）需求的讨价还价

　　做最大的努力，维护自己团队成员的开发利益。

　　产品和运营会根据他们的业务来提出需求，从他们的角度来说，这些需求无可厚非。

　　不过，他们提出的需求，在实现时有些改动会比较复杂。那么就需要与他们协商。

　　协商的目的不是砍需求，而是用一种更合适的方式实现，既能满足他们的需求，也能最小化的变动代码。

　　一般会先了解下需求的背景，他们为什么要这个需求。例如有个标签需求，产品想将标签的状态和另一个审核系统的状态有所关联，那么她希望将标签在审核中的每一步都能提醒到标签列表中。为此还画了张状态流转的表格。

　　我们在分析后发现，其实状态可以精简到3种，至于其他审核相关的状态，若业务有需要，可以从历史审核中去查找。并且运营其实也不需要了解审核的细节，只需要一个结果就可以了。

　　这个需求和更改后，改造成本就比较低了。大家都得到了满意的结果。

　　上述是与业务之间的讨价还价，经常性的，在与技术部的其他组协作时，也会涉及需求实现的讨价还价。核心就是明晰职责边界，减少开发成本。

　　例如有个专题页的评论功能，产品希望能和审核系统打通，还有评论的功能可以和客户端中的评论功能一致。

　　如果自己实现一套评论功能，那着实要有很大的开发量，关键是否能做到复用。既然现在有一套评论，那直接沿用，成本是最低的。所以就需要让服务端介入，提供评论的接口，我们来做专题页与现有评论的关联。

　　未来，与评论相关的活动页或专题页都能对接这套系统，这样对于我们组来说，实现成本也是最低的。

　　有时候在QA验收时，他们也会提出一些需求意见，这些意见会让用户体验更好。我们在收到这些意见后，需要自己做权衡。

　　首先要去核对需求文档，看看是否有这一条。这步很关键，因为漏了需求，那就明显是我们的问题了。如果没有，那可以作为一种依据。

　　然后就是出于性能和可维护性的考虑了，如果改动比较简单，那顺手做下，皆大欢喜。

　　反之，若改动巨大，那就要和产品明确潜在的风险，以免酿成线上事故。

2）各类兜底

　　人员离职和成员休假，都是团队内会正常发生的事情。

　　人不在，公司业务还是照常在运营的，所以或多或少还是有需求要处理的。

　　对于那些不紧急的需求，可以等到招到合适的人或休假回来再处理。

　　对于那些比较紧急的需求，就要着手安排解决，但是小团队的人员比较少，每个人手上都会有固定的业务在处理，可能就无法腾开手处理太多别人的需求。

　　那就需要由我来处理了，将这些需求兜底。

　　其实在日常，各类突发事件、比较难缠的遗留问题、团队协作制订方案等等，总之那些比较难搞的人和事，都得需要我去临时兜底处理。

　　所以我的时间比较碎，无法去处理比较大的紧急需求。

二、工作优化

1）想的多点

　　公司APP的版本做了一次比较大的升级，我们这边后台有个配套的功能，也要跟着升级。

　　而这次升级，会比较考验电脑的性能，所以在正式放开之前，让公司内的相关人员都动手操作了一下，看看结果。

　　虽然想到了全职员工的电脑，但是忘记了兼职人员的电脑。于是，在放开前的两天，急急忙忙的适配优化兼职人员的电脑。

　　之所以自己没有想到，是有几个原因的。

• 第一，是自己并没有完全参与这次升级，只是旁听，具体的执行由团队的另一名成员完成。
• 第二，不曾觉得我们这边有什么会影响发版的点，所以也就没有特别重视。
• 第三，过于依赖测试团队，以为只要他们能把关好页面质量，就没有其他问题了。
• 第四，团队成员经验尚浅，有些事情我还得帮衬一下，而这次放的太开，自己偷懒了。

　　所以的话，技术部重要的事情，只要与我们相关，我都得心里有数，必要的时候，需要深入参与，避免再次有遗漏。

2）QA资源不够

　　现在公司的 QA 主要在处理 APP 版本和重要活动，对于其他不紧急的需求经常没有人测试。

　　这些不紧急的需求就包括我们组自己推进的基建工作，技术栈升级，用户体验优化的功能。

　　一般用户体验优化的改动都比较小，也不会影响营收，那么就会先让业务方在预发环境验收，没问题的话，就直接上线了。

　　但其实有时候还是会有问题的，例如之前让运维给静态页面配CDN，但是他配的参数有问题，自己也只是粗略测试，上线后影响好多页面无法访问，妥妥的事故。

　　大部分的基建工作（例如前端监控、BFF、低代码等）都会创建新页面，并且也不影响业务，所以经常都是直接上线的。

　　不过问题也是有的，例如前端监控的参数采集一开始没走异步队列，就直接把服务器给搞垮了，又妥妥的一次事故。

　　不过好在，这些事故都不会影响线上业务，若会影响线上业务，例如充值，那就要好好斟酌了。

　　技术栈升级就比较谨慎了，因为网页中的体验要保持一致，若有问题，那么就会有投诉。

　　但也不能等 QA 释放资源，所以我们会先和业务方拉个群，将升级后的页面先交由他们来验收，验收周期可以长点，多多发现问题。

　　再给到 QA 的时候，他们的问题也能少点，测试也能顺利点。

3）2022 年终述职

　　今年的年终奖计算公司又玩出了新花样，在 360 评测的基础上，又加了个述职环节。

　　让各个组汇报下今年的成果，包括年度工作回顾、年度工作成果、团队成果与公司的核心价值的关联以及团队年度 KISS 评价。

　　好在今年我们组写了许多工作文档，我让组员都去列举自己今年完成的工作，标注重点，以及个人简单的总结。

　　我在自己写出第一版后，就让组内成员阅读，然后再提出补充意见，大家陆陆续续提出了 10 多条意见，让文档更为完善。

　　工作回顾就是列举今年的重点项目，写出选择原因、成功、复盘和学习与成长，我列举了两个项目，都用数字来描述它们的重要性。

　　例如榜单活动，列举了此类活动占比，成果就是 BUG 数和用户满意度评分，在复盘中重点描述了优化过程，以及经验总结。

　　例如组件化与抽象化思维的推广，还有研发活动工具，缩短上线时间，压缩上线步骤，解放生产力等。

　　在工作成果中，列举了本组的北极星指标和关键指标，并详细描述了优化前后的数据对比。

　　公司的核心价值是营收，日活，社交数据，用户体验等，我们组的价值是业务支撑和用户体验。

　　除此之外，还希望在更深入的理解业务的同时，能借助自身的技术背景，主动发掘一些能提升用户体验、营收等公司核心价值的点。

　　KISS 评价包括 4 部分，K-Keep、I-Improve、S-Start 和 S-Stop。

　　保持今年优异的表现，提升今年不足的方面，开始执行可以优化的工作，停止与关键指标无关的工作。