【4030】为何要借助第三方力量创业/做产品

这是对前段时间给创业者的一次分享的整理。

 

创业过程中碰到所有问题,最终都可以归结到:缺人、缺钱

也许你觉得还有缺资源,但所有资源也可以追溯到人和钱上,还有缺时间,但这个谁也帮不了。

 

这两个问题,我们分别有两种解决方式:旧模式和新模式。

旧模式缺人怎么办?招人。缺钱怎么办?募资。这是自上而下的模式,传统的『供给驱动』的模式,所以注定只能满足最优秀的公司,或者说,已经证明过自己的公司,很多新团队、还没什么名气的团队搞不定这两个东西,所以我们需要去尝试更多新模式。

缺人的新模式是什么?众包。缺钱的新模式呢?众筹。

这次重点讲众包。

 

一个团队是怎样从一个人发展起来的,逐渐庞大,发展到几个人、几十个人、 几百人的?

 

首先是第一个人,那么这第一个人是个什么样的角色?他每天在想的是我要服务什么目标用户,我要解决他们的什么问题,要做一件什么样的产品出来。这样的一个角色其实就是产品经理。有了产品经理以后,接下来他就需要人把东西做出来。所以我们就需要两种人:技术和设计。这三个角色(不是自然人)构成了一个初创团队,特别是互联网行业,最初的铁三角。他们分别负责三件很重要的事情:产品经理——有用,设计——好用,技术——能用。

团队启动越轻越好,所以最理想的一定是一个人,就是一个『会写代码,有点商业感觉,又有点审美』的程序员,比如facebook的扎克伯格。

 

等你的产品做出来之后,下一个问题就是要『有人用』,所以,广义的『运营』这个角色加入了团队。

随着公司的不断发展,人越来越多,分工也越来越细,技术分成了开发、测试、运维等等,设计分成了视觉和交互,运营细分为市场、销售、甚至客服,而最早的几个角色,通常产品经理变成了CEO、运营变成了COO、技术变成了CTO……对于传统的方式,我们肯定是缺哪个招哪个。

 

然而对于创业公司来说,招人是一件风险特别大的事情。

 

因为你的业务变化太快了,有时候等不急你找到一个合适的人,或者你招来这个人以后发现用不上他的全部能力,只能发挥40%,甚至根本不需要这个人了,或者发现招进来的这个人根本不合适。这时候你就要面对那个最大的风险——时间已经过去了。

 

精益创业的概念告诉我们,做产品要不断低成本试错,其实,用人也是。

那么就可以借助第三方的力量——众包,更常见的说法是外包、顾问……去解决掉部分本来需要招一个人来做的事情。

 

众包服务又分两类。

一类是为了现有的人节省时间的(通常是借力工具),还有一类是借助外面的人力的。

前者,比如做项目管理的时候,本来要花技术组长20%的时间,现在可以借助项目管理的工具,省掉部分精力,要给的APP加一个功能模块的时候,可以借助第三方组件,几行代码搞定。

 

后者,什么叫借助外面的人力?也就是一个共享经济的概念,公司也可以是这样,将来的公司和个人的关系,一定比现在更加灵活。在越来越多的任务的用人上,我们应该有一个『为我所有,不如为我所用』的概念。

 

把『专业能力』做成服务,用『非全职加入某公司』的方式协作,从『好产品』到『良仓孵化器』到『小得』,都在这条线上尝试。想了解更多可以看我公众号的『菜单-服务品牌』。

说到这里,发个小愿,希望有类似想法,愿意一起长期探索的朋友可以勾搭。

 

这种专业能力的贡献,又可以分成四个层面。

第一个层面叫做分享,就是我说你听,借的力可能只是一个想法而已,它并没有帮你做一个事情,而且针对性可能也不是很强。

第二个层面叫做座谈,可以有针对性的讨论,它可以给出一些针对性的建议。

第三个层面叫做咨询,给你指导,带着你做。

第四个层面叫做外包,直接上手。

 

外包形式也会变得越来越多,包括客服可以外包,财务出纳的事情也可以外包,这些都是可以标准化的。

将来可能,越来越多还不那么标准化的事情也可以外包,比如,你产品的1.0版本也是可以交给外包团队来做的(当然,这是早期,而且后续肯定要重构)。

 

Over。

产品设计体会(3004)项目外包不适合“敏捷”

2008春,前几个月尝试做了PM(这次是Project不是Product了),亲身经历了一个项目是怎样一步步不顺下去的。先说明一点:这里的“敏捷”是指甲乙双方配合的“敏捷”,而不是说外包项目本身内部的开发过程不合适“敏捷”。

先说一下背景,项目时间太紧,工期是由商业谈判决定的,没有及时评估工作量,做着做着产生delay,先试图简单的用加班的方法赶上进度,后来被迫注入“敏捷”项目方法,但事后发现“项目外包”模式不适合敏捷。

首先,项目外包使得甲方不愿意砍需求。为了敏捷灵活,公司内部的项目需求在很大程度上是可以砍的,是“保质不保量”,这是符合敏捷的原则的。但是项目外包,甲方在提需求的时候不愿把任何一个功能像平时那样推到2期做,因为项目结束后2期在哪里都不知道,所以“保质保量”变成了“不保质保量”。

其次,敏捷必然导致文档工作不细致,使甲方游离于项目之外的“验收测试”模式难以适应。敏捷从模式上会导致提交测试的产品和最初的需求之间必然有很多变化,并且文档很难跟上,而这种敏捷在公司内部之所以运行的很好,是因为PD、开发、测试在项目过程中可以充分交流,测试在TCTest Case)评审的时候会叫上PD和开发,有些属于详细设计的细节是在评审的时候与开发直接确认,在测试执行过程中也会协助确认需求细节并迭代测试。而项目外包的时候,甲方会从一份颗粒度过粗的需求文档上派生出“验收测试”的TC,又因为验收有“考试”的性质,所以不允许乙方的开发参加甲方的TC评审,导致只能和甲方需求人员确认细节,而需求人员对如此细节又没有要求,无奈之下只能按照自己的想法说,必然导致两边对需求的理解有鸿沟。另一方面,验收测试是一次性的,只有passfalse的结论,没有迭代的过程,不符合敏捷的思想。

最后,国内的乙方通常没有“敏捷”的经验和意识。一般甲方没有独立软件研发能力才选择项目外包(否则多用开发外包),职业性质/国内的项目管理现状决定了外包工程师的习惯是按照详细的设计文档开发/测试,抗拒需求改变,所以强行“敏捷”会导致失控。因为没有一份完整的详细设计文档,开发人员会按照自己的想法编码,测试人员也照自己的想法测试,没有做TC评审的意识,加之没有和需求人员即时沟通反馈的习惯,没有一个迭代的过程,再为了工期的死命令削减测试强度,结果就是发现做的与需求不符的时候已经晚了。

很多原因共同造成不好的结果,还有些没说,总结下来就是不能再这么做了,对敏捷的理解很粗浅,欢迎指正。