掐指一算从13年12月18日入职百度上海研发中心以来，一晃就是四个月过去了。我算是比较幸运，进来就碰到了新项目，经历了一个产品的完整的开发流程和迭代周期，学到了很多东西，我们的DSP产品也终于在上周上线。由于是商业产品，不像百度贴吧、文库那种用户产品有广泛的用户群，商业产品的用户群还是相对狭窄和集中的，对于我们的产品用户就是广大的广告主、代理商、销售，所以朋友们让我介绍下我的具体工作时也很尴尬，因为我说你去访问下：dsp.baidu.com 就知道了，但是普通用户根本没有权限使用这个产品，朋友们所能看到的只是一个蓝色基调的登录页面。 写这篇博客的动机并不什么四个月总结，而是想写些关于今天的周会的感想。由于涉及到公司的内部业务，所以这里不细谈各种具体名称。
由于产品的上线这段时间相对就比较空闲，不像上线前还要加班加点修Bug赶进度。另外一个产品从其他部门并到了我们部门，于是开周会讨论下交接事宜，技术同学简单讲些业务功能逻辑。这对于百度的同学们来说当然不在话下。但是之后经理和那个产品的PM讨论产品的目标用户时，发现其实这个产品的目标用户一直在变动，而且和另外又一个兄弟产品的目标用户有重叠。对于奉用户至上为圭臬的互联网产品而言，目标用户群的波动意为着需求的不稳定，意味着代码的浪费和重构的风险，这其实是个浪费人力物力的方式。另一方面，该产品与其他百度的产品的业务依赖与处理也与我们部门目前的方式有所不同，所以看起来感觉他们那种处理方式有着种种不合理的地方。
我听着经理们和PM的讨论，从他们的嘴里不断地蹦出一些我从来都没听过的产品或者模块的名字，心想“天哪，这么一个产品怎么会和那么多其他产品发生关系，这整个项目是该有多发杂！”
但是这种感受在你写代码时从来不会降临到你的脑海。写代码时，你只需要熟悉当前项目的框架，定好你自己的模块，然后在你的模块里肆意写代码，不管是照葫芦画瓢还是再创造些新的处理方式，最终的目的无非是让你的模块能够运行、满足PM的提出的需求、通过QA们的疯狂测试。通过将每个人的模块合理的组装，一个完整的项目就完成了。
这是现代软件敏捷开发流程的一个优点，功能细分，职位细分，每个人只需要用同一种逻辑或者技能去完成该功能列表中的某些功能即可。比如PM（产品经理）负责做市场调研，联系用户，挖掘需求，撰写需求文档；UE（用户体验工程师）负责按照PM的需求文档进行原型设计或者UI设计；RD（后端工程师）负责将需求文档转化为计算机的代码框架和功能代码；FE（前端工程师）负责将UE的设计稿在网页上实现，包括界面、交互、数据获取展示等；QA（测试工程师）负责测试通过RD和FE实现的功能，提出BUG给相应同学，不断完善系统。
这也是一个缺点。长此以往，就算你做了一年的项目，你所了解的项目也可能只是冰山一角。当然对于大部分人而言，能完美地完成自己负责的功能已经是件令人满意的事了，毕竟你被公司招进来的目的也就是来做这个工作。
但是，总有人想要站得更高，在那更高的地方，你能看得更远，看见自己前所未见的事物。一颗螺丝钉对于一架飞机来说固然很重要，缺一不可，但是飞机并不是全是由螺丝钉构成的，最后让飞机起飞的，是科学的飞行设计和准确的驾驶控制。鱼与熊掌不可兼得，站得高可能就意味着你看得不清楚，无法体验细节的魅力，你所能感受到的只是一览众山小的体验。
我无意进行小大之辩，价值只有在个人的价值体系下才能存在，外部的评判都是枉然。
对于一个正在路上的旅人来说，最美的风景莫过于闻着山脚的野花的芬芳、品尝山涧的甘甜，抬头仰望那高耸入云的山峰了。