下项目之后 通常来说，下项目总是一件比较高兴的事（大部分团队还会一起吃个饭庆祝一下）。这里面既有终于摆脱了厌烦了的技术栈的解脱感，也有对新项目/新技术的向往，可能还有些在旧项目中做的不太满意的事情，可以在新项目重头再来的期望。
可能有点老生常谈了，不过这里我想说说下项目后如何做总结的事儿。对上一个项目的总结，其重要程度可能要远远超过你的想象。我是在2014年初，在一个客户现场的一个会议室和一位同事谈我的Annual Review的时候，才意识到这个问题的。
Annual Review会回顾我们过去一年的项目经历，有哪些方面的进步，同时也会展望未来的计划。但是这其中有几个问题：第一个问题是以年为单位的Review粒度太粗，有些经历已经淡忘，也有人可能一年会换好几个项目；第二个问题是对于大多数人来说，展望未来是一件比较容易的事儿，每个人或多或少都会有一些计划（比如学会前端的某些技术，尝试一些DevOps方面的工作，或者了解一下大数据等等）；但是对于回顾过去，我们其实并不擅长；最后一个问题是即使做了回顾，回顾的层次非常浅，作用并不大。
说到回顾过去，更多时候我们关注的是从项目中学到了什么样的新技术，这种浅层次的回忆和记流水帐是容易的，但是对于我们的成长并不会有太大的收益。真正会为帮助我们在将来的项目中做决策，甚至会影响我们学习效率，解决问题能力的是：深度回顾。
深度回顾练习 深度回顾可以帮助我们梳理知识，将实际的案例归纳总结为实际可用的知识。要获得这种能力，需要做一些针对性的练习。根据我自己的经验，这些练习大约可以归为3类，难度依次增加。
项目上的直接经验 这个练习比较简单，就是问问自己：“我在项目里学到了什么？”
要回答这个问题是很容易的，项目中用到的技术如模板引擎，前端框架，自动化测试套件，build工具等等，总结这些内容的过程，对于我们的PS来说都是“自动”发生的，几乎不需要付出额外的efforts。这些回顾、总结可以帮助我们成为一个“熟手”，即当下一次遇到相同或者类似的场景时，我们可以很容易直接应用这些经验。
更进一步，再问问自己在项目中的其他收获。比如客户关系处理的经历，团队建设的经验，甚至是写英文邮件的技巧等等方面，看看做的有没有问题，有没有提升的可能？
人类最牛逼的技能是：可以审视自己的行为。也就是站在旁观者的角度来看待自己的行为，随波逐流式的在各种琐事中沉浮事实上无法得到提升的。可以经常性的将自己置身事外，以一个旁观者的角度来审视自己做过的事情。并从中找出做得好的地方和不足的地方，然后自己给过去的自己一些建议，并记录下来。这些刻意的练习会帮助你养成回顾，从经验中学习的习惯，而这个习惯正是一个人区别于另一个人的绝对“捷径”。
练习讲故事 这个练习是，假想你遇到了一个同一个办公室的同事，他对你刚做完的这个项目很感兴趣，你来给他描述一下这个项目。描述的内容包括但不限于这些方面：
项目的背景介绍 该项目以何种方式，为那些用户，带来了什么样的价值？（business model是什么） 该项目的实际用户数量是什么级别？ 项目的部署，运维是如何操作的？ 项目的监控是怎样做的？ 当遇到系统故障，项目组是如何反应的？ 能把一件事情描述清楚是一件非常了不起的能力。我见过很多的程序员，写起代码来好不含糊，但是却很难将一件简单的事情讲清楚。我们当然要提防那些夸夸其谈，华而不实的“嘴子”，但是也至少得要求自己做到清晰，准确的将自己经历过的事情描述清楚。
描述项目背景需要至少需要交代这样一些内容：客户是谁，最终的消费者是谁，项目以何种方式运作（离岸交付，本地，onsite，咨询，培训等），我们帮助客户为消费者带来了什么样的价值。客户的商业模式是什么，在我们周围有哪些类似的项目。
即使在技术方面，也有很多被Dev忽略掉的信息，比如项目在产品环境中如何部署，数据中心建在何处，客户如何运维、监控等。实际的发布周期如何，发布流程如何，客户的内部论坛上都会有很多的这样的信息，但是很少有人关注。从一个项目roll off的时候，这些信息即使做不到了若指掌，至少也能描述清楚，否则难免有些“入宝山而空回”的遗憾。
回顾项目中的挑战 从简单的CRUD系统，到复杂的分布式计算，从企业内部的管理系统，到支持高并发、要求实时处理的交易平台，每个项目都会遇到一些挑战。除了技术上的挑战之外，还有陈旧而无文档的代码库，复杂的业务场景，不配和的客户接口人等等。挑战无处不在，那么作为项目中的一员，你是如何应对这些挑战的呢？最后又是如何解决的？
现实世界是一个充满了trade off的世界，我们需要做种种权衡，代码测试覆盖率和交付压力，性能和客户能负担的机器实例数量，框架A和框架B的优劣等等。我们在采取这个方案的时候，只能舍弃其他方案，由于谁也无法在事先准确预料采取某个方案一定是对的，那么在一个失败的方案背后，其实也是一个很好的教训，至少可以为未来的决策提供帮助。
遇到的最大的挑战是什么？ 这个挑战是如何被解决的？ 如果有机会重做，你会如何考虑？ 其他练习 这里列出了一些我常用的，辅助性的练习。它们可以帮助你更好的梳理项目上学到的技能、知识，并且转换成你自己的知识。这些练习未必一定要等到项目结束之后才做，事实上它们都可以应用在日常的工作中。
记笔记 写博客 在办公室内演讲 去社区贡献话题 很多人都会记笔记，但只有一小部分的人在记录之后会持续翻阅。很多人会使用Evernote/印象笔记之类的工具将一些临时的想法，问题的思路，知识点的细节等记录下来，但是仅仅记录是不够的，笔记需要不断的检索、整理、提炼、修正、总结和归纳。在不断的加工之后，这些笔记可能会得到沉淀，并升华形成一些更有意义的内容（比如个人博客，或者可以发表到InfoQ/IBM DeveloperWorks平台上的文章等）。
除了记录笔记之外，写博客也是一种很好的总结形式。通过将素材不断充实、整理、完善，最终形成一个可供别人直接消费的文章，不但可以锻炼到总结能力，还可以很好的提升表达能力，而且可以帮助你将已有的知识体系化。如果你的博客写成了系列，也很容易通过Gitbook等将其发布为一本电子书，从而影响更多人（说不定还可以赚点咖啡钱）。
写博客/电子书，终究是书面形式的。事实上一个人可以很容易的通过文字将自己的实际情况隐藏起来。举个极端的例子：如果有足够的动机（比如公司的KPI要求），即使不熟悉某种语言/工具，仅仅通过Google，一个人也可以通过这种“作弊”的方式写出一篇“专家级”的文章。但是对于演讲这种面对面的形式，则基本上无法作弊，从而也更具有挑战性。另一方面，对于一个新的知识、技能，自己掌握是一回事儿，要讲出来让别人也能听懂，并从中收益，则完全是另外一回事儿。作为咨询师，语言表达（包括书面和演讲）能力的重要性勿庸赘言。整理知识，并归纳为演讲，会帮助你将体系化后的知识更好的表达出来。
在办公室里讲session有一定的挑战，但受众毕竟是“自己人”，压力相对会小一些（比如在ThoughtWorks，我们非常鼓励员工为其他人讲session，具体可以参看我的这篇文章）。要在社区中演讲则要面临更大的挑战，通过将话题不断锤炼，不断归纳，最终形成可以在社区分享的话题，则不但可以提高内容的质量，也可以更好的锻炼表达能力和临场应变能力。
不过归根结底，这些活动的重要输入还是对之前项目中的知识、经历的深度回顾。
总结 从项目上下来之后，需要深入思考并总结之前的经验，这种深入思考会帮助你建立比较完整的知识体系，也可以让你在下一项目中更加得心应手，举一反三。如果只是蜻蜓点水般的“经历”了若干个项目，而不进行深入的总结和思考，相当于把相同的项目用不同的技术栈做了很多遍一样，那和我们平时所痛恨的重复代码又有什么不同呢？
2015年总结 2015年在不经意间就过去了。又是一年。按照惯例，我会在年末回顾一下这一年自己的进步，收获以及一些感慨（牢骚）。然后对来年做一点展望，看看什么地方可以做的更好。
项目经历 今年基本上经历了三个项目，性质也都不一样：
海外交付 国内交付 国内售前 3月前的项目以及没有什么印象了，依稀觉得项目上的所有实践都是“错”的，可能由于太过与荒诞，所以大脑自行将这段抹去了。
4月到6月在深圳的一个国内交付项目上，交付压力还挺大。不过也是在这个项目上，非常直接的体会到了其他角色的不容易。无论是客户的接口人，客户的项目经理，客户的领导，我们的开发，我们的UX，项目经理，还有交付的lead，所有人都不容易。
《项目经理是大傻逼吗》这篇文章就是为了纪念这个项目，或者说是被这个项目驱动出来的。
6月之后回到办公室，在一个海外交付项目上。说是一个项目，中间其实换了6，7个不同的工作内容（出钱的是同一个客户而已）。总之一片混乱，所幸我们在10月前就结束了和这个客户的合作。这个项目事实上除了锻炼项目上人的耐心外，基本毫无益处。甚至对于很多毕业生来说，是深刻的伤害。
10月之后，我难得的在beach上待了下来，而且一待就是3个月。中间在一个联合国的项目上工作了2周，然后就是为另外一个咨询项目准备了几周方案。当然，闲是不可能闲着的。在beach上，如果不出意外，肯定会比项目上更忙！比如打黑工啊，内部什么系统的改进啊，总是有好多事情。
由于有一些本地的项目机会，而我又不在具体项目上，就来做这个售前的角色。帮助客户梳理需求，分析问题，设计方案，计算工作量等等。但是这个过程往往循环往复，一轮接着一轮，在合同确认之前，需要很多次讨论和交流。这应该不会是我自己的一个方向，在项目上写代码，培养新人，分享自己的学习所得，和他人一起进步，是我自己比较有热情的方向。
技术方面 在海外交付项目上，乏善足陈，项目中用到的也是非常厚重，已经至少10年的技术。通常来看，这样的大组织，没有人对要做的事情真正关心。好不容易遇到一个特别靠谱的人，结果我们的项目又结束了。国内项目上倒是有很多有意思的东西：
如何在前端代码中很好的使用MVC 流畅的前端开发模式 如何做前端的测试 上面这三点，我希望可以找时间整理出一本电子书，可以让没有工程级做过项目的前端工程师能有一个参考。
另一方面，由于项目的压力，和项目人员的特殊性（开发就俩人，一个做前端，一个做后端，要集成就pair一下），所以很多实践都没有应用，比如结对，自动化测试等，做的都不够好。虽然我们很推崇，强调CI/CD的实践，但是当和客户的后端系统集成时，就各种悲剧。
联合国的项目上，技术栈比较新颖，上一家的技术人员使用了他们当时能找到的所有酷炫的新技术，并用在了项目中，然后他们公司被收购。留给我们的在今年来看，依然是比较新的：
React Reflux ES6 mocha/chai 而在国内售前，基本上没有写过一行代码，更多是更高层次（高不一定是好哦）的工作。确认需求，估算工作量，确定方案（前后端测试，开发方式，部署策略，自动化测试等等）。
2016年，我希望可以多学习一些具体的编程知识，比如：
mongodb 数据分析，数据挖掘 容器技术如docker 书籍 今年读了一些技术方面的书，更多的则是一些非技术类的。《自私的基因》是在2012年11月去墨尔本时，在广州白云机场买的，路上10个小时，读了几页。直到2015年才又拿起来，读了两章左右，基本上颠覆了我之前建立的对“进化论”的认识。
另外读了一些科普类的，比如《哲学家在干了些什么》，《上帝掷骰子吗》等，又扫了一次盲。再就是一些佛教相关的书籍，《西藏生死书》，《能断：金刚经》，《正见》等，人生观和价值观得到了刷新。
技术类的，主要是一些与具体技术关系不太大的，比如《恰如其分的软件架构》，《企业级应用架构模式》，《发布！》，《实例化需求》，《持续发布》之类。
虽然竣工于2014年，但是我的一本著作和一本译作都是2015年才发布出来，那就算作2015年的吧：
《轻量级Web应用开发》 《7周7Web框架》 社区 今年在深圳的时候，有幸和ThoughtWorks的首席科学家马丁.福勒在同一次活动中作为讲师。
回到西安之后，在本地社区中还讲过一个前端工程师需要掌握的技能列表的session
2016年希望可以做一些更加深入的topic，以及一些更有意思，可以帮助到更多已经在路上的工程师们。
People Development 这个不知道如何翻译了，但是确实做了一些具体的事情：
给我的sponsee们安排了读书会 组织了一次《编写可维护的JavaScript》的workshop 组织sponsee来做一个side project 组织《Web开发实战》的workshop 我自己总结出来了一套组织workshop的方式，其实很简单：
做好计划，做好课表，做好课件 找学员，同时从学员里找出有基础，而且有意愿接着run workshop的人 讲课，收集feedback，并改进课表，课件 将run workshop的任务传递给那些有基础，而且有意愿接着run workshop的人 2016年希望可以找到更多的候选人，并帮助他们成为更好的讲师，教练。...
一些背景故事 坊间流传着很多关于PM（Project Manager，项目经理）的笑话，在这些不无刻薄的笑话中，PM往往被描述成一个盲目的承诺客户需求变更，不了解实际情况而又喜欢指手画脚的专门坑开发的家伙。毋庸置疑，这些笑话当然是那些聪明的开发发明的（不过你得承认，在很多团队，这些笑话其实是实实在在每天都在发生着的）。
在智力工作中，对于开发的实际进度，开发速率等问题，具体着手做的人永远比在背后指手画脚的人更有发言权。软件开发正是一项智力活动，优秀的软件无法通过人力的堆积而产生。一个关于PM的经典的讽刺是：PM就是那些指望着9个女人在1个月内生出1个小孩的二货。从传统的意义上来说，这个笑话还真是一针见血。
我记得在加入ThoughtWorks不久的时候，私底下经常听到这种论调：PM基本就是项目上被人鄙视（当然大家不会表现的那么明显就是了）的角色，基本上负责团队建设去哪儿这种杂事儿就行了，团队的其他人员可以高度自治，并不需要被管理，项目就会如预期般按时交付。
这些论调在某些情况下可能是对的。但是如果在国内项目的这个上下文里，没有一个专业的PM来协助项目，控制需求，划定项目范围，与客户谈判等等，没有任何一个项目是可以真正成功交付的，指望高度自治的开发们来完成项目？咱们还是现实一些吧。
一个悲剧的事实是，开发人员往往都恃才傲物，有时还会带着一幅要来拯救世界的心态来做项目，这事实上和客户的期望，以及PM的期望是有很大出入的。在项目启动之初，PM会面临重重困难：首先，团队里的每个人都不好管，而且每个人都认为自己不需要被管理（当然这种想法在大部分时候都是错误的）；其次，PM需要和客户快速建立信任，并推动项目进入正轨；最后，往往留给PM自己的时间也非常有限，他们也需要学习大量的项目相关的上下文（业务上下文，人员关系，资源协调等）。
除了催进度，PM平时还干点啥？ 本质上开说，PM其实就是一个轮询器：识别所有的项目风险，然后不断跟进。项目风险可能是技术风险，比如某个技术上压根搞不定的问题。也可能资源风险，比如人手不够，或者开发者很多，但是没有足够的设计师协助，这些风险都会导致项目无法按照时间交付。一个客观事实是，所有项目都会变化，做完售前到需求分析结束之后，需求可能会发生巨大变化，如果还按照报价来做项目很可能会亏本。
PM的一个重要职责就是在项目之初将项目范围定下来，这个范围的划分非常依赖经验：划得少了团队得天天加班，累得跟狗一样，然后才能保证交付（据我的经验，虽然项目一般不会天天加班，但是总会有一些攻关，打补丁的事儿，最后还是会累成狗），划得多了客户不买单，意思是就这个小功能你要做两个月，绝对不行。PM需要协调这些不一致，还需要和销售，客户等方面不断谈判，写方案，排计划，简而言之，也是累跟狗一样（而且潜在的，还可能被那些天真幼稚的开发坑 — 开发经常会高估自己的开发速度，反正我还没遇到过低估的，你见过吗？）。
我们每天看到的PM干的最多的事情就是：元芳，那个接口怎么样了？什么时候能做完，有什么blocker？李柯，昨天说的代理的事情怎么样了？小波，高保真什么时候出？何方，我们周三下午要showcase，麻烦你订一下会议室吧……
除了写代码，Dev平时还干点啥？ 如果脱离开PM的角度，做为一个孤傲的开发，时常会觉得PM为什么老是问我进度，是不是怀疑我的能力？为什么监视我的工作？相信我，其实他才不想监视你。但是你设想一下：如果你不参与代码编写，每天只是看旁边的哥们写，你如何知道他实际的进度呢？而且众所周知，开发很难准确的更新自己的工作进度，而且遇到问题也很少积极主动的报告，通常都会自己埋头尝试解决。那么，轮询显然是一种成本最低，反馈最快的方法。
不主动更新进度是另外一个大问题，不过这个得单独说。关于更新进度，典型的的场景是：早上站会的时候，开发目光呆滞的盯着某个卡片，努力回忆其中的验收条件以及自己的当前进度，如果恰好脑海中的技术细节和卡片的描述在某个点上匹配了，他会迅速的告诉你，目前进展良好，今天上午应该就可以做完。开发在更新进度时，不是盲目乐观，就是跳进太细节的地方进行讨论，最后讨论的结果就是：跟没更新一样，除了浪费了10分钟时间。但是别忘了，PM会在15分钟之后再来轮询一次。
PM每周都需要汇总很多数字，比如本迭代完成的点数，剩余的点数，总体进度如何，有没有人有请假计划，遇到什么blocker，每个blocker的具体原因，每个风险点的最终日期是何时，等等等等。他肯定不能记住这些数字，所以可能一天之内向你询问数次。
PM的其他职责/技能 上边说到的其实只是描述PM的辛苦，而最微妙，最考验PM的是其“察言观色”的技能。这绝对是一个工作经验在10年之内完全无法获得的技能（而且是在中国的项目上工作10年）。比如，在showcase的时候，有个客户说，嗯，挺好，整个流程就是这样的，后续你们的UI是不是还会美化？如果你遇到这个情况，请问，这个客户是什么意思？
如果你能回答上这个问题（而不是提出问题），那说明你还离PM差十万八千里。成熟的PM会先判断，问这个问题的人是什么角色，以及他在系统中的话语权如何，还有其他人就此问题的反应如何等等因素，然后找到一个合适的答案。
PM另一个绝技是扯皮（不是贬义），开发会花一个下午（我是说10分钟）去跟客户讨论需求的范围吗？或者会为5个人天来讨价还价吗？我想开发大概会说，尼玛，找其他供应商吧，老子不伺候了。
一个项目的成功，需要多方合作，这里说的合作并不局限在甲方和乙方之间，即使乙方的团队之中，也需要很紧密的合作。比如项目经理和开发，设计师之间的合作。如果仅仅从开发的角度来看，PM有时候看起来就是和客户站在一起来整开发的一样，比如催进度，过分保守的估算人天（导致团队加班赶工）。PM需要释放团队中的负面情绪，保证团队士气，还需要他做一些开发不屑于做的琐碎的事情。
设身处地，替他人着想 本质来来说，每个项目都是一次生意。在去掉那些繁杂的流程和形式之后，做一个项目和你去菜市场买菜其实并无二致。举个例子，根据传统，软件开发界特别喜欢找建筑行业做类比，我也找个建筑方面例子。装修房子的时候，我们会要求施工方提供图纸（水电改造，基本设计等），按期交付（确定工期），同时会界定项目范围（比如刷墙，贴地砖，吊顶，封阳台等等），会要求工人按时来上班，正常出勤，认真工作，直到项目结束。过程中我们还会讨价还价，比如捎带着把栏杆拆除，捎带着敲掉一面隔离墙等等。在过程中，我们还会敲敲地砖，检查过门石，检查吊顶，测试水电等等。作为甲方，这些活动相信没有人会觉得过分。
但是一旦我们做乙方，也就是施工方的时候，情况就全变了。比如客户要求打卡，有人会觉得不爽，客户要求代码review，有人会觉得不爽，要求代码有设计文档，有人会觉得不爽，要求设计有多个备选方案，有人会觉得不爽。大多数情况下，这都是虚无缥缈的虚荣在作祟，这种情况所在多有，不过还不致命。一旦涉及到讨价还价（不是商务上的讨价还价，而是和客户就工作量达不成一致，或者就某个技术方案达不成一致之后），开发全部歇菜，一言不合，转身就走，压根不具备讨价换件的能力，这样还怎么做生意啊？设身处地想一下，如果你是甲方，当提出了一些合理的要求（比如需要一方提供验收标准，通过验收测试等），结果施工方还一脸的“我不跟你说了，你就是以大傻B”，你能乐意吗？
如何合作？ 说了这么多，这两种角色在同一个项目上要如何合作呢？我想，作为开发来说，有这样几点可能：
首先，理解PM的工作。在很多时候，开发会有莫名其妙的优越感（其实每个角色都会有了，比如销售看不上技术人员，技术Lead看不上PM等等），主要原因其实是坐井观天，对其他角色的辛苦和工作不清楚。然后错误的认为别人的工作都很low。
之前听一个同事讲过一个小session，里面有一点我印象非常深刻：不要因为一个人不会某个技术而鄙视他。就好比你不应该因为不会弹钢琴，而被一个会弹钢琴的人鄙视一样。道理很简单，但是开发在长期的“宅”生涯或者坐井观天中，进化出了这种非理性的观点：如果一个人连vim（此处的vim可以换成任何其他技术）都不会，就压根不足以谈人生。
其次，学习如何报告进度。PM催你的根本原因是进度不明确，如果每一个潜在的风险都清楚的显示着进度，而且有明确的负责人，PM就会降低轮询的频率。这需要开发经过刻苦的练习才能达到：
站会前自己花3分钟整理一下昨天做的工作 根据story的验收条件（最好有和BA/QA一起的讨论需求），进行合理的任务划分（tasking技能） 可以借助便签纸等工具，帮助自己明确进度（划分了5个子任务，昨天完成了3个，那么可以粗略的估计为60%） 再次，合理估算。有些时候，新人（来自于传统管理环境的新人）可能会误以为PM是一个管理的角色，或者处于某些考虑会在PM询问进度时做出一些错误的回答。比如PM在迭代启动会议上是问这个迭代我们有没有可能做完所有计划内的任务，作为一个负责任的开发，你需要在第一时间指出那些“非理性”的期望，以便PM进行更加准确的计划。
明确告诉PM，有哪些需求是不可能按时交付的，PM会根据实际情况来重新定计划，并和客户确认 明确告诉PM一些可能的风险，团队整体对交付负责，而不是PM，或者开发 按照经验，项目从来就不会按照计划进行，在做好一个粗略的计划之后，PM的职责更多的是进行动态调整。所以团队内部至少需要保持信息的流通，虽然可能短期来看可能会影响开发速度，但是从整体上来看，可以减少很多不必要的浪费。
简而言之，要站在别人的角度考虑问题：如果换做是你，你会怎么做？
前言 这两天在好几个地方都看到了一篇关于为什么整个互联网行业都缺前端工程师？的文章，文章本身是去年的，中心思想是：其实我们并不缺前端工程师，我们缺的是优秀的前端工程师。我还是比较同意作者观点的，不过略有意犹未尽的感觉。于是我结合自己的经验，也来聊一下这个话题：我们真的缺前端工程师吗？
These walls are kind of funny like that. First you hate them, then you get used to them.Enough time passed, get so you depend on them. That’s institutionalising.
传统软件公司划分开发者的方式下，在前端部门的程序员永远不会去读缓存数据部分的代码，设计师也不太可能去和开发坐在一起，开发也不知道软件最终软件会以何种方式部署在服务器上。
什么是“前端”工程师 我在招聘广告和办公室的一些对话中，听到了一个新的角色：UI Dev，事实上我在知乎上还回答过一个关于ThoughtWorks的UI Dev的问题。简而言之，UI Dev可以快速的把设计师的作品实现为HTML/CSS/JavaScript代码。
如果按照这个标准，我觉得UI Dev对自己的要求太低了。毕竟要学会HTML/CSS实现mockup并不困难，但是成为一名前端工程师则需要掌握更多的知识：
会用PS来进行图片的处理（比如切图，微调等） 用HTML/CSS实现mockup（可能还有SASS/LESS等工具） 熟悉JavaScript（比如前端的MVVM框架，客户端模板） 前端开发的工作流程（代码检查，精简化，模块化CSS，LiveReload，调试） 编写测试（静态检查，单元测试） 跨浏览器、跨设备的解决方法（不同分辨率，不同厂商） 会根据项目的特点选择不同的前端技术栈（移动端，Web站点，响应式设计等） 在有了基础的HTML/CSS/JS技能之后，你会尝试做的更好：
如何更高效的操作DOM 如何将CSS写的更加清晰易懂 如何编写更加易于维护的代码（更有意义的单元测试） 如何组织大型的项目结构，模块化，组件化等等 这些要求事实上已经不那么容易做到了。它可能会花费你2到3年时间来完全掌握。但是2到3年之后，即便你已经成为了一个“合格的”前端工程师，这也还远远不够。在现实世界中，一个软件产品除了前端，还有非常广阔的空间，还有很多有趣的东西值得学习：
HTTP协议本身（缓存，鉴权） Web容器/HTTP服务器如何工作 无状态的Web应用的工作原理（如何让网站正确地运行在集群上） 动态，静态内容如何分离部署（反向代理配置） 安全机制如何配置 监控机制如何配置 有了这些，也算是有点端到端的意思了。这时你也已经不是一个“纯前端”工程师了，系统中的大部分问题你都可以搞定，不过日常工作中可能更多的职责还是做前端的开发。但是这些还不够，软件除了交付之外，还有一些非功能性的需求：
端到端测试（UI测试，比如selenium server/web driver） devops（比如数据库环境，测试服务器，CI服务器的自动化provision） 基本的UI设计原则（在某些页面确实的情况下，根据系统的已有UI做设计） 数据库性能优化 性能测试 不过这些还只是我对于Web开发这个领域的总结。其他领域，比如大数据，机器学习，GIS，图像/视频处理等等。...
ThoughtWorks内部培训 对新人的培训是每个企业都绕不开的一个话题，企业当然想要每个新人都能直接独当一面，最好可以直接上项目贡献自己的价值。但是从经验来看，所有新人到一个新环境都需要学习很多不同的新东西（新技术，框架，语言，工作方式等等），而每个企业对于培训新人都有各种各样的策略，比如老人带新人，比如扔到项目上让新人自己学。
在ThoughtWorks，我们有着丰富的培训方式，有面向社招的，有面向毕业生的，有民间自发的，有官方组织的，有内部的，也有面向社区的。
TWU TWU全称ThoughtWorks University，面向毕业生，入职之后的第一堂课。TWU的地点设在印度，之前在班加罗尔，后来改到了普内。每一期5周，学生们需要和和全球其他国家地区的同学一起，一般会尽量将各个地区的学生打乱安排，尽量让学生体会多元化的文化，培训内容设计公司文化，软件开发方法论，敏捷开发（Project SImulation）实践等，同时还需要保证学生有足够的代码练习机会。
我在2013年作为讲师参加了一起TWU，对我自己的帮助也非常大，在和来自不同地区的讲师一起备课，学习中学习到了很多的东西，之前似是而非的一些概念也得到了纠正。
TWI TWI全称ThoughtWorks Immersion，面向有经验的社招同事，主要涉及的内容为公司文化（合作，沟通），专业服务（如何专业的解决客户的问题），软件开发流程，敏捷开发方法论等。
我在2012年时参加过TWI，并整理了几篇相关文章，可以参考这里，这里还有这里。
Session Office局限在ThoughtWorks办公室之内，内容随意，参加不参加随意，可以随时加入或随时离开。虽然内容没有限制，但是大多数时候分享的都是技术主题。比如自动化部署，自动测试，Spring 4，Ruby中的构建工具等等。
Sessoin的形式是主讲者找一个自己感兴趣的主题，一个人讲，其他参与者听，鼓励互动。时间一般控制在一个小时以内，所以一般选择在中午饭的时候，有的session会给大家订饭，一边吃一边听。
虽然大部分Sessoin的主题是技术相关的，但是并不局限于此。比如旅游见闻，历史，财务，摄影等等，都可以分享，有时候这些趣味性的Session的参与者更多。
WorkShop Office之内，内容随意，以动手为主，讲解为辅。
HTML/CSS Testable JavaScript 设计工作坊 OO BootCamp Ruby BootCamp 一般来说，Workshop都会组成一个系列，通常会占用几天到几周不等。参与者需要带上电脑，在课堂上进行练习之外，课后还会有一些练习。
3周3页面和可测试的JavaScript是我去年做的两个Workshop。由于Workshop会在下班后或者中午的休息时间，公司会为每个参与者订饭，以节省时间。
郑大晔校 面向刚刚得到offer的毕业生，在上项目之前，我们希望学生的基本技术达到特定的水平，因此设置了一系列的练习。包括
编程基础 开发流程 工作方式 公司文化 等等。郑大晔校的周期为每周一次，一次一天。涉及的内容会与大多数项目上的要求一致，比如西安office的Java/Ruby项目居多，我们的课程安排就会涉及到Java/Ruby方面。当然，各种软技能如工作方式也会在课程中涉及，尽量的寓教于乐。
每期郑大晔校大概会有10周，学生入职之后有的会直接去TWU，有的则会在项目上工作一段时间再去TWU。
组内培训 各个组内自行组织，并不要求其他同事参加。比如某个项目需要一些docker的知识，或者需要AngularJS相关的培训，一方面是找自己组内的专家组织一次内部培训，，另一种是找办公室内相关的专家来进行培训，形式比较灵活。
项目中已经在使用的技术 项目中将要使用的技术 请别的组的专家来咨询 社区 OpenParty Rails Girl 问题 谁当讲师 活动经费 内容如何持久化（人，内部知识分享系统） 如何保证效果（宽松） 由于对任何的话题都没有限制，也没有对参与者的限制，因此任何人只要感兴趣都可以作为讲师。而又由于没有任何的强制措施，参与者和主讲者都凭着自己的热情来组织，这也算是比较独树一帜的事情。
而关于内容的持久化，更多的是为参与者打开一扇新的窗户，或者说洒下一些火星，而至于火星如何形成燎原之势，则完全在参与者自己的自觉。好多次和客户分享了我们的培训机制之后，被问到最多的问题是如何强迫参与者产生热情？
这个问题在ThoughtWorks不是问题，我们在一个人进入公司的最开始，也就是面试的时候，就考察了他的热情，如果在热情上有缺陷，则很可能会直接拒掉，免得破坏我们好不容易构建起来的学习氛围。