3

这是一条用坑铺成的路——创业经验教训实战

Posted by Elias on 五 8, 2015 in 无责任乱弹

从去年夏天开始,我辞职开始和朋友一起全职做一个创业项目。到今年春天软件正式上线前夕,由于节奏把握等一些原因,创始团队决定散伙,不再继续做这个项目了,目前公司已经进入注销申请流程。从结果看,项目未能成功生存并发展壮大,里头确实有教训,但是也有很多做得不错的地方,我觉得是时候做做总结,给自己做个反思,也与其他走在创业路上的朋友们共勉。

==========

值得发扬的正确选择:

1. 不是一个人去战斗。

我所在的项目最终形成的创始团队是一个两人团队,并且在前半段保持了非常高频的沟通密度。尽管两人的知识背景不同,但凡事有得商量,既利于借助这种沟通机会,在讨论时再次理清思路,也有机会多一个脑袋去发现明显的错误判断,提高一点成功率。

更具体一点来说,其实在创业路上,每天都会遇到各种各样的问题,其中有不少都有可能关系到项目的生死存亡。对于赌上时间精力全职创业的人来说,心理压力是非常之大,如果一个人独自创业,挺容易就陷入异常焦躁的负面情绪中,不利于工作能力的正常发挥。而有人可以商量的话感觉上就好很多了,往往都能发现一些恰好可以解决手头问题的办法。

最后,比较频繁的沟通讨论,客观上也能促使完美主义/拖延症患者带有一点“交账”心态,按时保质地把之前的沟通结论快速落实到位。

因此,有给我作咨询顾问的创业前辈曾经说,创业路上是需要对等的人做沟通的,最好是合伙人,不成的话外部顾问也管用,至不济也得有核心员工能聊得起来才好。

2. 未在创始团队中接受“资源型”合伙人。

在我们最初组建团队的时候,我的合伙人推荐了一个号称有很强融资能力的“资源型”朋友加入。我当面聊了一下,感到这个人确实挺聪明,也的确有可能给我们带来比较有效的融资资源。但她对我们即将涉足的行业并不了解,有她在的情况下,团队的讨论效率特别低,想法总是频繁变来变去。而且她虽然怀揣“创业梦想”,有意愿尝试,但我感觉其实比较缺乏实干的心理准备,甚至同时也在考虑移民,表示有可能未来以远程遥控的方式参与工作。于是最终我明确表示不建议她加入,维持了原始的两人创始团队配置。

至今反思,我觉得这是一个十分十分正确的选择,如果允许她加入,我认为将会导致团队迅速分崩离析。其原因在于:如果以合伙人方式引入“资源型”人才,那么本质是在以公司股权交换获取这些“资源”的可能性,但创业早期其实股权的价值并不明确,拿“资源”进来的人容易觉得价值不匹配,团队又觉得股权给多了,造成双向不稳定因素。而且客观来看,限于种种原因,绝大多数“资源型”人才最终能够落实到位的“资源”往往会与各人最初预期存在偏差,到时就更为尴尬。

再换个角度看,通常“资源型”人才在实际工作能力上或者工作意愿上是比较容易存在问题的。这样随着工作展开一段时间,通常很快就有其他合伙人或者核心员工,在心里或者公开抱怨某某怎么干活不努力,反而还舒舒服服地拿着公司干股。长此以往,要么就引发团队震荡,要么就会在公司文化中种下传播消极怠工情绪的种子。

因此,我认为,对于“资源型”合作者,最好还是避免给股份或者引入创业团队工作,不如商定一个双方都能接受的价格用现金交换所需的资源。创业阶段实在太缺钱的话,宁可上浮报价打欠条延后兑现,我认为也是要尽力避免给股份的。毕竟,现钱交换更容易达成双方在责权利上的公允稳定。

3. 使用了图片动画式的快速原型。

在项目很早期,我就使用 Balsamiq Mockups 工具制作了“低保真”原型,后来又使用 https://www.flinto.com/ 把低保真原型做成了能响应点击操作的动态原型。这个方法除了帮助我当时梳理产品逻辑时快速理清思路之外,我认为对项目涉及的各个沟通环节起到了非常重要的作用。

在创始人之间讨论产品战略时,由于思维习惯和各自背景不同,其实很容易聊着聊着就说得不是一个东西了。这时如果我们有一个看得见、摸得着的东西作为讨论基础,则语境更为一致,讨论的偏差更少一些。而且从非技术岗的运营和商务上,也就比较容易理解将来做出来的东西会是个什么样子,能够提前进行非技术类工作的提前安排准备,改善职能部门间的配合。

在我们项目的研发内部,这一“低保真”原型后来成为了沟通开发需求的实际载体。我曾经也以详细逻辑描述的方式书写过标准的产品需求文档,但后来发现详细而冗长的文档在小团队里其实没有人能认真看得下去,关键的细节经常并没有被有效理解。反而以 Trello 条目拆分任务、并且给任务标注业务逻辑最容易出现理解偏差的关键点、辅助动态原型作为参考这样的方式最为有效。我认为,正因为采用了这样的工作方式,我们才能做到在仅使用远程工作的兼职人员的情况下,在一个月左右的时间里,就基本完成了项目 iOS 客户端的主要功能。

因此我认为,在初创阶段使用“低保真”原型配合频繁的沟通,会是一套比较快速有效的研发组织流程。

