从我看到的--一个普通员工的自我剖析

      易保已走过十年，我们欣喜的看到他的茁壮成长。我相信，今天的成就，十年前已在莫总眼中，我也相信，莫总眼中的十年后，相比当下，一定无比辉煌。我同样相信，莫总眼中的蓝图，已转化为管理层眼中的蓝图。但是，这个蓝图是否在我们每一个员工的心中？我在易保一年半，我代表一个普通员工，下面，我从最近犯的两个错误说起：

      我的过错1： 在一新需求的设计、开发任务时，发现一个问题:“在校验投保人年龄规则时，发现其中用到的一个参数【生日】，竟然用的是被保人的生日”，我不想给自己找任何理由，这个错误我当时没有修改，也没有就其中的不理解部分咨询Product Rule相关比较熟悉的人，比如俺们项目（Fukoku）的Billy Li. 由于自己的疏忽，这个问题遗留下来了，直到后来测出这个规则中的其它问题，我才一并把这个问题修改了。这个问题是一期遗留的，可见测试难度大、隐藏之深（不是很严格的测试，很难测出来，因为大多数情况下投保人被保人都用同一个人，或者投保人被保人允许年龄范围很接近）。这个错误在生产环境现在一直还没有被发现（否则早提Bug过来了），如果不允许的年龄却投保并成立了保单，到理赔时发现问题，可能会使保险公司或客户产生纠纷，带来经济损失或更严重的后果。可见一个小小的Bug可能是致命的。就像冰河世纪中，一颗小小的松子可能导致整个冰山的毁灭。

      那是一颗邪恶的种子，我发现了却任其发芽，其实相当于是我种下的，种在代码里，也种在我心里。我希望我们eBao的系统中邪恶的种子越来越少，我们eBao人的心中没有邪恶的种子，只有我们心里没有，系统里才会少有。

      我的过错2：当TS测试我修改的某个规则时，所有的Case中没有一个是产生业务异常的Case。我竟然武断的回复说TS的Case覆盖面有问题，要求其重新设计。后来我的另一个同事（Taro兄）分析后，发现是代码的问题：我们的测试框架没有正确匹配一个关键数据，而这个数据在真实的系统中是肯定有值的，规则认为没有这个数据就不用校验此规则，理解为校验通过。

      武断是一个程序员很可耻的意识和行径，我们在编写着一段一段的逻辑，这些逻辑是一环一环IF Else IF Else下来的，我们天天这样严谨的在代码中使用这些逻辑。但是，在编码之外，却忘记了！任何事情都有因果，都有逻辑，在处理事情时也需要像在编码时那样，严谨的使用逻辑。

     本可以避免的错误却发生了，自我检讨之余，从中可以发现一些问题。我是一个普通的员工，我们公司有好几百个我，我希望对我提出一些建议：

      1. 对自己负责

          编码（测试等各工种）是一门手艺，我们靠软件吃饭，手艺不精吃不饱饭。我们手艺要精，至少得让自己满意，我们才吃得香睡得好。我总有一个感觉，上班越累，下班越轻松；上班越轻松，下班越累。

          编码是一门艺术，制造出美感是每一个艺术家的责任，也会让我们心灵得到慰籍和升华。心中不要邪恶的种子，开不出美丽的花。

          编码也可以成为一种爱好。

      2. 对公司负责

          公司为员工付出的成本是远大于员工收入的，公司是我们衣食父母，房子车子票子都得靠他。多为公司着想，其实就是为自己着想。         

      3. 对社会负责

         邪恶的种子会开除恶毒的花，危及生灵。我们不能种邪恶的种子，更不能看到邪恶的种子不扼杀。我们每一个字符都承载这那份社会责任，那也是我们与社会沟通的一座桥梁。

 

