在阿里巴巴的时期，我带领团队从零开始搭建了阿里巴巴集团的运维自动化体系，在初期的时候，团队没日没夜干出来的产品，却因为用户满意度不高而整体团队被打了3.25。

3.25的绩效

简单介绍下什么是3.25，阿里巴巴对每个人和团队都有绩效考核，会分为季度考核、半年度考核和年度考核，每个考核期初会由Leader跟成员团队确定KPI目标，期末针对KPI目标进行Review，然后决定你的绩效成绩。阿里巴巴当时的绩效考核有强制271分布的要求，也就是当你团队人数超过10个人之后，一定会有20%最好的和10%最差的（俗称1）。而绩效成绩是通过5分制来进行的，3.5分属于合格档次，也就是大部分人是会得到3.5分的成绩；而3.75分及以上就属于超出期望，通常年度超出期望意味着更多的奖金、加薪，以及晋升的机会；3.25分及以下就表示不合格，需要改进，对于个人如果连续两年都是3.25及以下，就有强制劝退的可能。

失败的产品

当年我们团队成员确实特别辛苦，而且因为研发和运维其实是技术中的两大领域，各自的一些行为习惯甚至价值观都是有可能不一样的，我们研发同学其实并不是很了解运维的领域的，在运维同学作为需求方的角度下，将产品从0到1做出来了，但说实话确实系统在用户体验上，符合运维同学操作习惯上是有很多不足的。当年年度绩效Review的时候，老大跟我说我和团队都被打了3.25，其实内心是非常委屈的。我还记得那年团队年终聚餐时，部门老大和我们一起加油，喝酒喝到半夜，整个团队十几个汉子都抱头痛哭，将心理的憋屈都散出来了。

复盘和调整

春节过后回到公司，我跟团队交流，做好思想工作，大家也都一致认同这个方向是没问题的，只是我们在做落地执行的时候，没有关注到用户体验的问题。

经过仔细分析主要有以下几个原因：

1、项目是公司内部的，我们是第一个给运维服务的研发团队，内心觉得有人专门给运维团队做产品就别太挑了；

2、资源非常紧张，招聘的时候我觉得不错的人都被老大以业务团队更需要为由搞走了，能将产品从0到1做出来，已经非常不容易了；

3、研发团队确实不懂运维；

4、运维人员其实非常忙，产品不好用的情况下就懒得用了。

我们团队决定按照以下思路进行调整：

1、从我们研发老大层面去沟通，争取资源和支持，明确这个项目的重要性；

2、从运维老大层面去沟通，从方向和认识上达成一致，只有运维自动化才是未来的方向，要明确从人工转向自动化的痛苦过程；

3、倾听客户的声音，重视用户体验。

改进和飞越

根据分析后的思路，我分别从研发和运维老大入手进行沟通，从高层的认知上先达成一致，研发方面的人才得要有保障，确保团队的技术实力，在运维团队要强调我们是给运维团队服务的，是为了帮公司解决运维领域的问题，帮大家从救火的模式中解放出来的，而且让所有运维同学明白这个事情的意义和重要性。

解决了高层领导的认知问题， 剩下的就是具体操作层面的事情，我们在系统中增加了一个用户登录和操作日志记录，每天会出一个报告，哪个用户登录和操作的次数排行榜，找到次数最多的几个运维同学，跟他面对面交流，甚至坐到他旁边去办公，了解他对系统使用的问题，哪些地方不方便以及有哪些建议等等。得到了第一手用户需求就尽快修改实现，大部分都是交互上的改动，修改起来还是比较快的，一般每周都能做到2-3次迭代。

通过贴近用户并快速迭代的方式，我们仅仅2个月不到的时间，大部分用户对系统的满意度已经提到非常高的程度，我觉得不仅仅是因为系统操作使用上确实改进很大，更重要的是我们团队提供的贴心服务，已经让用户感受到了上帝般的关爱。

这一年的年中，我们团队实现了80%的人晋升，这是在阿里内部非常少的情形（常规年中只有特殊的才晋升）。通过半年不到的时间将产品用户满意度提高到了一个全新的高度，为后续阿里集团打造运维自动化奠定了基础。

在后续阿里集团内部合并的时候，我所带团队研发的运维自动化的3个产品，跟其他子公司淘宝、阿里云等该领域的同样产品合并，选择了我们团队开发的全套产品进行集团层面推广，也是对我们团队的一个最大肯定，等我后续再专门写一下阿里巴巴集团合并时候的产品选择过程。