创过业的人都知道，创业初期是人均产出最高的时候，有时前一天大家吃饭时讨论出一个想法，在第二天晚上就看到这个功能，第三天也行就上线了。那时并没有分工一说，所有人都兼职测试、客服、市场、网维甚至前台……总之人员足够少的情况下似乎什么都可以干，也什么都得干。在这种时期面临的问题也较多。比如没有美术设计师便去找有一点设计基础的朋友；没钱买服务器带宽只能”借”，说是“借”是因为不知道什么时候能“还”等。总之就是各种忙，没有休息的时间，当时最大的希望就是尽快好起来，那样自己能专注做一些自己更擅长的事情。
业务稍微好转一些，有那么“几杆枪”后创始团队本以为会松一口气，其实会迎来新的一轮挑战，尤其对没有创业经验或者没有高层管理经验的团队。因为他们总以为此时终于可以更专注于思考业务和产品，但突然发现有好多事情都想做，这也令开发团队不知所措。不仅如此，随着业务的增长运维问题也开始显现。在我看来此时如果团队能开始“精益创业”和“敏捷开发”结合起来是个有效的方案，这两方面都有比较好的书，就不赘述了。这个发展阶段下公司的抗风险能力比较差，如果开发团队掉到“坑”里，那么公司就很危险了。而此时的研发负责人会面临第一次管理困境——人少又没钱找很贵的人才，如何凝聚和发挥大家的优势便成了大问题，此时就需要找“外脑”咨询，尤其是有创业经验的人。
迈过上面两个阶段，当公司发展到几十人的产品研发团队时，呱呱曾经陷入过项目管理混乱，那时候公司的市场人员、业务人员、产品人员都给研发人员提出了需求，而且看起来似乎都是对的。直到有一天公司决策层发现重大项目推进比较慢，便开始梳理研发团队的事情，一梳理吓了一跳，需求多到有些都忘了是谁提出的..... 然后公司立马决定“收权”，所有需求必须经过相关产品人员审核后才能进入研发，即使是研发内部的系统优化，如果超过一定工作量也需要经过产品经理同意。同时，公司引进了一套项目管理系统，把需求管理和研发任务纳入系统，对应负责人把控里程碑，由研发及产品Leader对完成的子任务进行审核，所有人员都可以直接打开电脑看到项目的情况，也不用去挨个问了。这样我们就很快渡过了这个阶段，并保证了后续业务的拆分和发展。
从上面的几个阶段也许大家能理解为什么二次创业容易成功了，其单在如何避免研发资源的浪费上就可以带来可观的收益。如果没有经历过这个研发“从小到大”过程，比如大公司的高管去管理小团队时容易犯的一个错误就是“照搬”。我就曾听说过某知名企业高管在创业的时候把原理的项目管理流程用在了一个不到10人的团队上，结果大家觉得所有事情大家都很清楚，却投入大量精力去走流程，以致开发人员认为这是不信任，对团队造成了很大的负面情绪。
其实所有流程和事情都需要针对人员的规模和水平进行调整。开发团队人员很少或者在业务不稳定期就需要考虑设计文档的必要性，测试用例的粒度也要根据人员的水平和业务情况进行调整。但我个人不建议省掉测试用例，哪怕只有几条或者停留在口头层面，尤其是开发人员同时兼任测试人员的时候，因为研发工程师的出发点就是我的程序是“没问题的”，而没有测试工程师那种“看我能找出几堆Bug”的使命感。有很多人有一种理想，就是“前期规划和设计好，后期就会如期达到目标“，而实际上项目的复杂度和不确定性是超乎一般人考虑问题的细致程度的。
组织过婚礼或者装过修的人都能感触到其中的各种“意料不到”，其实这些事情也是“项目”，项目周期越长越不可控所以建议吸收“敏捷”的思想。另外建议产品和研发负责人学习“精益创业”的思想，其降低研发做错误需求的成本和降低业务的机会成本上是非常有效的。
我们需要更多经验分享及总结，因为犯错不可怕，但犯别人犯过的错很可惜。
)