需要改善的错误做法:

1. 创始人之间股份划分标准不够明确。

都说十个创业公司九个倒在股权相关的问题上,我认为我们这次的创业实践在股权上也是犯了错误。包括我在内的创始人团队,从经验背景上看,商定一个负责产品和技术、一个负责运营和商务,算是创业公司里比较典型的配置。但在决定谁是“老大”的时候,就难以据此决定研发与业务两端谁更重要了。最终我的合伙人认为他有过组建创业公司的经验,主张由他主导,而我犯了熟人之间沟通反而不够坦率的错误,转而与之讨论占最多股份者应加倍出资的责任绑定方案,但这一方案也没有最终取得明确共识,客观上变成了“模糊处理”,被拖延下来。甚至直到公司已经正式注册,都没有以书面的形式明确约定股权、期权池预留及出资比例,给公司的稳定存续埋下了根本性隐患。

运行接近半年,我发现我的合伙人在业务方面比较努力,但实际上却并没有团队管理经验。具体表现在:讨论战略目标时主张的方向不够清晰、对吸引人才和留住人才缺乏办法这两方面。我开始认为这样的话他是不适合担任团队 Leader 的。再加上经过多次催促,股权比例的具体划分方案一直都没有被明确落实到纸面,让我开始对这个团队进一步感到失去了信心。遗憾的是,由于心态问题,这时我也没能做到如顾问朋友建议我的那样,推动一次完全坦率的沟通彻底解决这些问题,最后终于走到团队解散的地步。

我从这里得到的教训是,衡量创始团队“老大”的的真正标准只能是领导力,他必须要能以领袖的姿态带领团队前进。而类似股权这类极度敏感的问题,反而需要尽早形成结论并正式落实到纸面,才能第一时间把团队的全部精力放到生死存亡的实际业务中去。

2. 没有第一时间发布产品原型。

现在反思来看,其实项目开始的产品框架设计得就偏庞大,包含 POI、经验分享、社交、电商 四个组成部分。项目早期我们又是选择主要依靠自有资金运作,资源上并不能匹配这样的产品规模,导致研发周期拖得相对更长。尽管通过多轮内部复审和外部典型用户试用,得到的良好反馈使我们认为从纸面逻辑来看,我们选定的方向和解决方案都是对的。但早期时纠结于产品功能还不够完整,后期担心运营人员放假及培训准备尚未完成,于是上线时间一拖再拖,直到团队解散也没有选择启动上线运营。这就导致我们无法通过目标用户的实际使用情况来判断我们对用户痛点把握得是否足够准确、解决方案设计得是否足够有效,从而严重影响了对项目战略目标的验证调整。并且由于长期没有正式上线,一线运营、研发团队周期性感到缺乏成就感,士气定期极度低落。

我从这里得到的教训是,每个研发迭代周期都应精简功能,尽快上线接触用户并获得反馈。通过高速迭代修正,切实解决目标用户的实际需求,才是小公司切实有效的生存之道。

3. 接触投资人不够早。

到今天我仍然认为,我们在这次项目里选择前期依靠自有资金启动,相对独立地梳理行业特征逻辑仍然是对的。这能够在一定程度上避免过早受到某些投资人太过“风口论”及“赛道论”的影响,也就避免了有人给钱忙活半天却解决的是个“伪需求”这样的尴尬状况。但在这次项目的融资节奏上,我们走到了另一个极端,这同样是完全错误的——我的合伙人听信了他一位朋友的建议,认为投资人在接近年底时普遍资金已经基本用光,因而硬生生在两三个月的时间内完全放弃了找投资这件事。而我由于纠结在团队内部股权结构未明确这个问题,也没有花精力去找投资。这就在后期导致了真正的资金困难。

最终在我决定从项目退出,并明确告知合伙人时,开始合伙人打算去找投资挽救项目。于是情况变成:项目开发基本完成,但“缺钱雇佣有经验的运营人员做好准备=>担心运营跟不上不敢上线=>不上线没用户数据=>前景不明朗没人愿意加入也没人愿意投资=>没钱雇人做运营准备”这样的死循环。最后的最后,合伙人也决定退出,于是项目解散。

我从中得到的教训是:应保留独立判断,但也应当较早与投资人保持接触。融资应保留一定提前量,毕竟钱花光了再找钱救命那么显而易见要么不好找要么条款不好。即使市场环境存在困难,那么我认为不妨融一小轮做一下过渡也仍然是可选的方案。创业的三个核心无非是“定方向、码团队、找钱”,忽略了其中任何一条说起来都实在是非常搞笑的事儿。

==========

创业的路总是异常艰辛的,结合风险因素其总体的收益其实也并不如媒体大力宣传的明星项目那样光鲜。如果即使这样,我们还是愿意选择走在创业的路上,那么我唯有与诸君共勉。

标签:

 
0

完美主义和什么都会做,程序员变身好产品经理的两大阻碍

Posted by Elias on 三 22, 2012 in 无责任乱弹

最近半年虽然还是做技术的事儿,不过挂的衔儿却是产品经理,就这么慢慢发现了一些挺有意思的故事。差不多每隔几天,就会有产品经理小朋友嚷嚷着要找我学技术,说如果自己也会写程序,那工作起来要有效得多。而我转眼一看,却发现纯程序员出身的产品经理们,转行头几年基本上都是踩坑不断。说起来,有没有编程底子,以及编程底子有多厚,对做产品经理来说,本来应该是有利有弊的一个事儿,不该有个太过绝对的评判。不过最近发现,优秀的程序员想变身为同样优秀的产品经理,还真有俩挺麻烦的障碍。

