写在最前面
本人绝非大牛，在掘金做了多年的看客。由于最近公司内有一个才入行不久的新人经常来和我讨论一些问题，也引发了自己的一些思考。结合自己知识层面，希望能把自己从业这些年的体验分享出来。因为我不是什么大牛，因此可能对于很多同学我写的东西价值不高，尽请忽略。当然，如得各位高人指点一二，在下也是感激不尽
这是否也是你的日常？
- 作为前端在公司经常被当做资源使用，日复一日按照PD的要求堆页面
- 产品较强势，即使需求看上去是个伪需求我也说不过他
- 好像谁都能来给我提需求，除了产品，自己的老板，运营，测试也都经常会以各种形式提大大小小的需求或者改动，经常听到“现在这样体验不是很好，改一下吧”
前端只能作为资源存在么
自我认知的改变
在很多公司，研发岗位的多数人都是被默认看做是资源的，前端更是食物链的底层。因此在他们眼里，不管需求是什么给你，不要问，做就是了。是的，这很可怕，但更可怕的是作为一个前端研发自己接受了这个观念自己也把自己定位成资源。如果想从纯资源的角色中走出来第一步就是不要自己也把自己当成资源。自我认知的改变说起来容易，但实际操作却要通过一定的心理建设和自我能力的提升。
先来说一下能力的提升。这里的能力提升主要包括技术的深度和广度，合作方的知识领域，以及思考事物的能力。
1. 技术的深度和广度
在技术的深度和广度中，由于人的精力和时间都是有限的（尤其是埋头于业务的前端来说），因此可以有主有次。如果是想成为全栈工程师或者成为一个技术团队的Leader那么技术广度可能就相对重要，这是因为团队Leader的主要工作不是写代码而是做判断。判断一个技术在应用时大概能有多少收益和成本，是否会有什么风险，和现有技术方案可否平滑过渡，和客户端服务端的技术是否可以很好的搭配，甚至说技术的瓶颈在哪里。而技术的深度挖掘就对成为技术专家更为有利。因为作为技术专家，需要在产生一个问题时快速判断问题的形成原因提供解决方案，并且在团队的即使Leader做决策时作为可靠的顾问。
2. 合作方的知识领域
平时各个合作方日常工作的知识在很多研发人员来讲觉得没什么意义，觉得自己写好代码就可以了，但事实上这些知识可以帮助我们减少沟通成本并且可以从不同的角度审视我们自己的工作。比如说我们跟产品合作，就可以多去了解一些产品是如何挖掘以及定义用户需求，怎么转换成我们日常工作需求的方法论。跟运营对接最好能明白他们是如何通过数据衡量一个活动或者一个功能的价值。跟项目管理合作要最好是对敏捷开发和项目管理知识体系有一定程度的了解。
3. 思考事物的能力
这大概是最难得一种能力提升了。其依靠的不仅书本中的理论还有坚持不懈的练习。之所以难是要时刻提醒自己不要陷入思考的误区。这又包含了误区的识别，刻意练习的改变，以及进一步的思考能力的传播传递
工作方式的改变
认知层面是内，实际工作是外。想要改变生存状态还是需要内外兼具。为了能从海洋一般的业务需求当中挣扎出来。一个最直接的办法就是学会 拒绝。想说“不”很难，一方面总有些来源的需求，除非你是不想混了，否则很难拒绝。二来在很多情况下，不是那么容易区分什么需求值得做，什么需求是伪需求。对伪需求和低价值的需求该刚的要刚，对于那些价值高的需求即使难度高工作量大也值得去拼一拼。想要打破这种困境，有两个方式。
表层以下
一个是问“为什么”。既要知道果，也要知道因。很多需求在提出时是提需求的人想的方案，其很可能不真正解决用户的痛点，不是最原始的需求。因此在日常工作中不妨多问问产品的同学几个为什么。一来可以帮你更好的了解深入业务，二来从你的角度解读出来的信息可能和产品同学表达出来的很不一致。
完美陌生人
另外一个，我给他起名叫“陌生人意见”。越是对产品功能熟悉，对业务了解深入的人越容易陷入思维的误区怎么看自己的想法都是对的，别人的就是错的。但是我们的用户却往往是对整个业务逻辑知之甚少的，因此不妨拉一个不熟悉这块业务的同学在听完你们简单介绍后给出他的意见。这也更贴近真实用户的思考方式。
Deep Work
前两年有一本比较流行的小册子就叫《深度工作》，如果你没看过也不要紧。大致的意思是不要在碎片化的时间里做需要深度思考的事情。尽量把时间整合起来。这是因为人一旦把注意力从一件事情上移开，想再回来需要一段时间才能恢复深度的精神状态。
关注数据
数据是一个衡量产出的很好的依据。很多前端同学都在做页面的时候写过埋点。埋点的作用就是帮我们判别每个功能，每个修改对用户究竟产生什么影响。这样我们才知道自己做的是对是错。要知道在错误的方向做百步的努力也抵不上在正确的方向上的一步。
自己的KPI
好了，我们把不合理的需求拒绝了，似乎可以喘口气了。但是这不是万全之策，毕竟一年下来你的工作量比别人小可是很危险的。这个时候就需要自己去设定目标，比如说为了不为了运营活动天天让自己改图改文案，开发一个可配置运营管理工具。再比如说不想在不同的项目中复制粘贴代码，我们把其中一部分抽离成公共的组件库，等等。至于给自己定什么样的KPI，我个人觉得就是越能解放生产力越好。越能节省成本带来业务价值越好。
也只有当我们又充足的理由和实力时，才能对那些个非常别扭的需求们说不
