入职一年多，在大公司里面学到了不少东西，比如学习了模块的开发流程，了解了公司的许多业务系统、模块，也体会到了不少工作中的“狼性”。但是工作的这一年多，尤其是最近这段时间，也感受到了大公司的一些“病”，今天来吐槽一下。（可能并不一定就是病，也可能和自身的理解有关，我这里只是罗列一下，仅代表个人观点）

会议太多

周一到周五，几乎每隔一天就要开上一次会，会议时间有长有短，短的15分钟，长的要开上一下午。虽然大部分的会议时间并不算很长，但也严重打断了我们RD的思路。经常是问题想了一半，然后被拉过去开会，开完会再试图把上下文切换回来，结果花费很长时间，说不定中间再被一个事情打断，那整个下午（或者上午）就算是废了。

大多数的会议，内容就是在过进度，PM这周做了哪些事，RD开发到什么进度了。这种事情大家每天写在一个公共的地方（比如日报、周报系统），让大家都能看到也就行了，不必每次都把所有相关人员聚到一个专门的会议室。大家来会议室，也都是带着自己的笔记本电脑，做自己的事情。做自己事情的效率、以及开会的效率都很低。

项目太多

公司大了，不管旧的项目维护，还是新的项目开发，都渐渐多了起来。这样一来，一个人所涉及到的项目也就多了起来。作为一个RD，经常需要维护A项目的升级、排查B项目的bug、再进行C项目的开发。你的C项目开发正进入状态的时候，让你再弄一下啊项目A和B，换做谁效率都高不了。对于QA，可能更悲剧，公司QA人手本来就少，结果项目、模块越来越多，QA经常一个项目接着一个项目进行测试，之前我甚至看到过一个QA的签名是“同时测10个模块……”，这么赶，测试case就不一定想得很周全了，线上出现问题的概率也会越来越大。

人员比例失调

不知为何，公司里面，PM（产品经理）：RD：QA差不多是3：2：1 这么个奇怪的比例，按我的理解，PM：RD：QA应该是1：2：2.5才比较合理，RD和QA，都算是开发，具体什么比例其实可以比较灵活；至于PM，应该保持少而精，1~2个人就能撑起一个规模不小的项目。对于目前公司PM的人数，我觉得是太多了。经常1个RD需要接口5~6个PM，别说是5、6个PM，就算是2、3个PM同一天有事联系你，也够RD同学喝一壶的，要是5、6个PM每周“均匀”地“骚扰”你，你也别干什么事了。

而且，许多PM同学也都是新人，经验明显不足，本来PM应该是给项目规划好一个大的方向，协调各方、共同朝这个方面努力的。结果许多新的PM是在一边参与项目，一边学习，能不添乱就已经很好了。许多PM，连基本的处理数据的能力都欠缺。经常是，PM有一个数据的需求，RD在服务器上运算好了，PM不会登录服务器，需要RD线下或者邮件提供，有的甚至一定要Excel格式的才行。数据里面多了一列、多了个逗号啥的，PM就不会处理了，需要RD调整一下格式再提供……

不过话说回来，还是有些PM是比较给力的，文档写得明确、数据也能自己处理，有的更给力的直接对RD说，“把mysql的账号密码告诉我，我自己跑sql”，对于RD来说，遇到这种PM真是件令人愉快的事情！

KPI

这个算是老生长谈了，每半年或者一年，大家都需要回顾一下过去，并对自己所做的事情打个分，还要展望一下未来，对于半年甚至一年之后的事情，做一下规划。回顾下过来也就算了，这是有必要的。对下一个半年进行规划，这就有点勉为其难的。比如项目刚刚开展实验，还不知道效果怎么样，如何确定半年里面对这个项目做规划，或者说半年里面，这个项目做不做还要打上一个问号呢。

另外，不同职位上的同学对于KPI的理解和要求不一致，也会导致许多问题。比如对于一个商业产品，PM的KPI会是指这个产品给公司带来了多少收益、新增了多少客户；而对于我们RD同学，我们KPI的定义除了收益之外，还有这个产品中的系统的稳定性、能够承受的性能指标，还有比如采用了什么新的技术，使得系统扩展性更好、同时减少人力的投入等等这些。

这样一来，双方为了达到各自的KPI，所采取的行为可能就是相悖的。比如对于一个新的商品产品，PM想到的往往是接几个大客户、大单子，这样一下子PM的KPI就很容易达标了。而如果是这样的话，对于RD来说，所需要做的工作可能就是：开发一个能够满足功能的系统、修改下配置、上线这几家客户。这对于RD来说，意义很小。

RD的想法一般是接入许多中小客户，使得大规模的客户能在系统中运转起来，产生规模效应，RD在这个过程中就可以依据线上的效果，对系统进行迭代的升级，以提高这个产品的整体收益。不过整个过程肯定是要花上不短的时间的，PM可能对于这个时间就不能接受了，毕竟接大单子一下子就有不小的收益，还体现了PM的工作能力，PM何乐而不为呢。

不过，KPI这种事，就像是高考一样，虽然有各种各样的弊端，不过对于一个有上万乃至十几万人的公司来说，可能已经算是最公平的方法了，谁让我们在一个大公司呢，呵呵。

—EOF—–