我在两家创业公司工作过。A公司，由3人发展到20人；B公司，由20人发展到60人。这两家公司都不算成功，因此，要讲收获，更多的是经验与教训。就如同教材一样，反面教材更加有教育意义。我针对创业公司面临的重要问题，谈谈我的想法。
灵活性
相对于大公司，小公司的灵活性是核心竞争优势。小公司的灵活性，是指小公司船小好调头，能够快速地响应用户。我在B公司时，公司刚好处于创业扩张期（20→60人）。公司也就是在这个时候失去它的核心竞争优势的。
初到B公司，公司的情况是：已经做出了产品，有一些铁杆用户，有投资者表示愿意入股，希望在两三年能够上市。上市，则要求公司在人数上，管理上发生一些改变。我们公司实施了如下举措：
一、将技术部细分为各个小组。如Android组、iOS组、Web组、通讯组、架构组等。为了让公司的整体技术实力提升，公司花重金为每个组都招来工作经验丰富的人带队。在之前，两三个人通过简单的沟通就可以完成包含 Android, iOS, Web 前端以及后台服务的整个软件。现在，要完成这样的软件，需要各个组的组长相互讨论，得到一个相互妥协的结果。
得到妥协的结果存在三个问题：（一）花费的时间长；（二）各个开发组长更多会采取各为其组的策略，而不站在全局考虑问题。各个组长所花费的力气不是共同的产品目标上，而是各组的局部利益上；（三）因为结果由多个人共同决定，这样会导致没有承担责任的人，大家会相互推责任。
三个问题直接的结果就是，公司处于船大难调头的局面。这个时候更需要的是一个能够站在全局进行快速决断的人，并且这个决断的人能够说服各个小组接受已经决定的方案。因为此时的公司还是一个小公司，还需要保持灵活性，保持快速反应能力。
二、成立项目部和产品部。也许是为了让公司看起来更加有规模，公司需要新招一些员工，并给这些员工安插一些事情。项目部与产品部就招了很多员工，用来计划和管理开发部的工作流程。新招来的员工有两个问题：（一）经验不足，很多是刚毕业没多久；（二）缺少技术背景，无法管理技术研发。与此同时，各开发小组组长都是工作经验丰富的人，本身就具备一定的管理能力。当被其它部门的人管理的时候，会存在不配合的情况。
比如，项目部要管控进度，开发组会尽可能多要时间，项目部无法评估时间的合理性。小组与小组之间推责任的时候，项目部也无法决断应该由谁来担当起相应的责任。产品部做出来的产品设计，往往不考虑开发实现的代价，结果导致开发的时候，花大量的时候来满足产品的非核心功能。这些情况使得项目部与产品部不得不间接地管理。
所谓间接的管理，就是，项目部招集所有的开发组成员给自己评估时间，然后与开发组在时间上进行讨价还价。比如，Web组评估时间需要1个月，项目部就会说，1个月太长了，我们半个月就要提交给客户演示……产品部则通过开发组（而不是用户）来找产品设计的缺陷。比如，Android组发现按照产品的设计实现代码会与Web端不一致，这反过来促使产品部重新考虑如何保持产品的一致性。
间接管理使得整个公司在内部不断地消耗人力资源。一个把产品做出来的部门不仅仅要把产品做出来，还要应付项目部、产品部的管理。这样的组织形式很难适应快速变化。
在公司度过创业初期，准备扩大规模的时候（20→100人），往往重视的是单纯地扩大规模，而忽视了继续保持创业初期的优势——灵活性。使得响应用户的时间拉长，用户的增长速度减缓。一个企业的价值高与不高取决于用户，而不是公司的管理水平和技术水平。只有快速地响应用户，才能不断地提升公司的价值。
确实存在的用户
我在A公司的时候，公司只有7人。两位创业老大和5个刚毕业的学生。我就是学生中的一个。当时老大刚从大公司出来，有一定的业务关系，可以容易地拿到客户订单。我们初期就是针对一个客户做项目，做了两年。在这两年内，公司还是有些营利的。这正是因为有确实存在的用户。
公司为了发展，转做了一个互联网产品。做产品的时候，公司往往容易忽略实际用户，更多的是自己去想像出一些用户，然后按照想像的用户需求去设计产品。我们公司就是这么做的，结果产品的实际用户量比较少，并且难以增长。这使得我所在的A公司陷入被动的位置。
在公司创业初期（2→20人），一定要做有确实存在的用户使用的产品。产品虽不完美，但如果确实能够解决用户的问题，用户也会有比较大的容忍度。并且这个时候的用户都是专业级的用户，所提出的建议对完善产品有着巨大意义。在产品完善之后，这些用户还能够通过口碑将产品推广出去。因此，有着确实存在的用户是创业用户成功的必要条件。
定义产品版本
对于做一个产品，我建议的版本管理如下：
| 版本号 | 版本名称 | 版本描述 |
|---|---|---|
| v0.1 | 开发版 | 针对于铁杆专业用户，解决他们的实际问题，并且根据用户的建议不断对产品进行完善 |
| v1.0 | 正式版 | 能够系统地解决所在行业的问题，代码可能不容易维护，效率可能不高 |
| v2.0 | 升级正式版 | 针对第一版代码问题进行彻底重写，解决维护性及效率不高等问题 |
| vx.0 | 后续版本 | 这个时候公司已经运作起来，后续版本根据公司的运营进行调整 |
对于创业初期到扩张期，所需要关注的主要就是前三个版本。
开发版(v0.1)。可以快速出来一个可用的产品，能够确实解决某个领域的用户的实际问题。这里强调一点，如果出来的版本过早，导致并不能解决用户的核心问题，会让用户失去信心。但又要防止想开发出来一个完美无缺的系统的行为。简单来讲，就是开发出来一个具有核心功能的产品，让用户在使用的过程中对产品完善。在完善的过程中，可以进一步推出 v0.2、v0.3 等版本。
正式版(v1.0)。这个版本出来的时候，用户已经能够系统地解决所在领域的问题了。比如，一个销售系统，核心功能是进销存功能，用户在使用的过程中会产生如：报表生成，工资管理，人员管理等功能。这些功能在 v0.x 中进行不断地完善。到 v1.0 时，用户已经可以使用这个软件解决整个销售环节的问题了。
升级正式版(v2.0)。v1.0 是通过代码的修修补补不断地积累而成的。代码不容易维护，在初期也无从知晓性能的瓶颈会出现在什么地方。在用户在实际生产中使用 v1.0 的时候，性能问题就会出现。这就是升级正式版要解决的问题：一、重新设计整个软件，让代码易于维护；二、解决 v1.0 出现的性能等问题。
招的人越多越好吗？
创业公司要尽可能降低运营成本。在公司选址，人员招聘，费用支出方面，都可以想办法节约。对于软件创业公司，最大的支出项就是人力成本。公司支出了高昂的人力成本，是否能够达到预期的效果，这就是我接下来要说明的问题。
软件行业有一本20年前的著作——《人月神话》，里面所讲的内容到现在还非常适用。书中提到软件开发的核心：保持概念的统一性。开发人员多了，为了保持概念的统一性，可能需要花费更多的时候去交流，进而造成时间上的浪费。即， 第一、人多并不能使得开发速度变快 。同时，因为交流当中会产生歧义的理解，会造成概念不统一。即， 第二、人多会更加有可能在软件中引入BUG 。
所谓保持概念的统一性，就是指，一个软件的各个部分和谐地统一在一个软件当中。软件的各个模块相互配合，完成软件的整体功能。打破概念的统一的情况是，开发人员只看到局部，并不理解全局。做好局部的同时给其它局部引入问题（引入BUG）。这需要各个局部的开发人员一起解决冲突，这就会产生交流的时间浪费。
因此，一位月工资 1W 的程序员的工作效率并不会比总工资 1W 的三位程序员低。特别是在创业性的公司，程序员是为自己而工作的时候，会更加有效率。
当然，并非人越少越好。一个创业公司，主要的问题是：一、将产品做出来；二、将产品卖出去。人的多少依赖于这两点。要招的人要么是能够将产品做出来的人，要么是能够将产品卖出去的人。
招人之后，是以合作的方式，还是其它的方式来发挥人的积极性，也是需要考虑的。让一个人有积极性容易，让十个人都有积极性非常难。
软件创业对人的要求
一个软件创业公司至少需要两个人，一个负责将产品推出去(CEO)，一个负责将产品做出来(PA)。如果 CEO 对技术有所了解的话，会更加有优势。
CEO 需要具备以下的能力：
- 说服别人，让别人接受自己
- 遇事能够沉着冷静处理
- 强有力的整合统一能力
PA(Programming Artist) 需要具备以下的能力：
- 掌握软件从需求、设计、实现、测试、运维的各个生命周期所需要技术
- 有黑客的特点：好玩、高智商、探索精神（摘自《黑客与画家》）