分享

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

 快读书馆 2017-12-16


(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管理系统。系统要对全研发开放,但可只读,这样大家都知道其他人在干什么


四、快速迭代上线


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




    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多