这是我入职第四年的年终总结（2016年，有删节，项目及公司敏感信息已隐去），这一年真的很精彩。

 2016 年度总结

2017年1月6日

感谢 2016

2016年对于我来说是不平凡的。

2016年一切都是新的。我作为一个新人，带着一批更新的人，面对新的DEV 8。然后一起学习新的技术、新的项目、新的合作环境。

2016年一切都是陌生。面对新的部门，我不敢怠慢却又对如何才能让它拥有执行力、凝聚力而担忧、疑惑。面对新的项目，我们又该如何与别人有效、友好的合作、相处？2016年一切都是责任。作为部长、作为学长、作为兄长，是否应该无尽地扮演一名保护者的角色？泛滥的负责会不会反而成为一种不负责任呢？我又怎样才能变化自己？

2016年一切都是坚持。面对XX项目的任务，如何同大家一块儿在学习如何开发的同时，按时完成我们的开发任务？如何面对压力、如何权衡度量？当异常紧张的工作逐渐舒缓以后，我们又该如何面对自己？

“能得到锻炼能力的机会”本身就是一项极其稀缺的资源。对我自己而言，我只想用无比幸运来形容这一年，我得到了那么多的机会，然后由此或为此去尝试改变，这是最难得的经历。

回顾年初目标

重新翻看2015年的年终总结，我只有一个目标。

“2016年的目标只有一个，全力以赴做好新XA，这比什么都重要，也希望由此，充实地度过我在AXP的第三个年头。”

在2016年春节过后，H哥找到我们几个做新XA的开发，告诉我们新XA暂时搁置不做了，我当时很抑郁，事实上，我差点没忍住哭出来。一年改变了我很多，当时我真的太脆弱了，那时候走出会议室，我特别失望，只觉得自己无为、无能，感觉准备了好多废纸，甚至质疑自己为什么还要留在这里。总之，也许正如2015年确定的这个目标一样，我不该把单一的目标或具体的一点看得太重，成长还有太多种方式了，这是自己对目标做错了定位。

在当时的环境下，新XA也许并没有太多的生存机会，不过2016年我深切感受到的两点就是，（1）只要付出，一定会有成效，但是要有耐心；（2）墨菲定律是公理。当时的一些预研并没有白费，在7月份XP项目的开发中，它的一部分被实现出来，这些实现在小范围上弥补了之前XA的一些不足，同时也让我自己在有准备的情况下和XP第一次遭遇。

2016，责任降临

年初的时候，我负责培养两位实习生，SHY和GXY，他们都是我同校的学妹、学弟。在他们上大一的时候，通过学校的“实验室”就有过几面之缘。无论如何，我都在尽自己的全力去培养他们。当时，SHY对前端技术非常感兴趣，对后端技术却又不了解且排斥；GXY却相反，对后端技术非常感兴趣，但对前端技术并没有更多的了解。他们俩上学的时候就是实验室里配合默契的“小伙伴”，所以，每个人并没有过多的顾虑，一切都还顺利。

SHY通过前端编码规范的整理，从HTML、CSS，再到JavaScript、JQuery、ASP.NET MVC，在我的骂声里，一遍又一遍的修改、重写，随后又学习了AngularJS、XUI的前端类库。对于这横贯了2016的小半年来讲，这确实折磨了她不少。不过，我相信她自己学到了很多，估计她以后也很难再遇到如此“充实”的一段生活了吧。这段时间使SHY在前端技术方面有了很好的基础准备，在进入XP项目后，由于这些准备，她或者说我们，没有变得无从下手。

GXY则属于主动型选手，平时不必为他规划详细的计划，只要定期设定目标，提出标准和要求，然后按时验收、讨论即可。在与他的几次配合里，比较印象深刻的是年初他对于将Metadata在SQL Server下转化为K-V形式存储时， 1亿条数据对于查询效率的影响。其自身主动的学习态度，使得对于他的培养逐渐成为一种正向反馈，一切很顺利。但是后来出于家庭的原因，还有自己对于Java平台和上海这座城市的无限执著和热爱，在给我写了一封长信后，他选择离开这里，去上海继续发展。

