以朴素的方式开发产品

企业（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，并不值得。

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