带团队后的日常思考(八)

一、日常问题

1)模糊的提测时间

最近有个活动,在提测后的第二天,大家才得知上线时间是后天。但是问各个技术,大家都不知道这个时间,而产品是知道的,运营也知道这个时间。
那这就有点诡异了,为何会出现这个情况呢,进一步了解后,才发现原来在一次会议上,口头说了下上线时间和提测时间。
在那次会议上,大家都说了自己的开发时间,但是,对于提测时间,开发和运营却有不同理解。我的提测时间是11或12,但运营的提测时间是10号,以后对于这种时间截点还是要更敏感一点。
UI给到我们设计稿的时间,晚了一天,其实如果不晚的话,即使我们不知道上线时间,也会按预期进行。
但现在晚了一天,加上大家都不知道上线时间,从而就没有紧迫感,按照往常节奏推进,项目就会有延期风险。
还好发现的早,还能补救,运营肯定是不接受突然延期,因为她们做了很多前期准备。那只能加加班,赶进度了。
细究下来,其实还是沟通出现了障碍,之前也发生过一次对上线时间理解不一致的情况,只是当时是精确到小时,而这次是精确到天。
未来,对于项目,心里一定要明确各个时间截点,免得再出现这种乌龙了。

2)招聘

招聘是件蛮难的事情,就像找对象一样,要对上眼很不容易。
在年前的时候,因为业务的上升,需要扩编,于是发布了两个前端岗位。
可能是年前的原因,也没收到几份简历。HR也很忙,年底还有很多事情要做,也不能全部扑在招聘上。
后面自己也在V站上发帖,也投稿给知名前端公众号和知名技术周刊上发布招聘信息。虽然转化率还是很低,但是终于收到了几份简历了,也算是0-1的突破了。
其中年前面试了一名候选人还不错,年后让他过来继续后面两轮,谈下来都还不错,就发了offer。自己也总结了些对求职者的一点小建议

3)无人维护业务的修改

客服在半年前提过一个业务需求,当时其实也没什么结论,因为是中等级的,所以也没放心上。
后面又提过一次,得出的结论是服务端招人后,将整个服务全部迁移过去,做个彻底了断。
但是近期,客服说要经常处理那个业务问题,很影响工作效率,于是提升优先级,当即安排。
我们组内的其他成员手上都有事情,所以我自己来修改。在改的过程中,根据域名查到了项目文件。
根据package下载依赖包,但本地却无法运行,代码已然缺失。还好改动程度并不大,于是就将代码修改后,发到预发环境。
发代码我自己还无法发布,权限在服务端那边,我这边也因为权限组的原因,无法给我开这个项目的发布权限。
所以我每次修改完,都要请服务端的人发布,然后再让QA验证。期间调用一个接口,涉及到另一个项目的改动。
这个项目也一样,无法本地运行,也只能发到预发环境。期间查看日志,没有访问记录。
这个问题还请运维介入排查,原来是因为接口调用了线上的域名。而这个域名其实是个IP地址,直接关联网关。
由网关根据地址路径做转发,预发环境没有这类地址,又折腾了半天才调好。
运维前几天打算释放几台服务器,这其中有台服务器搞了个私有的npm,服务于这次修改的项目。
如果运维将那台服务器释放掉了,那么这次连代码都无法发布了,还要重新配置。
就是一个简单功能的修改,涉及两个无人维护的项目,前端、QA和运维三端参与,服务端还需要配合,在人力成本上面,还是蛮大的,ROI(投资回报率)有点低。
不仅开发调试困难,QA验收也困难,没有需求文档,只能通过我对代码的解释和她说明整个项目的流程。
还有一个比较麻烦的点是,修改的功能需要与支付宝对接,支付宝会回调我们这边的一个接口,需要外网访问,就不能在内网的测试环境验证了。
有个地方比较庆幸,那就是回调地址可以根据环境改变,否则的话,又要改造,开发成本就更高了。
这些项目就是安全隐患,平时看不出,一旦有问题,要修复就要花费巨大的成本,今年需要推进迁移计划。
后面和运维单独将正在使用且无人维护的后端服务找出,并且筛选出正在访问的接口或定时任务,择机做迁移,交给服务端维护。