对于新人的培养，是我去年年终总结里说的（或者说抱怨的）最多的。所以，在上半年对于SHY、GXY、以及后来的LXH，有时候真的是小心翼翼。我一直怀疑自己带新人的方式是不是有问题，总是追求细节的培养、总是追求基础技术的牢固，总是技术至上，这些是否真的正确？对于实习生而言，他们今后是否能够留在公司不得不该成为一个权衡的指标，大量的前期培养成本是否带来了后期相应的工作效益？还是——学会了就离开？除此之外，当新人开始由于外部的影响不断渐趋于一种“觉醒”状态时，单纯的技术是否还是有效的吗啡？

这些，也许因人而异，每个人对于自己、他人和技术的态度都不同。在这个过程中，对于我的转变是，与以前带新人不同，我不会再选择急功近利了，也不会再过于主动地去推送知识点或者各种建议了，而是尽力去让对方主动的来向我询问具体的问题，不做事儿妈的好处显而易见，我自己首先感觉轻松了好多，同时，这也确实让那些知识点升值了，对方开始更加珍视这些东西，而非以前的左耳进右耳出。

 

2016年的春节前夕，在年初的提升中，我有幸被提升为新的XX_DEV_8部门部长。当我看到公司的提升邮件时，我毫无准备，瞬间石化。事实上，我仅仅是在那之前的1个多月前，听到过一次这种可能性。当然，我个人是万分开心的，因为这意味着一种非常珍贵的信任，也意味着我有了一个更大的舞台，当然，这更意味着更多的责任。那之后的很长一段时间，我想了很多。包括对于我们这个Team的建设路径，大家的交流风格，基本的做事原则（当时我希望我们能够成为“游骑兵”类型的团队，能够有一天做到指哪打哪）。

那时候我们还定下了几个小规矩，（1）必须定期举行周会；（2）永远不开早会；（3）用OneNote记录每天的主要工作内容和经验（Work log）。

（1） 必须定期举行周会。通过双周会的形式，我们的周会到了今天已经进行了21次。目前来看，周会是非常有必要的，我们不仅可以通过周会统一的发布一些信息，同时，还能透过周会这种集体形式，对个别人进行表扬或批评，使一些重要的问题得到重视和解决。而周会的频度，可以根据当前项目的紧张程度进行调整，如果工作紧张，则提高周会频度，反之则降低，这样可以更好的发挥周会的基本作用。

（2） 永远不开早会。众所周知，早会是早餐会的缩写。把每天头脑最清晰的时间花在开会计划当日工作或总结前日工作上，是非常不合时宜的。不过要是每天早上大家围在一起，吃吃早餐，憧憬、回忆倒也是自在惬意。如果有必要，我们更希望选择下班前进行“晚会”，首先，下班前的时间，大家的状态都是最不好的，这个时候更适合大家聚在一起讨论问题、或者回忆当天处理过的问题，思路更加清晰、也减少了回忆的时间。同时，这个过程中如果发现了当天一些没有处理完的问题，更适合督促大家继续加班并在当天完成相关的工作。更重要的是，每个人都希望下班尽快回家，所以基本不用主持者去过分Push大家说话，相对更加自然。

（3） 用OneNote记录每天的主要工作内容和经验。这项要求主要是在团队成立之初，以及进入XP项目之后开展的。Work log的主要目的，其一是记录每日工作内容、离岗时间，方便月底对于加班、绩效等进行考核和统计（最方便的莫过于统计打车票报销）。其二是作为一个共享平台，让大家相互看见彼此完成的主要工作，方便任务跟踪，同时，也可以有效分享工作的经验总结，作为一个互相学习的机会而存在。其三是提供给大家一个记录自己工作的备忘录，防止工作中的一些细节遗漏，同时也可以为自己后续反查一些问题提供依据。Work log 目前已不再被强制要求，但是大家已经会非常自然、主动的选择OneNote来共享问题、总结经验，这也是我们的根本目标。

 

