0%

背景

首先,关于这篇文章为何取名为设计一个糅合系统的设计,所谓的糅合系统,是指这个系统的用户群体没有那么纯粹,比如,是一个既有c端用户,又有b端用户的使用场景的系统,起初在设计这样一个系统之初,我思考过这样的一个系统会有几个问题:

  • 逻辑混杂,到时候会出现这个c端是这个样子的,b端为了兼容而妥协,折中出来的并不是一个好的方案,对两类用户来说都不够简洁
  • if/else糅合的代码可理解性比较差,随着迭代的推进,后续会越来越来维护。
  • b端更加注重功能体验,他们要的是功能能不能满足他日常运营,而且不同类的b其功能是不同的,用户端更加注重操作体验体验是否好,当然b端也注重操作体验,但相对没c端这么匠心。
  • 不同的b端可能需要的主体风格不同,是考虑一个b一套代码,还是一套代码配置不同的b,还是一套b的框架下组合不同的工具。
  • 分离/b-part/c-part之后,如何复用公共逻辑,减少重复开发工作,公共逻辑包括哪些,下层的规则是什么,该放在何处。
  • 假如让一个新手加入进来,他怎么快速找到相应的业务的代码逻辑在何处,如何新增,修改代码已实现需求。

基于以上这些点的思考,我首先走出了一个设计的雏形。

孵化

wecom-temp-ae90559c80f2c549419e1bc9bcc34488

首先,我们先站在上帝视角来看一看,一个用户是如何和我们的系统打交道的。第一个我们关心的是一个三要素:

是谁?来干什么?干什么后去哪里?我们可以用一个故事的方式来描述几个这样的案例。

  1. 我是巴乐兔的合同管理员,我来这里给张三发起一份合同,完事之后我要回公司报备下。
  2. 我是李子柒,朋友说这个挺好用的我就来了,我也不知道干什么,我更不知道我要去哪。
  3. 我是黎明,是一个学生,我来签一份摩尔公司发给我的暑期实习劳务合同,完事之后我就没事啦。
  4. 我是韩梅梅,是旺旺兴趣培训班的店员,我来签一份佳佳食品发给我们培训班的采购服务合同。
  5. ….

以上的场景,我们均可以从里面抛出【是谁,干啥,去哪】,这其实就是我要说的意图2.0,。

image-20211012150705417

故事2是一个特例,实际上,不知道什么干什么也是一种干什么,不知道去哪也是一种去哪,不知道是谁也是一种是谁。

是谁

就是要确定进入系统的用户身份,是b端的用户,还是c端的用户,一旦确定了身份,这个应该是全局可知

  • isC
  • isB
干啥

就是要确定是谁之后的事了,就像大家去政府办事一样,人家首先明确你是谁,然后在问你来干啥,你干啥是不是得交出一些办事的凭据来,事情的id,通过这个事情的id就对应到了不同的功能

image-20211012153451750

去哪

首先每个功能有其内部的流转流程,它自己知道哪一步该去哪?但是:

  • 他这个内部的流程结束了呢?
  • 遇到异常了呢?

那么他下一步将走到哪里呢?这个是这个故事里的人的是,应该把选择的权利交给他。

实施

如何确定用户身份

要确定用户身份,我设计需要一个用户管理模块,它具备的能力有:

  • 切换身份,满足一部分用户既是b端用户也是c端用户的场景。
  • 申请身份
  • 登录角色

最终是为了确定用户身份。

如何确定用户来干什么

我们去银行我们会带上银行卡,我们去买菜会带上菜篮子,我们去做火车会带着车票,我们去考试会带上准考证….我们都会遵守一些既定的事情的协议。

  • xx:bank
  • xx:buy
  • xx:train
  • xx:exam

我们去买什么东西会写一个清单,如是:

  • xx:buy&item1=”南瓜1斤”&item2=”瓜子1公斤”

所以,用户来干什么,都是一系列的动作,做这些动作需要一个清单才知道具体怎么做,交给谁做很容易,我们就想到了路由

路由器就是一个配置表,表述的事情是,xx:buy&item1=”南瓜”&item2=”瓜子1公斤”

功能 参数 realPath
xx:c-buy c端买东西 item1=”南瓜1斤”&item2=”瓜子1公斤” pages/c-buy/index
xx:b-buy b端买东西 item3=”南瓜1斤”&item4=”瓜子1公斤” pages/b-buy/index
功能是什么?

