Back to Details

yc-sv-development-framework

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

YC/SV Development Framework

YC/硅谷软件开发决策框架

Decision-making framework based on principles from Y Combinator founders and Silicon Valley leaders.
基于YC创始人及硅谷领导者理念打造的决策框架。

THE CENTRAL QUESTION

核心问题

Before any technical decision, ask:
"Does this help us make something people want?" (Paul Graham, YC motto) "Will this help the next customer pay?"
If the answer isn't clearly YES, you probably shouldn't do it.
在做出任何技术决策前，请先问自己：
"这能帮助我们打造出用户真正需要的产品吗？"（Paul Graham，YC座右铭） "这能帮助下一位客户完成付费吗？"
如果答案不是明确的“是”，那你很可能不应该做这件事。

CORE PRINCIPLES

核心原则

1. Ship > Perfect (Michael Seibel)

1. 先上线，再完善（Michael Seibel）

"Launch something bad quickly" - Michael Seibel, YC
"If you walk away with one thing: launch something bad quickly"
  • Launch MVP in days, not weeks
  • Iterate based on real feedback
  • Your first version MUST be embarrassing
"Launch something bad quickly" - Michael Seibel, YC
"If you walk away with one thing: launch something bad quickly"
  • 数天内推出MVP，而非数周
  • 根据真实反馈迭代优化
  • 你的第一个版本必须“拿得出手但略显粗糙”

2. Validation > Architecture (Patrick Collison)

2. 验证优先于架构（Patrick Collison）

Patrick Collison built Stripe with Ruby + MongoDB, not "elegant" technology.
"Every time there's a super elegant way to do things and a practical, pragmatic way,
we're just gonna cut the corner—at least until we validate there's actual user value."
  • Ugly code that works > elegant code that doesn't exist
  • Don't optimize prematurely
  • Solve the problem first, refactor later (if necessary)
Patrick Collison built Stripe with Ruby + MongoDB, not "elegant" technology.
"Every time there's a super elegant way to do things and a practical, pragmatic way,
we're just gonna cut the corner—at least until we validate there's actual user value."
  • 能运行的“丑陋”代码 > 不存在的优雅代码
  • 不要过早优化
  • 先解决问题，之后再考虑重构（如果有必要的话）

3. Do Things That Don't Scale (Paul Graham)

3. 做非规模化的事（Paul Graham）

Brian Chesky at Airbnb: do things manually until it hurts, then automate.
Stripe founders installed the product in person ("Collison installation").
  • Manual processes are FINE at the start
  • Don't automate until the manual process is a real bottleneck
  • Use "Collison installation": set up customers manually one by one
Brian Chesky at Airbnb: do things manually until it hurts, then automate.
Stripe founders installed the product in person ("Collison installation").
  • 初期手动流程完全可行
  • 直到手动流程成为真正的瓶颈时再自动化
  • 采用“Collison安装法”：逐个为客户手动部署产品

4. Default Alive or Dead (Paul Graham)

4. 默认存活或死亡（Paul Graham）

Ask yourself: "If I don't raise more money, will I reach profitability before running out of runway?"
  • If you're "default dead", NOTHING matters except changing that
  • Fancy features are irrelevant if the business dies
Ask yourself: "If I don't raise more money, will I reach profitability before running out of runway?"
  • 如果你的公司“默认死亡”，那么除了改变这一现状，其他一切都不重要
  • 如果公司都活不下去，花哨的功能毫无意义

5. Founder Mode (Brian Chesky)

5. 创始人模式（Brian Chesky）

Brian Chesky at his YC 2024 talk: the best founders are in the details.
Great leadership is presence, not absence. Know the work, not just "manage people".
  • Being in the details is NOT micromanagement
  • Know the code, the product, the customers
Brian Chesky at his YC 2024 talk: the best founders are in the details.
Great leadership is presence, not absence. Know the work, not just "manage people".
  • 深入细节并非微观管理
  • 了解代码、产品和客户

DECISION FRAMEWORK

决策框架

Question 1: Is it currently working?

问题1：当前功能是否正常运行？

YES it works → DON'T TOUCH IT
"If it works, don't touch it"
YES it works → DON'T TOUCH IT
"If it works, don't touch it"

