这两个月是我在新公司A努力奋斗的2个月，从工作绩效上来说，第一个月自我评价70分，主要是因为与上司前端Team的Lead B不和耽误了几天，第二个月自评90，自认为越来越进入状态，积累了很多经验如满载的火箭正欲分享。在一个多月的时候老板Z也表示了他的满意，并建议我主动Drive一些事情，还在会议中表扬了我积极主动的分享精神。但接近2个月试用期结束时，突如其来始料未及的来自别人的评价是6：1要淘汰我。

离开已近一个月，我想再次总结一下这段经历：

因为上一家单位的人事变动，以及跳槽至公司A的最好的朋友C的强力推荐，我也跳至公司A，在面试时也确实发现A公司用的技术都很先进，特别是有一个后台高手给我极深的印象，我于5月28日正式上班了。

进来之后也确实遇到了巨大的学习压力，新的前端MVC框架E是一个非常重量级的工具，我足足用了一个多星期才比较全面的了解了它的概况，并且发现了很多当前项目中的问题，于是在接下来的2周里，边做实际的功能，边大量的奋笔疾书，总结了问题，提出了建议。主要包括3方面：

1. 工具各特性的设计意图和使用方式

最重大的问题有2方面，一是路由与数据管理特性没有被用到，二是未建立标准代码库以示例方式展示各特性的最佳用法。

对比B的回答是，他不明白我为什么把路由和数据管理看的这么重要（可判断出他对Design的认知程度），他认为建立的示例应该是复杂的（可判断出他对技术方向上的把握问题）

我认为路由与数据管理E的两条腿，地位极其重要，能够极大提高可维护性。如不尽快把这2项内容增加进来，我们将在错误的道路上面越走越远（我提出过重构的建议，无人重视）。

示例应该是简单的，越简单越能表示出重点在哪里。之所以项目中存在各种各样的奇怪问题，在我看来，乃是实际用法与其推荐用法不同，造成生命周期与标准用法时有不同。釜底抽薪之计是赶快纠正错误用法（有时能Work，有时不能），研究正确用法。

2. 开发的价值观和方法论

公司号称使用敏捷开发方法，在我看来，只能打不及格。

首先缺乏文档，他们认为敏捷开发应该是用口头表达来代替文档来达到高效率，所以非常的轻视书面的东西。此乃极大误解，口头代替文档的后果正是低效率。精髓是文档要小，不必讲求特定的格式，求的是里面每一句话都是有用的，都是为了解决实际问题而存在的。这种理解上的不同可以从后面他们对我的评价里看出。

第二是迭代会议的形式主义。迭代之前，应该把数据准备好，在我看来，最重要的数据应该是Case数，而实际上我们的会议仅仅是大略的演示一下做好的功能，因为知道脆弱的漏洞百出，所以点任何一个按钮都很心虚，甚至不愿意点击，搞的大家哈哈大笑，气氛很热烈，其实很危险，不愿意把问题暴露出来，不敢正视问题，与敏捷精神背道而驰。

第三敏捷开发也是测试驱动开发，团队并未这样做，仍然是先开发后测试，这也罢了，最关键问题在于开发人员没有在开发前在测试用例上下功夫。我在开发前都把测试用例搞定了，用例来自于需求，包括书面写的和与项目经理沟通取得的。之后用例就是我的需求，我要做的仅仅是写代码让用例通过。

第四进度估计极度不准，原因是未使用数字来代表工作量，敏捷开发书籍里面使用任务的点数来表示工作量，我认为用Case数代表更实用，只要Case的粒度控制的比较平均，那误差就不会大。

第五遵循计划胜过应对变化，与敏捷精神相反。只是被动的加班重复劳动，从不检讨和改变自己的工作方法。问如何提高效率，想了半天，答曰加班。应想方设法让每个人做适合他做的和他喜欢做的事，让人有成就感，感到快乐。不要被动的看短期目标，而要时时刻刻关注长期进度，当一项改变对长期目标有促进作用时，必要时可牺牲短期目标。

