企业(Enterprise)和初创公司(Starup)最大的区别在于,企业通常已经找到了(算是)牢靠的现金流管道,短期内不必担心生存问题;而初创公司还在不断探索什么样的产品真的能卖到钱,以及如何让用户持续从口袋里掏钱。对于初创公司,一旦账上的钱不够发出下个月的工资,团队就立刻、马上面临爆炸,溃不成军。

在真实的商业环境里,很多工程师加入的是Enterprise,而不是Starup。他们习惯等产品把PRD文档和原型摆到案前,对商业模式的认知通常是:

商业模式不是我要考虑的事,反正我只需要把确定的模块实现,公司就会自动赚钱。如果碰到返工,那产品经理和老板全是猪,自己没想清楚,只知道让我先做。

而在一家互联网企业中,碰到一个既不懂商业逻辑,又不懂技术的产品经理的概率,还是很高的。

这样的PM通常是老板聘请的跟班,负责收集内部(通常来自上级)和外部产生的「需求」,将需求以文档形式「翻译」给研发团队。一个两边都不懂都人在中间当翻译,结果只会炸成一地鸡毛。老板隔三差五跑进办公室拍桌子要功能,留下PM和RD面面相觑,重新排期,把修改后的需求加塞插入。

中间一来一回,很可能一天就过去了。

企业还有机会试错,初创公司这样做就是自杀。

所以Starup的工程师(通常持有公司股份),就必须掌握开发任务的主动权,要厘清当前issue的优先级,用MoSCoW原则来驱动,而不是没有意义的P1,P2,etc. 而团队中的PM,最好有技术背景,即便不能自己做研发,也要明白基本概念。如果工程师不止一次抱怨跟某位PM沟通是鸡同鸭讲,那么这个PM会让团队整体的战斗力打个7折,甚至可能让团队完蛋(因为TA不晓得自己坐在这里有什么意义)。技术、商业(实操和嗅觉)、逻辑(包括数据的敏感性),PM至少占一样,否则不适合干这份行当。

那么,我认为初创公司最基本要做到的,是(朴素的)讲好的你的用户故事(User Story)

User story是Mike Cohn提出的一种描述需求的方式,通常包含:

  • 几句话讲清楚用户需求
  • 验收测试

典型的用户故事描述格式是这样的:

作为 <某类用户>,我想要 <完成某个目标>,这样的话 <某些理由>

  • 例如:作为一个炒币用户,我想要夜间功能,这样我晚上看行情做操作不刺眼。

拿这样的需求摆在台面上讲,才能将PM和RD放在同一个原始场景内,效果远好过丢过去十几页的PRD功能描述(没有人知道你到底想干嘛)。

RD也是用户,几句话能讲清楚的需求,人家才能立刻秒懂,才能知道可能有哪些坑要填。

User story适合放在confluence(或语雀)上,团队中的任何成员都有权利抛出User story,快速对其进行讨论。用户故事作为团队Knowledge base的一部分,必须做到快速冒泡,快速验证。

User story最好能拆解到工程师能在一个Sprint(通常一到两周)内完成,甚至一天的工作量搞定。否则粒度就应该拆的更细,由多个小的story拼接成某个具体场景。只有这样才能:

  • 大概齐能预判要花费的时间
  • 工程风险可以在每天Standup(或者你用Geekbot代替)上被抓到
  • issue看板上的任务才是「活的」,而不是「死在那里」

通常,我会在所有的User story上追问:

这样做对大部分客户有价值吗?他们想要这个功能想要到愿意从口袋里掏钱吗?

这是因为初创公司就这点人、这么点钱、这么点时间窗口,任何不是Must Have(a.k.a 不是商业闭环里必需的)的功能都占用了你的研发资源。

功能被研发出来后,应该迅速在你的 Alpha用户->粉丝用户->普通用户 里验证,如果它对拉高Retention Rate/用户付费/交易频次没有直接(或间接的)好处,那么它甚至一开始就不应该出现在backlog中。

对于初创公司的研发,重心应该在打造当前阶段可交付的产品上。早期的过度设计(Over-Engineering),会将自己的工作暴露在全然不可预测的环境中,被设计模式(Design Pattern)绑架。

拿TDD当例子,资深研发都认同这样的论点:TDD对于功能明确的、过程复杂的、核心的模块,可以有效减少系统风险,提高开发效率。

但对于「未知问题的解决」,TDD派不上什么用场。多写的那部分Unit Test,只会让开发耗时成倍数上升。而TDD通常来说又都很具体,Unit Test只能保证局部代码的牢靠,无法防范系统整体架构的风险。

从这点看,应该抓大放小,核心框架的测试有充分必要,而C端面向用户UI层的Unit Test,并不值得。

初创公司的产品开发必须精悍紧凑,迅速修正,不然上线的一天,就是梦想破碎的一天。