功能需要是一个比较内聚的概念,他可以包含一系列的动作,有自己内部的流转流程,更具数据的状态及用户的操作来驱动页面UI 的展示,即:

功能= 数据 + action + UI

image-20211012170713165

功能,他有依赖底层的一些服务,及一些公共的工具函数。

image-20211012171053961

那么,基础服务包括哪些呢?

  • 网络服务
  • 邮件服务
  • 短信服务
  • 甚至是三方服务,如人脸核身
整体的三层架构

经过上面的分析,我们不能达成一个从上倒下依赖的三层架构模式:

  • 路由层
  • 功能层
  • 基础层

image-20211012172537275

路由层的作用是找到三要素【是谁,干啥,完事之后去哪】

拦截器是干啥的,上面已经提到,是找出三要素,找到之后如果发现非法入侵,就会把他路由到非法页。

功能层是解决干啥的。

功能才的Action是干啥的,是处理用户的的各种动作的,包含:

  • 网络请求
  • 本地请求

这样的一些操作都的会引起数据变化,进而导致UI发生改变。UI的实现可以原生,可以web,

基础层是帮助功能层很好的完成干啥的。

还缺点啥?

一个好的系统肯定是需要可观测性的,需要trace用户的行为,包含

  • 进入哪个页面
  • 做了哪些动作
  • 动作的前因,后果是啥

在研究某个问题的时候,你需要把它转换成一种认识。故事是描述认识的一种好方式。与一大堆需求描述相比,故事可以让读者更容易明白什么重要和为什么重要

什么,你觉得故事不是非常有条理或者不具备技术性?错了。管理人员无时无刻不在使用故事(想一想公司的使命),技术团队也都在讲故事(流程图和用户案例)。用户体验团队同样也写故事写了很多年了。

故事应该用三言两语把核心体验表达出来。

对于像Flip这样的数码摄像机,可以这样写:

你站在香港城市街头,忽然一阵骚乱:发哥(周润发)正向你走来。

你迅速从口袋里掏出你的Flip摄像机,把它交给一位路人,请他帮忙拍了一段视频,发哥就在你的身后。

之后,你赶紧敲开附近朋友家的门,不需要任何安装配置,就通过他的电脑把这段视频分享到了网上。

如果你正在设计一款数码摄像机,这个故事会告诉你如下重要事项。

  • 这个摄像机很小,可以方便地带到任何地方。也许是像一个小挂件一样,能够随身携带的那种。肯定不是只有在某些特殊场合才会用到的大摄像机。
  • 开机速度快(因为发哥不会等着你),而且拍摄简单,即使是第一次见到它的人都能够拿在手里就拍。
  • 要上传视频不需要特殊的软件或者数据线。
  • 最后,拍摄视频的目的是为了与朋友分享。

故事可以把大量信息浓缩到寥寥数语之中,效率极高。而且,故事很容易记住,很方便与人分享。

也就是说,在你们讨论设计决定时很可能需要准备几个故事。

事实上,人人都喜欢故事,即使你不讲,别人也会编出来

(“如果我使用这个摄像机,我就……”),让你不由得跟着他们的叙述展开想象——因此,要确保他们在使用你的故事。有必要多花点儿时间把故事的每一个细节都想清楚。如果你想让自己的设计简单,每一个细节都至关重要。

故事的情节要短

千万不要长篇大论地详细描述重大活动。要通过一个小故事展示出每一个需求点,并确定满足该需求的功能(核心功能)。这样做有3个原因。

  • 首先,简单的故事容易记也容易复述,因而容易被别人传播。
  • 其次,容易让别人把这个故事的情景套用到其他环境中(你可以想象在一个孩子的生日会上把你的Flip摄像机递给孩子的父母)。
  • 最后,为故事增加细节就像是拉近相机的焦距:人们会认为你要展示一些重要的信息。乐观估计,你的细节会吸引人;最差的情况,人们也会自己找到细节重要的理由。因此,务必只添加要紧的细节,这样你的故事才会真实丰满。

一旦走进现实的环境,你就会发现影响用户体验的因素原来如此之多。以下是几种现成的环境。

