Goodbye2014，Hello2015

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

正如我在研发会议上说的，总结是为了更好的计划；而计划，则是让你做事有目标，有方向；有了目标和方向，你才能真正把事情做成！

总的来说2014年可以归纳为下图：

2014年总结

一年的活动，基本可以归纳为三个： 工作、家庭、个人 。工作是主线，在工作中个人得到发展；通过写博客，读书等不断更新知识体系，增强核心竞争力；在年末的时候，迎来了女儿的诞生，可谓是今年最大的收获！

公司混乱的管理局面

2014年其实说是公司最为混乱的一年并不为过，年初把华北的商务总监升级为事业部总经理，干了一个季度又撤了。接着换总经理秘书管，不到一个季度又换了。这次老板又回来主持大局。管理层的混乱，必然导致公司各项制度、计划的混乱，甚至有几个月工资迟了一两周发。工资、报销迟发对员工有什么影响，相信大家经历过的都知道，没经历过的也可以想象下。搞到下半年，两个事业部的总经理都离开了公司，整年的业绩也一般般。

所幸，对这种情况我早有预料，及时的把部门进行了封装，由我作为对外统一的接口，因此公司的混乱没有对我的部门有任何影响，并且在公司如此混乱的局面，部门经历了某数据中心高强度高要求高性能的一次开发，并最终挺了过去。 截止目前为止，部门的离职率为0% ，系统的性能较2014年初也大为提升，系统的架构也在有条不紊的改进中。

两个项目

说起来，整个年度花费时间最多，也是最难做，最让研发 “谈虎色变” 的就是某数据中心的项目——直接和竞争对手真刀实枪的在现场对着干，公司之前的系统的缺点基本在项目暴露无遗，整个项目时间少要求严性能指标一点都不虚；其次，就是某银行网点设备监控的项目——网点多，BUG隐蔽，无法调试(系统只有8M内存的μcLinux)。相对于这两个项目，其他项目就跟以前一样的规规矩矩。

某银行灾备数据中心开发

如果大家看过我的《我是如何在SQLServer中处理每天四亿三千万记录的》这篇文章，应该对这个项目有一点了解。

13年年末，我没有参加公司的年会，和另外一个同事到了现场处理这个项目，终于在最后的一天把暴露的问题解决，而因为年尾的原因，大家对这些也没有深究，草草过了。这为接下来的苦难日子埋下了伏笔。

2月底，还在研究年初制定的高大上的研发计划的时候，现场告急！通过两天的邮件沟通之后发现并没有效果，现场要求越来越严厉，提出必须制定解决方案的计划，并且延期一天罚款1W——我们开始意识到这次的项目并不那么简单。2月底，出差到了现场，而此时现场，已乱的不行。

来到现场之后，但是已经是夜晚11点，约在酒店集合，现场实施人员噼里啪啦的说了一大堆，并跟项目经理在某些问题上产生了一些分歧（平时两人也是矛盾不断，现场实施人员根本就不鸟项目经理），我马上制止了。这样描述问题根本一点都没有效果，反而会让项目更为的混乱。我说，你作为实施人员，你只需管提出问题，但是要经项目经理确认，并以项目经理的意见为最终意见；然后你要一点一点的提出问题，然后按优先级排序，我按这个马上安排人员解决，争取一周完成。所幸，大家还是比较尊重我的意见，很快就都理清楚了各自的角色，并把当前最重要的问题提出来，进行了部署。深夜1点，和项目经理到酒店拜访了上包负责弱电这块的负责人，并和我们项目经理进行详谈，对整个项目有了更深入一层的理解

该项目是xx银行在xx省最大的数据中心项目
该项目关系尤为复杂，据说涉及到当地政府、总行、省分行，以及多个承包商运维厂家等等的各种利益关系
项目总共3栋大楼，但是分开给两个知名公司进行机房施工建设，聘任了第三方的项目管理公司对整个项目进行管理
我们公司本来业务是没有在该银行项目做的，该银行的数据中心一直由我们的竞争对手做。托了各种关系在竞争对手的手中拿下了两栋楼。而更为糟糕的是，项目管理公司之前一直和我们的竞争对手在其他项目保持着合作关系。
虽然是我们做两栋楼，但是三栋楼的集成却是交给我们的竞争对手，这意味着，我们在整个开发的过程中，将会以竞争对手作为主导，明显处于弱势地位