由于GXY在春节后就去上海发展了，所以我这边只剩下SHY一人，随后另一位新人CQ被调入DEV 8，春节后公司又为我们补充了一位实习生，LXH。这就是我们DEV 8最开始的四位成员。

CQ之前已经在其它公司有了3年的工作经验，不过他之前并不是开发，而是测试岗位。成熟、有亲和力、虽然老了但还能保持对学习的热情，是我认为他的三个优点。虽然并不是开发出身，但是良好的工作经验，使大家的沟通反倒没有任何障碍，而且非常果断有效，CQ能够轻易的抓住任务的重点，分清主次，更有效率。而技术上，虽有很多缺失，但是它对于技术的向往，使他能够很快的弥补这些不足。

LXH刚来公司的时候技术真的是比较薄弱，加之，我自己带新人的方式有了改变，所以对LXH的培养速度和质量是有很大下滑的，在这一点上，我个人对LXH是特别愧疚的。LXH的培养方式与以往不同，在入职培训期间，便并行投入到小项目的开发里，不再首先学习技术原理，而是直接解决实际问题。这种赶鸭子上架的培养方式，使LXH这位刚来公司不到10个月的新人，在截止今天的XP项目中一共close了148个前端相关问题。但是随之暴露出的问题也是明显的，对于深入技术的理解缺失直接导致LXH在复杂问题或在今后发展过程中的乏力，弥补这类缺失也是接下来一年里的一个工作重点。

由于我们四个人里，两位还没有毕业，一位刚刚实际接触开发技术，所以Team初建时还是以基本的应用技术为主，先求不被饿死，这是16年第一季度的工作背景。

当责任降临时，必须得把事情做好，如果做不好，失去的不只是机会，更可能是信任。

由于新XA的搁置，我们被计划投入到年中XP项目的开发中，为了让我们这些新兵不至于刚上战场就被打死，H哥为我们预备了两个小项目，让我们在技术和实践上进行初步的整合、尝试，同时也希望能带来一些直观的成果。

Mobile Portal 与 XYM 项目

我们的第一个任务，是在较短的时间内，完成一个为公司各类移动App产品提供统一下载的Mobile Portal站点。基于对快速构建的需求，并结合当时对于前端技术的首要培养需要，我们采用了基于ASP.NET MVC + MongoDB的方式进行项目开发。由于MongoDB并不需要进行细节的表设计，加之之前我已经完成了MongoDB持久化层的封装，所以初期的开发还是较为快速、顺利的，程序从3月初开始编写，3周后被首次部署。当时的主要工作集中在摸索一个较为有效、可以适度重用的前端编写准则及模型。

Mobile Portal的功能需求相对简单，在基本完成后，它被部署到XE虚拟机上，随后，为了使项目能够更加贴合XE的运行环境，Native的MongoDB被修改为XE 原生 Service——DocumentDB。在更改并替换的一周后，一个周二的半夜，我突然接到了一通来自美国的电话。

打电话的是正在US onsite的XA开发S，他在替US的N老师询问情况——我们那个使用了DocumentDB的XE实例在过去一周，花费了25万美元！（我哪见过这么多钱呐！）

第二天早上，H哥也来了同样的电话，我们都急急忙忙赶到单位（我个人确实是慌张的，因为弄不好这次是要被公司开除了），在排查了代码问题并模拟计算了可能的花费上限后，我们确认这个数额应该是不可能的。几天后，US与微软进行了确认，果然是微软的账单计算错误，我松了一口气——至少不会在这段邪门的日子里被莫名的开除了。

既然微软能算出如此离谱的账单，那么小数额的计算错误也是在所难免的，积少成多，也许不会是一个小数目。同时，由于公司的XE资源日益增加，出现了很多闲置的资源，所以，开发一个可以有效监控公司XE资源使用情况的产品XY Manager（XYM）被N老师和H哥推进到了日程上。

 

