从去年入职到今天，整整满一年。这一年经历过很多事情，发生了很多的变化。很幸运当初选择了互联网行业，整体感觉还不错~
看着这张图，突然想起来，这是我毕业后待的时间最长的一家公司o(╯□╰)o
一.流水账
PHP是最好的语言
最开始的那段时间并没有直接做iOS开发的工作，而是去帮忙一起搭建稳定性的平台。但是我负责的部分主要是配合自动化测试、降低崩溃率。主要方式是使用PHP搭建了一个崩溃日志查询平台出来。PHP之前没用过，等于是从零开始。。。
过程比较折腾，整个人精神很紧张，因为不确定性实在太多了，而且PHP这个东西远离了iOS开发，让我有点心虚。但是咬咬牙还是坚持了下来，一个多月后查询平台基本成型，不完美但是可以工作，能够满足我们的需求，算是熬过了第一阶段。
感受：从零开始学一门语言其实也没那么可怕，只要能达到自己的目的，不要拘泥于实现的方式。PHP果然是最好的语言！！！
压力山大
一个多月后正式加入到需求开发中。工程很大项目很复杂，九游里边好多个子工程，架构师设计好了各模块的依赖关系，懵逼了好久才了解了个大概。
倒是代码规范这一块过渡比较平滑，因为之前我也是模仿Apple官方的规范来着。
具体到项目开发中还是有一个适应的过程，刚开始接的几个需求，基本处于疲于奔命中，几个需求并行开发，又会涉及到多方协调的问题，所以很多时候会感觉被打断的太多，以及时间不够，另外本身leader对团队成员的要求也蛮高的，所以当时也是略焦虑：
中间还因为测试流程少了某个环节导致线上出问题而被罚款过一次，至今记忆犹新。也是那一次，让我明白了需求负责人的职责和界限。
步入正轨
后来慢慢的也就适应了新的节奏，一些业务需求和技术需求，虽然难度不大，不过好歹没出什么大的问题，至少没有再被惩罚过。跟产品同学和质量同学的配合也越来越默契，整体上波澜不惊。
拥抱变化
9月份后公司开始震荡，到9月底基本结束，多事之秋。 10月下旬，产品规划比较清晰了，进入会战状态，恩，也就是开始996的工作模式，我们正处于并将长期处于这样的状态中。。。
二.大厂的那些事
流程与做事情的规范
一次完整的需求开发流程是这样的： ①需求预审、评审； ②概要设计与评审； ③测试用例撰写与评审； ④开发； ⑤测试与bug修复； ⑥发布； ⑦版本总结/项目过程总结。
架构师整理了一份团队内部用的代码规范，基本上是按照Apple官方的规范来，加一些通用的可以避免留坑的规则而已。我们还有CI平台每日构建打包和执行测试，进行代码扫描，一些不规范的地方会有警告并通过邮件发出来，以便得到及时的解决。
git工作流基本是按照master作为稳定分支，不开发代码，只做合并和打tag用，每个版本使用一个新分支，开发完毕后合并到master并打tag，之后开新的版本分支出来供大家开发，旧的版本分支往往在新版本分支开出来过一段时间后会锁定禁止再提交代码。其他诸如多个零碎的提交整合成一个提交，commit信息写明白等等这些都是业内通用规范了。
会议与信息同步
①每天早上会有晨会，主要是信息同步和风险把控；
②每周各小组会开周会，也就是通常的上周工作总结和这周工作计划，以及一些信息同步；
③剩下比较多的主要是需求评审会议和技术上的概要设计评审会议比较多，且比较耗时间，在开发周期的前期阶段，往往开会占了很大一部分的时间；
④会议通常会有会议纪要，记录和整理问题，然后邮件发出来方便后续跟踪和解决；
⑤通常一些重要的信息同步，或者技术问题的分析过程和解决方案，也会通过邮件发给全组，一些技术预研也是如此；
⑥会议多占用大量的时间也是不争的事实。
另外就是有时候需要跟外部门有一些协同配合的工作，架构师算是我们组的接口人，跟外部门的配合工作，往往是他自己解决或者他制定另一个人来解决，指定一个人之后，这个人就必须负责解决，不能再转移给其他人了，这也一定程度上避免了扯皮和拖延。
定计划与工作排期
对于大厂来说，按部就班的执行计划而不延误是非常重要的。
通常会根据需求稳定后或者评审后，根据评估的工作量来确定开发计划和测试计划，正常的发布时间点也会在这个时候明确。
这里边有一个很神奇的地方就是评估工作量，评估工作量是一个很有艺术性的事情。要想评估的准确得有这么几个点：
①首先你得足够了解产品的需求，理解产品所想要的是一个什么样的东西，避免信息不一致所导致的返工甚至是背道而驰；
②其次对需求的实现基本要能hold住，不一定都做过，但是大体上要知道怎么去实现，会有什么样的难题或者坑存在，如有必要留出预研时间；
③不可控因素，比如工作互相依赖，别人没完成某个功能会影响到你的工作进度；或者UE/UI要求的动效，可能稍微改一点或者有部分没识别出来，就有可能引起实现方案的变更，进而产生进度delay的风险。
通常我们评估时间的时候会相对保守一点，留些余地以备不时之需。
内部技术分享
小组内部有技术分享的KPI，一些有意义或者大家都感兴趣的话题，可以找个会议室来做分享，包括且不限于技术，之前就有人分享过西藏的骑行之旅。
虽然我对这种以KPI来驱动分享有点不爽，但是整体上看还是有收货有效果的，内部同事间氛围会更好，且能互通有无，开阔一下视野也是挺不错的。
除了小组内部这种分享，阿里的ATA技术社区也有很多的技术文章，部分甚至写的非常有深度，值得学习。
另每过一段时间都会有集团其他BU的人或者外部的技术人员过来针对某个主题做分享，比如什么双十一大数据啦，七七八八这些。不过这种一般我都不怎么去就是了。倒是有时候遇到问题时，会找其他部门的大神求解决方案，之前做安装包优化时就找支付宝团队沟通过，后来我们组在稳定性这一块也找天猫请教过他们的技术实现方案，感觉工程师都挺友好的，赞一个。
UC有成立技术专项攻克难题的传统，针对必须要克服的技术难点进行特别攻关。效果还不错，这种做法和效果也得到了豌豆荚CEO的赞赏。
产品驱动与上级驱动
产品决策者决定产品的方向，但是往往，产品leader是出于用户的角度来做产品，还是为了迎合上级的意思，这就是一个问题，而且是一个困恼多方的问题。
如果产品发展块，用户增长迅速，那一荣俱荣，大家都很happy，全身心投入即可。但是如果产品停滞不前，增长乏力，很多问题就暴露出来了，比如产品同学会不断的去试错，产品方向会频繁的调整，研发疲于奔命的同时又看不到希望，代码写的浑身没劲，运营同学不知道干点啥才能提升日活/留存。
一般说来，一个手机APP的问题往往都是出现在这几个方面：
①产品所在的市场/潜在市场是否足够大，是否能够满足启动该产品时的心理预期；
②行业格局是否已经建立，是否仍然有做大的机会（创造新的需求）；
③产品方向对不对。
我们之前和现在做的产品，个人看来，瓶颈其实都在第一点——潜在市场的容量到底有多大。具体就是你的潜在用户量有多少，你能从每个用户身上赚多少钱。
产品方向决定你能否激发和满足已有的和潜在的用户需求。
至于行业格局这种基本上是很明显的事情，有一个微信你就没必要再做熟人间的即时通信产品，有一个形成垄断地位的滴滴打车，你再做一个出来也意义不大，机会已失。
产品、运营与研发
①从目前的情况来看，产品和运营对业务增长的贡献更明显，得到破格晋升的概率也更大。
②战功导向的企业文化决定了能帮公司的业务取得突破，能帮公司赚更多钱的人，在公司会更有存在感，而恰恰，技术性岗位在贵司只是起支撑业务发展的作用，并不会对爆发性增长有直接的影响。
人员流动性与拥抱变化
去年今日此门中，人面桃花相映红。人面不知何处去，桃花依旧笑春风。
①铁打的营盘流水的兵，转岗或者离职这种事情每天都在发生；
②有服务器的同事回老家啦；
③有个北方的同学回家里转行不写代码啦；
④更多的人还在各自原来的岗位上坚守与付出;
⑤加班多已经不需赘述，对UC来说，加班最多的应该是研发。不过出乎意料的是，对阿里集团来说，加班最多的并不是研发，好像是运营？客服？或者其他某个岗位？比如这位潘洋同学所在的岗位
——“在阿里，加班是应该的，不加班也是应该的，只有完不成工作是不应该的。”
三.阿里相关
从员工角度分析公司的好与不好的地方
好的方面
①虽然集团在进一步整合UC，包括最近职级都统一了，不过阿里的HRG政策并没有渗透过来，UC还是相对比较人性化；
②战功导向的企业文化，员工激励还算不错的（尽管跟我没啥关系）；
③没有水分的五险一金和额外商业保险；食堂包餐；饭后水果；每月团建经费；免费体检以及体检时的阿里特别取号通道；
还不错的办公环境和基础设施。还有一些阿里的福利，比如iHome无息贷款一类；
④工程师文化还不错，公司大牛多，内部分享和培训也不少，对个人能力的提高有明显的助推作用。集团内部开发工具共享，很多我们遇到的问题可以用集团的工具或其他部门的方法来解决，一定程度上避免了重复工作；
⑤阿里光环对阿里人在外部是一个加分（装逼）项，对个人职业生涯大多也是加分项；
⑥贵司各种制度比较成熟，基本到了公司就什么都不用管，安心（加班）工作就好；
⑦听说有不少妹纸来UC或者阿里内网论坛征友相亲，拯救单身狗哪家强？
⑧再一次强调，超赞的饭堂（仅限于UC广州）。
不好的地方
①加班有点多，有会战的传统，每年总有那么几个月要996，直接导致员工的业余时间太少；
②自上而下的产品决策机制，让人有一点面向领导做产品/编程的感觉。可能跟公司基因有关，整体上感觉产品能力比鹅厂还是差了一截，研发都能感受到很多时候产品同学对于以后的产品方向心理也根本没底；
③拥抱变化的次数略多，加上本身战功导向的企业文化，如果掉队，公司不会给你太多赶上来的时间，由此造成焦虑感略多以及归属感的缺失；
④相对小公司来说，沟通成本较高，工作效率也会低一些，这也是通病了。
四.关于团队
iOS小组内部团队氛围特别好，因为森哥的存在，团建特别有水准，禄鼎记/炳胜/外婆家/海记牛肉/希尔顿自助餐/萝岗烤全羊等等，好多餐厅都是来了这里才去过的呢(^__^) 。
另团队内部管理还是比较扁平化的，沟通上基本没有太多的顾忌，大家都是纯粹的程序员（手动微笑
下图可以说明我们组的组内文化：
贴两张篮球4V4的图片作为结尾：
一周年happy~ 愿与大家共同进步。
ps:本文仅以移动事业群广州分部为例，集团各BU情况不太一样，不具有广泛代表性（如果有阿里同事看到请不要代号入座）。
