专栏名称: 码农翻身

工作15年的前IBM架构师分享好玩有趣的编程知识和职场的经验教训，不容错过。

小李在外企

码农翻身 · 公众号 · 程序员架构 · 2016-09-19 21:58

正文

小李所在的公司经营不善，换了个CEO, 新的CEO曾经任职于某知名外企，上任后急于重振雄风，不断就给大家打气，在一次员工大会对大家说：

“我们虽然是个小公司，但是灵活，效率高，船小好调头啊，我在外企的时候，公司虽然很有实力，但是机构臃肿，决策复杂，有一次有个东西需要审批，要层层的盖章，你们猜猜需要盖多少次章？ ”

“五次，八次，十次... ” 大家都没猜中，最终CEO揭开了谜底：

“整整28次！”

小李被惊到了，什么事情需要28次的审批才能通过，这样的效率该有多低？这不可能吧？

提到外企，小李脑海中全是光鲜亮丽的白领形象，心向往之。

过了两年，小李在机缘巧合之下也进入了这家外企，呆了几年也没有见过需要审批28次的情景，小李想这要么是个非常罕见的个例，要么就是自己级别太低，无缘相见。

但是审批的确无处不在，刚进项目组的时候，为了把自己的开发环境搭建起来，小李的师傅指导着他可真是忙活了很久啊。

虽然公司的日常OA账号在入职的时候已经创建了，接下来要还得申请巨多的账号，特别是这些账号的申请流程还都挺复杂，所以前辈们把申请过程仔细的记录了下来，存放在一个文档数据库里，方便后人查阅。

可是令人想不到是，这个文档数据的的访问权限也需要申请！

小李算了算，这些需要申请的账号包括：数据库账号（开发库，两个测试库），源代码访问账号，文档库账号，应用服务器账号，应用服务器控制台访问账号， Bug 系统账号，生产系统支持账号

服务器维护系统账号，这些统统需要审批，甚至是测试系统内为了获取某个角色，也需要特定人的审批，一句话，你能想到的账号几乎没有不需要审批的。

如果中国人审批还好，如果是需要国外的审批，那至少得等一天 -- 因为有时区问题。

小李花了近一周的时间，这些账号才陆陆续续的弄好。

小李经常想，这些审批真的是需要的吗？

正式的开发工作展开了，小李发现，之前的审批完全是毛毛雨，跨地域，跨时区的协作才是大问题！

小李也看过一些全球化协作的文章，听起来很美好：中国人白天干，下班前提交代码，晚上美国人能接着干， 24小时轮流转。

但实际情况呢？　小李团队的需求主要在美国提出，开发分散在美国，印度，中国，项目管理在欧洲展开。

小李的工作有一些和美国团队有接口的交互，　这一天小李遇到了一个问题，　可是白天没人能回答，　只好发个邮件出去，等待回复。　

第二天一上班，小李就兴冲冲的打开邮箱，心想着今天可以继续开工了。　

可是邮箱里空空如也，没有任何新邮件，　可能是美国同事太忙，　忘了回复了吧，　小李又追发了一封信，还特意把优先级置为“紧急”。

第三天，回复果然到了，悲催的是这位美国同事没有读懂自己的问题（可能是英文太差，没有描述清楚），回答的驴唇不对马嘴。

小李还想再发邮件，被师傅制止了，师傅说： “小李，这样下去太浪费时间了，你晚上9点上线直接去找这个美国同事，在线沟通吧”

从此以后，晚上自主加班，上线和老美交流需求和接口变成了一种习惯，每天晚上不上线的话总觉得有什么事情没有做完，浑身不自在！

小李经常会怀念原来公司，有什么问题直接跑去一问就行，面对面沟通，效率极高，小公司就有这样的好处。

唉，在同一个地方办公是多么重要啊。

随之时间的推移，小李慢慢适应了这里的流程，学会了用各种各样的流程工具去完成工作。

