其实整个创业的过程就像倾倒一瓶金黄色的青岛啤酒，从胖胖的酒瓶肚子里，突破那长长瘦瘦的瓶颈，经过漫长的等待，最终喷涌到啤酒杯壁上，溅起厚厚的啤酒沫，直到举起冰凉的已经结了水雾的啤酒杯一饮而尽的瞬间，才将那漫长的、通过瘦长瓶颈的等待、痛苦和焦虑抛之脑后。我经常这么鼓励自己，创业就像倒啤酒喝，当鲜美的啤酒在突破了瘦长的瓶颈后，最终那甘美的佳酿就是你的战利品了。而这个过程中最痛苦，最漫长的，是等待啤酒冲破瓶颈的时候。
最近我也经常调侃说：“随着大姨吗用户量发展成了第一，我们也拥有了国内人数最多的专研女人月经的团队，50个人每天8小时都在研究月经，那是相当壮观的景色…”。从创业最早的4个人团队，慢慢成长为一个50人的团队，期间遇到的瓶颈和挑战非常多。比如与用户共同改进产品、与投资人谈判资本回报、与有关部门协调法税、与员工博弈报酬的多少，当然还有与恶意的抄袭者盗版者争斗领地。任何新兴的创业团队也和我们一样，会面临无数的瓶颈和分歧，而遇到瓶颈时往往先是手足无措，然后….一般会出现下面三种情况：
乱成一团吵架 上级指责下级 同级较真起来的话，结果往往是你走我留，我走你留
其实不管吵架与否，大家都是热爱这个项目和公司的，问题往往在于遇到瓶颈和分歧的时候，大家很难冷静下来分析问题的根本在哪里。尤其是随着创业者年龄越来越小，越来越混搭和跨行业，导致管理方法的缺失。其实很多大公司都有着冗长的管理教条，效率低下，但是问题最终却可以被正确解决。而许多创业企业虽然脚步轻盈，但是却因为不懂得如何找到瓶颈的根本，导致发展受限。就像以前带兵打仗，有的将领可以管好10个人，有的将领就可以管好10万个人，这里面的管理哲学和方法，其实是需要创业者去不断学习的，当然之后还要根据自己的情况不断优化。方法论到最后并不重要，但是不会方法论则万万不可，经历过无数瓶颈的大姨吗一直使用着一个叫“COPR模式”的简单模型，辅助我们快速找到公司发展瓶颈的根本，然后解决它。这个方法其实最最重要的就是可以让人冷静下来，理智地将吵架和指责的能量转化为分析能力和生产力，最终解决问题。
先说COPR，是不同类型的瓶颈的缩写，Capability（能力），Occasion（事件），Process（流程），Regulation（制度）：
第一种瓶颈：Capability，能力带来的瓶颈，这样瓶颈的成因一般是因为没有能力去完成某事。比如我就不会编程，如果团队里也没有会编程的，我们就自然而然做不了软件开发。
第二种瓶颈：Occasion，事件带来的瓶颈，一般是突发事件，意料之外的事情，规划之外的事情，比如本来做活动谈好了的赞助商，忽然跑单了…
第三种瓶颈：Process，流程带来的瓶颈，这个瓶颈有很多触发因素，比如公司的开发/生产/服务流程存在缺失或者效率低下的地方，又或许是因为业务拓展新增了需求，导致流程变了。比如以前我们团队还小的时候每个人都是测试员，上线流程非常简单，但Bug也相对多一些，但现在加入了专门的测试环节，那么整个大姨吗开发上线的流程也就应该做出相应的调整。
第四种瓶颈：Regulation，制度带来的瓶颈，无论是公司制度，还是法律制度，总之是顶层规则性的要求导致的瓶颈，比如以前我们所有的版本发布和更新都会要求必须有CEO签字，CEO要对产品品质做出把控，但是随着公司规模扩大，CEO能签字的时候可能往往会错过发版的良机（配合市场炒作或者周末的超大流量），那么这个瓶颈就必须改进。
在三年创业的实战中，我们也总结了解决这些瓶颈的方法框架：
如果发现是Capability能力瓶颈：那么用S解决。Supply补给，Study学习，趣味一点说，S也代表Superman，一个能力无限大的英雄角色，没错如果是能力不够解决不了的问题，最简单就是找来一个超人！换而言之，如果是能力不足导致的发展瓶颈，要么去找补给（外援团队、外包服务），要么去自己学习。比如当年我们从web项目转型移动开发的时候，就要求CTO对移动开发进行了恶补，而同时因为不能耽误进度，我们还采取了半外包的方法，也就是让一个外包开发公司的程序员来到我们的办公场所进行开发，并且让技术团队配合他，同时进行学习，很快产品出来了，自己也有了一支移动开发的团队。
如果是Occasion事件瓶颈：那么用A解决，Action行动，Agility灵活度，趣味地说，A也是24个英文字母中的第一个，代表了速度和优先级。所以遇到突发事件的时候，最主要做的，一定不是哥几个先坐下来开个小会，而是立刻找到最灵活有效的解决方案，并且立刻行动起来。比如前一段时间大姨吗因为出现大量盗版、恶意攻击和严重侵权事件，这个时候从法律、市场、公关各方面就必须并行立刻行动起来。事件瓶颈的解决一定要通过可以量化的行动来解决，把执行具体到跑了几个小时的工作、找几个关键人聊了天等非常细节的层面，在不打乱公司正常运营的节奏和规律的同时，使公司发展尽快回归正轨。
如果是Process流程瓶颈：用O解决，Optimization优化，Overwrite重写。同样，在英文中，O就是一个闭环，流程的通畅也正好代表一个完整的闭环，很好记。流程不光是生产和服务过程中的，也有可能是管理上的，流程瓶颈多是因为增加了新的功能，或者因为某个环节效率低下导致的。这个时候需要大家坐下来，用数据分析流程中出现问题的地方，分析下是否可以通过优化效率、或者调整顺序来解决，如果不能，那么就只能打破流程，重新安排流程的组合了。比如以前我们没有融资也没有盈利的时候，基本是不考虑为自己的产品打广告投的，没钱嘛。但是当公司上了正轨，也就会将一部分利润作为规律的广告投放成本，而这个其实直接影响了产品的开发上线流程，新版本的发布可能会需要配合营销，或者广告位，于是在产品上线的流程中就会将广告同样作为一个参考因素和关键点。
如果是Regulation制度瓶颈：用R解决，Restructure重构，Revolution革命，大家可以这样想象，制度的问题就要靠制度本身解决。所有不合理的制度产生的问题，除非把制度改变了，否则问题都不算得到了根本的解决。所以制度瓶颈要么推翻重来，要么依据现有的结构进行重构。
这个模型中最最重要的是首先学会找到问题瓶颈的根本，到底是能力、事件、流程还是制度瓶颈；其次，学会向下解决问题的方法。所谓向下解决问题就是当遇到瓶颈并且时间很紧的时候，尝试把COPR反过来，用RPOC的思路解决问题。
遇到Regulation制度瓶颈，实在无法解决了，看看能否用Process流程的方法解决，比如对流程进行调整，规避制度的影响，比如苹果官方市场是抵制软件内去推荐其他市场类应用的，那么在上线的时候如果就带有这个推荐，那肯定无法通过审核，而调整下流程，开放一个后台更新接口，先将没有推荐的产品上线，成功后通过后台更新的方法加上其他合作市场，这样也就规避了制度。
而当遇到Process流程瓶颈无法解决时，看看能否用Occasion事件的方法解决，流程忽然被打断或者出现问题，这时候也不应该拖拖拉拉想太久再去做，而是并行地用一些临时性弥补措施，临时事件对流程出现问题的环节进行补充。
特别要强调的是，当遇到Occasion事件瓶颈无法解决时，就需要看看Capability能力方法了。有的突发事件很违背常规，可能不在自己的能力可以解决得范围之内，那么这个时候采用外援，或者突袭学习补充知识的方法是可以及时解决问题的。要理解的是，很多时候Occasion事件瓶颈会让人非常紧张，因为事件的突发性以及当即性，导致被管理团队过度重视，甚至临时性打断原有公司运作的流程，更有甚者让所有团队全部投入到事件的处理中去，结果让正常的流程被破坏，公司的一片混乱。要提醒创业者的是，中国的互联网恶意竞争是常态的，很多你的竞争公司其实很善于用事件打乱你的公司运营，为他自己争取更多时间。其实不用紧张，这正是你的对手产品品质不够好的表现，中国的许多流氓创业者很擅长的就是“既然我成事不足，那我就败事有余”这个方法，要理解他是想拖累你的产品，打乱你的流程。所以越是遇到这样的情况，创业者越要临危不乱，千万不能把Occasion事件瓶颈提升到流程层面去解决，正中了对手的下怀。
但是当最后遇到的是Capability能力瓶颈的时候，那么就只能通过能力补充或者外援的方式解决瓶颈了。
很多时候创始人会一味去提升公司的人数，认为是能力不够，或者人数不够，其实仔细沉静下来思考，发现还是有很多闲余战斗力的，比如好多公司不会迭代开发，非要等到一个产品的成品设计图完全出来了才开始安排程序员开发，其实前期很多数据库架构、数据接口、和基础功能，在设计图的原型方案出来的时刻就已经可以提前开始了，这样可以让设计师并行具体的设计，待底层工作完成了，新的设计图也就出来了，整个开发周期就可以缩短许多，这种情况其实完全可以通过Process工作流程的优化解决，而不是一味追求通过补充能力Capability去完成。
说了这么多，最后，其实最重要的就是冷静下来思考瓶颈发生的根本是属于哪种，而不要在问题的表象上面大做文章，应该去找到瓶颈的根本。本文也只是我们自己在发展中归纳的一些小小的方法论，每次发生问题我们就仔细分析问题的根本，再迅速做出反应。创业团队要保证的是在不停地解决问题，而不是在等待问题被解决。
转自：http://www.chinaz.com/start/2013/0724/310626.shtml
新疆商业网新闻中心编辑风铃网络采集