XYM的开发集中在4月和5月，现在回看，当时的开发目的有两个，其一是尽快开发出一个包含核心功能、可供使用的原型产品，从而为Design Team及更高层领导提供一个可见的交互原型。其次是为我们Team提供一个机会，既锻炼一下基础技术的使用，又在这个过程中尝试下同其他Team进行合作开发。

但是，在5月末的时候，开发的结果很令人失望。开发的速度很慢，需求没有变化，但实现却在原地踏步，一遍又一遍的重写、不断的纠结。

究其问题的原因，我个人认为，其一，是我自己完全没有在4月和5月之间竭尽所能、发挥应有的作用，除了受到当时发生的一系列意外事件影响以外，也与自己对这个产品的意义认识严重不足有关。其二，当时我过分关注了产品的交互模式，导致交互模式驱动了产品逻辑，这使得很多时间都被浪费在了次要的工作上。其三，也与当时部门面临着多项目并存相互影响、整体产品在前期引入过多的参与者，管理责任不够明确有关。

总之，由于原型项目没有被有效地完成，导致后期开发模式发生了根本改变。交互Design Team被引入，使原有的交互设计、甚至少部分的逻辑概念被颠覆，最终导致原有代码在现实情况下变得不再有良性价值，原有代码中倾注的细节设计、结构设计在全新开发模式下，以及全新设计下变得不再有用，从某种程度上讲，原有代码的作用演变为一些控件或者前端技术细节的DEMO而已。

这些问题值得我自己反省、思考。首先，对于上级所交付的这种类型的任务，应该坚决地保证其完成进度和有效性，不容动摇，否则确实会从一个角度使既定的目标全功尽弃。其次，在完成这类任务期间，应该注意任务进度的绝对优先，并保持这一原则，而不是重复的考虑细节，过度地提供所谓的封装、结构或者并无需求的创意。快速地完成原型的构建是绝对首要的任务，这会直接影响一个项目的“命运”。基于XYM项目的特点，可能前期最好的开发方式就是狼群或独狼式的快速原型开发，对于我个人一定程度上的缺失所带来的项目影响我一直深感愧疚，我只能说我会吸取这些教训，不让这类故事重演。

在我们6月份投入XP的开发工作后，XYM项目被继续改进和扩展，在半年后的12月末，一场由XDW带来的精彩的XE资源管理培训给我留下了深刻印象，W通过XYM清理了公司大量的无用XE资源、为公司每月节省了2万美元的开销。这场培训让我体验到了转化的重要性，在开发XYM的初期，我们把任务当作了首要目标，完全忽略了这个产品的客观价值。作为一个产品，它能给使用者带来如此显著的成效，这本应是一个开发者最引以为豪的事情，只可惜在当时，我并没有做好。

正如之前所言，当责任降临时，必须得把事情做好，如果做不好，失去的不只是机会，更可能是信任。一定程度上说，今年的工作，XYM可算是一个很大的败笔了，这是非常需要我自己今后注意的。

在XYM项目的开发期间，我们还在5月开启了XP XA的准备和开发工作。基于XP项目启动时，Z老板对于性能的要求（每分钟可以正常响应万次的HTTP Request），我们开始了XA for XP的改写工作。

总体思路是，XA API不再和XA自身共用Website进行Host，而是通过重新编写新的、Restful且基于OAuth认证的API站点来独立响应请求。相关请求会被直接加入到基于Redis的请求队列中，然后立刻返回，而相关任务将会被异步的由具体的XA Worker进程消化、执行。同时，XA API将支持多站点Host，并利用Nginx搭建负载均衡。对于具体的逻辑实现，则仍将复用原有XA的实现，这样保证了我们在对原有XA不做任何改动的情况下，重新实现了Web API接口和相关队列执行模型。

基于以上结构，在整个大XA team的共同参与下，我们进行了并发测试，这是一次有趣且令人兴奋的实验。

经历 XP 项目

7月15日开始，我们全面交接了XYM项目，并全力投入XP项目的开发中。站在今天回想，那个时候我绝不相信这个只有三次迭代、五轮测试、三次UAT，包含了100个Project，7242个文件，1572111行代码，16485个JIRA的庞然大物，会按计划如期上线。