办公室

  • 在开放式的办公室里,各类人员之间会频繁地相互干扰。看吧,由于某个有意思的话题顺风传入耳朵,有人就会放下手头的工作把耳朵竖起来,人们因此而打断工作的频率会高得让你大吃一惊。
  • 来电话了,收到短信了,有新邮件了……,这些全都是干扰用户的因素。
  • 如果有人要为某个会议打印文档,他们通常都会等到最后一分钟才去打印。而忙中出错那更是常有的事儿了。家里头
  • 人们在家里边使用笔记本电脑边看电视或听收音机,花在哪方面的时间和注意力多些实在不好说。
  • 家庭宽带连接有可能不如公司的线路那么稳定,速度可能也没那么快,尤其是晚上的上网高峰期。
  • 妈妈要在孩子看动画片的30分钟左右的时间内上网购物,要从3万种商品中选择购买100种日用品。

家里头

  • 人们在家里边使用笔记本电脑边看电视或听收音机,花在哪方面的时间和注意力多些实在不好说。
  • 家庭宽带连接有可能不如公司的线路那么稳定,速度可能也没那么快,尤其是晚上的上网高峰期。
  • 妈妈要在孩子看动画片的30分钟左右的时间内上网购物,要从3万种商品中选择购买100种日用品。

户外

  • 站在大街上,你会看到人们快走到十字路口时才忙着查看手机上的地图。如果这时候他们还得先看懂使用说明,那这个软件肯定是没有前途的。
  • 人们在打手机的时候可能会背着几个包,如果手机按键不够大,就会非常麻烦。
  • 人们在排队的时候可能会试用手机应用——随时都可能被打断。
  • 明亮的阳光可能会让人看不清手机屏幕。
  • 较大的设备,例如平板电脑,很容易让人觉得太重,拿着不舒服。于是,人们总会想把它们放在某个地方。
  • 在黑夜的是时候扫码骑共享单车。

如何找上级领导要取资源

反面案例
上来就说你要的资源是什么,接着是打消领导的顾虑。策略是

索取资源,打消顾虑,没有背景

image-20211007171623555

下面这个案例以另外一种方式要资源

讲述背景,提及冲突,解决方案(获取资源),展望结果

image-20211007171221596

研究表明,老板平均60%以上的时间花在业务上,20%的时间花在跟他的老板、客户的相处上。最后剩下的20%的时间才能花在管理团队上,按照平均每个管理者管理6个下属来看,管理者能花在你身上的时间只占3%。

用心做的决定,然后找数据证明自己这个决定

当你用数据解释A方案比B方案好,你老板却提出其他奇奇怪怪的理由证明B方案更好或者索性说“让我再考虑考虑”,结果这一考虑就没下文了。现在你知道为什么了吧?因为你总想着用数据和事实说服他的“脑”,却并没有打动他的“心”。

高手的一些做法
  1. 通过类比、比喻这样的修辞手法,也可以让我们把复杂的概念变得浅显易懂,深入浅出地解释一些复杂的问题,有效地表达自己的思想
  2. 冲突升级,随着剧情层层递进的冲突不断升级,最后变得无比强大

如何讲好故事

  1. 一是要“清晰”。
    • 没听懂的都是白搭。你得明白想表达什么,要有一条主线,其他内容都是串在主线上的珍珠,如果没有那根线,所有内容就散了。
  2. 二是要“好奇”。
    • 那怎么让人产生好奇呢?美国著名的经济心理学家乔治·勒文施泰因认为,好奇心来源于某种“认知差距”,当一个人意识到自己的“认知差距”时,就会产生对信息的饥渴感。
  3. 第三是“共鸣”。
    • 第一层是最简单的共鸣,来源于共同的经历、背景、目标等,就是所谓的“有共同语言”。
    • 第二层共鸣来自共同的感受,比如痛苦、喜悦、愤怒、难过等。
    • 第三层来自价值观层面的共鸣。马丁路德金,若为自由故两者皆可抛..,民主,共和三民主义等等

当你把自己的观点强加于人的时候,不但剥夺了别人的愉悦感,效果也很有限(此处“脑补”你爸妈的唠叨)。教导不等于说教,没有一个人喜欢被说教。一个好的教导的故事不会敲着我们的脑袋指指点点,而是帮助听众去反思自己的价值观,探索自己的动力,找到属于自己的答案。

最近想换回自己的iphone7玩一玩,充满电,看下电池的最大容量居然只有79%,

image-20211007110447499

这你也能忍?果断在某多多上买了一个电池;

电池哪家强