如果数据库表需要改动，就要按照流程在系统中给DBA开一个ticket（意思是说这里有个事需要你去做，给你发个通知单）， DBA看到以后（只是不知道他什么时候能看到），就会去处理，把处理的结果放到同一个ticket中。

想修改一下应用服务器的配置，到另外一个系统中开ticket, 管理服务器的人自然会去处理。

想部署新功能，开ticket, 想查看生产环境的数据，还是开ticket, 这家公司的流程极为完善，令人叹为观止。

这些流程就像一张大网，把每个人紧紧的包围起来，只要按照流程办事，基本不会出错。

自己的项目按部就班的开发，每年按计划发布那么2-3次，只是最近发布时感觉有些不爽。

按照公司规定，对于生产环境开发人员是没法去碰的，只能由运维人员来处理，之前项目有个固定的美国运维小哥，对项目非常熟悉，部署是驾轻就熟。

后来公司为了节省成本，采用了一个“运维人员池”的形式，这一次是墨西哥的运维来部署，下一次可能就换成了阿根廷人。公司是节省了成本，可是每次都是新人，对项目了解太少，偏偏自己的项目部署是又异常复杂，手工操作特别多，每次都得费劲口舌给这些新人重复的解释部署过程，即便如此，还是时不时的出错，让人崩溃。

小李提了好几次自动化部署，并且已经在测试环境实现了，确实能极大的降低工作量和出错的可能，但是生产环境的运维就像一个独立的王国，水泼不进，针扎不进，一直我行我素。

由于涉及到跨组织的协调，不但是小李，就连小李的经理都没法办法，只有期待着哪一天公司组织的变革了。

小李慢慢的发现，自己每天真正的工作时间越来越少，时间都被会议给占据了，好像所有的事情都得由开会来决定。

每周有三次需求沟通会，两次项目进度汇报（一次是全球的，一次是中国的），一次开发人员沟通会。

还有不确定时间的技术分享会议，专利想法讨论会，更不用说参加了社团以后各种各样的会议了。

后来采用敏捷软件开发，每天还有15分钟的站会，可惜的是只是学了个形式，没有学会真正的神韵。

会议白天有，晚上也有，小李感觉每天的工作都是被会议所驱动。

会议室成了公司最热门的资源，为此公司还特别开发了一套会议室预定系统，每月开始的时候，大家都需要去抢会议室。

会议如此之多，有时候为了防止冲突，协调与会人的时间，一个会议的时间被迫不断调整。

如果你听说专门开个会来讨论什么时候才有时间开会也不用感到惊奇了。

这些审批，流程，会议还不算什么，最让小李觉得不爽的是自己的技术能力没有办法充分的施展。

自己所负责的是一个非常古老的遗留应用，上个世纪写成的，技术成熟，框架成熟（恩，其实是前辈们自己写的非常简陋的框架）。

现在每次升级，每次都是小打小闹的根据业务改一点点，完全没有机会去设计一个稍微大点儿的东西，没有办法展示自己的设计能力。

小李有点担心，现在技术发展这么快，虽然自己也在跟进，但是没有机会去在项目中实践，在这里长久待下去，一直吃老本，技术可能要废掉啊。

后记：外企虽然有很多让人不爽的地方，但也有很多优点，下回再说，敬请期待。

你看到的只是冰山一角，更多精彩文章，尽在“码农翻身” 微信公众号，回复消息"m"或"目录" 查看更多文章

有心得想和大家分享？欢迎投稿！我的联系方式：微信：liuxinlehan QQ: 3340792577

公众号：码农翻身

“码农翻身”公众号由工作15年的前IBM架构师创建，分享编程和职场的经验教训。

推荐一个叫掘金的开发者社区，很多技术干货，我的文章也会在这里分享：

掘金是一个高质量的技术社区，从 Swift 到 React Native，性能优化到开源类库，让你不错过互联网开发的每一个技术干货。长按图片二维码识别或者各大应用市场搜索「掘金」，技术干货尽在掌握中。