第一就是优秀程序员往往多多少少带有完美主义的倾向。写程序写得好事实上是需要相当程度的重构的。往往第一个版本都不能真正准确、完整地理解需求。有时候是比较简单地没理解透;有时候是没能预计到真实环境中全部的使用场景,最后很多东西被用在了超出范围的地方;也有时候,是第一版本还没上线的时候,用户和市场自己也没搞清楚怎么回事,一旦有东西用,一切情况就都变了。于是,补丁个几轮以后,代码结构变得越来越乱,维护程序也是越来越不清晰。此时好的程序员会迅速选择恰当的时机搞一次重构,花的时间未必多,但会发现程序代码量少了一半,能适应的场景更丰富,运行效率往往有所提高,结构也能清晰得带有或多或少的美感。而不够好的程序员呢,这时候就每天都一边干活儿,一边骂骂咧咧的。想来内心都是存有一份离完美更近的美好。

不过这种思维套用到产品经理头上却会造成障碍。产品经理不得不比程序员更多关注事情的“性价比”,其中时间因素对产品经理压力要大得多,经常是时间一过,整个市场都变得完全不一样了。所以产品经理尽管也希望自己的产品尽善尽美,也通常是不大敢搞重构的。在发现系统出现结构性问题的时候,产品经理通常会主动或被迫选择“边跑步边调整队形”;而程序员如果选择一边加新功能一边整理旧系统,往往是死路一条,所以通常会选择冻结需求,先搞好了架构再说。这种完美主义和残酷市场现实的冲突,通常就造成“新”产品经理们项目失控,常常 Delay 。要么被老板们打板子打得惨兮兮的,要么就直接被无情的市场抛弃了。。

第二个就是“其实什么都会做”这么一个感觉。对程序员来说,其实一切都是 0 和 1 ,各种变量传来传去,各种 Api 来回调用罢了。什么?某个功能没有,那么我们自己封装就好了!什么?某某功能没有做过,其实原理明明是一样的嘛~只做过网页没有写过操作系统,其实没关系啦,参考一下网上的开源程序,自己做就好啦。虽然这样搞出来的“操作系统”可能是依赖 Javascript 的。。好吧,反正好多人也认为程序员们都是既会修电脑、又会修电视、修手机,能拆冰箱改造成个卫星登月的人。。而事实情况是,有大量的系统、大量的软件虽然搞出来了,可是却没有什么人用。极端一点来讲,基本可以说是没有产生价值。于是“什么都会做”结果变成了“什么都做不好”,事事不成。

好的产品经理呢,通常会是逻辑倍儿清楚,哪儿容易出问题也是倍儿清楚,可是自己动手开搞八成没戏。产品总是心里有一笔隐含成本的帐——这家伙搞 C 不错,可是拉去写网页怕是要耽误事呀。。

有了这些个前车之鉴,现在再被人讲“这家伙什么都会”的时候,就不再是年轻时候心里暗暗得意,而是立即紧张起来——惨了,八成又有人刨了个坑,准备让我填呢:)

==========

PS:今年 1 月还是请假跑到厦门去跑了人生第二个马拉松,可惜训练不足, 6 个多小时才勉强跑完。。而且貌似还把膝盖跑伤了。。好吧,既然证明了我是可以完成马拉松的,并且也就此留下老伤作为纪念,不妨就此告别业余马拉松生涯,寻找其他更安全的活动去好了。。

标签:, ,

 
1

杰出领袖在中国是珍稀动物

Posted by Elias on 十 9, 2011 in 无责任乱弹

总觉得以中国的幅原辽阔、人口之多,杰出领袖实在是不成比例地稀少~于是总觉得各种事情办得不够妥贴,事倍功半、比较土鳖的感觉。以泱泱文明古国的观点来看,不是很明白其中的原因。今天看《技术领导之路》第二章——“领导方式模型”算是碰上了答案。

其中提到反领导力的 MOI 模型(也即做到其中任何一条都会导致领导力的倒退)如下:

  • M:打击激励——让人觉得变化是不受欢迎的;替他们包办,这样他们就不必自己执行;如果人们出于兴趣而乐意去做事,要扫他们的兴;
  • O:增添混乱——鼓励恶性竞争,让合作变得不可想象;提供的资源应该比必需的最低限度还要少一点;封锁具有公共价值的信息,或是用无聊的谈话和文件埋没它;
  • I:阻碍思维——如果能批评,就不要倾听;你的想法要在第一位,声音要最大;惩罚那些提出建议的家伙;不让人们在一起工作;最重要的是,坚决禁止说笑。

基本上,中国的家长们或主动或被动,差不多算是把这几条全部都占全了。那么中国的年轻人们,以及由年轻人成长起来的老人们,想培养能发挥影响力、把事情推向靠谱方向的领导力自然也就难上加难了。所以我想说,不要纪念乔布斯,不要怀念乔布斯,如果在自己将来成了父母的时候,能够做到不灭杀了孩儿们成长起来的机会,那么是改善世界最好的实际行动了。

××××××××××

