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秒左右，未来如果将构建也进一步优化的话，那发布速度还能往上提。