(word)在百度两年里的蜕变.docVIP

在百度两年里的蜕变 还未毕业就在百度实习了，两年多的磨练，有被磨平的棱角，也有精彩的收获；谨以此文献给在百度并肩奋战两年多的兄弟姐妹们。忘不了离职日那场特殊的告别午餐；忘不了这两年和你们的讨论、争论；忘不了脑海中你们的一个个优秀的细节。真想说无论“嫁”到何方，你们都是我的娘家人，我在天猫玩得蛮开心，请不要牵挂！ 3月底，离职前的闲暇跑了趟蜀地，去九寨的山道上触景生情（照片扔在我的微博相册中@徐凯-鬼道），整理出这么一篇，多是从细节总结出来的心得，不喜勿喷可轻拍，各种原因拖到今天才发上来。 大巴行驶在通往九寨的环山道上，望着奇险的山景，睡意全无…… 团队 随着时间的推移，对于团队的理解在不断改变和加深。团队中一些有趣的现象，比如： 误解往往来自于缺乏沟通；原来的团队中角色众多，因为不了解其他角色的工作而发生的不愉快经历是难免的，发生了就要沟通，大家坐下来聊聊天化解误会就好了；这种事情我经历过两次，大家平心静气地谈过后彼此更加信任，完全不会因为误会而交恶。 团队间的合作分工是有讲究的，互相补充、制衡、各尽其责；在遇到紧急问题时也能表现出一贯的效率，最终推动问题的解决；这有点像《寒战》中的情节。 曾问“技术和产品是什么关系”，答曰“合作的关系”，何尝是与产品，技术与任何角色不都是合作的关系吗？ 合作 笔者在百度的两年经历中，作为团队中的客户端（web前端+移动app）tech leader有一年的时间，需要频繁和各类角色打交道，为了让工作更加平滑地开展，需要了解每一种角色关注的焦点，与他们密切地合作。在一个产品的生命周期中，依次会接触到这些角色：产品、设计师、前/后端、测试，之间还穿插着和老板以及其他tech leader的沟通。 产品 需求的发起人。这群人能说会道，砍他们的需求就和要他们的命一样；一般情况下“砍”不如“拆”，需求可以分期做，通常双方都能接受；特殊的情况需要说明下，漂亮mm带着水汪汪的大眼睛死死盯着你的时候，你的思路一定要保持清晰 设计师 需求像水一样流到设计师这里。设计师一般分为交互和视觉；交互根据产品方需求提供交互稿原型，视觉在交互稿基础上丰富页面元素、配色、细节调整等；和设计师尤其是视觉要处理好退化的问题，真不是所有的设计师都能够理解“渐进增强，平稳退化”的概念，这个需要沟通；之前在圆角问题上遇到过阻力，通过和视觉的沟通，视觉最终还是接受了前端的退化处理（border-radius）建议。 前/后端 之前，前端无论与业务端后端还是服务器后端的合作都是很顺畅的；前后端之间应该尽量解耦，只通过规范接口通信是最理想的状态；以java环境的业务端为例，jsp和freemarker（fm）二选一，应该选fm，因为fm是模板语言，尽管仍包含逻辑控制，但在前后端解耦上优于jsp；再进一步，fm和整站ajax通信（js渲染页面）相比，显然选ajax，因为这样前后端的耦合又更小了。 业务系统中是否选择ajax需要根据业务类型来考虑，引用ER框架中的一段描述： 整站式Ajax应用不利于搜索引擎抓取。故ER框架不适用于内容提供的WEB站点。 测试 见到过技术和测试掐架的场景，实际工作中这两块人的合作远多于分歧；而且必要的掐架是对项目负责的表现，大家吵完架还是可以坐一桌吃饭的。有一点应该注意，不要等到项目快结束了想到让测试介入，这样测试很被动，对整个项目的进度也可能带来风险；应该尽可能拆分手头的需求，安排开发计划，让测试能尽早介入，技术和测试能够交替完成各自任务是最理想的。 选择团队 新团队机会多，但是可能会缺乏足够的指导 新团队往往没确立在公司的地位，对个人晋升有可能造成影响 老团队高手云集，如果没有好的新人成长计划，要想杀出重围也不容易 总体来说建议在老团队学习，打下基础，寻找合适的机会去新团队闯一片天地 这些观点仍然很泛，请具体情况具体分析。 带新人 带新人是老板对你能力的认可，是好事 带新人对自己的能力提高是显著的，因为有一个机会把业务和技术的基础回顾一遍，给自己查漏补缺甚至是理解得更深刻 安排好自己的时间，因为要想带好新人是要花精力的 新人可能随时会打断你，要有忍耐力 如果新人太多，应该考虑找人帮忙带，都揽下来的话对自己和新人都是不负责任的 结果导向 面试过的互联网公司，HR都会来上一句“我们是结果导向的”，当时很配合的点点头，以示理解（其实压根没听懂）。两年下来，我对结果导向的理解变成了： 上下班时间可以自由，但是要干满8个小时或更多，因为活就在哪里，不离不弃 半年或年度考核时，KPI可能是唯一的评价标准 团队的结果不够好，个人肯定受影响，因为结果导向嘛 个人 承受压力 尽管笔者在学校的时候已经做了一些小项目，初到公司环境还是有点发懵，人家提的需几乎不加判断地接受了，导致初期工作量奇大，压力剧增。