PS:最近换了新工作,如同很多仍然处在创业期的企业一样,这里有环境可以发挥创造,也有无数急待开拓的领域,只是永远不会水到渠成,而是必须自己去主动地寻找方向,去开拓、去推动。这样的环境肯定不是地狱,也不至于是天堂。到底会是什么,我想得看我要怎么去面对这新环境的挑战了~

标签:, ,

 
3

创业易筋经之“少即是多”

Posted by Elias on 六 10, 2011 in 无责任乱弹

最近几年参加了好几家处在创业阶段的公司,回头看看出现的问题经常是很类似的。比如这样的场景:

  1. 搞技术的兄弟们每个人手边都堆放着大把大把的需求,似乎永远也做不完。
  2. 负责产品的弟兄至少 6、7 成的工作时间是被 Boss 们抓着开会,会上 Boss 首先对上次布置任务的完成进度表示了不满,接着讲他/她又有了某某某某新想法,如何如何有亮闪闪的光明前景。于是会议的结果是决定启动一个很有前途的新项目,完成时间必须在某某某某时间。
  3. 产品同志们连熬几夜弄好了初步原型,丢给技术。
  4. 技术同志们只好丢下弄了一半的上上次会议确定的需求,去搞这些新玩意儿。
  5. 新需求一边开发着,一边发现有不少大大小小的地方存在逻辑上说不通的地方。问产品,产品常常也说不清楚个所以然,于是技术们都觉得产品是混子、是傻蛋。
  6. 上线日期马上要到了,于是原型没法做大的修改,技术们只好糊里糊涂地对付完这些有点儿“说不通”的需求,一边做一边在心里默念 Boss 和产品都是傻蛋、是傻蛋。
  7. 最后上线日期还是拖了一拖,并且有很多实在搞不懂或是很难实现的功能被当作 Bug 计入任务追踪系统了事。
  8. Boss 看到最终产品非常不满意,认为根本没有体现他/她思想的精髓,而且很多几个月以前完成的功能仍然 Bug 多多,和竞争对手的产品相比简直就是垃圾。
  9. 于是 Boss 只好又提出一个新想法,打算再一次靠新鲜玩意儿在产业链中重夺制高点。
  10. 产品也开始在心里觉得 Boss 其实是一个傻蛋,照这么搞下去,刚刚有点起色的上一版产品线会被 Boss 搅合成彻彻底底的垃圾。
  11. 技术开始觉得在这个团队里根本没有前途,团队的其他人都不懂技术、不懂产品,公司弄上线的东西对用户也根本没有意义。
  12. Boss 愤怒地觉得团队完全没有执行力,产品根本就没能理解他/她的想法,技术除了制造越来越长的 Bug 列表什么都做不了,于是开始考虑是否对团队来个大换血。
  13. 就在这样的折腾过程中,初期积累的仅有的一点用户再也没有回来过。。。

是否有朋友觉得上面的场景似曾相识,其实这种状况并不一定只是出现在创业公司中,在大公司的小部门里同样经常出现。只是对大公司来说,后果可能仅仅是一个部门被砍掉或者重组,但对创业公司来说,就很可能会伤及命脉,消声弥迹了。因此对创业阶段的公司来说,后果实在是严重得多!

如果我们用更清晰的方式提出其中蕴含的问题,那么——创业公司该如何有效提高执行力,取得竞争优势呢?我想,其中的第一条秘诀就是——“少即是多”原则。

在数学模型上,“少即是多”隐藏了这样一个基本判断:在不加控制的情况下,需求和 Bug 的数量成指数级增长,而技术人员的任务处理能力通常是线性的。在需求不断增多时,代码的复杂度变化接近于指数级,于是对 Bug 的指数级增长性无需过多解释。而需求的指数级增长,主要来源于缺乏合理的边界控制。比如公司开始也许只是想做一个普通的网站,之后考虑到大规模资料上传就搞浏览器插件,再之后插件遇到操作系统的安全沙箱限制于是开始发行自己的浏览器,然后忽然觉得依靠自己的浏览器其实可以搞一个完全在浏览器之内运行的操作系统来重构 IT 基础环境,接着又想起还有手机和平板电脑于是搞移动客户端,被移动设备厂商们互不兼容的编程界面折磨以后企图开始搞跨平台开发工具,最后干脆开始开发自己的操作系统……当技术能力与需求爆发的差距大到难以调和时,往往会再经历一个痛苦的坚持期,之后不外公司倒闭或是项目被砍掉的结局。(当然,我觉得大公司有时候什么都想做的原因就是故意把战线拉长,折磨竞争对手。毕竟从某种意义上说,大公司实在不缺钱。。)

从商业模型角度讲,一家能够长期生存的公司必然是在产业链的一个或多个环节中占有相对不可替代的位置。创业公司人才有限、资源捉襟见肘、市场声誉缺乏积累,又如何跟大公司竞争?其实答案是比较明显的,就是—— Focus ,首先将力量集中到部分细分领域、细分环节,根据用户需求,提供比大公司更为出色的解决方案,来获得局部市场优势。具体操作中,又可以进一步利用局部优势正向、反向整合产业链资源,借助现代信息技术手段实现快速响应的纵向联盟,威胁大公司占据的市场甚至直接改变产业格局。这一思想,在《轻公司》一书中已经写得比较清楚。正因为公司仅直接控制自己擅长的部分环节,做的事情“较少”,才留给产业链合作伙伴更大的发挥空间。在理想情况下,联合所形成的产业合作链条,在每个环节上都能发挥各方优势,将形成对单一大公司全面超越的有利势态。因此,自己做的事情“越少”,最后获得的优势“越多”。

