以樸素的方式開發產品

企業（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，並不值得。

初創公司的產品開發必須精悍緊湊，迅速修正，否則上線的一天，就是夢想破碎的一天。