只看了两家 品胜 和remax,对比了下发现最大容量差不多,发现品胜的差评比较多:

  1. 做工不像品胜的,怀疑某些商家以次充好
  2. 发现还不如以前的原装电池,掉电像跑表似的

基于以上两点,本来想买品胜的我果断选择了remax,

remax的稍微便宜10来块钱,差评还挺少见的。

如何拆下老电池

电池到手之后,看到包裹里面放了一个二维码,打开是这个这个视频,这里详细的介绍了如何拆下老电池的方法,大概来说分为7步:

  1. 将充电口那里的2个啰嗦下下来,注意,最好用一片卫生纸把螺丝都搜集在一起,不然很容易丢失。
    1. image-20211007105842711
  2. 使用吸盘吸屏幕,顺便用塑料翘片把机身撬开,注意,先从充电口这边开始撬,然后顺着左右两边,分别撬到电源键,和声音键为止,基本上就可以打开盖子了
    1. image-20211007105920823
    2. image-20211007105952649
  3. 打开盖子这部一定要注意,只能是由声音键的这边揭开屏幕,因为排线在电源键那边,那个很容易段开毁掉,所以,这部得千万注意,然后揭开的盖子最好不要超过 90度,实际测试110也问题不到,但是180度的话,果断排线会被你毁掉,所以,最好是用基本上靠着。
    1. image-20211007110014961
  4. 使用螺丝刀拧开电池接线头的盖子,这部没啥风险,就是拧啰嗦,注意点在于,这个螺丝很小,小心别丢了,另外,有一个螺丝设计有点古怪,可能因为电池接线头铁盖子和螺纹口距离有点远,它是先用了一个大的螺丝点地下一层,再在螺丝上上一个螺丝。
    1. image-20211007110103787
    2. image-20211007110130179
  5. 撬开电池接线和主板接口,轻轻用力就可以撬开了。
  6. 把电池和手机盖子的粘胶扯下来,注意用力别太大,很容扯断,我就扯断了,不过没关系,把电子撬开点,用镊子拉出来继续往外扯。2个粘胶都扯下来后原装电池就自然很容易拿出来了。
    1. image-20211007110201498
    2. image-20211007110219436
  7. 换上新买的电池来试试吧,接线和主板接好就尝试开机,不要急着把粘胶贴上了,如果可以开机,看看电池容量是否是100,如果是,就没问题了,就可以开始最后一步了。
    1. image-20211007110515588
  8. 这时候可以贴粘胶,沾到手机盖子上,注意粘胶别贴反了,这个是要放在背面和手机金属盖贴在一起的。然后改上贴片,盖上手机,上号螺丝,大功告成。
    1. image-20211007110342412

小桥流水人家,也许是大多数人所向往的退休后的生活;

  1. 依山傍水渺无人烟,远离城市的喧嚣,这里有清澈的流水,清晰的空气。
    1. image-20210929102716172
  2. 一个不大不小的宅院,小二层的别样阁楼,最好是有一个合适的院子,里面可以放上一些基础的设施:
    1. 邀请朋友来做客,沏一壶上好的龙井,几人围坐在石桌旁,品味人生
    2. 累了,就在秋千上躺平,摇摇晃晃如婴儿般入睡
    3. 醒来,去私人的听歌房闭幕欣赏半个小时的音乐,然后去书房与古人来一场灵魂的对话

关于团队组成

一个团队的人员构成大概都是会有以下几类人:

  1. 责任心强能力也强
  2. 能力强责任心一般
  3. 责任心强能力一般
  4. 责任心一般能力也一般

其中,第1类人是团队的基干,需要对他进行充分的授权,把重要的项目交给他处理来带;

其中,第4类人是团队需要淘汰的成员,基本没有什么可塑性,一个团队的leader自身的定位应该是团队的教练,而不应该是团队成员的父母。

作为团队的教练,最重要的目标是把合适的人放在合适的位置上做合适的事情,同时也需要遵循一定的自然法则,优胜劣汰,这样的团队才会永远是一个健康的团队。