再从哲学角度看,简单的才是美的。如果一件事情的解决方案庞大而复杂,那么很有可能其背后真正的真理还没有被发现。与数学中的逻辑类比,公理假设越少,往往衍生得到的理论体系反而越牢固、越丰富。以软件业来分析,简单而健壮的基础功能,往往能够比复杂定制后得到的专有软件获得更有趣的用户创意、适应更多的问题,从而占领更大的市场范围、获得更长的软件生存周期。比如互联网基础应用之一的电子邮件,发明至今已经接近 30 年,仍然在互联网服务流量中稳居三甲。因此,越是凝聚在少数基本服务中,粘住的用户反而越多。

少即是多

在创业公司的发展过程中,会有很多很多因素造成干扰:有可能是对市场把握仍不够准确,也可能是因为团队执行力上的幼稚而造成混乱,更可能是竞争对手有意开辟多条战线进行误导,但牢记“少即是多”原则,坚持核心方向,稳抓用户需求,或许会在创业这个“以小博大”的游戏中抓到稍微好上一点的底牌。

××××× ×××××

PS,在现实生活中,有时人讲的话是要反着听的,比如,宣扬“Work Life Balance”的公司往往也是因为工作压力大员工出问题最多的公司。所以在遇到 Boss 大谈“少即是多”的时候,要小心看他/她是不是真的能够落实这条原则到执行上,否则,那也不过说明这位朋友在事务庞杂的状况里吃过亏,却未必真有本事扭转时局了:)

标签:,

 
16

推背图——百度身边上线以后

Posted by Elias on 十一 25, 2010 in 无责任乱弹

近期“百度身边”由封测转为公测了,因为我目前所在的公司主营业务和“身边”有一定相似性,因此不得不思考一下相关影响和我们后续的发展路线。

××××× ×××××

问题1:身边是否会把其他公司都挤死?

首先不要迷信大公司,大公司推出的产品并非各个都会获得压倒性的成功。国外倒下的有 Google Wave ,百度自己的“有啊”也没见到多少实绩。所以百度大力推出“身边”其实主要是说明生活搜索/商户索引/商户折扣这个市场非常重要,为百度这样的巨头所看好。众多大公司加入这场游戏,一方面会由于竞争加剧,给相关领域公司的经营带来困难;但同时由于这些大公司在竞争过程中大力开展营销推广而将使相关市场被迅速催熟,教育出来的新用户会使得市场规模迅速扩大,因此竞争造成的市场份额危机不一定会导致具体公司用户绝对数量的消退,于是找对方向的中小公司反而有机会在细分市场活得更好。

××××× ×××××

问题2:竞争的核心指标会变成网站的流量吗?

通常流量决定网站的广告价值,所以有些人可能会认为生活搜索/生活服务这个行业的竞争核心会变成流量之战。但流量其实只是表象,真正决定网站长期竞争格局的是用户粘性,换句话说就是是否拥有独占的特定用户群,以及这个用户群可以发展到多大多稳固。

以大众点评为例,他们通过这些年的积累不但拥有了一批习惯于发表评价的核心用户,而且一提到看餐馆点评和写餐馆点评,很多人第一时间就会想到它。而百度身边只是把生活服务信息和自身的 SNS 平台硬凑在一起,另外可能计划依靠商城的积分换礼来激发评论和店铺信息补全等,个人认为其体验还不足以让点评的核心用户群叛逃。当然,百度可以砸钱,给捧场的筒子们大方的奖励来挖墙脚。但这也是一把双刃剑,一旦用户形成了为奖励来发评价的习惯,那么一旦奖励降低或者停止将意味着部分核心用户的再次叛逃。

再以爱帮为例,这么多年来它看好生活搜索,勤勤恳恳耕耘却也一直未见爆发,现在反而看起来更像是一个以团购为主业的网站,这可以说是其长年忽视社区建设而造成的必然恶果。爱帮刘总以多年搜索引擎建设形成的过硬技术基因,把网站和手机客户端都调教得很“工具范儿”,数据信息都是以抓取为主,而不大重视鼓励自有用户生产数据。可惜这些工具又都还没有凝聚成自己的灵魂,达至非它不用的地步(参考部分人群只用 Google ,不用百度的故事),于是用户用用就走,在竞争对手推出类似服务的情况下受到的冲击会是最大的。

此外,稳定用户群的特性将决定什么样的商户愿意为此而付费,以及付费的额度。模糊的用户群特性将难以获得商户的关注。因此,用户粘性才是真正意义上的长期竞争核心。

××××× ×××××

问题3:百度耍流氓在搜索引擎入口搞劫持怎么办?

据同事说,爱帮等网站流量的一半以上来自搜索引擎,因此担心一旦百度在搜索引擎入口端截流,会对自身网站造成巨大的伤害。但我对这一观点也不能完全同意。

在网站保证自身各自粘性的情况下,竞争对手之间并非简单的相互替代关系(参考问题2中的“想评论找点评”这个意思),网站的灵魂也不是简单抄袭一下功能和界面就可以完全复制的。因此用户需求将基本保持原先的趋势,导致搜索引擎入口不敢截死,至多原先搜索某店铺名字,第一是点评的页面,而以后变成第一个是百度身边的,第二个变成点评的罢了。在网站内功到家的情况下,这种截而不死的方式也并不容易伤及筋骨。再邪恶点的话,还可以购买百度的 Ad Words ,给他交点保护费就又变回一家人了:)