3. UI设计的问题与建议

最有问题的是人，设计师乃实习生也。设计出来的效果图对比度低，层次不明。我给出例子和建议。

交互设计存在的最大问题是支持双击，此乃外行人的操作习惯，且用户不知道是否可以双击或双击之后产生的效果是什么。我亦给出文档证据。

在接近一个月的时候，老板看我有很多总结性和建议性的邮件，所以安排我主持一个分享会议。会议上我的任何一句话都被B所针对，在这之前的工作时间，我只是觉得B喜欢抬杠。会议很失败，我意识到我被针对了，下午的时候我做了强烈的思想斗争，也写了个示弱的邮件，但第二天，我还是提出了辞职，因为我觉得再进行下去我无快乐可言，我被压制了。现在想想，B有人品问题，它的眼光没有放在公司发展层面，而在自己的私利，或许我的表现威胁到他了。

然后老板找我谈话，希望通过深度会谈的方式解决问题，在这次老板主持的会议上，我们选了一个显而易见的问题（变量的命名是否要看它是普通变量还是类还是命名空间而不同），我费了九牛二虎之力获得了90%的胜利，因另一人J仍存不同看法。下班的路上我对朋友C说，这次会谈并未解决实际问题，我和B仍是互相不服。

但是之后B的表现令我感动，他不笑不说话，与原来的态度呈180度大转弯，我以为他真心转变了，不知有诈，我也一直以勤奋与仗义直言及着眼于公司长远发展的方式继续工作。

转眼到了试用期评审的时候了，我发了第二个月的自评和打分（90分），踌躇满志。第二天收到反馈6：1。反馈主要集中于3方面：

1. 沟通技巧

普遍反应我的面对面沟通不够。我的辩护是我把重点放在工作上，而非人际关系上，但我不承认对于我的本职工作口头沟通不够，我认为足够了。

2. 产出速度

认为我交货时间超出计划时间。我的辩护是我们的目标是短期的还是长期的，从短期看我确实慢了，但我非常重视质量与方法，长期来看，只要我的方法得以贯彻，难度会下降，速度会上升如果继续保持原路线不变，难度会上升，速度会下降。我慢的原因是我探索了新的更好的方法，为何忽略好方法本身的产出，自身能力得到了提升算不算产出，有些人在重复自己，而我坚持DRY，这算不算间接产出。

3. 学习方法

认为我不从其他人身上学，而是自学。我入门时离不开他人的帮助，我也问了啊，但是我入门之后就发现了很多问题，这些问题我也问了，没人能回答得了啊，我只有自学。如果我自学学懂了，我为什么还要问其他人呢，而且我学的成果在邮件里面都写出来了，问题反而在于别人不从我的身上学才对啊。有几个人写自己的总结了，更无一人的质量与数量能与我相比。

发完辩护邮件后，我决意辞职了或者说不得不离开。老板确实挺好，安慰了我几句，特别有一句是你决定走了，我尊重你的选择，我回答说这是大家的意见，他说不，是你自己决定的。现在想起来老板是有与其他人不同的看法的，只是如果我留下，所有人都会没面子，那6个人一定认为老板不尊重他们的意见，老板可能会很难做，我自己也没脸在被那么多人反对的情况下留下来。

总之一句话，一个人在公司里待的时间长短取决于这个人与公司整体价值观的一致程度。我认为应该长远发展作为头等大事，如果每个人都有这样的思想，那么就会顶住暂时的压力，做很多尝试去获得各种任务的最佳实现方法，而不是重复自己或别人以前的旧方法，这样即使短暂的延期也会换来下一任务的高效率。公司领导应大力支持这种勇于开拓和创新的人。现实情况却不然，我只能选离开。

现在我正继续学习和实践E框架的相关知识，我自信现在所掌握的超过他们所有人，只为证明自己。