关于开发团队之我思

[winixt]

目的是什么?

一个公司需要谋求发展增长,一个团队也要寻求成长,自我开拓.

作为技术团队,一个最基本的任务是保证当前业务的稳定.在这个条件下谋求进一步的成长.

那么问题可以拆为两部分:

1. 保证当前业务的稳定,我们还需要哪些工作需要做?
2. 稳定后可以从哪些方面进一步开拓?

问题2是在问题1之上的进一步思考,进一步探索,也就是问题1是问题2的前提.先讨论问题1.

问题1: 保证当前业务的稳定,我们还需要哪些工作需要做?

我们现在已经做了哪些工作?

1. 基础技术紧跟社区步伐,保证我们随时应用社区的力量.
2. 框架 + 组件库的积累, 让我们快速响应需求,避免重复的工作.
3. 对业务的基本了解,辅助我们的技术决策.

我们还有哪些工作需要做,或者进一步加强:

1. 各个业务的日志收集没有统一的标准,杂而乱,不好分析问题.
2. 对页面性能没有做到应有的重视.
3. 页面自动化测试的缺失. 靠开发评估边角有太强的随机性,并且随着业务复杂度的提升,靠人评估影响范围的可靠性也大大下降.

对于上述4个问题,我提出几点建议:

1. 定义系统类型: 配置型、作业型. 用于日志区别对待. 配置型, 做到“一键”能捞足够分析出问题的日志.作业型,以会话为维度,记录全流程日志
2. 定义性能指标包括h5 和 pc,全系统接入监控.
3. 推动页面自动化测试,全系统接入.

上述要落实必须各指定1、2个核心负责人出方案和排期推动.可以自己组,强行指定>=2 个人需要他们能真正合作做到 1+1 > 2.

除了上述问题,我觉得,对于h5客服没有一个很好的沉淀.一方面是因为业务少,另一方面这少量的业务又分派给了不同的人.这是一个应该以技术为维度还是以业务为维度划分负责人的问题.我们目前是以业务为维度.我认为以业务维度是我们以后能更上一层的关键.至于为什么,先按下不表.接着看第二个问题.

问题2: 稳定后可以从哪些方面进一步开拓?

有两个方向,技术和业务.(技术为业务服务,本质只有一个: 业务).先看技术:

为什么问题1是问题2的前提,只有在问题1的基础上我们才能看清我们当下面临的真实问题,在把问题1做好了前提下我们可以拥有什么?

日志标准.
性能标准
自动化测试标准.

以及基于上述标准的技术实现.

有了这些我们能进一步做什么?可以接入AI进一步加强,解决问题的一切前提是认识问题,在具体的问题上想利用好 AI 更是需要把问题描述清楚,有标准和数据沉淀.想让AI什么都能干就是什么都干不了.(这还愁 AI 没有研究方向?)

回归业务,业务是技术存在的前提,特别是在 AI 的浪潮下,只做“需求翻译官”后面难有出路.在理解我们的系统之后,我们需要能回答一个问题:

业务需求源生于哪里?

业务是基于什么考虑提出这个需求的?在业务没提出来之前,我们自己能有这种想法提前反馈给业务吗?要达到这个需求的目的,有没有更好的手段?

一句话,我们得了解业务.一方面能更好的设计我们的系统,另一方面,业务能力未来很重要,技术的开拓源于业务的开拓,在业务上能有主动权.

要达到这种程度虽然很难,但这是我们前行的方向.

怎么做?

1. 首先得建立起这种意识
2. 不需要细节,但是客服的整体架构要有清晰的认识,一个比较好的思路是,我们目前提供了哪些服务给客户,以什么形式提供的? 以全局观,去把握你所能决定的细节,犯错的概率会小很多.
3. 少说,有产品思维,去了解了解市面上的各类竞品,慢慢形成一套自己的想法
4. 有了自己想法后,结合自身业务的场景,自然而然会有问题,此时是找产品和业务唠嗑的时机,不然啥也不懂就去聊,问题问不到点上,别人会以为你没事找事