××××× ×××××

问题4:我们下一步应该怎么办?

既然“问题2”中的结论大致是用户粘性优先,那么显然没弄清定位的需要先理清定位,没有搞清楚用户群的要明确用户群。如果非要用散弹枪部分对象地乱开战,那么准备绝对充足的资金和巨头浴血搏杀那或许也是一条难以劝阻的道路。个人认为,凡事有弊必有利,商业模式的选择同样如此。以饭统为例,它选择了电话订餐方式,导致了巨大的呼叫中心费用,并且订餐必有折扣限制了它自身拥有的商户数量,制约了抢占市场的速度;但反之,它的这种模式避开了显示/下载次数式的互联网广告/商户折扣券形式,同时也就绕过了广告效果造假的陷阱,对部分商户来说,广告效果和广告投入的比值关系似乎更为稳定可靠,从而有可能成为更好的合作选择。

对我们公司自身来说,我个人倾向于对市场进行细分,首先占领一块细分市场作为后院,同时也作为未来继续成长的种子。一方面,百度身边同时开放 300 多个城市全面开花的作风必然导致运营力量存在一些薄弱环节,留出难以覆盖到的部分细分市场,因此取得局部战场的胜利是有可能的;另一方面,我们公司规模有限、资源也有限,缩小战区到有可能胜利的范围是最为经济的选择,同时有利于扬长避短。

以市场特性来看,低端商户价值不大,如成都小吃之类(或许我们该叫它为“成都料理集团”或许更为礼貌^_^)运营成本低、覆盖范围小,以互联网方式帮助它不但与其经营特点有所冲突,而且也难以从这样的商户手上收取费用。中端商户的主要销售手段以各种促销活动为主,具体一般体现为各种各样的优惠券,优惠券推广效果的比较又往往将竞争的方向引向网站流量,目前并非我们所长而且流量的竞争对我们目前可以使用的资源来说回报也不够理想。如果继续以中小商户作为主攻方向,那么受流量压力,我们很可能不得不与一些流量过硬的网站合作,向他们开放我们的优惠券资源,这样从长期来看很可能使业务退化为专门的扫街公司,为各个网站提供优惠合作商户,最后远离互联网一线竞争。最后剩下的高端商户的营销推广目前还没有妥善成熟的互联网解决方案加以配合,有可能成为我们这一阶段的突破口。其原因一方面是高端商户消费者单笔交易数额较大,有利于实施推广我们和银联的合作优势;另一方面高端商户由于自身品牌形象考虑极少打折,因此不会因为优惠券为单一核心而引发流量竞争。当然,由于高端商户自身的经营特点,也需要我们在互联网营销服务等方面加以大胆创新,才能与之建立长期稳固的合作关系。这既是挑战也是机遇。

考虑到目前我们公司仍以自力更生为基本目标,那么由以上推出相对合理的策略将会是:基本放弃缺少商业价值的低端商户,将其维护与宣传开放给普通互联网用户,任其自生自灭;维持、接触中端商户但不作为业务重点,避免流量方面的直接竞争并以此扩大商户数量,扩大用户基数;通过模式创新突破高端商户,由此形成稳定牢固的特定商家/消费者用户群体,作为继续发展的根本基础。

××××× ×××××

面对巨头的竞争,无需妄自菲薄,走对自己的路,建立自己的竞争优势,那么大卫也能战胜哥利亚~这正是当今中国互联网创业路上所必须要学习的一课~

大为战胜哥利亚

标签:,

 
1

所谓“职业规划”及创业

Posted by Elias on 六 28, 2010 in 无责任乱弹

最近换了一个新工作,很忙。忙到什么程度呢,可以说是忙到导致我“每个月至少一篇博文”的计划再次泡汤了,不但 Wiki 和博客从4月初就都没有动过,浏览器上等待整理的页面(我习惯把可能有用需要整理一下的内容保持打开在浏览器的标签上,这样可以提醒我,而且反正 Firefox 每次重启都会自动把原先开启的标签页重新打开,很方便~)大约也有一百多了吧,另外打算帮寇老师调整网站的事儿也一直从4月初拖到了现在仍然是还没下手的状态。

好吧,报怨的环节就到此为止,现在转入说正题环节。话说导致我这么被动的其中一个原因是现在手下人手不足,也就是说招聘计划实施得相当不成功。虽说招聘靠谱的人一直就是相当困难的事儿,近期我听到过各种行当、各种规模、各种成份的公司的各种级别的人报怨招聘难的现状。也就是说我其实对这种状况是有一定心理准备的,可是我还是被雷到了。我吃惊地发现很多应聘程序员职位的同志其实不想做程序员。其中经验薄一点的多半认为程序员就是民工,又累又不挣钱;经验多点的则一心惦记着转向管理职位,要么就是整创业。这样的想法早就听得多了,得承认存在即合理,多少也是反映了国内 IT 业界的真实状况——就是靠谱的、可令人安心发展的公司很少。

