以樸素的方式開發產品

企業(Enterprise)和初創公司(Starup)最大的區別在於,企業一般已經找到了(算是)牢靠的現金流管道,短時間內沒必要擔憂生存問題;而初創公司還在不斷探索什麼樣的產品真的能賣到錢,以及如何讓用戶持續從口袋裏掏錢。對於初創公司,一旦帳上的錢不夠發出下個月的工資,團隊就馬上、立刻面臨爆炸,潰不成軍。設計模式

在真實的商業環境裏,不少工程師加入的是Enterprise,而不是Starup。他們習慣等產品把PRD文檔和原型擺到案前,對商業模式的認知一般是:架構

商業模式不是我要考慮的事,反正我只須要把肯定的模塊實現,公司就會自動賺錢。若是碰到返工,那產品經理和老闆全是豬,本身沒想清楚,只知道讓我先作。框架

而在一家互聯網企業中,碰到一個既不懂商業邏輯,又不懂技術的產品經理的機率,仍是很高的。測試

這樣的PM一般是老闆聘請的跟班,負責收集內部(一般來自上級)和外部產生的「需求」,將需求以文檔形式「翻譯」給研發團隊。一個兩邊都不懂都人在中間當翻譯,結果只會炸成一地雞毛。老闆隔三差五跑進辦公室拍桌子要功能,留下PM和RD面面相覷,從新排期,把修改後的需求加塞插入。翻譯

中間一來一回,極可能一天就過去了。設計

企業還有機會試錯,初創公司這樣作就是自殺。blog

因此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,並不值得。

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

相關文章
相關標籤/搜索