Question 2: Are users/customers complaining?

问题2：用户/客户是否有投诉？

NO complaints → Not a priority
YES complaints → Evaluate revenue impact
NO complaints → Not a priority
YES complaints → Evaluate revenue impact

Question 3: Does it block revenue?

问题3：它是否会阻碍营收？

YES blocks revenue → P0 (do it TODAY)
NO doesn't block → P1 or P2
YES blocks revenue → P0 (do it TODAY)
NO doesn't block → P1 or P2

Question 4: How many users does it affect?

问题4：它会影响多少用户？

10 users who LOVE the product > 1000 who "kinda like it"
- Michael Seibel
10 users who LOVE the product > 1000 who "kinda like it"
- Michael Seibel

PRIORITIES (P0/P1/P2)

优先级划分（P0/P1/P2）

P0 - Do TODAY

P0 - 今日必须完成

  • Bug losing money/customers
  • System down
  • Exploitable security vulnerability
  • Feature blocking first payment
  • 导致流失客户/损失收入的Bug
  • 系统宕机
  • 可被利用的安全漏洞
  • 阻碍首次付费的功能

P1 - This week

P1 - 本周完成

  • Bug reported by paying customer
  • Feature requested by multiple customers
  • Technical debt causing recurring bugs
  • 付费客户反馈的Bug
  • 多位客户请求的功能
  • 导致重复出现Bug的技术债务

P2 - When there's time

P2 - 有空再做

  • Refactoring "to clean up"
  • Tests for code that works
  • CI/CD improvements
  • Documentation
  • 为“代码整洁”而进行的重构
  • 为正常运行的代码添加测试
  • CI/CD优化
  • 文档编写

NEVER

绝对不要做

  • Rewrite something that works
  • Add features nobody asked for
  • "Improvements" without a real problem to solve
  • 重写正常运行的代码
  • 添加无人请求的功能
  • 没有实际问题需要解决的“优化”

TECHNICAL DEBT

技术债务

When to ACCEPT technical debt

何时可以接受技术债务

Technical debt is leverage - most startups need it.
  • To ship faster
  • To validate hypotheses
  • When the cost of NOT having it is greater than the interest
Technical debt is leverage - most startups need it.
  • 为了更快上线
  • 为了验证假设
  • 当不承担技术债务的成本高于其“利息”时

When to PAY technical debt

何时需要偿还技术债务

  • When it becomes a bottleneck for new features
  • When it causes recurring bugs (high "interest")
  • When 20% of the code causes 80% of the pain (Pareto)
  • 当它成为新功能开发的瓶颈时
  • 当它导致重复出现Bug（高“利息”）时
  • 当20%的代码引发80%的问题时（帕累托法则）

When to IGNORE technical debt

何时可以忽略技术债务

  • If the code works and nobody touches it
  • If the business might die before it matters
  • If it doesn't affect customers
  • 如果代码正常运行且无人改动
  • 如果公司可能在问题爆发前就倒闭
  • 如果它不影响客户

QUICK TECHNICAL DECISIONS

快速技术决策

Add tests?

是否添加测试？

Tests for critical payment code: YES
Tests for UI that changes every week: NO
Tests after production bug: YES
Tests "for best practices": NO
Tests for critical payment code: YES
Tests for UI that changes every week: NO
Tests after production bug: YES
Tests "for best practices": NO

Refactor?

是否重构？

If current code blocks needed feature: YES
If it "looks ugly" but works: NO
If it causes recurring bugs: YES
If it "would be more elegant": NO
If current code blocks needed feature: YES
If it "looks ugly" but works: NO
If it causes recurring bugs: YES
If it "would be more elegant": NO

Add CI/CD?

是否添加CI/CD？

If manual deploy takes >30min: YES
If there are <10 deploys/month: NO
If deploy errors are common: YES
If the team is 1-2 people: PROBABLY NO
If manual deploy takes >30min: YES
If there are <10 deploys/month: NO
If deploy errors are common: YES
If the team is 1-2 people: PROBABLY NO

New dependency/framework?

是否引入新依赖/框架？

