带团队后的日常思考(十一)

时间:2023-02-06 10:08:08

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。

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