XP项目前期的既定计划是，SHY和LXH在长春XLL及ZYK的带领下进行XP项目XA模块的编写工作，我和CQ完成XP项目XA模块的编写工作。在七月份这一个月中，我们主要涉及了XA模块的近两次迭代，以及XA作为基础功能模块的逻辑支持。

七月初，我们Team整体搬迁到XP Team的工作位置，开始适应和熟悉XP项目。在XP XA迭代开始前，SHY和LXH主要对XP所用到的AngularJS和重新封装的XUI控件库进行学习和熟悉，我和CQ主要对之前所编写的XA新Rest API工程以及对应的简化Workflow进行调试和文档支持。在这段时间里，SHY对AngularJS进行了较为认真的预研，这使得我们Team在XA的第一次迭代中做好了基础准备，从一定程度上保障了第一次迭代任务的有效完成。CQ方面，其对于XA相关新旧代码的学习、理解速度很快，尤其是他具有的工作经验，让日常工作的沟通交流成本变得很低，这也从一个方面使得他在技术上的进步要明显优于他人。

XP项目一期共分为三次迭代，每个模块根据各自的相关性分别设置迭代的启动时间，每次迭代的周期都为固定的两周，两次迭代之间会有一周的时间用来给Team内部和新加坡Team进行Demo。从迭代的角度来讲，这算得上是高强度了，因为每次迭代之间并没有QA测试的时间用于喘息，同时，每次迭代的时间也不是按照实际的工作量给出的（而是直接按照功能模块进行分割）。这直接导致我们必须在不同迭代场景下采用不同的开发策略。

XA和XA在XP项目中占据了九分之一的份额，但我们远没有占用九分之一的开发资源。特别是XA模块，功能松散，且前端页面非常多，这也是导致我们Team大量加班的核心原因之一。具体来讲，第一次迭代是完成XA的YYP模块，这相当于XP学校现有的一个子系统，整体功能是为XP学校的同学提供一个跟踪、选定、评价课程设计、毕业设计内容的系统。而第二次迭代是完成XA的XXP模块，这与前一次的迭代功能完全无关，其为企业、学生和指导老师提供一个实习岗位注册、审核、申请、跟踪和评价系统。第三次迭代则是开发XA的PD模块，这是一个跟踪、管理和评价学生在大学期间个人作品的系统。三次迭代，三个无关的系统，构成了XA模块10月之前的开发任务。

七月中上旬，第一次迭代开始，本次迭代分为两部分进行。我和CQ继续优化XA的已有代码，为各个模块提供统一的SharePoint Provisioning功能，由于各模块都刚刚开始迭代，开发目的只局限于Demo，所以对于XA的需求很弱。同时，XA代码单独维护，不受到其他开发Team的影响，所以我和CQ的工作相对轻松。而与此鲜明对照的是另一队，由ZYK和XLL Lead的XA YYP Team，由于XP项目整体所采用的ASF框架当时非常不稳定，加之各个Team所提交代码的认真程度参差不齐，导致了异常大量的时间被花费在解决环境的部署问题或代码冲突的处理上。可以不客气的说，如果单就每天8小时的正常工作时间而言，第一次迭代期间，由此每天浪费的时间在4小时以上。

这些问题的产生，一方面是由于ASF框架前期的稳定性非常欠缺（ASF框架实现了网站子模块站点XXL的热拔插管理，这里有两个问题，首先，与当前ASF框架的稳定性和其在IIS的启动速度相比，当时的ASF一定存在较大的实现问题，这也是我认为当时ASF的稳定性非常欠缺的原因。其次，在项目开发的初期便引入这种热插拔框架的必要性究竟有多大呢？至少，它非常严重地影响了我们近一个月的开发效率，为什么不考虑先实现子模块功能，等待适当时机再进行引入呢？）。另一方面则是作为一个大Team所带来的切身感受，当我们走出MX Team、走出XA Team，当我们看到更大的世界、和更多人进行合作以后，我们会发现不同的Team、不同的开发，是有很大区别的，这不仅仅是技术水平上、认真程度上、做事态度上、沟通习惯上，同时，也可能起始于我们自身的原有历史，或者所谓的荣誉感。我们会更把原来的Team当作是自己的出处、原属的家，我们会开始关注我们在其他Team面前的荣誉感，这也是初到项目的一种感受。