接下来就是一周的辛苦工作，每天都工作到凌晨两点、三点，然后拖着疲惫的身躯踩着泥泞又崎岖不平的道路，步行50分钟回到酒店，第二天9点又步行到工地上。经过整整一周的努力，我和另外一个同事在现场，连同后方的同事，终于把问题都解决掉——至少按我们的标准以及经过上包的测试。

再过一周以后，项管终于来了，带着竞争对手5、6个人，抱着笔记本，对着我们的系统一通的折磨，一旦发现其中有点不对，3、4个人马上群起围攻；测试流程根本不按操作习惯来，不管合理不合理，总之我操作你不能出错，有问题你必须给我个合理的解释，然后再把问题认认真真的记录在本子上，还很严肃的对你说，你这是个问题，我们不管结论，只管事实，由业主来评判；查个历史曲线，就拿起鼠标对着“查询”按钮一通的狂点，不把系统点出“未响应”誓不罢休！兄弟们当然不干了，于是当场就争吵了起来。我一听觉得这样不行，必须得出招才行，于是大声吼了一句，都TM的别吵了，听项管的行不，按项管的步骤一步步测试Ok不？项管一听，不出面不行了，于是重新把竞争对手的人员分配了一下，按着拟定的流程一步步测试。可惜最终在核对历史数据的过程中，发现上层的系统和下层的系统没有完全一致（系统是3级的系统，嵌入式->EMS->BMS)，数据也明显有点滞后，于是项管判定系统性能没有达标，不再继续往下去。当晚邮件直接发出来，说我们公司的系统不能满足要求，而且多次测试并不合格。业主一看，事情严重了，当即有意更换监控厂家。于是公司的总监、总经理、总经理助理、老板都到了现场，企图在商务关系上能够有所进展，无奈各处关系都不通，但是好歹，给我们争取了三天的时间。

接下来的三天，基本上是每天的睡觉时间都不超过4个小时，并且把各个软件的主力开发人员都叫到了现场，全力对系统进行优化改进，对涉及到的性能部分的代码，细到每个方法都进行了一些优化。在这样高强度的工作中，很多同事都已身心疲惫，甚至有时出现了一些较为低级的错误。于是，我开始鼓励大家要先休息好再继续工作，并在开发前，仔细与他们讨论每个步骤的实现方案的可能性，并把自己的想法与他们充分的交流，然后安排人员对一些可能的方案进行单元测试和性能测试，每个人上传的代码我都认真进行一遍审核，并与研发交流一些改进的看法。最终在封场测试前，做出了一个足以应付当前测试要求的临时版本，但是并没有经过完整的测试，怎么办？这时，大家都比较慌，都没有底气。这时我突然灵机一动，封场开始到次日早上的测试这部分的数据，其实是可以生成的，因为采用的都是模拟的随机数据，于是我让他们放心大胆的测试，封场部分的数据我来保证(当时没有严格封场，事实上还是有一根网线通往监控室)。当晚的测试修正了一些小的bug，最重要的是经过测试，实施人员都非常具有信心，不至于到时进行测试操作时心里没有底气。果然，在次日的测试中我们通过了项管长达14个小时的测试，最终他也不得不在测试报告中写上， 系统基本满足性能要求 ，截止到测试结束，我已经整整48小时没有合眼。但是经过此次测试，基本让我们在这个项目上保留了生存空间。接下来的几个月，我们又持续对系统进行了优化，最终达到无论项管和竞争对手再怎么折腾，也提不出任何性能上的问题，我们的测试人员和现场实施人员在现场也有了足够的底气。

在那天项管测试过程中，还有个小插曲至今让我回味。当时很多人都认为我们公司不可能通过接下来的测试的，竞争对手还在外面放话，说我们公司铁定是被赶出该项目的了。测试那天竞争对手的总经理助理也来到了现场，当时听这货在说话就知道他为人不咋地，说话处处针对我们公司。不巧，那天他兴致起来了，在跟做消防的厂家在那里晒他玩 flappy bird 的成绩，当时成绩玩到14吧，他说一般人玩都玩不过5。恰好我前一天刚从同事那里了解到这个游戏，并试玩了一会，知道这个游戏主要靠手感，平稳，心静。于是默默的跟他要了手机玩，刚开始还真没过5，于是他开始变本加厉的渲染这个游戏的变态。当然，到我这个境界，那是不可能受他影响的，默默的再玩两盘之后，不小心玩到了40+，这哥们脸色那个尴尬，接着马上又开始找借口说自己才第一天玩，然后装得很惊奇的看着我玩，原来是要把小鸟掉最下面才弹起的啊？对此，我只有呵呵了……结果那天的测试，我时不时问下这位仁兄的玩到了多少，结果他也不好像前两天一样到处炮轰我们，也算是为公司争取了一些优势！

