从大三的暑假开始，我就一直在某互联网公司一直实习到来年的一月份，算起来也六个月了，经历过这六个月的洗礼，颇有感想，假如自己没有这段经历的话，或许自己会错失职场和技术上的收获。我始终相信，所有的经历无论对错与结果如何，都是一段收获的旅途。这篇文章就撇开技术层面的细节，说说宏观上的收获。
接触到流程化管理
我所在的部门是属于技术服务类型，也就是利用平台流量为不同的厂商导流，从中获利。这样一来就要求部门要有高效的合作精神能够快速完成各种需求方提的需求任务，用最新又稳定的技术来节约资源和提高工作效率。管理层要做的是协调需求方和开发人员的矛盾，规范化开发流程，及时为需求方提供高质量和速度快的服务。而这一切大概是怎么运作的呢？
首先说说需求方和技术开发两者之间的矛盾在哪里。需求方各种素质不一，有的甚至连开发流程都不清楚，还有的总是改需求，这些都容易造成需求方和技术开发人员之间的矛盾。比如，正常的开发流程是：需求方提需求—产品设计—后台接口开发—前端开发—测试—上线。而需求方以为前端开发完就可以上线了，于是上线后出现问题后就找前端开发，前端开发这时候才发现需求方居然没有通过测试环节就上线了？！于是心中怨气重重，怎么不按照套路走呢？！还有的需求方在前端开发完成后居然说改需求，于是前端同学又是一口老血，不仅浪费了开发资源和时间，还造成了彼此的矛盾。然而需求方心中也对开发不满，有时候开发者可能同时在处理几个项目，其中一个项目花的时间和精力有限，可能要延迟一两天才开发完，这时需求方心中会埋怨不是说好几号上线的吗，怎么又延迟了？！于是向老板告状。除了需求方和技术开发之间的矛盾，其实技术开发团队之间的不同环节也是需要协调彼此工作的，不然整个开发流程就乱套了。
那具体怎么处理这些矛盾点呢？每周项目经理都会开一次会议，各需求方都可以在这次会议上提出自己的需求和想法，而技术开发的老大们会根据需求方提的需求估算开发时长和难度，项目经理会听取各方的意见和想法，协调在会议上产生的矛盾，再根据目前的情况以及需求的优先级和分类，制定出一份总需求表。而各个需求的开发时长需要各相关的技术老大预估和提交，项目经理才大概知道这个需求的开发总时长， 然后再和需求方进行后期的沟通，约定完成的时间。
有几个环节比较重要，第一个是与需求方的前期和后期沟通。从有需求方提出技术需求开始，项目经理就需要和需求方进行前期沟通，开需求会议，如果需求方已经有产品的具体实现想法，那就引导他根据之前约定的需求文档规范写下来，如果需求方对产品的定义比较模糊，就需要产品经理跟进，设计一款产品，写下需求文档。需求文档也是有讲究的，好的产品经理会按照技术开发的思维来制定详细的符合逻辑的文档，还需要当面和开发人员沟通，这样一来最后的效果才会皆大欢喜。需求这一关最好是确定性的，充分和技术开发沟通，才可以减少因为需求产生的冲突。而与需求方的后期沟通，可能是因为技术开发某种原因导致开发延迟，还有产品开发完了但是需求方不满意需要和需求方商量一下解决方案。这些沟通的重活都主要落在项目经理的肩膀上，其中各种情况的复杂性和处理方式只有项目经理经历过才明白如何预防和处理。
再来看看和开发人员紧密相关的整个开发环节吧。由于之前出现项目开发的延迟次数比较多，因此影响到开发预估时长，所以项目经理就采取新规定了，下面阐述的是新规定的流程。各技术主管根据需求的难度和数量，分配给适合的开发人员，然后列出开发人员对应的需求表格。项目经理约定，下午不同时间段前，不同的开发岗位对应的人员，必须根据主管分配的任务预估自己的开发时间，并在线上excel上填写开发时长，必须在开发结束时间前完成需求，延迟的话将影响到个人的指标评比。部门内自己开发了一个需求管理系统，需求方可以上传自己的需求，然后项目经理经过前面的流程后，将任务细分给不同的技术主管，技术主管再将任务细分给不同的开发人员，开发人员可以在需求系统上看到自己的需求任务，获取需求文档、设计稿等材料和信息。而整个开发流程需要不同角色进行充分沟通，所以在开发的时候，项目经理会在通讯软件上给每个项目小组开一个小群，产品、设计、后台、前端、运营都可以在上面沟通自己遇到的问题。如果通讯软件上说不明白的事情，就需要当面进行沟通。另外，我们组在每周开头都会开一次会议，每个人都需要在开会前在需求管理系统上写自己的周报，总结上周完成了什么任务，遇到什么问题，怎么解决，计划这种完成什么事情。主管在会议上了解大家需求进度，以及总结一下问题，更好得把控需求任务的分配。
大致流程就是这样子了，但实际执行的过程中难免会遇到一些特殊情况，这些就需要管理层权衡利弊，制定出更好的解决方案了。
规范化的团队管理和更好的技术氛围
我所在的组是前端组，有十多人，根据不同人的能力负责不同的需求任务。主管重视我们组内建设，根据基础业务，组织核心人员开发sdk，为业务层提供统一的服务，并且开发自助系统，便利业务层的开发，争取在简单的业务层上减少重复的人力。在一些业务上，也有对应的比较详细的文档，对于新人来说，会相对友好一些，但由于有时候文档更不上业务的变更，新人有时还是需要问问其他人。
为了便于管理，我们组内规范了开发工具，但具体的开发框架比较自由，可以根据自己的业务场景进行选择，这样一来，整个团队的技术选择会比较自由，我在实习的时候也尝试了不同的框架和库，把理论上学到的用上，并可以对比一下哪种会比较好，实习会有更自由的实战机会。一开始主管不放心实习生自己弄一个项目，会找一个人带着。刚好那时候组内有一位资质比较高的前端是在做一个第三方游戏运营的移动端项目，主管让我去帮忙“打打杂”，我起初是做一些比较简单的样式布局，到后来争取到做一些逻辑处理，还研究了整个项目的框架结构，如此一来从打杂中收获了不少。在后来的小项目中，有了前面的积累，可以稍微应用自如。
为了营造更好的技术氛围，主管要求正式员工每两周就轮一个人进行技术分享。说实话，作为一个实习生，一开始接触的东西不是很多，所以一开始就听大牛们的分享会感觉吃力，听不怎么明白。除了组内的技术分享，项目经理也会组织全部门的技术分享，这种跨组的分享的确可以学到东西，但说实在的，学习这种事情更多的还是靠自己。
接触到更多优秀的人和提高自己的认知
我接触到的身边的人，都是优秀的。他们有的是热爱技术、喜欢专研技术、有自己理想抱负的年轻人，有的是资质高、有接近十年的经验、带过团队的高级工程师。作为一枚实习生，一开始可能懵懵懂懂，跟着别人做项目的时候，别人会发现你技术上的不足，然后会帮忙推荐一些书籍和公众号。在实战中，遇到不懂的，还有人可以指点你，起码知道弥补自己不足的方式，然后静下心来认真把技术补上，如此才有了技术上的收获。一开始接触陌生的业务时，会有点困难，需要多问别人，才会比较明白整个业务流程，才不会影响到需求进度，多问很重要。
有时候自己在工作的时候，是意识不到自己的不足的，这时候可能需要找前辈来指出不足才有进步的空间。我找过主管和当时面试我的面试官，和他们聊了一下后，才有如下的感悟。
虽然是实习生，但是要拿出正式工的态度和责任来对待任务，要对任务负责，并且思考自己和正式工的距离 在哪里，争取向正式工靠齐甚至超越，这样才可以体现在一个组里的价值所在。并且要懂得反思，思考自己一天的时间花在哪里了，需求的效率怎么样，如何去更好更快得完成某一项任务。其实前端开发会更加注重沟通，如果仅仅是利用通讯工具的话，可能效果会有所欠缺，该当面聊的话就当面去找，刷刷脸也好，积极主动地去找别人聊。
在需求进度紧张而任务一直完成不了的时候就需要反思了。很多工程师包括我可能会有视觉上的洁癖，一定要严格按照像素大小来调整界面，然而，假如该项目不是公司主要营收来源，也就是边缘项目的话，那注重太多的细枝末叶只能是浪费时间和精力。假如需求繁重，而刚好手头上这个 项目是边缘项目的话，不妨削减不必要的细节问题，节省宝贵的时间和精力。这也就是要把时间精力花在刀刃上。
前辈为个人成长铺路
在实习中，有时候会遇到各种各样的问题，这时候有个资深前辈带一下，问题很快就可以解决了。而且在做比较复杂的项目时候，有前辈带着你一起做，帮忙搭好了代码结构，这些代码结构可以抽取出来，在以后自己独立做项目的时候可以使用到，也算是一种积累，但最好还是要理解好代码结构原理。
团队里的人需要用新技术，有时候我和其他小伙伴会围在在熟悉的前辈电脑前，看前辈在github或博客上逛别人写的插件效果，一起讨论这个插件好不好看，怎么实现的呀~就像是女生们围观购物一样，乐趣无穷。
总而言之，这就是我在大公司那段实习经历的收获，觉得一开始可以在大公司实习真的很不错，有成熟正规的规章制度，还认识了一群热爱技术的小伙伴们，这些想法和收获分享出来，希望可以帮忙到选择实习或工作的你们。