除了上述的经常性的环境问题，还有XUI控件的使用问题。虽然XUI控件在之前的Mobile Portal项目和XYM项目中都有使用，同时，在当年准备新XA的时候也对AngularJS做过了解，但当两者结合在一起，并点缀上一些Knockout之后，一切就变得完全不同了。

第一次迭代作为填坑迭代，初期我们对于AngularJS控件的使用并不熟悉，我们花费了大量时间在诸如“如何将一个XUI控件嵌入到另一个XUI控件中的”问题（例如，如何在Grid的一行字段中嵌入一个People Picker）。因此，ZYK、SHY、LXH都付出了巨大的努力。随着迭代的推进，授T老师之命，我也开始投入到开发XA YYP的人民战争之中，XA部分则暂时由CQ独自负责。在这次迭代期间，SHY的任务集中在对于部分页面前端控件组合用法的摸索上，其表现得到了T老师、ZYK和XLL的肯定，表现出了自己的能力。而LXH的研究能力目前尚浅，第一次迭代没有能够带来令人非常满意的表现，不过，LXH通过这次迭代，也对XUI控件以及页面编写的基本规则进行了积累和掌握，为第二次迭代的开发工作做好了重要的基本技术储备。此外，这次迭代期间SHY在基础技术方面非常有耐心的为LXH提供了力所能及的讲解和支持，这一点从Team和主动性上来讲，我是很肯定的。迭代期间SHY和LXH基本上每天都主动加班，有时甚至到11点多还不走，一定要把当天的问题处理完（这些加班都是主动的，我没有提及一句）。通过这次迭代，两位新人真切的体会到了真实项目的开发节奏和流程，同时，也为第二次迭代更高强度的开发做好了准备。

由于长春和大连相距两地，开发的沟通和交流成本较高，所以第二次迭代XA XXP模块由我来负责完成。与第一次迭代不同，第二次迭代全部由大连Team进行开发，其后台由CQ独立完成，前台由LXH和SHY完成，中间层由我完成。鉴于当时第二次迭代的页面量非常大（有近20个页面），所以我们采用了和第一次迭代不同的开发模式。

第一次迭代采用纵向开发模式，一个页面从前到后，处理好一个再开始下一个，由于时间所限，这显然不能应用到第二次迭代中。第二次迭代我们采用了横向开发方式，确定的方针是，先基本确定数据交互的Model，然后前端专心、快速地按照标准方式实现页面及Angular VM的构建，后台同样快速地提供数据库及相关Service，然后由我这边进行两端的数据集成。在这次迭代中，LXH负责前端绝大部分页面的快速实现，由于充分吸取了第一次迭代中基础控件应用的经验教训，LXH仅仅用了三天，就完成了绝大多数页面（12个Grid页面）的编写工作。SHY则负责这一实现过程中，所涉及的较为复杂的数据绑定问题，以及个别复杂逻辑页面的编写。CQ则单独负责数据库和Service层的编写。

由于XLL和ZYK有自己额外的工作任务，CQ需要一些时间来独立明确Entity Framework的使用问题。同时，由于项目前期XXP部分逻辑的确认存在较大缺失，所给设计图需要重新绘制，导致珍贵的开发时间又被缩减多天。而在这次迭代期间，我和CQ还额外占用了两天时间去处理XP LCMS模块对于XA的紧急需求问题。LXH和SHY在迭代中间的周末，都申请了两天的串休（这是半个月前申请的，加上周末合计四天）。以上种种情况，基本上可以用“屋漏偏逢连夜雨”来形容了。