经过这个项目，我们虽然发现了自身系统存在的诸多问题，但是都已经有了较好的应对的思路，下一步系统的重构也越来越清晰。更为可贵的是，我们团队得到了一次锤炼，无论从技术上还是从心里上，都有了长足的进步。

某银行网点监控

这个项目的难点在于，嵌入式采集器是一个μcLinux，只有8M的内存，没有MMU，所有的处理都要非常小心。而且硬件厂家是台湾的大公司，很难取得对方有效的支持，程序的应用非常简单，只有三个设备，但是量大，总共400多个点，出现问题的时间随机。在这种情况下，要想有效的解决问题，非常考验一个人的调试能力和问题解决能力。这个项目出现的问题是： 很少一部分系统在运行一段时间之后，无故死机并无法自动重启 。

一开始程序是当前嵌入式采集程序的阉割版，用的是C++，C++在没有MMU的系统中运行，着实是会存在一些问题，后面改用c重写，果然出现这种问题的个数大大减少，但是还是存在。经过公司多个技术骨干无法解决之后，老板把这个问题丢给了我（之前他自己来主抓，因为我不懂c++），好像在解决了上面某数据中心的问题之后，老板认为我是没有什么问题解决不了的了，对此我只有苦笑……

接手这个项目之后，马上确认了几点：

问题是否能够在公司重现，通过压力测试、调整采集评论、模拟现场环境变化
如果无法实现，是不是系统能够记录下相关的 core dump ，能够分析出导致系统死机的根本原因，这样能够确认是否我们的程序有问题，还是厂家的硬件及系统根本不支持7*24小时的工作（至少在某些场景下是存在问题的）
积极的与厂家再深入进行沟通，有必要可以把源代码发给厂家分析
把现场发生问题再进行深入的统计分析，以便发现一些问题
切忌做无谓的猜测工作，做各种版本的修改，以及盲目安排人员到现场蹲点开发——由于出现问题的地区之间跨度大，一天之内也只能勉强跑两个点

很快，得到了统计信息：

从上面这个统计大家应该可以看出这个问题排查难度之大，只有一个点是重复出现两次的，其他都是出现一次（debian嵌入式的不算在内），根本是毫无规律可言。而系统在公司运行3个月，一点异常都没有，根本无法重现，而受系统的限制， core dump 也是无法保存，现场调试更不可能了。剩余途径只能跟厂家继续沟通。

经过两周的沟通，厂家回复说 RD从现象和硬件上也无法复制问题和分析问题 ，于是只能把源码发给厂家分析。一周之后，厂家再次回复说，从源码上也没有找到任何的漏洞……于是我继续追问，为什么硬件看门狗不起作用？厂家做出如下回复：

xx使用CPU內建的watchdog, 預設由kernel餵狗, 當user開啟watchdog後, 轉由user application餵狗.Watchdog不起作用可能是user application仍然在運作

系統掛掉的原因可能有: 溫度, 電源, 外部訊號, 硬體故障, kernel或程式造成系統異常等等.如果系統已經沒反應, 有監測的機制可能也起不了作用, 從console記錄kernel output能幫助釐清問題.

uClinux并無MMU保護，固任何程式皆可動用另一程式或核心的記憶體位置。記憶體溢位或不正常存取皆可能導致其它process異常。

说了跟没说一样。WTD应该是在硬件层面的，为什么不能在硬件层面起作用？如果能够通过console口查看kernel output，那我们也不至于如此被动。但是看看上面的统计，当出现问题的到赶到现场，估计就过去几天了，而且现场出现通讯中断的问题还有可能是因为维护、断电等等其他原因造成的，不可能一发现中断就跑现场的，厂家给的解决思路根本毫无可行性。

于是继续在WTD的问题上与厂家进行沟通分析，但是因为厂家台湾的RD不愿意直接跟我们进行交流，都是通过大陆这边的实施工程师进行一些转发，这个过程非常的漫长，而且，我们对这个硬件了解并不深入，很多时候都必须按厂家回复的思路去考虑。