对管理者的建议:

       易保从几个人变成了接近千人。公司的成长壮大，人少的时候，大家靠得是团结、信仰、凝聚力、目标一致。人多的时候呢，也一样。但是难度会越来越大，我们公司在硬件管理上付出了很多：

       公司有通畅多样的沟通途径（moc、email、phone等），

       先进的管理工具（文档管理CC&SourceForge等、版本管理CQ、项目成本监控TimeSheet、测试过程管理平台TestDirect等），

       先进的云概念服务：虚拟机应用，

       先进的员工考评模式：文档量代码量监控、单位时间内的bug数量、HOD和PM/TPM的评价、SAPE考评系统等，

       成熟的任务管理流程（以FUKOKU为例，从需求到设计到开发到测试到交付，都要经过层层Transfer、层层Review、层层测试等一系列流程），

       先进的工具很重要，毋庸置疑。但是，软件最终是由程序员一个字符一个字符累加起来组成的，我认为程序员（可以延伸到各个工种）个人的态度、能力是决定性的。这里有一个辩证关系：正是因为程序员个人的素养千差万别，所以软件行业需要更多的先进管理工具、流程来减少因为程序员个人的素养不同带来的风险；但是这些管理工具、流程并不能从根本上提升程序员的个人素质（态度、能力、文化认同）。而恰恰，提升员工素质是公司管理上最最困难的一环，也是最最重要的一环，员工素养是基石。

       不可否认，在提升员工素养上，公司做了很多：公司周一到周五晚上都有免费的体育活动（篮球、羽毛球、网球、足球、乒乓等），可以免费在天行健健身，出游（这个属于我有人家也有），入职培训，项目培训（因项目而异，没有形成统一的文化），免费英语外教教学（内容很好，只是安排在中午，中午不休息，下午犯困，影响工作效率呀，而且受众面窄）。但是，我觉得，还不够，相比于公司在其它方面付出的成本而言，在提升员工素养方面还不够，还可以在很多方面有所做为。

        例如，新人进入项目后，一般都会安排一个老员工带一下，但是这只是指导性的，老员工除了要多花一些额外时间、多交一个朋友外没有太多收获（哦，还有付出就是收获），而新员工呢，因为怕耽误太多老员工时间，通常也是一知半解、效率极低。据我估计，通常，在一个月左右，这个老员工和这个新员工的帮扶关系自动解除了。要知道对于新人来说，老员工满脑子都是宝啊，在规则上将老员工的时间有尝分配一些（比如30%，有偿不是说要另给报酬，而是算入工作量）在帮扶上是必要的。

 

      小小建议：引入一带一机制

           1）老员工对新人的工作成果负责，带好了有奖励（具体啥奖励，我都说了，老大们不就没事干了嘛），带差了没有（惩罚就不要了吧）。

           2）帮扶关系始终维持（制度上半年或一年，人情上终生），长久下去会形成一种企业文化（比如以后介绍，嘿，谁谁谁是我入门师哥！俺带了十八徒弟等等）。也只有形成那种类似真正意义上的师徒关系，师傅为了光耀门楣才用心教，徒弟为了不丢脸得用心学，徒弟的成长对师傅也会形成鞭策作用，虽说后浪推前浪，但也不能拍死沙滩上啊。

           3）因为是师徒关系，徒弟惹事了，师傅要负全责，比如整了一堆Bug，谁让你是师傅呢。当然，徒弟屡教不改，师傅也可以申请逐出师门（少林寺还有方丈管着呢，师傅也不能自作主张啊）。徒弟也可以另谋门派，师傅难免也有冒牌的。

           4）师徒关系得记录在册，反正俺们公司管理系统多，也不多这一个。整合到staff portal上更好，一查就知道了。大家茶余饭后还多了一主题，有利于增进人与人之间的感情。这里谈到感情我再废话一句：有人的地方就有情感，公司是由人组成的，所以公司和人之间也有可能碰撞出火花；用工具、技术手段管人是下策，把人心聚起来最牢靠；咋聚啊，给好处啊，给员工more and more and more 好处，不光是钱还有more，也不能白给，得让员工都知道那是好处，像父母对孩子那样，真爱，别溺爱（当我公司傻啊）。（就一句号，还好~）

           我希望，公司对人心的管理也像在其他软硬件设施，管理流程方法一样，更加先进。也希望每个员工都能文化认同，有归宿感，真爱易保。人心齐了，我们即使少一些流程，少一些规范，我们仍能做强做大；人心不齐，就算再规范的流程，再先进的工具也没有用。千里之堤毁于蚁穴，居安思危，希望到eBao 1000 sites时，我们的基石更加牢靠！

            打扰大家，诚挚歉意，只因晚上睡觉吃饱撑着了，睡不着，胡思乱想。熟话说好记性不如烂笔头，遂冒着被老婆批的风险，凌晨三点伏笔疾书，如有些许启示，甚感欣慰，熬一宿都值了。老婆又在嘀咕，俺不在旁边她睡不实，罪过罪过。