Solves real problem you have TODAY: YES
"Would be useful in the future": NO
Team already knows it: BONUS
Nobody knows it: CAUTION
Solves real problem you have TODAY: YES
"Would be useful in the future": NO
Team already knows it: BONUS
Nobody knows it: CAUTION

COMMUNICATING DECISIONS

与非技术利益相关者沟通决策（Sam Altman）

With non-technical stakeholders (Sam Altman)

—
"Listen to everyone. Then make your own decision."
"It's better to make a decision and be wrong than to equivocate."
  1. Listen to the business problem
  2. Propose simple technical solution
  3. Give realistic timeline (and meet it)
  4. DON'T ask permission for technical decisions
"Listen to everyone. Then make your own decision."
"It's better to make a decision and be wrong than to equivocate."
  1. 倾听业务问题
  2. 提出简单的技术解决方案
  3. 给出切合实际的时间线（并兑现）
  4. 不要为技术决策请求许可

When to say NO

何时说“不”

  • "That would require rewriting X, which works fine"
  • "We can do it, but it would delay Y which is more important"
  • "The simple version takes 2 days, the 'correct' one takes 2 weeks"
  • “这需要重写目前运行正常的X模块”
  • “我们可以做，但会延迟更重要的Y任务”
  • “简单版本需要2天，‘完美’版本需要2周”

METRICS THAT MATTER

关键指标

"Choose 1-2 key metrics. Decide based nearly exclusively on how tasks impact those metrics"
- Michael Seibel
"Choose 1-2 key metrics. Decide based nearly exclusively on how tasks impact those metrics"
- Michael Seibel

For B2B SaaS:

B2B SaaS产品：

  1. MRR (Monthly Recurring Revenue)
  2. Churn rate
  1. MRR（月度经常性收入）
  2. 客户流失率

For Marketplace:

平台型产品：

  1. GMV (Gross Merchandise Value)
  2. Take rate
  1. GMV（商品交易总额）
  2. 抽成比例

For Consumer:

消费级产品：

  1. DAU/MAU
  2. Retention D7/D30
  1. DAU/MAU（日活跃用户数/月活跃用户数）
  2. D7/D30留存率

DON'T measure:

不要衡量：

  • Lines of code
  • Test coverage (except as a signal)
  • Team "velocity"
  • Story points
  • 代码行数
  • 测试覆盖率（除非作为参考信号）
  • 团队“速度”
  • 故事点数

EXECUTIVE SUMMARY

执行摘要

yaml
do:
  - Ship fast, iterate based on data
  - Solve real problems for real users
  - Ugly code that works > elegant code that doesn't exist
  - Manual first, automate when it hurts

dont:
  - Refactor code that works
  - Add features nobody asked for
  - Optimize before having users
  - "Best practices" without a real problem

guiding_questions:
  - "Will this help the next customer pay?"
  - "How many users are complaining about this?"
  - "What happens if we DON'T do this?"
  - "What's the simplest version that solves the problem?"
yaml
do:
  - Ship fast, iterate based on data
  - Solve real problems for real users
  - Ugly code that works > elegant code that doesn't exist
  - Manual first, automate when it hurts

dont:
  - Refactor code that works
  - Add features nobody asked for
  - Optimize before having users
  - "Best practices" without a real problem

guiding_questions:
  - "Will this help the next customer pay?"
  - "How many users are complaining about this?"
  - "What happens if we DON'T do this?"
  - "What's the simplest version that solves the problem?"

SOURCES

资料来源

Principles extracted from:
  • Paul Graham (YC Co-founder): paulgraham.com
  • Sam Altman (ex-YC President): blog.samaltman.com
  • Michael Seibel (YC Partner Emeritus, Former CEO): michaelseibel.com
  • Patrick Collison (Stripe CEO): Interviews and Stripe culture
  • Brian Chesky (Airbnb CEO): "Founder Mode" talk at YC 2024
理念提取自：
  • Paul Graham（YC联合创始人）：paulgraham.com
  • Sam Altman（前YC总裁）：blog.samaltman.com
  • Michael Seibel（荣誉YC合伙人，前CEO）：michaelseibel.com
  • Patrick Collison（Stripe CEO）：访谈及Stripe文化
  • Brian Chesky（Airbnb CEO）：2024年YC大会上的“创始人模式”演讲