最后，第二次迭代留给我们实际进行开发的并行时间只有一周多一点。如上所述的这些“连夜雨”，我并没有打算拿出来作为任何的借口，因为项目的开发与产品的迭代是完全不同的。我们没办法把各种问题先拿出来进行讨论或追责，任何问题都不能成为不能Demo的理由，我们只想尽快解决错误，然后继续向下走，这是（我认为的咱们公司的）项目和产品的一个巨大的区别。无论如何，客户所需要的只是在Demo那一天，看到我们做出的成果。

随后的一周，我们加班到很晚，甚至有三天的通宵开发。我们如期在周一交付了迭代要求的功能，并为XP Team带来了一次内部Demo。这是一次绝对疯狂但又令人欢心鼓舞的开发经历，我只能说，感谢Team每一位成员的真心付出。

那之后的第三次迭代，以及其后的各种遭遇就不再讲述了，总之，XP锻炼了我们很多。

以下是XX_DEV_8进入XP项目后，已上报的加班时间统计。

为了缓解大家的心情，在这段值得回忆的疾风暴雨之后，我们大家组织了一次海岛游，虽然只是一天一夜，不过我们玩得很开心。

Team 成员与状态

按照Team成员加入的时间顺序，我对Team的每位成员发展进行下简单说明。

1 SHY

2016年，SHY对我和许多人来说，影响很大。15年年末和16年年初，在她身上发生了几件重大的事件。这些事件我都是亲历者，于我，也都是从来没有想到、或经历过的，而对于她，这个当时还没有毕业的实习生来说更是如此。

SHY的初期培养目的和定位就是成为Team的前端达人，这个目标在经历过XP的两次迭代后（到9月初），基本被推入正轨。经过前半年前端基础技术的常规折磨，以及XP这紧张刺激的两个月开发磨练（两次开发迭代和所处理的近100个前端bug），使她在前端基础技术上有了很大的进步，与其他同期新人比较很突出，这一点也是受到广泛认可的（包括长春GUI Team以及XA Team的诸位同事）。当时我相信，如果抛开其他因素，她如果继续保持这个状态的话，作为一个刚毕业三个月的新人来说，再用一些时间，她的潜力会被更好地挖掘，一定会有更大的进步，并且会得到一定的认可。但是，事与愿违。

首先，如果这并不是她想要的，那就会演变为一切都是我设计并强加给她的。在经历过一系列的严重事件以后，SHY自身的追求已经和刚毕业的新人有了非常大的区别。刚来公司的时候，她和其他人一样，希望通过热情和技术的成长，来改变或成就自己。而如今，这些东西被太快的消耗和转变。除了这些，与后端技术的稳定相比，结合上XP当时的一些场景，前端技术于她可能更像是一种折磨。加上几次她父母来大连看她，认定她不适合自己独立在外工作，应该回沈阳的家里（甚至拿走了她在大连过冬的衣服），再加上我不合时宜、没完没了的（可以理解为反向的）“鼓励”。在XP最为紧张的那个出UAT包的早上，她突然且自然的写了一封申请调转到沈阳Office的邮件。当时，在刚开始的那一个小时里，我自然是气炸了。幸运的是，在怒火之下我突然明白，有些时候我真的是把她看得太过重要了，我总是在付出了很多之后，期望回报。于是一瞬间，我觉得她的离开对于她自己和我们来说更是一件好事。在这个过程里，我感觉需要看清楚一点，无论我自己多么主观地认为，自己的付出是基于多么好的目的、或者是多么的为别人去计划、考虑，也不应该把别人不需要的东西强加于他人。正像G总今年来大连的时候说过的，“不能瞎努力，做了很多，结果还恶心到自己”。当一个人拒绝别人影响他的追求，那就绝不要再在这个人身上浪费时间。只期望并相信，SHY会通过自己的能力，在沈阳Office做出更多努力，在新的环境里向上生长。

2 LXH

