在职场，有时候需要有更大的视野和格局。这样说其实有点空洞，就拿 jd 来举个例子说一下。
找工作的时候，都会看一下这个岗位的 jd，以便对这个岗位有更加深入的理解。
当通过这个岗位的面试并且入职之后，这时候开始就不要被这个岗位的 jd 所束缚。
其实你可以想一下，这个 jd 是怎么来的，为什么会这样写。我自己本人也经常会参与到公司一些 jd 的修改工作。还有一些 jd 都是以前没有的，需要重新写。你所看到的 jd 本质上就是写这个 jd 的人，他对这个岗位的认知和理解，然后再加上每个公司的业务特点形成的。
首先明确一点，jd 是可以动态变化的。下面就说说引起 jd 变化的原因有哪些。
* 对岗位的理解有个逐渐深入的过程：这个在大公司可能感觉不明显，因为他们的业务都比较成熟，对岗位的要求也比较固定。但是在一些中小型公司或者大公司里面的一些偏研究性质的岗位，对这个岗位的要求一般都会有一些变化；
* 业务的变化也会引起 jd 的变化：同样是 java 开发工程师，不同的业务特点决定了对这个岗位的要求不完全一样。公司的转型或者业务的转变也有可能引起 jd 的变化。

拿软件测试来说，最重要的工作是发现产品的质量问题。但是随着对测试理解的加深，发现测试还需要有一定的产品思维，要站在最终用户的角度看待问题。即使软件测试之后没有任何问题，但是没有解决客户的需求，也是不合格的。又比如说测试和开发经常会有一些矛盾，因为测试就是要去找开发的软件里面是够有问题，有一种"大家来找茬"的感觉。这时候如果发现了一个 bug，对于有一些开发来说就需要比较好的沟通技巧，这时候就要求测试同学有一定的沟通技巧。

你看，这就是随着对测试理解的加深，测试的 jd 也会有对应的变化。

说了这么多，还是没有说格局的问题，这就来了。在工作中，是要自己去定义这个岗位的职责而不是让岗位职责定义你。我们要去思考这个岗位除了原来 jd 的描述之外，还能做那些事情。还拿软件测试举例：

发现了一个 bug 只是开始，怎么推动开发区解决问题呢？有一些开发是很配合的，不需要推动，但是也确实有一些开发不愿意配合。

大多数公司测试的地位其实是弱于开发的，测试经常会受到各种埋怨，这时候怎么能够排解压力呢？

开发的流程走的很不规范或者现有的流程不适合当下的业务，怎么去优化流程呢？

事情多，时间紧，怎么上自动化呢？

所有和这个岗位相关的事情都可以思考怎么去改进，做着做着你就会发现自己已经超出了原来对这个岗位的要求。做到这种程度，即使没有升职加薪，也不远了。最终即使真的没有升职加薪，跳槽也会有一个不错的涨幅。

其实在一个公司工作还有一个"福利"，我这里姑且就叫福利吧。公司其实提供了一个平台，用来让你在真实的环境中进行实操。在实战环境中锻炼自己的技能，这个其实很重要。刚开始大家的差距其实不是很大，都是在解决问题的同时提升了技能。不同的公司就是提供了不同的平台，其实也就是不同的问题在等着你，解决了这些问题能力自然就上来了。

说了这么多，工作的时候不要只盯着 jd 里面说的内容，要站得高、看得远，到时候收获的才更多。