又反复沟通了一个多月，对厂家的系统有了进一步深入的了解，发现他们在硬件上确实是存在一些缺陷，于是，我直接给出了一个强硬的结论：

按道理说，系统异常之后，即使是kernel的异常，你们狗是在cpu中的，应该会起作用才对；现在的这种情况，应该就是你们硬件设计上存在一些缺陷导致的。我们后续还有上千个点需要实施，如果你们不认真对待这个问题，那么只有更换厂家了。

这时候，厂家回复了一些非常有用的信息：

关于watchdog的问题（我认为系统宕机的话，应用程序一定也不存在了，这个观点是错的）：

xx雖然是使用CPU的watchdog, 但之前為了避免flash read/write mode造成開機卡住的問題,

Reboot的動作改為由driver來啟動, 因此有可能因為kernel panic造成driver異常而無法將系統reboot.

如果你们的程式不會寫資料到flash, 我們可以提供由CPU來做watchdog reboot的CV firmware來排除driver異常的情況 .

另外, 即使kernel panic, user application仍然有可能繼續運作.

也就是說, kernel panic不是一定會導致user application無法運作而啟動watchdog reboot.

節錄自http://en.wikipedia.org/wiki/Kernel_panic.

通过这么一段话，我已经可以肯定厂家现有版本的系统给出的是软狗，而不是硬狗，目前的WTD还是受限于系统的健康状况。于是找厂家要来了这个用CPU做WTD的 firmware ，经过长达两个月的现场测试，基本没有出现系统挂掉无法重启的情况。

这个项目的顺利解决，让我对软件调试的一些实践和理论都有了进一步的认识，并坚定了我对软件调试、问题排查的一些设想。而在这个过程中，我同样发现一个人的沟通能力以及基础知识能力将会带来多大的帮助！很多时候，我们的问题解决起来非常的简单，但是由于现场人员与研发人员的沟通障碍以及各自的知识水平的差距，会让问题看起来非常复杂甚至无法解决。

产品研发

受限于研发人员的数量，公司大量项目的运维支持，以及公司对产品的定位，整个年度，真正能够有时间进行产品研发的，不超过40%的时间。不过即使这样，在产品方面还是有不少的进步：

经过产品经理的一番设计，系统的用户体验有了不少的提升，而我们复杂的报警机制也更为的清晰
经过某数据中心的开发，在系统的性能上有重大的改进，而且通过一些技巧，让整个系统的使用较为流畅，可以参考我之前的文章《从四分钟到两秒——谈谈客户端性能优化的一些最佳实践》
客户端程序终于采用了MVVM模式进行了改写，这意味着不但在程序的结构上较为清晰，而且在处理界面样式，页面定制方面有了更强的能力
服务端通过引入bundle的机制，可以很方便的扩展各种线程任务，不但开发起来容易测试，而且在满足定制的时候与现有系统没有太大的关系，大大增强了系统的灵活性。

团队建设

2014年由于各种原因，其实甚少进行团队建设，但是我确定了没有特别情况绝不加班，上班时间稍微弹性的原则，并统一了代码的规范和管理，加强文档知识库的建立，基本上让大家干活还是比较规律，强度适中的。当然，由于绩效不太明确，大家不时还是有懈怠的情况，这个在下一年有待加强！

绩效体系

关于绩效，我始终是认为，这个东西有利有弊。无论是考过程还是考目标，并不能完全反应一个人的实际工作能力。假设我们以目标为导向，那么是否员工在指定时间内完成任务，就一定优秀吗？其他领域我不太了解，但是从研发的角度来讲，这个考量的指标，未必正确。假设我们要求一个月完成一个产品，但是这个产品是一次性的还好，我们也不用管代码的质量，反正能够符合合同要求，能够顺利通过验收即可；但是，如果这个产品是公司生存的基本，考虑起后续的扩展和维护，有可能带来更多的成本，那么你是愿意选择花费更多的时间来给程序员做出更稳定更易扩展更易维护的产品呢，还是只是要求程序员只需达到目标即可。

当然，有些人认为，只要我们在考量的指标中加上一些代码质量的指标即可。但是，这个指标怎么定本身就是一个大的问题。大部分的程序员都会认为自己写的代码才是牛逼的代码，他们总是这么的自信，如果你指定了一个标准，那么就相当于你到任何一个技术群组放上 C#是世界上最好的语言 一样，会得到更多的反驳；另外，一旦你制定了量化的指标，那么大部分人都会想着先完成指标，而不是考虑花更多的时间去把程序做得完美，因为指标关系了收入。