但我想说的是,当前状况光报怨是没有用的,光报怨不可能改变现状。从公司的角度讲,愿意提供什么样的待遇大致还是和这个人能平多少事儿(或者貌似能平多少事儿)的能力相紧密结合的。而这种能力的增长就需要结合当前社会现实做一个跨度至少为几年的规划,基本上在有一定压力、项目实用性强、领导及同事办事风格靠谱的环境里能力增长是最快的,否则一般会沦为自生自灭的状况。也正是因为这样,主流的发展路线通常最好还是通过大公司入行,环境靠谱的几率要比小公司和创业公司大上不少,一般也能受到比较正规的训练并遇上比较靠谱一些的“前辈”或“师傅”。而小公司及创业相对更适合头脑一贯清醒、自律性强、能自己逢山开路、遇水搭桥的人。

也正因为如此,虽然李开复先生开的是创业的生意,还是不得不说“大学生毕业就创业是冒险”这种话。而且开复先生的《给创新工场求职者的一封信》其实也应该反着读,个人建议的读法是:其实没有那么多“特殊的人”,大多数人还是应当仔细考虑如何找到适合自己的、靠谱的职业规划。

对于程序员来说,赖勇浩先生在前俩月发过一篇博文“程序员职业生涯中的〇一三五七”说了说他自己的一些看法,颇有值得借鉴之处。可是我觉得赖兄还是把创业说得过于简单了。大致在开始前已经觉得准备比较充足的人当中,创业运作到第二年末,大约就会有90%左右倒闭。说明其中有很多重要的因素没能提前看到也没能处理好。而且创业的风险或许比能看到的部分来得要大,比如创业一旦失败会对职业规划造成相当不利的影响,通常在创业失败时重新找的第一份工作的待遇都会有所缩水,而且找工作的过程恐怕也相对会比较不顺利。

话说回来,到目前为止我工作过的企业其实都是创业企业,有的人可能会说我这样不是说一套做一套吗?倒也不是这么回事。人的选择都难免受到之前选择的限制和影响。我由于种种原因,走上了现在的职业道路,倒也谈不上后悔。只是结合自己的经历和理解,建议仍有机会以比较小的代价选择靠谱的路线的朋友认真考虑自己的选择。而已经像我这样走上似乎不那么靠谱的道路的朋友,也仍有机会做出靠谱的事。来日方长,与诸君共勉~

××××××××

顺带给自己做个广告吧~长期招聘靠谱的 Python 程序员从事网站开发。觉得网站开发这种东西没有技术含量的朋友请直接绕道,任何事情都是有靠谱和不靠谱两种做法的,任何事情认真对待也都能把它做到有技术含量的程度。有兴趣的朋友可以通过邮件向我投简历和咨询状况,我的邮件地址可以在 Wiki 页面上找到~

标签:, ,

 
0

诚实不等于正直,开放不等于透明

Posted by Elias on 十二 29, 2008 in 无责任乱弹

原始思想来自于《代码之道——I.M.Wright’s “Hard Code”》第八章“2007年3月1日:‘不只是开放和诚实’”一文。原文是打算讨论一些关于软件工程实践的要点,但这一章节也完全可以用于生活到其他方面。其实所谓软件工程,也无非是做事的方法之一,而如何做事也可以说是如何为人,因此当作是一回事自然不会冲突。(由此莫非可以引申出:与不晓得如何做事的人交朋友是一个高危事件?^_^)

原书的观点已经表达得非常明确,我暂时没有太多打算补充说明的,在此仅摘录原文中提及的名言一段,与诸君共享:“诚实就是……使我们的言论跟现实保持一致。正直就是使现实跟我们的言论保持一致。”——Stephen R. Covey

标签:,

 
0

关于为啥有人偏偏喜欢写程序

Posted by Elias on 八 1, 2008 in 无责任乱弹

经过最近几个月毕业期的考虑,我发现无论未来发展的道路如何选择,恐怕我或多或少还是难以避免会与软件这个行当扯上点关系抑或完全陷入。因此我决定重新开始关注一个软件行业自身的故事,所以我买了《梦断代码》这本书,想看看集合了无数牛人的开源PIM系统Chandler到底是如何以失败告终的。书还没有读完,就已经取得了副产品,也就是标题说的为啥会有很多痴迷玩程序的人,或者应该称为黑客的原因。

我和书的作者在以下事实上看法一致:软件行业从诞生至今数十年,其实仍然是一个非常缺乏标准化同时也很难标准化的行当。当前虽然有甚至多到难以尽数掌握的强大开发工具、语言、代码库等等存在,但软件的开发还是远远达不到组装PC机时把板卡、线头分别插到一起那么简单正规,相反是纷繁而混乱的。绝大多数现成代码常常是覆盖了所要完成的大部分功能,可是这没有被覆盖的一小部分特性偏偏正好是产品最新颖的特性,有人甚至怀疑是否能真正实现软件组件的完整重用。有些人,特别是高手,难免较真起来大挑毛病,甚至在一些时候会把现成代码直接放到一边看也不看,就深信自己一定能够很快就做出一个无论在各个方面都好得多得多的实现。这些“牛仔程序员”认为自己的方法一定能够解决项目中出现的问题,挽救整个项目。就算退一步,通过组合重用现成代码来完成软件时,选择什么样的类库,以及如何组合使用这些类库使之能够相互配合,其实也还有相当深邃的随意余地可供调整。

