背景
最近换工作了，想想应该为这三年的工作做一个总结。
三年前从杭州回到星城加入国内大型外包公司的分部，刚加入时，团队只有十多号人，业绩也就是几十万。发展到今天，团队成员将近150人，业绩将近2000万，承接的项目也从几十万的小项目过渡到几百万、上千万的大项目。虽然整体看下来，个人产值并不高，但也可以看出整个团队在稳步发展中，也在不断积累各行业经验，以及建立与大厂的联系。
起因
这次换工作也是前前后后思考了几个月，最终才决定做一些改变，总结起来原因主要有以下三点：
首先，想做公司自己的产品，自己运营，然后看着它不断发展壮大，由雏期 → 成长期 → 成熟期，可能最终走向衰退，而做交付型的外包项目，就像是将自己费尽心力拉扯大的孩子交给别人去培养，你无法知道他在成长过程中会遇到什么问题，也无法去干预他的走向，这种感觉并不好。虽然说公司也尝试了几次做产品，但是最终都因为业绩压力而将人员抽调出去做项目交付，导致不了了之。所以，我得出一个结论是: 我们公司没有做产品的基因和决心，最起码目前来看是不具备的。
其次，是个人发展问题，虽然在团队中冠以前端架构师的title，但是，总感觉很虚，主要是因为我也不清楚我架构了什么？如果说根据业务、人员进行技术选型、搭建开发框架、制定规范、复杂业务的实现、拓宽团队的技术面等这些工作算架构的话，那我也算是名副其实了。但是，我也常想前端需要架构师吗？如果需要，那么他应该在什么样的团队和项目中存在？他的工作是怎样的？他需要怎样的能力？他的价值几何？因为从我自身出发，我并不认为自己是什么前端架构师。基于此，那么我在团队中的价值如何体现呢？因为如果不能够为团队或公司产生价值，产生超出预期的价值，也很难在公司有什么很大的发展空间。
最后，感觉目前的团队氛围、节奏就像是一个步履蹒跚的老人，它与我想要的那种朝气蓬勃、充满斗志的气氛不符。
工作
大部分人都比较抵触做外包，那么他们抵触的是什么？做外包是不是真的这么一无是处，毫无价值？并不是的，我想谈谈这三年做外包项目过程中的一些想法。
做外包对技术有提升吗？
我觉得是有的，尤其对于刚入行的前端同学而言，对各技术栈的使用可能并不熟练，而项目一个接一个的来，你需要快速的实现业务，这个过程就是熟练使用各技术栈的过程。另外，对于大部分项目而言，甲方并不会限制技术栈，因此，我们可以在做项目的过程中实践我们想用的技术，借此来拓宽我们的技术面。当然，这种方式也有它的弊端，因为需要不断的写项目，所以在这个过程中并没有太多的时间来深入研究某个技术点。可能做了很多个项目，但是对各技术栈的理解仅仅是停留在会使用的阶段，对其核心原理、实现方式都不甚了解，我觉得这可能并不是外包项目的锅。即使是做自研产品，也会有进度紧，需要不断的加班赶进度的情况，同样也会存在这种问题，公司也并不仅仅是个学习的地方，大部分人的提升可能还得靠下班后的时间，靠自己在做项目过程中不断的思考、反省和总结，多问问为什么。
做外包真的只是不断的重复写业务？
像项目交付型的外包公司，其业绩来源主要是通过不断的接项目并快速交付，交付的项目多，产生的价值自然大，那么如何保证快速的交付项目呢？我觉得这里面还是有挺多可以思考关注的点，例如：很多项目其实大同小异，像后管项目，基本功能大体相同，不同的可能就是行业相关的业务功能，那么如何快速的实现复用，当然，我们可以通过Ctrl C 和 Ctrl V来实现，但是这种方式是否有点low呢？我们能否对做过的项目总结下，然后实现一个中后台管理系统作为我们的基础开发框架，随着做过的项目增加，框架所承载的内容会越来越多，我觉得它至少应该包含这些方面的能力：基础能力（如：登录、菜单、权限、错误页、面包屑、表格、换肤、适配、代码规范等）和领域相关的能力（如：电商类、新闻类、教育类），甚至我们可以实现一个公司内部使用的组件库，以便更加契合业务，同时，也可以针对不同的项目快速的作出调整，这些东西真正要着手去做还是需要花费一些时间的，在做的过程中自然对我们的能力会有很大的提高，这样既能帮助公司快速完成交付，又能提高自身能力，也算是为公司积累了一些技术资产，对我们的kpi考核肯定也会有所帮助，算得上是一举多得的事了，当然，市面上也有很多开源的中后台项目以及UI库，但是，这些都是别人实现的，我们会用、看得懂，但不代表我们自己也能够毫不费力的实现出来，如果真的做出来这也能为我们的简历增色不少，以我面试了百多号人的浅显经验，大部分人的工作内容大同小异，并无很出彩的点。
做外包能提升的只有技术吗？
在做项目的过程中，作为技术人员很多时候需要参与到项目投标、提供技术方案、配合前端业务人员去争取客户，同时，在项目开发过程中，也有可能需要跟甲方进行技术对接，这其中会涉及到大量的沟通，很多问题可以通过沟通来解决。例如：在我参与的一个项目中，甲方在标书中明确写明了要适配移动端和PC，但是，在投标时并未对这个点太过关注，直到开发时才发现工作量并不小（PS：以为要做两套代码来实现）。这时候我们就需要站在技术的角度去分析这个需求存在的意义，这个项目是一个类似于在线课程的系统，其中包括观看视频课程、做实验等等功能，在手机上观看视频这还说的过去，但是做实验就很难操作了。如果是花费大量的时间来单独做一套移动端的代码来适配就没有太大必要，因此，我根据业务需求、使用场景来制定方案。首先，考虑到首页的出现频率最高，同时也会承担一部分引流的功能，所以，由产品出原型、UI设计，为PC端和移动端分别实现一套代码，对于其他页面则使用同一套代码进行适配，保证在移动端能够比较好的展示。然后，拿着这个方案去和甲方谈，最终也获得通过，这个举措大幅的减少了UI、前端和测试人员的工作，这也算的上是沟通所带来的益处。如果作为技术人员不主动思考，并积极沟通，肯定是达不到这个效果的
在沟通的过程中，很多情况下都是通过提供强有力的论据来进行说明或说服别人，那么什么样的论据才足以说明呢？是否只凭感觉，只凭借经验，只凭借看到的表象就可以？当然不是，就拿我们和大厂甲方合作的一个hybrid app项目来说，我们实现h5部分，甲方使用原生实现端，双方通过JSBridge来进行通信，其中涉及到一个富文本编辑器，最初决定是由我来实现，我花了大概一周时间做出了demo，但是，不管在android还是在ios都存在一些问题：
问题一：
在android上，输入内容后无法展示出来。
问题二：
因为UI设计的富文本编辑器的工具栏是固定在底部的(如下图所示)，当输入文字，输入法键盘弹出时，工具栏要位于输入法键盘的上方，也就是键盘需要将工具栏顶上去，这个效果在android上是可以正常实现的，但是在ios上，输入法会将工具栏遮挡，工具栏并不会被顶上去。
针对问题一，我将富文本编辑器的页面放在多个主流app中测试，也包括端使用的UC Webview，都可以正常输入并展示，同时，还让我们这边的android开发帮忙做一个demo，并将h5页面嵌入其中，所有的这些测试都表现正常，唯独在甲方开发的端内无法输入。
针对问题二，也是花费了比较多的时间研究，当输入法弹出时，ios和android对webview的处理方式有何不同？根据测试得去的结论是：在android下，当输入法键盘弹出时，webview的高度会被减小到可视范围之内，也就是webview的高度 = 屏幕的高度 - 键盘的高度，所以工具栏会被顶上去，但是在ios下，webview的高度并不会被减小，它会保持webview的高度不变，系统只是会根据光标聚焦的点，将其推动到可视范围之内，所以工具栏会被遮挡。针对这个问题，我跟我们这边的ios开发沟通，确认是否有方式实现与android对webview同样的处理机制，他经过测试确实是有的，然后我拿着我这边的测试结果和解决方案与甲方ios开发进行沟通，由于这个解决方案与h5这边的业务强相关，所以，由ios提供一个监听键盘弹出的服务，然后h5这边拿到端传过来的键盘的高度，再根据屏幕的高度和键盘的高度，动态的改变工具栏的位置，使其保持在键盘之上，通过这种方式来达到UI设计的效果。
虽然，富文本编辑器最后还是由端来实现的，但是，对于这两个问题，应该算是比较有理有据的与甲方进行说明沟通，并不是一上来就是我们这边无法实现，也不去寻找原因及解决方案，同时，在这个过程中也协调了我们这边android和ios的开发进行一起来处理，这也要求我们在公司的交际面要广一些，而不仅仅是只在自己那个狭小的圈子里转悠。
结合以上两个例子可知，在做外包项目的过程中其实也会遇到很多的问题，这些问题也并不仅仅是与技术相关，也跟我们自身的沟通能力，解决问题的思路，处理问题的方法都有关。
因为负责的项目多了，所以可以与不同的甲方进行合作沟通，这对我们的综合能力还是有一定要求的，这其中也会遇到与头部大厂合作的机会，在与他们合作时，也可以从他们身上学到很多东西。例如：在最近与大厂甲方合作的项目，前前后后就做了一年多，大大小小的会议可能开了有几十个，不管是技术对接、周会、资源协调、解决方案的探讨等，总的来说会议的效率还是比较高的，很少出现议而不决的情况，有时我想是不是他们公司内部会做这种沟通技巧的培训，在与他们沟通的过程中，我总结了以下几点，觉得还是值得我们去学习与实践的：
- 注重观点或者问题是否准确的传达：就某个问题拉会沟通时，在他们描述完一个问题后，往往会在最后加一句：不知道我有没有表达清楚？以此来保证问题的准确传达，同时，收到与会者的反馈。
- 注重总结： 主持会议的人往往会在最后对会议做一个总结，主要包括：会议的主题，解决方案，负责人，deadline等等信息，以此来保证会议的有效性，避免议而不决的问题。
- 负责人的问题：在项目开发过程中会涉及到与多人合作的问题，例如：我与甲方端内同学联调比较多，所以遇到问题先找他，但是他可能只负责一部分功能，有的功能是其他人负责的，对于不是他负责的功能，他会先了解是什么问题，然后再去找他们那边的负责人，再把相关人员拉到一起开会讨论，而不是让我直接去找负责人，这样就避免了 “踢皮球现象”。
所以说，做外包能提升的并不仅仅只是技术，还涉及到其他方方面面的能力，而这些能力在我们的职场生涯中也是至关重要的
综上，做外包项目真的那么不值得吗？我想未必。