二、工作优化

1)项目管理的流程漏洞

最近有个功能的修改是由服务端的人提出的,在和产品沟通后,拉上相关人员开了个需求会,还整理出了相应的产品需求。
后面产品就没怎么跟,让我们自己开发去了。这个功能前前后后总共持续了1个多月,服务端的那个人由于要去考试,就只能断断续续的开发。
中间他请假了好多天,QA在预发上对功能都验收后,发出了上线邮件。
然后这里就有问题了,虽然这个功能只是改动了售后流程的一个地方,但势必会更改客服的工作流程。
直接上线后,和他们简单的沟通如何使用后,他们就开始使用了。晚上19点多的时候售后有个地方卡住了,咨询服务端,也没响应。
那么客服只能按照自己的理解采取措施,但是那些订单都创建失败了,等到第二天早上10点,服务端才说他们漏了一步。
大家都很无奈,一个早上都在配合着改,我这边还回滚了代码。
从这边我看到了一个项目管理流程的大漏洞,就是在上线前还是得和业务方同步一下,让他们先了解整个操作的步骤,避免出现歧义。
如果能多这么一小步,那么就不会搞出这么多麻烦事儿出来。很多时候都是人为的给自己制造麻烦,都自以为是很简单的事情,其实不然。

2)Tower

Tower就是一个需求管理工具,公司的业务人员会将双月需求提交到此工具中。
我们技术部的工作就按照此工具来排,老板的想法是让业务和技术两个部门的人沟通能无障碍。
他觉得现在技术部和业务部之间的信息还不够透明。业务部提了需求,有时候就会泥牛入海。
借助此工具,就能了解到需求进行到了哪一步了。
在实际操作中,就暴露了很多问题,其实已经实行了一年,但是大家并不会太关注上面的状态。
也就是说,大家并不会及时更新,也就是上面推了下,自己再写点东西。
这个工具中的大部分工作,都指向了我们。对于我们来说,这上面的需求排在版本和活动之后,属于第三优先级的需求。
在过去的一年中,由于人员有限,在完成版本和活动后,也就没剩下多少时间来改需求了。所以对该工具就更不上心了。
但今年有所不同,管理层对这个工具很上心,还说要和OKR关联。这个双月开了好几次Tower会议,一遍遍的强调该工具的使用。
其实每个双月都会遗留很多需求到下个双月,除了人员紧缺之外,还有就是落后的生产力,今年这种局面都会有所改变。

3)UmiJS升级

去年因为要引入微前端,所以做过一次 1.0 到 2.0 的被迫升级。
今年是想主动升级到 3.0,一则是与主流技术栈接轨,二则是因为3.0 版本默认支持TypeScript。
今年想要在组内推广 TypeScript,进一步的提升项目质量。
升级的过程也不是说很困难,但是遇到些体力活,改文件和移动文件,弄了一下午,具体过程在此
还有比较担心的是,升级后业务的稳定性,我们缺少有效的全局测试,目前只能人工一个一个页面的点击。
在发到正式环境之前,会先在预发环境发布,邀请相关业务负责人,先在该环境中操作界面,提早发现问题。

4)管理后台发布提速

管理后台的界面代码发布一直很慢,基本保持在12分钟左右,去年也一直尝试着去优化,不过都没很好的成效。
这次和运维仔细分析了下症状,尝试着再做一次优化。
每次发布大致可分为四段,第一是下载依赖包(2分钟),第二是构建(3分钟),第三是上传镜像(3分钟),第四是部署(3分钟)。
除了构建之外,其他都可以靠运维来优化。
依赖包可以开启缓存,镜像原先要1.4G了,所以上传才要几分钟,主要是因为将 node_modules 目录中的文件也打包了,这部分其实在网页运行时,并不需要,所以要去除。
部署也在优化后,总共的发布时间控制在5分30秒左右,未来如果将构建也进一步优化的话,那发布速度还能往上提。