如果完全不考虑目标和绩效，那么也是不可行的。人都是有懈怠的心里，一旦缺少监管和目标，就如放任自流的洪水，会造成更多不可预估的损失。目前从我的角度来考虑，很多时候，更多的时候需要人治，需要研发的领导人能够有控场的能力，在定量与定性之间进行一定的平衡。另外考虑人的心里，大多的时候我们应该多进行鼓励而非打击。

最后，我们需要认识到， 只有一个人有兴趣投入他从事的工作，并从中发现更多的乐趣，那样才会有更多的动力去把事情干好 。比如，我们可以适当把员工写博客、开源等活动加入到绩效中，通过社会的一些认可，让程序猿在工作中又得到心理上的满足；而让程序猿有更多自主的权力去选择框架，研究架构，并乐于分享，也同样会让程序猿工作起来更有活力。

质量体系

关于测试部分，我从进入公司一年之后，就已经深刻意识到这个公司在这方面的缺失，当时也引入了包括 BugTracker.NET 等测试软件，但是一直得不到老板的重视。到某数据中心项目之后，老板也开始深入认识到相关的问题，开始加大在这方面的投入，包括硬件和测试人员。这个时候，通过一段时间的选择，采用了国内开源的禅道管理系统，该系统确实做得不错，当然，还有很多可以改进的地方。不过，在很大一部分，我认为这个系统较为符合国人的使用习惯。

而通过测试系统的引入，测试和研发之间也有了联系的纽带，配合起来也不至于有太多的沟通障碍。当然，要想真正把公司的质量体系建立起来，制定更为严密的标准，以及得到公司领导们的认可，还是需要一定的时间。

统一管理文档和代码

当然SVN源码管理器一直都在用，但是大家使用起来并不规范，而且因为产品线较多，大部分人都是各自为政。年初便提出了把所有的代码放在同一的服务器管理，并且要求定期提交代码，把日志详细写清楚。经过一段时间的培训，确实有了一点进步。

关于源码，我认为日志、注释有时比代码更为重要。只要从事过几年研发活动的人应该都比较清楚，单单代码，有时我们根本是无法理解的。很多人并不认可这个。我们考虑下在你研发的过程中，是否存在一些情况，你不得不舍弃一些公认的正确的解决方案，而采取一些较为极端的办法来处理？这种情况，如果没有特别的注释和日志提示，后面的人看起来肯定是莫名其妙的，甚至几个月之后你自己也看不懂！

文档也是公司比较缺失的一环。我跟同事们说这个事的时候，我就说，为什么你们老是说没有时间，没错，你们是不停的在帮助现场的同事解决问题，但是你们到底有没有想过，你们为什么一直都在做这个事情。是的，不排除我们现场确实会有很多的未知的问题，但是，大部分的问题，都是我们之前已经给某个同事解决过的了，对于这种情况，难道我们不会把这个解决方案记录下来，现场有问题的时候让他们先看文档吗？我之前也是负责公司的产品研发，我从来都不会像你们这么累，为什么，因为我一遇到问题，我就把它记录下来，并把详细的分析和解决方案都写到文档中，谁问我问题，我都是让他们看文档，他们看不懂，那我说你继续看。看多几次，他们总会懂的，而且，从这个详细的分析中，他们也对系统运行的原理有了更深刻的了解，感觉到自己学到了东西，以后遇到问题，也更具有了分析的能力。 我对你们最不满意的地方就是，现场有了问题就说，来，我给你远程解决！ 这种做法，不但你自己累，而且你也害了现场的同时，他们将丧失一次技术提升的机会！

经过一段时间的强制要求，初步建立的知识库，而同事们不断处理现场问题的现象也有所减少，相信通过接下来一两年的努力，我们开发应该会更加的轻松。

团队成员的成长

很高兴在2013年中招的两个高级程序员已经能够独立承担起客户端和集中服务端的架构设计和开发工作，很多在1年多以前定下的开发计划以及对系统架构的设想，他们也已经帮忙开始实现。虽然这是一个漫长的过程，但是能够在1年左右把原有系统接手，并且完成了众多项目的运维支持，并逐步对系统进行改善，到如今可以开始对原有不合理的地方进行重构调整，我觉得这是非常大的一个进步，而这两位在完全承担相应的开发任务之后，同时也能让我在接下来的时间里更多的思考一些规划的问题。

