【深度长文】老IT公司怎么做到像创业公司一样快

现在的人啊，由于短信微信消息的阅读习惯影响，因此现在都很难阅读超过1000字的东西，所以必须写小品文，每次写一个点，才能让读者理解。所以我过去一块块写了不少聚焦单点单方面的文章，其实我是一套框架思路，我给串联一下

（1）整体策略

一、指引

给战略方向，但不要做战略管理。

给目标约束，不能给细节行动约束

二、预算限制方法

战略规划按照三三制，每个战略项目最多不能超过3个月。如果做不到，就打回重做，或者拆分成两个战略项目。但是按照三三制，一年也最多只能做3个战略级项目。所以预算不会漫无边际

三、时间进度限制方法

不能憋大招。有仗打仗，没仗造仗。一年故意设计两场大仗大促。做的战略项目必须在这两场大仗中生产上线、兑现执行、展露出战略项目的实际成果。这就叫交作业大考，要经得起考验。所以有大考时间倒逼，所以战略级项目的时间、预算都不会漫无边际

大仗，能看穿人、历练人、发现黑马人、有上位真实证明成果。

四、组织匹配

全职能小团队。比如一个研发团队，有产品经理、UI、架构师、前端开发、后端开发、测试。都是铁打的营盘流水的兵，聚焦做好业务应用创新突破。

不用担心专业提升问题、不用担心人才能力提升问题，打大仗是最好的历练提升方法。

不用担心组间交流问题，只要做好每周大讲堂即好。反正有开放源代码、开放项目管理系统/文档管理系统/需求管理系统/bug管理系统这些共享资源，让大家都知道其他人在干什么。

不用担心资源重复浪费问题。效率机会窗口比成本更重要。更不要想着如何做资源共享节省成本的事，大量员工都是中庸人，往往共享的地方就是最塞车最打架的部分，擦屁股、做调解的成本更高。

五、组织激活

鼓励并强制人员自由流动，只有有部门接收就可以转岗转部门。如果你在一个部门一个岗位待了3年，还必须强制转部门转岗，防止熟路懒政、惯性思维、山头队伍坐大、组织僵化其他新人没有上位机会、找到腐败窍门。

一个团队大于20人自动拆分、一个团队人跑路的小于7个人自动取消，让管理者无人可管。这样就保证谁不千方百计突破创新往前跑往前增长发展，他的手下就自然先跑路了，人往高处走水往低处流，自然法则

六、人才激活

重奖之下必有勇夫。尤其在IT界，一个卓越的人才，可以抵得上100个中庸人。IT界不能拿堆人来缩短周期，反而因为中庸人太多都搞成泥潭烂摊子。

所以高薪高期权高创新自由度高自主决策性，这样筛选的人才也自然在个人素质、自我约束管理、专业能力上高其他人一筹。

七、产权激励

最好是独立成公司，对外估值对外融资对外收购、对内期权赠与、在美国上市而且还是美金市值（国内A股市值不死不活，而且还是人民币市值，而且有好多增长要求利润要求）

八、创新

不用规定死每个部门能做什么不能做什么，这件事该归哪个部门应该去做。面对业界创新业务和创新模式，每个部门都可以去做，谁跑的最快，其他竞争部门都落败下去了，那么这块新业务就归谁。

宁可自己把自己革命，不要让外部公司把自己革命了。

另外，不用非要全部想明白才做，不要等层层审批通过后才做。直接开干，每个部门都虽说有自己的主业主要战略项目，但是如果你真的想干新业务，那么你部门自己去想办法挤出时间挤出资源去干，想借助新业务理由去扩编扩预算，没门。

（2）产品：五条军规

需求是一切行动落地、成本消耗的起源。其实大部分需求都是伪需求，根本不产生收益。企业软件界有句话：不买单的需求都是伪需求。电子商务界也有句话：不能拉升业绩指标的产品设计都是伪需求。

第一个原则：产品设计，必须为提升流量、转化率、客单价、推荐率、复购频次、库存周转率、现金周转率而负责。如果不为这些指标提升，就不能提出产品需求。拿经营数据说话，拿经营数据说话，拿经营数据说话，重要的话说三遍

第二个原则：每批次提需求，只能满足一个指标提升为主要目标，本批次需求要全部紧紧围绕这个指标目标而服务，不能包含多个目标

第三个原则：不能憋需求搞大规划，最长项目必须从规划、需求调研、设计到真正生产上线就最多两个半月

第四个原则：必须每周至少生产上线一次，不能憋在最后一周生产上线

第五个原则：必须灰度发布

（3）研发：快速迭代

一、关于顶层架构设计与系统重构

如果公司业务不行垮了，技术债就不用还了；如果公司业务迅猛发展，也没啥技术债，因为不断的有新业务，而且业务可能生命周期很短，很多没多久就被抛弃了，所以干脆不用去解决；技术债，大多存于不死不活的公司，所以大家心态要放稳：一开始就煞费苦心做顶层设计是傻X的，重写才是正道。

但很多人害怕重写，都想做重构。首先来说，重构是高成本的、复杂的，还不如快速重写。而且重写我说的也不是整个系统重写，而是你实现了微服务架构后，你是一块块重写的。

那重写的时机是什么呢？就是性能瓶颈，一年两次故意大仗大促，故意堆积流量，故意形成性能压力。为了一个个打掉性能压力瓶颈点，你就会自然对一个个瓶颈点进行重写或技术架构大变动。

二、关于技术架构

1、技术平台：积极拥抱开源、拥抱公有云，在业界成熟的Open API、中间件基础上做事

2、微服务：业务功能都做成微服务即可。一个小服务烂，只烂它自己的，它重写就重写它自己的，不会把问题蔓延影响到其他模块和整体。这样稳定性、维护性、运维性，都很好

三、关于软件工程流水线

1、代码平台：代码集中，对全研发开放，但只可读，这样大家都知道其他人在干什么。各个研发team内管辖的模块代码，全组可操作。

2、DevOps平台：统一的自动化编译、自动化测试、自动化大规模分布式部署、灰度上线、热补丁更新

3、自动化运维平台：统一的用户行为跟踪、流量统计、日志监控预警工具平台

4、软件工程管理系统：项目管理系统、文档管理系统、需求管理系统、Bug管理系统。系统要对全研发开放，但可只读，这样大家都知道其他人在干什么

四、快速迭代上线

和产品经理一样的原则：必须每周至少生产上线一次，不能憋在最后一周生产上线