关于分工

  1. 责任心强的能力强的应该放在团队的第一梯队,重要的攻坚项目尤其是时间比较紧张,任务比较繁重,不容许有延期出现的项目,应该交给这样的成员来处理跟进,一方面可以确保项目正常进行,一方面他也会在这个角色上持续成长,同时会获得较好的报酬,对于团队,对于他本人是一种双赢的局面。
  2. 能力强,责任心一般的同时,需要交给他一些重要,但是不紧急的事情,比如项目的性能优化,前沿技术的探索等等。
  3. 责任心强,能力一般的小伙伴,一般来说,目前处于一个能力成长的阶段,大多是毕业生为多数,这类同事需要可以分配一些容易处理,但是比较繁多的任务,比如,换图,刷新样式,用例走查,文档整理,在这个过程中,第一梯队的成员需要战出来带一带这类小伙伴,促进他们有一个较好加速度的方式成长。

项目迭代

项目迭代比较关系的问题是:

  1. 项目产生的bug,通常在提测之前会有自测,这个过程就是为了预防有一些低级的bug比如功能都没验证通过就提测了,这是机器不应该的,应当命中责任心较弱,但不可一次性否决,老虎也有打盹的时候。

  2. 多人合作开发,其过程和接力赛跑有类似之处,但是不同点在于,后面等待前面传递接力棒过来的选手可以”抢跑“,比如通过mock数据的方式先走一步。那么,纵观整个过程中,一定不是所有人都有任务在处理,项目owner是一个例外,因为负责的事情繁多,需要持续push项目进度,关注项目风险点之所在,那么剩下的这些人呢?他们的空闲时间可以用来干啥?

    1. 责任心强的人,此时应该会有两个选择:
      1. 关注项目中哪些地方做得不够好,如果时间允许,站出来,和大家说下,这块我来进行重构下。
      2. 协助其他小伙伴处理一些比较独立的事情,或者review下上下游的代码,帮助发现风险。
      3. 持续学习,提升自身技能,调研一些技术方案,以便在后续迭代中用到
    2. 责任心弱的人(一般来说不太可能存在),此时的选择可能是
      1. 躺平,等待别人push,事不关己高高挂起,不到最后一刻绝不出手,但往往最后一刻这里就有问题

    当然大多数人应该属于有一定的责任心但是还可以提升的阶段。

  3. 一个比较好的习惯

    1. 项目有一个deadline,我们自己也应该有一个deadline,通常项目迭代会预留一定的buff,因此在工作做完之后,不妨抓紧自测一下,把代码review一下,抽空把代码该重构的点重构一下。

    今天就写这么多吧,有新思考在补充

Vue 不仅限于开发 Web 和原生移动应用程序,它还允许构建桌面应用程序。以下是人们选择 Vue 而不是本地语言解决方案的一些重要原因:

  • 跨平台:所有应用程序均采用JavaScript开发,可打包为Windows/MacOS/Linux;
  • 易于构建:框架允许您简单地开发 Web 应用程序,然后使用打包程序将其“转换”为桌面应用程序;
  • 社区:如果您维护一个开源桌面项目,您将更有可能为它找到贡献者。

然而,有一些缺点,所有 JavaScript 驱动的桌面应用程序都很常见。它们往往具有较大的包大小(至少 30 MB),并且已知内存使用量很大。

使用 Vue 构建桌面应用程序主要有两种方式:基于 HTML+CSS 的解决方案或原生 GUI。第一个是 Electron 和 NW.js,第二个是 Vuido。

Electron

Electron是由 GitHub 开发的开源库,用于使用 HTML、CSS 和 JavaScript 构建跨平台桌面应用程序。Electron 通过将ChromiumNode.js组合成一个运行时来实现这一点,并且可以为 Mac、Windows 和 Linux 打包应用程序

Electron 是目前最流行的用于编写 JavaScript 桌面应用程序的库。一些比较知名的应用程序是SlackDiscord messengers、Atom代码编辑器和Visual Studio Code IDE。

优点 缺点
容易上手 打包比较大
良好的开发文档 内存占用高
无需更改现有源代码 包中未受保护的源代码
Vue CLI 插件
成熟的开发者社区

NW.js

NW.js(以前称为 node-webkit)是一个使用 HTML、CSS 和 JavaScript 构建桌面应用程序的框架。与Electron类似,它基于 Chromium 和 Node.js。NW.js 允许您直接从浏览器调用 Node.js 代码和模块,并在您的应用程序中使用 Web 技术。此外,您可以轻松地将 Web 应用程序打包为本机应用程序。

优点 缺点
容易上手 打包比较大
无需更改现有源代码 内存占用高
编译为受保护的二进制文件 使用率明显低于 Electron
Vue CLI 插件

Quasar Framework