个人的一些发展

通过在博客园分享工作中遇到的问题以及对一些开发中的体悟，跟大家有了很好的互动交流，这个过程中也得到了很多人的建议，认识了不少的朋友，非常开心。因为对博文质量的严格把关，也得到了很多人的推荐，成功获得了 推荐博客 的荣誉。来年会继续在博客园分享一些技术知识以及生活的感悟，因为博客园的 markdown 编辑器的支持以及样式定制做的真的很棒！
因为已经逐渐把具体的研发工作下放，自己主要负责研究团队建设和系统的架构方向，有了更多一点的时间，因此也花了很多时间在解决研发过程中遇到的一些疑难问题，通过观察分析、读书、学习一些高级的工具，在系统调试方面有了很大的进步：能够熟练使用了windbg解决很多无法在开发环境无法重现的问题，而且很多时候，在只看程序日志、系统日志等的条件下就能把问题的根本原因找出来
采用Excel作为计划工具，取得了不错的效果《用Excel做出比肩任务管理软件的操作技巧》
每天上班前把当天要做的事情列出来，有新的任务过来又放进去，然后根据上面的任务排序，每天确保完成上述最重要最紧急的事情，通过这种方法可以很好的把事情安排处理，又不至于丢掉事情。每周周末还可以汇总总结，分析得失，做事比较有条理
完成了CMMI3的一次培训以及老外的访谈。虽然这种事情不能较真，但是通过认真阅读CMMI3项目经理部分的内容，以及进行深入理解和背诵，掌握了较为完善和详细的项目管理方法，对于培养一个人的思维还是比较有意义的，也算是今年的收获之一
重新把《CLR Via C#》读了一遍，同时又阅读了《Microsoft.SQL.Server.2005技术内幕》系列，以及《Dreaming Code》等书籍，对很多技术观点和理论有了进一步的理解

家庭

2014年最重要最高兴的事情就是宝贝女儿的诞生，2014年是马年，宝宝又姓马，也算是比较有意思的一件事情，呵呵……

2015年展望

经历了2014年的风风雨雨，也到了年关，我们可以展望一下接下来的2015，某人也说了， “梦想还是要有的，万一实现了呢” 。如果我们连梦想的勇气都没有，那么你接下来的路，可能会比较容易感到彷徨。

星星之火可以燎原

2014年虽然艰辛的一年，以至于我们都不愿意回首那段日子，但是恰恰又是我们浴火重生的一年，虽然我们在业绩上没有什么体现，但是经过这么艰苦的一役，我们都顶住了，在最艰难的时候没有一个人退缩，这就像一块生铁百炼终成钢：

直接竞争对手真刀实枪的对着干，非但没有被干趴下，反而顶住了冲击，提升了系统性能，在竞争对手的眼皮底下把系统做得对方无话可说，面对着数倍于我们的研发人员的竞争对手，我们也可以直起腰板子说，我们的系统是可以经受考验的，是没有问题的
在开发过程中遇到了众多的性能问题，大家伙不断的寻找解决办法，积累了很多的经验，无论在测试上、开发上都有了长足的进步，也同时提出了很多先进的架构思想，相信在接下来的一两年内，如果有足够的资源支持，在机房监控领域做到国内第一完全不是问题
在高强度的开发中，同事们没有一个跟我抱怨说苦说累，都是憋着一股子劲，要顶住压力，要把系统做好，要让竞争对手无话可说，而我们最终做到了。不但在性能方面让人无话可说，在系统的可用性，系统响应速度，界面的美观和友好，在多个方面都比竞争对手要强，以至于竞争对手根本就不敢让我们照着他们测试我们的标准去测试他们

年底，老板跟我说，明年我们的目标是超越竞争对手，做到第一。多年的老二的位置，让老板做出如此设想不足为奇。但是我却知道，要超越，还有很多事情要做，商务上的，工程上的，质量体系上的，还有公司的激励制度绩效体制，以及在整个行业内的布局。这不是简简单单的一句话。

但是，从技术的角度来说，我可以大胆的保证，只要给我足够的支持，完全没有问题。虽然我们还有很多的问题，但是，我们这个团队已经进行了锤炼，已经有足够的能力去颠覆。我们成功的“突围”并走完了“长征”，这是一支有无限生命力的团队了！