LXH在XP项目中，已经处理了接近150个bug，作为一个A band、入职9个月的新人来说，是很不容易的。与入职时相比，LXH的进步是巨大的，在解决前端问题上，经历了这百余个bug的浸染，处理问题的“感觉”被不断加强， 在Team中发挥的作用也逐步得到显现。同时，LXH还在扮演Team小助手的角色，日常的会议记录、发票报销都是由她完成。

但是，LXH目前对于基础技术的深度特别需要加强，对待一些工作的认真程度也需要多多注意，在新的一年里，我会着重培养LXH，努力使她成为Team处理前端问题的达人。

3 CQ

CQ在处理问题上很让人放心，通过XP的这半年培养，在后端技术以及跨团队交流方面，他不仅可以比较自如的完成已有工作，同时还可以在一定程度上主动地协调Team中其他成员的工作。虽然对于一些较为复杂的问题，显得经验欠缺，但是相信只要通过一段时间的积累，一定会有很大的变化。非常期待CQ在接下来一年里的表现，也希望他能够继续发挥自己多年工作经验的优势，在新的一年里，取得一个突出的进步。

4 LQC

LQC是在XP的中期被调转到我们Team的，他也是我们这个Team中资历最老的一位。在处理XP项目期间，LQC同时兼顾MXX项目XA部分的开发与CI问题的处理，这使得LQC在11和12月份的每个周末都得来公司加班。这种从容、稳定性以及多年来的经验积累，是LQC最大的优势。

不过，LQC以往最大的劣势在于自身的交流和工作风格上。LQC的性格比较内向，在以前的Team也不扮演一个带领者的角色。在转入我们部门后，LQC便成为了Team的中流砥柱，这需要他重新定位自己的位置和理应扮演的角色。在这段时间里LQC的性格被大家改变了很多（基本转为闷骚型），并在一些事情上，开始主动带领Team的新人完成工作，并分享自己的经验。我相信，新年里LQC一定能给大家展现一个变化更大的全新形象，为自己和Team带来更多的进步和推动。

5 LJY

LJY虽然不是我们部门的一员，但是我们每天朝夕相处，已没有任何区别。11月18日LJY初来XP项目，结合已有对于AngularJS及公司前端控件类库的开发经验，他非常快速的融入了具体功能的维护与开发进程。在最短的时间内充分完成了与SHY的工作交接。这一个半月来，LJY共解决66个Bug，同时，通过快速学习XP XA模块的后台结构，在较短时间内，为XXP模块完成了大数据测试Tool的编写工作。

LJY表现出的“快、稳、准”、以及对于诸多前端技术了解的广度，给我留下了比较深刻的印象，期望他能在新的一年里，继续深入学习技术，做到既有广度，也有深度。

期许 2017

如前所述都是2016年的回忆，除此之外，今年还继续作为 IITS 和大连新人培训的讲师，又认识了许多新人，和每年一样，这总是一年过往中，最让人轻松、开心的回忆。今年我还内推了自己的表妹到咱们公司，现在正在PM team实习，希望她可以通过努力构建一个属于自己的舞台。

人在一个陌生的环境里，面临着全新的挑战，会本能的去学习和掌握更多东西。这个过程并不舒服，但却能让我们急速成长。而一旦我们周围的环境和自己所做的事情变得熟悉和容易，这就意味着我们进入了所谓的“舒适区”，不需要学习新的东西就能做好眼前的事情，我们的成长会逐渐趋于停止。当XP的紧张工作逐步缓解，如何去面对我们自己，成为一个重要的问题。

我们不想混掉自己的前途，因为这不仅是一份工作，也是自己的事业。在2017年，我们部门将会坚持每周开展内部培训活动，大家轮流做讲师，回归基础技术的学习，然后尽力深化我们的知识水平，努力成长。2017年，我们也会多多组织Team内和Team之间的活动，大家一起放松、一起结识更多的同事、朋友。

对于我自己，希望17年能有更多的时间脚踏实地的多看书、对产品或项目多做些有益的贡献，过好每一天，就知足了。

以上，就是我的2016年年终总结，感谢您的耐心阅读。

2017/1/6