Quasar Framework是一个允许跨平台应用程序开发的框架。使用大型 VueJS 组件库设计您的应用程序,然后使用 Quasar 强大而简单易用的 CLI 通过 Electron 为桌面自动构建您的应用程序。如果您希望对您的代码做更多的事情而不仅仅是 Electron 应用程序,那么 Quasar 是您跨平台应用程序想法的绝佳解决方案。

优点 缺点
容易上手 桌面也比较大
无需更改现有源代码 内存占用高
可以打包到各种平台,Android,iOS,以及桌面,网页等

Vuido

Vuido是一个基于 Vue.js 创建原生桌面应用程序的框架。使用 Vuido 的应用程序可以使用原生 GUI 组件在 Windows、OS X 和 Linux 上运行。

在幕后,Vuido 使用libui库为每个桌面平台提供原生 GUI 组件,以及用于 Node.js的libui-node绑定。

Vuido 和 Electron 或 NW.js 之间的核心区别在于,您不会在 Vuido 中使用 HTML 标签或 CSS 样式,您只能使用操作系统平台提供的一组预定义的 UI 组件。

优点 缺点
容易上手 外观仅限于操作系统本机 GUI 组件
无需更改现有源代码 没有 Vue CLI 插件,只有 Vue CLI 2 样板
可以打包到各种桌面版本
与 Electron 或 NW.js 应用程序相比,提供更小的封装尺寸
有据可查

总结,如果你想使用vue来构建全平台应用,而且还要颜值OK的话,选择Quasar Framework 是正确的

管理者应该做的事情

  1. 关注小伙伴优点,并非弱点,用人所长容人所短,找出优点,放大优点。
  2. 充当教练,培养人才,找出每个人的才能,表现好需要积极反馈,表现不好需要进一步完善的建议。
  3. 关心下属,设定成功的目标,在成功的途中做一些辅导。
  4. 需要怀疑但也需要倾听,保持尊敬,心平气和接受反馈。
  5. 协助小伙伴共渡难关,但要分辨什么时候提供什么样的帮助,掌握分寸。
  6. 需要讲一些故事来说明愿景,打造一支高效的团队,让大家参与愿景建设。
  7. 不断充实自己,保持对行业技能能敏锐,分享学习心得。
  8. 就事论事,客观看待事情。

技术团队leader的要求

基本要求

了解每个小伙伴的技术特长,根据以往项目经历合理分配任务,保证业务按时高质量完成。

更高要求

  1. 团队文化(团队氛围)建设

    1. 大多数人的认可文化才是团队的文化。

    2. 可以具体实施的,绝对不是空泛不可达的。

    3. 如电子签前端,做技术中心最开心的开发【事假机制灵活,通勤时间不做考量,任务导向,拒绝无效加班,责任为先】

  2. 小伙伴技能水平提升

    1. 业务之外,技术成长与业务需求相结合,产品需求和自研需求相结合
    2. 控制下产品需求的进度和占比,留出一些时间用来做自研需求。
    3. 分享,尽量和平时工作有点关联,可以维护一个技术分享的主题池,控制分享质量及相关度
  3. 研发规范体系建设

    1. 流程、规范与稳定高于一切
    2. 崇尚技术深度,而不盲目崇尚新技术,且不可拿项目稳定性开玩笑
  4. 团队凝聚力(稳定性)建设

    1. 注重培养归属感、责任感与主动性,并明确赏罚机制
    2. backup机制,避免应对线网问题时出现单点故障
    3. 灵活的“7*24”,而不盲目推崇固定的“996”,事情多的时候,大家就辛苦点,多加点班;事情少的时候,大家就早点回家,多休息休息,养精蓄锐而不是在公司干耗着混加班时间。
  5. 上通下达

    1. 下达,对齐目标,把控项目风险,攻克技术难点,通过晨会周会的形式。
    2. 上通,月度总结,宣讲,邀请领导参与,了解小伙伴工作。
  6. 注入新的血液,新人培训机制

    1. 流程规范培训要优先于技术培训,新人引发的问题中,很多都是由于操作不按照流程,不遵守规范导致的
    2. 老人踩过的坑,新人也很有可能会踩,每个新人入职时,都把这些常见的坑提前多熟悉几遍,不要求全都一一记住,至少要在脑海中留个印象
    3. 明确新人熟悉系统、技术等的顺序和进度安排,制定一个合理的熟悉顺序和进度安排,明确每天任务,确定deadline