总之呢,把这么复杂的事儿完美搞定可是不大容易,当前现实是仅有一少半的软件产品是真正能够按照开始时确定的人力物力和时间成本顺利搞定的。可是呢,玩程序这事儿的条件却又不高,随便有台电脑也就能做。个人以为门槛未必就比早年玩半导体收音机的时候就高了。玩好了呢,则有可能让全世界程序员都叹为观止。上手简单,又可以如此有效地展现自己这么聪明、这么酷的一面,建立一个领域内的崇高声誉,一定难免有人愿意为此茶饭不思、不计报酬了吧^_^

只是这事儿反过来想的话可是让人冷汗直流,当今世界的诸多事项如此依赖软件的正确运行,其基础又是何其薄弱。本来做靠谱的事儿就挺难,恐怕软件行业又是尤其如此了。天热,为防止继续大冒冷汗,不妨就想到这儿暂停好了^_^

 
0

万勿一提Google,鸡犬升天~

Posted by Elias on 六 12, 2008 in 无责任乱弹

我承认Google推出的服务都挺有特色,并且其中绝大多数也是聪明而出色的,因此Google是我的搜索引擎第一选择,并且在可能的情况下,我会考虑尽量使用Google提供的服务。可是话说回来,Google也不是任何事情都是完美的,我们完全没有必要去神化它~至少其选择的一些合作伙伴还不能比较靠谱地处理遇到的问题。

至今为止,Google在中国举行过两次开发者日活动,今天在北京参加的就是其中的第二次。我得说Google中国在组织开发者日这件事情上实在是没啥经验,今天几乎是我参加过的组织最差的开发者日活动。当然,其中绝大多数状况应该归罪于会务公司。但会务公司是Google自己选的,Google同时应当派出有能力的人员监控会议的进程在预期的情况下展开,所以我们还是只能把问题归罪到Google头上,说Google不好。

  • 大罪一:筹备的午餐餐厅至多只能坐下一半左右的餐会人员,临时采取了分两批就餐的措施,但没有任何提前通知,也没有告知放行第二批参会者的预计时间,导致大量参会者饥肠辘辘地焦灼地被拦在餐厅门外以及二楼楼梯口长时间等待,极大地破坏了参会者心中对会议的印象。
  • 大罪二:注册工作安排不周,导致大量参会者无法在开场演讲前完成签到,影响了开场演讲的顺利进行。会务组临时决定将手持会议邀请函的参会者直接带入会场,跳过签到流程。这样导致大量参会者没能拿到签到时发放的会议资料(其中包括意见反馈书),而意见反馈书又是会议结束后领取纪念T恤的必备道具,造成了自相矛盾。同样是正常注册餐会的开发者,凭什么由于会务组的工作失误而造成差别对待~
  • 小罪一:会务组为各个分会场准备的麦克风声音出奇地小,不少经验不够丰富的演讲者的表达在会场上后排基本听不清。
  • 小罪二:开场时声明好的提问会有纪念品发放,可是后来到下午也未见到实际行动。作为提问纪念品的毛绒玩具就这么在会场后面堆着。。

写这一抱怨贴固然是为了表达对会议的不满,更重要的是要提醒一下,要做出靠谱的事情,就必须要与靠谱的人合作,否则即使是Google中国,恐怕也免不了栽跟头。那么如果不得不与不靠谱的人合作那又怎么办呢?没有其他办法,只能——花时间、花精力去监控它不出状况。这恐怕是希望自己做事靠谱的人所难免遇到的情况。

 
0

讲讲《奋斗》是怎么回事

Posted by Elias on 二 29, 2008 in 无责任乱弹

显然该剧所表达的与我们传统认识的奋斗精神不是一回事。然而热播与否与是否是真正的奋斗精神也没什么关系,有一定洞察力的人应该都不至于把这个片子当成励志片看。从文学的历史来看,最多通常都是在故事的关键处或是结尾,出现神仙或是高人,一番指点帮忙,于是善有善报、恶有恶报。通常大多数观众不会在乎事件实现的具体手段,于是整出来两个好爸爸和一个有钱女友,也算是传统的省事而有效的手段了~简单来说,能过干瘾就得~

再者,按照石康本人的说法,他大致想通过这个剧表达的是在现代社会衣食不愁、甚或条件优越的人群里,仍然存在着一种与传统头悬梁、锥刺骨所不同的奋斗状态。虽然我个人以为石康先生这明显是在给自己脸上贴金玩,不过话也的确可以反过来说:难道衣食无忧的同学们就只能纸醉金迷,就只能腐败堕落;抑或在当今社会要立即鼓励大家放弃自己所有的有利条件,非彻彻底底白手起家不可?特别对保持后一种说法的人,如果其本人根本就不是这么实践的,那么不外满嘴谎言抑或别有用心~

文学或影视这种东西,每人能看到自己所满意之处就可以了,未必非得跟中学语文似的总结出个千人一面的中心思想。有人看片子为的是看美女;有人图的是听京贫;有人是想受到精神上的感召;再有人可能只是与剧中人物分别对号入座,启发自己的人生经验。我个人以为,无可无不可。您喜欢就看看,不喜欢就关注点儿别的好了~猫猫狗狗中意吃什么,咱们管那么多干啥。

Elias的邪异门 is proudly powered by WordPress.(京ICP备10013669号 瑞豪开源提供VPS)Theme design by Laptop Geek.
Copyright © 2018 All rights reserved. Entries (RSS) and Comments (RSS).