Làm một mình: nhanh, tự do, nhưng dễ lạc trôi

Khi làm một mình, có vài thứ rất dễ chịu. Chúng ta tự do tuyệt đối, thích gì làm nấy, không phải thuyết phục ai. Quyết định cực nhanh – nghĩ xong là vibe code. Và có cảm giác “nghệ sĩ”: được sống trong thế giới của chính mình, theo đúng gu sản phẩm mình thích.

Nhưng sau một thời gian, mặt còn lại hiện ra. Chúng ta dễ xây tính năng cho một người dùng duy nhất: chính mình. Độ ưu tiên trở nên mơ hồ – thứ gì cũng thấy hay, nên làm cái gì trước cũng được. Và năng lượng tinh thần lên xuống thất thường: đặc biệt khi public xong không ai truy cập, không ai góp ý, rất dễ tự hỏi mình đang làm cái này để làm gì.

Pipeline có thể rất công phu, nhưng chỉ có một người bước vào đó – là mình.

Mở sớm, miễn phí trước: không chỉ là feedback

Khi thử chia sẻ sớm hơn, cho người khác dùng miễn phí, vài thứ thay đổi rõ rệt.

Tính năng sắc hơn. Thay vì nghĩ “tính năng này hay”, chúng ta bắt đầu hỏi ai sẽ dùng, trong tình huống nào, và nó giải quyết nỗi đau gì cụ thể. Những câu hỏi này thường không tự xuất hiện nếu không có người thật, feedback thật.

Roadmap bớt cảm tính, thêm dữ liệu. Mỗi comment, mỗi request nhỏ, mỗi lần user dùng sai tính năng – tất cả đều là tín hiệu để cân nhắc cái gì tối thiểu nhưng giá trị nhất nên làm tiếp theo. Tool không còn là sản phẩm mình ném cho người khác, mà trở thành thứ mình và người dùng cùng mài dũa.

Năng lượng tinh thần: lý do lớn nhất để mở sớm

Thứ mình cảm nhận rõ nhất không phải là tính năng chuẩn xác hơn, mà là năng lượng tinh thần. Có người chờ build mới, tự nhiên muốn làm tiếp. Có người báo “tính năng này giúp em tiết kiệm X phút mỗi ngày”, tự nhiên mọi giờ debug đêm khuya đều đáng giá. Có người chủ động đề xuất ý tưởng, tự nhiên sản phẩm không còn là chuyện cá nhân nữa.

Nếu nhìn ở góc độ kỹ thuật, nhóm người dùng đầu là nguồn feedback. Nếu nhìn ở góc độ cảm xúc, họ là nguồn nhiên liệu.

Từ độc thoại sang đối thoại

Làm một mình không sai. Giai đoạn đầu cần cô lập để prototype nhanh, thử sai nhanh. Nhưng nếu dừng ở đó, sản phẩm rất dễ mắc kẹt trong thế giới của chính mình.

Ship code là bước đầu. Ship không gian – mở cửa, để người khác dùng sớm, kể cả miễn phí – là bước tiếp theo, và quan trọng không kém. Vì thứ làm ý tưởng sống không phải là tool hay pipeline, mà là những người chịu bước vào đó cùng mình.

DESIGN.md là gì?

Một file markdown nằm ở root project, mô tả design system ở dạng plain-text. Không cần export Figma, không cần JSON schema, không cần plugin. Chỉ cần một file .md mà cả người lẫn AI đều đọc được.

Cách dùng:

1. Đặt DESIGN.md vào thư mục root

2. Để AI agent (Claude Code, Cursor, Gemini CLI, Copilot…) đọc

3. Yêu cầu: “Build the UI according to this design system”

Agent sẽ sinh giao diện bám sát màu sắc, typography, spacing, component styles đã định nghĩa – thay vì UI “generic AI” mặc định.

Tại sao markdown?

LLM được train trên text. Khi chúng ta export design system ra JSON schema hay qua Figma API, thông tin phải đi qua nhiều layer chuyển đổi – mỗi layer là cơ hội mất mát ngữ nghĩa. Markdown thì model đọc trực tiếp: headings, tables, bullet points – đúng format mà nó đã xử lý hàng tỷ lần trong quá trình huấn luyện.

Google Stitch gọi markdown là primitive chuẩn để mô tả design system cho LLM.

Vài điểm đáng chú ý:

• Single source of truth – mọi agent đọc cùng một nguồn, hạn chế drift giữa các lần prompt

• Không phụ thuộc design tool, plugin hay schema format cụ thể nào

• Versionable, reviewable, mergeable – sống trong Git như mọi file code khác

DESIGN.md biến design system thành thứ mà engineering workflow đã biết cách xử lý.

Cấu trúc một file DESIGN.md

Google Stitch cung cấp format chuẩn. Một file đầy đủ thường gồm:

• Visual Theme & Atmosphere – Mood, triết lý thiết kế

• Color Palette & Roles – Mã màu, vai trò (primary, success, danger…)

• Typography Rules – Font, scale, hierarchy H1 đến caption

• Component Stylings – Button, card, input, navbar kèm states

• Layout Principles – Spacing scale, grid, whitespace

• Depth & Elevation – Shadow, surface layer

• Do’s and Don’ts – Guardrails, anti-patterns

• Responsive Behavior – Breakpoint, touch target, collapse strategy

• Agent Prompt Guide – Quick reference và prompt mẫu

Format vừa đủ structured để agent parse, vừa đủ tự nhiên để người đọc không thấy đang đọc config file.

Ví dụ:

# Design System

## Overview
A focused, minimal dark interface for a developer productivity tool.
Clean lines, low visual noise, high information density.

## Colors
- **Primary** (#2665fd): CTAs, active states, key interactive elements
- **Secondary** (#475569): Supporting UI, chips, secondary actions
- **Surface** (#0b1326): Page backgrounds
- **On-surface** (#dae2fd): Primary text on dark backgrounds
- **Error** (#ffb4ab): Validation errors, destructive actions

## Typography
- **Headlines**: Inter, semi-bold
- **Body**: Inter, regular, 14–16px
- **Labels**: Inter, medium, 12px, uppercase for section headers

## Components
- **Buttons**: Rounded (8px), primary uses brand blue fill
- **Inputs**: 1px border, subtle surface-variant background
- **Cards**: No elevation, relies on border and background contrast

## Do's and Don'ts
- Do use the primary color sparingly, only for the most important action
- Don't mix rounded and sharp corners in the same view
- Do maintain 4:1 contrast ratio for all text

DESIGN.md và AGENTS.md

Trong thực tế, DESIGN.md thường đi cùng AGENTS.md:

• AGENTS.md – Cho coding agent: architecture, naming convention, CI/CD, quy trình

• DESIGN.md – Cho design/UI agent: sản phẩm nên trông và cảm giác như thế nào

Nghĩ theo mô hình onboarding: AGENTS.md là engineering handbook, DESIGN.md là brand guideline. Chúng ta onboard AI agent giống cách onboard một engineer mới – cho đọc tài liệu trước khi đụng vào code.

Kho DESIGN.md tham khảo của các dịch vụ nổi tiếng

VoltAgent đã build repo với hơn 40 file DESIGN.md trích xuất từ các sản phẩm nổi tiếng: Stripe, Vercel, Linear, Notion, Claude, Cursor, Warp, Zapier, Airbnb, Spotify, Uber, Coinbase…

Mỗi thư mục chứa DESIGN.md theo format Stitch, kèm preview.html và preview-dark.html để xem trực quan trước khi dùng.

Cách dùng:

1. Chọn site có style gần với brand của chúng ta

2. Copy DESIGN.md vào project root

3. Cho agent đọc và build UI theo

4. Refactor dần thành bản custom riêng

Repo MIT license, community maintain. Có thể mở issue yêu cầu thêm DESIGN.md cho website khác.

Kết

DESIGN.md là một ý tưởng đơn giản: biến design system thành file markdown, đúng format mà cả người lẫn LLM đọc tốt nhất. Khi kết hợp với AI coding agent, nó giúp chúng ta thu hẹp khoảng cách từ brand guideline đến UI thực tế, và chuẩn hóa cách AI agent làm việc trong team.

Link tham khảo:

• Docs chính thức của Google Stitch: stitch.withgoogle.com/docs/design-md/overview

• Repo tài nguyên: github.com/VoltAgent/awesome-design-md

“Viết code đúng” và “viết code đúng style“ là hai chuyện khác nhau. DESIGN.md là mảnh ghép ở giữa.

Vấn đề mà AutoAgent nhắm tới

Mỗi domain (CSKH, vận hành nội bộ, phân tích log, tài chính…) đòi hỏi một harness riêng. Người thiết kế vừa cần hiểu domain, vừa cần hiểu hành vi của mô hình ngôn ngữ – và hầu hết các team không có đủ bandwidth để tune hàng trăm harness như vậy.

AutoAgent tiếp cận bài toán này bằng cách cho phép domain expert chỉ cần định nghĩa tiêu chí thành công thông qua bộ eval/benchmark. Phần còn lại – thử nghiệm, sửa harness, phân tích failure trace – do một meta-agent đảm nhận.

Ở góc độ tổ chức, AutoAgent được định vị như một lớp infrastructure cho agent fleet: liên tục sinh, tối ưu và bảo trì các task-specific agent trên quy mô toàn công ty.

Cách AutoAgent hoạt động

Kiến trúc cơ bản gồm bốn thành phần: một task agent (ban đầu chỉ có bash tool), file program.md để định hướng cho meta-agent, agent.py là implementation của task agent, và một Harbor adapter kết nối vào benchmark/eval.

Meta-agent chạy một vòng lặp: chỉnh harness → cho task agent chạy trên task → đo performance → đọc failure traces → giữ thay đổi tốt, revert thay đổi xấu → lặp lại. Quá trình này được scale bằng cách chạy song song hàng ngàn sandbox. Theo nhóm tác giả, sau khoảng 24 giờ, hệ thống có thể tự khám phá được tooling, verification loop và orchestration logic phù hợp cho domain đích.

“Model empathy” – meta-agent hiểu task agent như thế nào

Một quan sát đáng chú ý từ nhóm nghiên cứu: meta-agent có xu hướng thiết kế harness hiệu quả hơn con người trong một số trường hợp, do nó đọc được reasoning trace của task agent và có sẵn hiểu biết về giới hạn, thiên hướng, kiểu lỗi thường gặp của chính mô hình đó.

Thực nghiệm cho thấy cặp cùng model (ví dụ Claude meta-agent + Claude task agent) cho kết quả tốt hơn cặp khác model (Claude meta-agent + GPT task agent). Giải thích được đưa ra là meta-agent viết harness đúng “ngôn ngữ nội tâm” của model hơn khi cả hai cùng kiến trúc.

Một số hành vi emergent

Trong quá trình chạy, meta-agent thể hiện một số hành vi tự phát:

• Spot checking: khi chỉ thay đổi nhỏ, meta-agent không chạy toàn bộ test suite mà chọn một vài task để kiểm tra nhanh.

• Forced verification loops: tự tạo bước self-check và validator format, tách riêng budget cho việc verify/correct output khỏi budget làm task chính.

• Viết tests: meta-agent hướng task agent tự sinh unit test cho từng task.

• Progressive disclosure: khi context quá lớn, agent tự ghi ra file rồi tham chiếu lại, thay vì nhồi vào một context duy nhất.

• Orchestration logic: tự tạo thêm sub-agent và flow riêng khi domain yêu cầu chia nhỏ nhiệm vụ.

Một vài kịch bản áp dụng

Xử lý ticket nội bộ (Ops/CS): Chuẩn bị tập ticket thật hoặc synthetic kèm expected resolution làm eval. Implement task agent với các tool cơ bản (query DB, gọi internal API). Định nghĩa tiêu chí thành công (tỉ lệ giải đúng, SLA, không gây side-effect). AutoAgent sẽ tối ưu harness dựa trên pattern ticket thực tế của tổ chức.

Phân tích log & incident (Data/Platform): Lấy bộ incident thật với timeline, log và RCA đúng làm ground truth. Cho task agent quyền truy cập log store, metric API, runbook repo. AutoAgent sẽ tự tìm cách tổ chức tool call phù hợp – khi nào đọc log, khi nào tra runbook, khi nào hỏi lại context.

Tự động hóa workflow nhỏ: Hầu hết công ty có hàng trăm workflow lặp lại (chuẩn hóa dữ liệu, sinh báo cáo tuần, sync giữa hai hệ thống…). Thay vì mỗi team tự build script riêng, có thể chuẩn hóa cách xây eval rồi dùng AutoAgent sinh và tune harness cho từng workflow, dần hình thành một agent fleet phụ trách các tác vụ lặp.

Kết quả benchmark

Trên các benchmark công khai, AutoAgent đạt 96.5% trên SpreadsheetBench và 55.1% GPT-5 score trên TerminalBench, hiện đứng đầu leaderboard – trong khi các entry khác đều do con người thiết kế harness thủ công.

Chúng ta nên làm gì?

Kết quả trên cho thấy một hướng tiếp cận đáng cân nhắc: thay vì đầu tư nặng vào việc thiết kế thủ công từng agent, có thể chuyển trọng tâm sang meta-layer – xây dựng tooling và eval tốt để một meta-agent liên tục sinh và tối ưu các agent nhỏ, gắn vào workflow cụ thể của tổ chức.

Trong đầu kỹ sư, mọi thứ luôn ở “high resolution”: từng module code, từng đoạn log, từng góc performance, từng quyết định kiến trúc đã cân nhắc rồi bỏ qua v.v.. Ở trong vùng đó, mọi thứ rất giàu thông tin và có logic, chỉ là nó ko hiển thị trực tiếp ra ngoài.

Vấn đề là người nghe – sếp, khách hàng hoặc stakeholder – không sống trong cái “resolution” đó. Họ chỉ cần một bản tóm tắt đủ để hiểu chuyện gì đang xảy ra, rủi ro/cơ hội là gì, và họ cần phải quyết cái gì. Nếu mình bê nguyên cả “bản đồ rõ nét 4K” trong đầu ra, xác suất cao là họ chỉ thấy một mớ chi tiết rời rạc, không ráp lại được thành bức tranh.

Thật ra mình cũng từng ở phía người nghe. Là manager có background kỹ thuật, nhưng khi engineer trình bày mà đổ hết mọi thứ ra – từ root cause, đến từng bước debug, đến config đã thử – cảm giác như bị DDoS bằng thông tin. Cuối cùng phải hỏi lại từng ý một, tự lọc ra đâu là thứ mình thật sự cần biết. Nghĩa là ngay cả người có chung ngôn ngữ kỹ thuật cũng vẫn bị ngợp, nếu thông tin không được lọc và nén đúng cách.

Ở giữa hai thái cực “nói qua loa cho xong” và “kể cho đã hết cả mọi chi tiết” có một cái điểm ngọt (sweet spot). Chạm đúng điểm đó thì người nghe hiểu được bản chất vấn đề, không bị thiếu context nhưng cũng không bị chìm trong thông tin. Vượt quá, mỗi thêm một lớp chi tiết là thêm một lớp nhiễu.

Và sweet spot đó không cố định – nó phụ thuộc vào người nghe. Cùng một incident, trình bày cho CTO khác với trình bày cho Product Manager, khác với trình bày cho CEO. Nên trước khi chuẩn bị nội dung, câu hỏi đầu tiên không phải “mình muốn nói gì”, mà là “người nghe cần biết gì trong buổi này”. Hiểu được điều đó thì tự khắc biết đâu là thông tin giữ lại, đâu là thông tin lược bỏ.

Cách xử lý thông tin : làm sao lấy cái vòng tròn “core experience” trong đầu, nén lại thành vài câu, vài slide, để một người không có cùng background vẫn hình dung đúng được vấn đề. Cố gắng sử dụng ẩn dụ hợp lý và gần gũi để người nghe nhanh chóng nắm được các ý niệm. Còn những phần chi tiết thì để dành cho Q&A, khi họ thật sự muốn đào sâu là được.

Sau đủ nhiều kinh nghiệm trình bày, mình nhận ra kỹ năng khó nhất không phải nói cho hay, mà là biết cô đọng và on-point. Khi phía bên kia hiểu đúng ý mình muốn nói – dù mình không kể hết ý mình đang nghĩ – thì đó chính là lúc mình đã chạm đúng sweet spot.

Why bother with profiles?

I use different auth methods depending on what I'm working on:

• API Key: Personal/Company projects using Anthropic credits

• AWS Bedrock: Work stuff through company AWS

• Pro Account: Quick experiments with my Claude Pro subscription

Instead of juggling env vars, now I just type claude-pro, claude-aws, or claude-api and boom - done!

Steps

1. Make a folder for profiles

First, create a directory to store all your profile configurations:

mkdir -p ~/.claude-profiles

2. Create environment files

These files tell each profile which credentials to use. Create three files:

~/.claude-profiles/api.env

# Clear any Claude session tokens if they exist
unset CLAUDE_SESSION_TOKEN

# API Key profile
export ANTHROPIC_API_KEY="your_anthropic_api_key_here"
unset CLAUDE_CODE_USE_BEDROCK
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_REGION

~/.claude-profiles/aws.env

# AWS Bedrock profile
unset CLAUDE_SESSION_TOKEN
unset ANTHROPIC_API_KEY

# Using AWS Profile (use `aws sso login --profile "profile_name"`)
export AWS_PROFILE="your_aws_profile_name"
export CLAUDE_CODE_USE_BEDROCK="true"
export ANTHROPIC_MODEL="us.anthropic.claude-3-7-sonnet-20250219-v1:0"
export ANTHROPIC_SMALL_FAST_MODEL="us.anthropic.claude-3-5-haiku-20241022-v1:0"

# AWS credentials for Bedrock (In case you use static credentials)
# export AWS_ACCESS_KEY_ID="your_aws_access_key_id"
# export AWS_SECRET_ACCESS_KEY="your_access_key"
# export AWS_SESSION_TOKEN="your_aws_session_token"
# export AWS_REGION="your_aws_region"

~/.claude-profiles/pro.env

# Pro account profile - clear all API credentials
unset CLAUDE_SESSION_TOKEN
unset ANTHROPIC_API_KEY
unset CLAUDE_CODE_USE_BEDROCK
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_REGION

3. Create the magic wrapper scripts

These scripts load the right environment and launch Claude Code:

~/.claude-profiles/launch-api.sh

#!/bin/bash
source ~/.claude-profiles/api.env
echo "🔑 Launching Claude Code with Anthropic API Key authentication..."
claude "$@"

~/.claude-profiles/launch-aws.sh

#!/bin/bash
source ~/.claude-profiles/aws.env
echo "☁️  Launching Claude Code with AWS Bedrock authentication..."
claude "$@"

~/.claude-profiles/launch-pro.sh

#!/bin/bash
source ~/.claude-profiles/pro.env
echo "👤 Launching Claude Code with Pro account authentication..."
claude "$@"

Don't forget to make them executable:

chmod +x ~/.claude-profiles/*.sh

4. Add some sweet aliases

Add these to your shell config file (I’m using zsh, so I edit ~/.zshrc, your case maybe the ~/.bashrc file):

# Claude Code profile aliases
alias claude='~/.claude-profiles/launch-api.sh'
alias claude-api='~/.claude-profiles/launch-api.sh'
alias claude-pro='~/.claude-profiles/launch-pro.sh'
alias claude-aws='~/.claude-profiles/launch-aws.sh'

5. Reload and you're done!

# For Bash
source ~/.bashrc

# For Zsh
source ~/.zshrc

How to use it

Super simple! Just use these commands:

# Use API key (default)
claude

# Use API key (explicit)
claude-api

# Use Pro account
claude-pro

# Use AWS Bedrock
claude-aws

All the usual Claude Code arguments work too:

claude-pro --help
claude-aws --verbose
claude-api --config myconfig.json

Quick notes

API Key setup:

• Replace "your_anthropic_api_key_here" with your actual key

AWS Bedrock setup:

• Make sure AWS CLI is configured: aws sso login --profile "your_profile_name"

• Update the model names if needed

• Uncomment and update the static credentials if you're not using AWS profiles

Pro Account setup:

• Log in to Claude Code with your Anthropic account first (just run claude-code normally once)

• After that initial login, claude-pro will work perfectly

That's it!

Now you can switch between different Claude Code auth methods without thinking about it. The setup takes 5 minutes but saves you tons of time later. Plus, it just feels so much cleaner than managing env vars manually.

Happy coding! 🚀

First, install Gemini CLI and authenticate it:

npm install -g @google/gemini-cli
gemini

Now, add this to your ~/.claude/CLAUDE.md

# Using Gemini CLI for Large Codebase Analysis

When analyzing large codebases or multiple files that might exceed context limits, use the Gemini CLI with its massive
context window. Use `gemini -p` to leverage Google Gemini's large context capacity.

## File and Directory Inclusion Syntax

Use the `@` syntax to include files and directories in your Gemini prompts. The paths should be relative to WHERE you run the
gemini command:

### Examples:

**Single file analysis:**
gemini -p "@src/main.py Explain this file's purpose and structure"

**Multiple files:**
gemini -p "@package.json @src/index.js Analyze the dependencies used in the code"

**Entire directory:**
gemini -p "@src/ Summarize the architecture of this codebase"

**Multiple directories:**
gemini -p "@src/ @tests/ Analyze test coverage for the source code"

**Current directory and subdirectories:**
gemini -p "@./ Give me an overview of this entire project"

# Or use --all_files flag:
gemini --all_files -p "Analyze the project structure and dependencies"

## Implementation Verification Examples

**Check if a feature is implemented:**
gemini -p "@src/ @lib/ Has dark mode been implemented in this codebase? Show me the relevant files and functions"

**Verify authentication implementation:**
gemini -p "@src/ @middleware/ Is JWT authentication implemented? List all auth-related endpoints and middleware"

**Check for specific patterns:**
gemini -p "@src/ Are there any React hooks that handle WebSocket connections? List them with file paths"

**Verify error handling:**
gemini -p "@src/ @api/ Is proper error handling implemented for all API endpoints? Show examples of try-catch blocks"

**Check for rate limiting:**
gemini -p "@backend/ @middleware/ Is rate limiting implemented for the API? Show the implementation details"

**Verify caching strategy:**
gemini -p "@src/ @lib/ @services/ Is Redis caching implemented? List all cache-related functions and their usage"

**Check for specific security measures:**
gemini -p "@src/ @api/ Are SQL injection protections implemented? Show how user inputs are sanitized"

**Verify test coverage for features:**
gemini -p "@src/payment/ @tests/ Is the payment processing module fully tested? List all test cases"

## When to Use Gemini CLI

Use gemini -p when:
- Analyzing entire codebases or large directories
- Comparing multiple large files
- Need to understand project-wide patterns or architecture
- Current context window is insufficient for the task
- Working with files totaling more than 100KB
- Verifying if specific features, patterns, or security measures are implemented
- Checking for the presence of certain coding patterns across the entire codebase

## Important Notes

- Paths in @ syntax are relative to your current working directory when invoking gemini
- The CLI will include file contents directly in the context
- No need for --yolo flag for read-only analysis
- Gemini's context window can handle entire codebases that would overflow Claude's context
- When checking implementations, be specific about what you're looking for to get accurate results

Ok, now start new Claude Code session and try to tell it to read a large file or explicitly tell it to use Gemini to analyze a file.

> explain @large-file to me. Use Gemini.

Why use Gemini inside Claude Code?

While Claude Code excels at detailed implementation planning, Gemini's massive context window makes it unbeatable for codebase comprehension. Gemini can instantly digest entire codebases using just 1% context per query versus Claude Code's 10%, making it perfect for quick code understanding before switching to Claude Code for actual implementation work.RetryClaude can make mistakes. Please double-check responses.

“Basal Cost” – Chi phí duy trì ngầm của phần mềm

• Khái niệm này được Eferro — một product dev, giới thiệu. Đây là chi phí liên tục phát sinh sau khi một tính năng được triển khai lần đầu đến người dùng.

  • Giống như cơ thể con người tiêu tốn năng lượng để duy trì sự sống, phần mềm cũng tiêu tốn tài nguyên để duy trì các tính năng hiện có, ngay cả khi không có thay đổi nào được thực hiện.

• Chi phí này bao gồm:

  • Tăng độ phức tạp của hệ thống, khiến việc hiểu và bảo trì trở nên khó khăn hơn.

  • Ảnh hưởng đến việc phát triển các tính năng mới, do phải đảm bảo tính tương thích và tránh gây lỗi cho các phần hiện có.

  • Chi phí đào tạo và truyền đạt kiến thức cho các thành viên mới trong nhóm.

Timeline chi phí của một tính năng

• f1: Chi phí ban đầu để tạo tính năng.

• Lớp trên: Chi phí ngầm của tính năng mới được thêm vào.

• Lớp dưới: Chi phí ngầm của các tính năng trước đó.

• Đường nét đứt dọc: Thời điểm công nghệ của tính năng trở nên lỗi thời, khó bảo trì

Sự hiểu nhầm tai hại

Một sai lầm phổ biến là việc thiếu cân nhắc chi phí bảo trì về sau, mà cứ mặc định là nếu không sửa gì thêm thì ko tốn chi phí. Không phải như vậy.

Hệ quả

1. Team giảm dần dư địa nguồn lực để phát triển tính năng mới (vì phải phân bổ thêm cho việc bảo trì)

2. Thậm chí sẽ tới lúc việc bảo trì chiếm gần hết nguồn lực, ko có nguồn lực để tạo những tính năng mới cho người dùng.

3. Hoặc lúc đó team phải giảm tốc độ tạo tính năng mới, do phải tiêu tốn nhiều vào chi phí nền.

Giải pháp

1. Tối thiểu hoá chi phí ngầm này ← Kỹ sư

• Nếu có thể, hãy cố gắng giải quyết được vấn đề mà không cần phải viết thêm code. Hãy tự đặt các câu hỏi trước khi làm:

  • Nó có thật sự cần thiết không? Nếu không có nó thì sao?

  • Liệu có thể giải quyết vấn đề mà không cần code không?

  • Khi thêm vào, có làm hệ thống phức tạp thêm nhiều không?

  • Sau 3 tháng, tính năng này có thể sẽ gây ra vấn đề bảo trì gì không? v.v.

• Sửa lại tính năng để phù hợp tối đa với nhu cầu thực tế của người dùng, và luôn giữ giải pháp ở mức tối giản.

• Thiết kế và code nên càng đơn giản càng tốt. Hệ thống cần dễ dàng mở rộng khi cần mà không bị thiết kế quá phức tạp ngay từ đầu (tuân theo nguyên tắc YAGNI).

2. Theo dõi liên tục mã nguồn sản phẩm để phát hiện các thư viện, ngôn ngữ hoặc công nghệ lỗi thời để xử lý sớm (nếu ko chi phí sẽ đột ngột tăng mạnh) ← Kỹ sư, CTO

• Nếu có thư viện nào đã ko còn được bảo trì, nên tìm cách thay thế sớm.

3. Ngăn chặn việc đưa các tính năng ít giá trị vào sản phẩm hoặc xoá bỏ các tính năng ko còn phù hợp ra khỏi sản phẩm ← Product Manager, CTO

Nguồn tham khảo: https://www.eferro.net/2021/02/basal-cost-of-software.html

Một điều tôi biết rõ là: nếu bạn muốn làm được những điều lớn lao, bạn sẽ phải làm việc cực kỳ chăm chỉ. Hồi nhỏ, tôi không chắc điều đó là đúng. Việc học ở trường có lúc dễ, có lúc khó; không phải lúc nào cũng cần cố gắng hết sức mới đạt kết quả tốt. Và khi nhìn vào những người nổi tiếng, tôi thấy họ dường như làm mọi thứ một cách nhẹ nhàng, dễ dàng. Liệu có cách nào để “né” việc chăm chỉ chỉ bằng sự thông minh xuất chúng không? Giờ tôi biết câu trả lời rồi. Không có đâu.

Lý do một số môn học có vẻ dễ là vì trường tôi đặt tiêu chuẩn thấp. Còn lý do người lớn nổi tiếng làm việc trông như “nhẹ nhàng” là vì họ đã luyện tập trong nhiều năm – họ khiến nó trông có vẻ dễ thôi.

Tất nhiên, những người nổi tiếng đó thường có năng khiếu bẩm sinh. Có ba yếu tố tạo nên công việc xuất sắc: tài năng bẩm sinh, rèn luyện, và nỗ lực. Bạn có thể làm khá tốt chỉ với hai trong ba thứ đó, nhưng để đạt được đỉnh cao thực sự, bạn cần cả ba: có tài, luyện tập nhiều, và cố gắng hết sức.

Ví dụ như Bill Gates – một trong những người thông minh nhất trong giới kinh doanh thời ông, đồng thời cũng là một trong những người chăm chỉ nhất. “Tôi không nghỉ một ngày nào trong suốt những năm 20 tuổi,” ông nói. Không một ngày nào. Lionel Messi cũng vậy. Anh có tài năng thiên bẩm, nhưng khi các huấn luyện viên hồi nhỏ của anh nhắc lại, điều họ nhớ không phải chỉ là tài năng, mà là sự tận tâm và khao khát chiến thắng.

Tác giả P. G. Wodehouse có lẽ là cây bút tiếng Anh xuất sắc nhất thế kỷ 20 nếu tôi phải chọn. Chưa ai viết mà khiến mọi thứ trông dễ dàng hơn. Nhưng cũng chưa ai làm việc chăm chỉ hơn. Ở tuổi 74, ông viết:

“Mỗi khi ra sách mới, tôi lại có cảm giác lần này mình đã chọn phải một quả chanh trong khu vườn văn học. Mà cũng tốt thôi. Nó giúp tôi luôn tỉnh táo và buộc tôi phải viết lại từng câu đến mười lần. Hoặc nhiều khi là hai mươi lần.”

Nghe có vẻ hơi quá đà, phải không? Nhưng Bill Gates thậm chí còn cực đoan hơn. Mười năm không nghỉ lấy một ngày? Hai người này sở hữu tài năng bẩm sinh đỉnh cao, và họ cũng làm việc chăm chỉ gần như không ai bằng. Bạn cần cả hai yếu tố đó.

Điều này nghe có vẻ quá hiển nhiên, nhưng thực tế thì nhiều người lại không nắm rõ. Có một sự mơ hồ, như thể phải chọn một trong hai: hoặc là tài năng, hoặc là chăm chỉ. Niềm tin đó phần nào đến từ văn hóa đại chúng – nơi tài năng thường được tôn vinh một cách thần thánh – và phần nào do thực tế rằng những người thực sự xuất sắc rất hiếm. Nếu cả tài năng và sự nỗ lực đều hiếm, thì người có cả hai lại càng hiếm hơn nữa. Đa phần những người bạn gặp, nếu có rất nhiều cái này thì thường ít cái kia. Nhưng nếu bạn muốn trở thành một người xuất chúng, bạn cần cả hai. Và vì bạn không thể thay đổi mức độ tài năng bẩm sinh của mình, nên thực tế là để làm được những việc lớn, bạn chỉ còn cách duy nhất: làm việc chăm chỉ.

Việc làm việc chăm chỉ trở nên dễ dàng hơn khi bạn có mục tiêu rõ ràng và được người khác giao việc – giống như khi đi học. Cũng cần có một vài kỹ năng: bạn phải học cách không tự dối mình, không trì hoãn (vì trì hoãn thực ra là một dạng tự lừa dối), không bị xao nhãng và không bỏ cuộc khi gặp thất bại. Nhưng kiểu kỷ luật này vẫn nằm trong tầm với của trẻ em, nếu chúng thực sự muốn.

Điều mà tôi học được sau này, là cách làm việc hướng đến những mục tiêu không rõ ràng, và cũng không ai giao cho bạn. Bạn sẽ cần học cả hai kỹ năng, nếu muốn làm nên chuyện lớn.

Mức cơ bản nhất trong việc đó là bạn phải cảm thấy mình nên làm việc – dù không ai bảo bạn phải làm. Bây giờ, mỗi khi tôi không làm việc chăm chỉ, trong đầu như có chuông báo động vang lên. Khi làm việc chăm chỉ, tôi không chắc mình sẽ tiến được bao xa, nhưng khi không làm gì cả thì tôi chắc chắn mình chẳng đi đến đâu – và cảm giác đó thật tệ.

Không có một khoảnh khắc nào cụ thể mà tôi nhận ra điều này. Như bao đứa trẻ khác, tôi từng thấy vui khi học được điều gì mới hay hoàn thành một việc gì đó. Khi lớn lên, cảm giác đó chuyển thành sự khó chịu khi không làm được gì có ích. Cột mốc rõ ràng nhất mà tôi nhớ là khi tôi dừng xem TV – lúc 13 tuổi.

Nhiều người mà tôi từng nói chuyện cũng nhớ rõ rằng khoảng tầm tuổi này họ bắt đầu nghiêm túc hơn với việc học hành hay công việc. Khi tôi hỏi Patrick Collison (nhà sáng lập Stripe) rằng anh bắt đầu thấy “rảnh rỗi là phí phạm” từ khi nào, anh nói:

“Tôi nghĩ khoảng 13 hoặc 14 tuổi. Tôi vẫn nhớ rõ cảm giác lúc ngồi trong phòng khách, nhìn ra ngoài cửa sổ và tự hỏi vì sao mình lại đang phí phạm kỳ nghỉ hè như vậy.”

Có lẽ đến tuổi dậy thì, trong ta có sự thay đổi nào đó. Nghe cũng hợp lý thôi.

Lạ thay, rào cản lớn nhất ngăn tôi nghiêm túc với công việc, lại chính là… trường học. Trường học khiến “công việc” (cái họ gọi là công việc) trở nên nhàm chán và vô nghĩa. Tôi đã phải học cách phân biệt đâu là công việc thực sự, trước khi có thể toàn tâm toàn ý muốn làm nó. Điều đó mất khá nhiều thời gian, vì thậm chí đến khi học đại học, vẫn có nhiều môn học hay cả ngành học mà tôi thấy vô nghĩa. Nhưng khi tôi dần nhận ra “hình dáng” của công việc thật sự, tôi thấy mong muốn của mình dường như khớp hoàn hảo với nó – như thể hai mảnh ghép được tạo ra dành cho nhau.

Phân biệt công việc thật và giả

Tôi đoán là hầu hết mọi người đều phải học cách hiểu công việc thực sự là gì trước khi họ có thể yêu thích nó. Nhà toán học Hardy từng viết rất hay về điều này trong A Mathematician’s Apology:

“Tôi không nhớ là hồi nhỏ mình từng có đam mê với toán học. Những suy nghĩ của tôi về nghề toán lúc đó chẳng cao quý gì. Tôi nghĩ toán học chỉ liên quan đến việc thi cử và giành học bổng. Tôi muốn vượt lên người khác, và điều này dường như là cách hiệu quả nhất để làm được điều đó.”

Ông chỉ thật sự hiểu toán học là gì khi đọc cuốn Cours d’analyse của Jordan – khoảng giữa thời đại học:

“Tôi sẽ không bao giờ quên sự kinh ngạc khi đọc cuốn sách phi thường ấy – nguồn cảm hứng đầu tiên của rất nhiều nhà toán học cùng thời tôi. Lần đầu tiên trong đời, tôi hiểu toán học thực sự có nghĩa là gì.”

Để hiểu được công việc thực sự là gì, bạn phải học cách loại bỏ hai kiểu “giả tạo” thường gặp.

Kiểu đầu tiên là kiểu mà Hardy gặp phải khi còn đi học. Khi các môn học được đơn giản hóa để dạy cho trẻ em, chúng thường bị bóp méo đến mức không còn giống gì với công việc thực tế mà người trong ngành đang làm.

Kiểu “giả” thứ hai là loại công việc vốn dĩ đã không có giá trị thật. Một số loại công việc đơn giản là vô nghĩa, hoặc nếu tốt lắm thì cũng chỉ là làm cho có việc.

Ngược lại, công việc thật sự thường có một cảm giác rất “thật” và vững chắc. Không phải tất cả đều ở tầm viết Principia như Newton, nhưng tất cả đều mang cảm giác cần thiết. Tiêu chí này nghe có vẻ mơ hồ, và tôi cố tình để nó mơ hồ – vì nó cần đủ rộng để bao trùm nhiều kiểu công việc khác nhau.

Cách để duy trì năng suất cao mà không bị kiệt sức

Khi bạn đã hiểu rõ công việc thật sự là gì, bước tiếp theo là tìm ra mỗi ngày nên dành bao nhiêu thời gian cho nó. Bạn không thể giải quyết chuyện này chỉ bằng cách làm việc suốt từ sáng đến tối, vì với nhiều loại công việc, sau một ngưỡng nào đó, chất lượng công việc sẽ bắt đầu giảm.

Giới hạn đó thay đổi tùy vào loại công việc và từng người. Tôi từng làm nhiều kiểu công việc khác nhau, và mỗi kiểu có giới hạn riêng. Với các công việc khó như viết hoặc lập trình, giới hạn của tôi là khoảng năm tiếng một ngày. Còn khi tôi điều hành startup, tôi có thể làm việc gần như suốt ngày – ít nhất là trong ba năm tôi làm việc đó; nếu làm lâu hơn chắc tôi cũng sẽ cần nghỉ ngơi định kỳ.

Cách duy nhất để biết giới hạn của mình là vượt qua nó và tự cảm nhận. Hãy rèn luyện sự nhạy cảm với chất lượng công việc của bạn – để có thể nhận ra khi nào nó giảm đi vì bạn làm việc quá sức. Sự trung thực là yếu tố cực kỳ quan trọng – theo cả hai chiều: bạn phải nhận ra lúc nào mình đang lười, và lúc nào mình đang làm việc quá sức.

Và nếu bạn cho rằng làm việc đến kiệt sức là một điều đáng tự hào – hãy loại bỏ suy nghĩ đó. Không chỉ là bạn đang cho ra kết quả tệ hơn, mà lý do còn là để “khoe” – dù là với người khác hay với chính mình.

Việc tìm ra giới hạn làm việc hiệu quả không phải là chuyện làm một lần rồi xong. Nó là một quá trình liên tục, luôn thay đổi. Mức độ khó của công việc và khả năng của bạn có thể thay đổi theo từng giờ. Vì vậy, bạn cần luôn đánh giá cả:

• Bạn đang nỗ lực bao nhiêu

• Và kết quả bạn đang tạo ra tốt đến đâu.

Nhưng làm việc chăm chỉ không đồng nghĩa với việc lúc nào cũng phải ép mình. Có thể có người như vậy, nhưng theo kinh nghiệm của tôi – và tôi nghĩ cũng đúng với nhiều người khác – thì chỉ những lúc bắt đầu dự án mới hoặc gặp trở ngại thì mới cần ép bản thân. Đó là lúc dễ trì hoãn. Nhưng một khi đã “vào guồng” thì tôi có xu hướng tiếp tục.

Động lực làm việc

Điều gì khiến tôi tiếp tục làm việc phụ thuộc vào loại công việc tôi đang làm. Khi tôi làm sản phẩm Viaweb, động lực chính là nỗi sợ thất bại. Tôi hầu như không trì hoãn gì khi đó, vì lúc nào cũng có việc cần làm – và nếu tôi có thể đẩy xa khoảng cách giữa mình và “con quái vật đang đuổi phía sau” bằng cách hoàn thành việc đó, thì cớ gì phải chần chừ?

Còn bây giờ, khi tôi viết các bài tiểu luận, động lực lại là những lỗi sai và thiếu sót trong chính bài viết. Giữa các bài, tôi thường “lượn lờ” vài ngày, giống như một con chó quay vòng tìm chỗ nằm. Nhưng một khi bắt đầu, tôi không cần ép mình – vì luôn có lỗi gì đó đang thúc ép tôi sửa nó.

Tôi cũng có cố gắng nhất định để tập trung vào những chủ đề quan trọng. Nhiều vấn đề có một “lõi cứng” rất khó ở trung tâm, bao quanh bởi những phần dễ hơn ở rìa. Làm việc chăm chỉ tức là cố gắng tiến gần đến trung tâm càng nhiều càng tốt. Có ngày bạn sẽ không thể chạm đến lõi, chỉ xử lý được những thứ dễ ở ngoài rìa. Nhưng quan trọng là bạn luôn nhắm đến trung tâm, miễn là không bị đứng lại.

Câu hỏi lớn hơn, kiểu như “mình nên làm gì với cuộc đời này?”, cũng giống như thế – một vấn đề có lõi cứng. Ở trung tâm là những vấn đề quan trọng và khó nhất, còn ngoài rìa là những việc dễ hơn nhưng ít ý nghĩa hơn. Vậy nên, ngoài những điều chỉnh nhỏ hàng ngày khi làm việc, đôi lúc bạn sẽ cần những điều chỉnh lớn, mang tính cả đời: chọn loại công việc để theo đuổi. Và nguyên tắc vẫn vậy: làm việc chăm chỉ là hướng về trung tâm – là những vấn đề tham vọng nhất.

Nhưng lưu ý: khi tôi nói “trung tâm”, tôi không có ý là theo số đông nghĩ cái gì là quan trọng nhất. Quan điểm chung về cái gì là “đáng làm” thường sai – cả ở mức độ xã hội lẫn trong từng lĩnh vực. Nếu bạn không đồng ý với quan điểm số đông, và bạn đúng, đó có thể là cơ hội vàng để làm điều gì đó đột phá.

Những loại công việc tham vọng thường sẽ khó hơn – và bạn không nên phủ nhận điều đó. Nhưng bạn cũng không nên coi độ khó là tiêu chí tuyệt đối để chọn việc. Nếu bạn tìm ra một loại công việc “tham vọng nhưng hợp với bạn” – ví dụ vì khả năng bẩm sinh, cách tiếp cận mới, hoặc đơn giản là vì bạn thấy hứng thú – thì hãy làm nó. Nhiều thành tựu vĩ đại đến từ những người tìm được cách dễ hơn để làm một việc cực khó.

Làm sao biết mình phù hợp với loại công việc nào

Bên cạnh việc hiểu được bản chất của công việc thực sự, bạn còn cần tìm ra loại công việc nào phù hợp với mình. Mà “phù hợp” ở đây không chỉ có nghĩa là bạn có năng khiếu bẩm sinh. Không phải cứ cao 2 mét là bạn phải chơi bóng rổ.

Bạn phù hợp với công việc nào không chỉ phụ thuộc vào tài năng, mà còn – thậm chí nhiều hơn – vào sở thích. Một người có đam mê thực sự với một lĩnh vực nào đó sẽ làm việc chăm chỉ hơn rất nhiều so với người chỉ có kỷ luật.

Thật ra, khám phá sở thích còn khó hơn khám phá tài năng. Tài năng thường có ít loại, và được nhận ra từ sớm. Nhưng sở thích thì tinh tế và phát triển chậm – có khi phải đến tuổi đôi mươi, thậm chí muộn hơn, bạn mới nhận ra mình thích gì. Có khi, lĩnh vực bạn thật sự đam mê còn chưa tồn tại vào lúc bạn còn trẻ.

Ngoài ra còn có những yếu tố dễ khiến bạn bị lệch hướng – những “nguồn gây nhiễu” mạnh mẽ mà bạn cần học cách nhận diện và loại bỏ. Ví dụ:

• Bạn có thực sự thích lĩnh vực đó không,

• Hay bạn theo đuổi nó vì nghĩ sẽ kiếm được nhiều tiền?

• Hay vì người khác sẽ ấn tượng với bạn?

• Hay chỉ vì cha mẹ muốn bạn làm vậy?

Mức độ khó khăn khi tìm ra “mình nên làm gì” rất khác nhau giữa mỗi người. Đó là một trong những bài học quan trọng nhất tôi rút ra về công việc, kể từ khi còn nhỏ.

Khi còn là trẻ con, bạn thường có cảm giác rằng ai cũng có một “tiếng gọi” – và chỉ cần tìm ra nó là xong. Trong phim ảnh, hay những tiểu sử đơn giản hóa dành cho trẻ em, mọi thứ thường được kể như vậy. Và đôi khi, ngoài đời cũng đúng như thế. Có người biết mình muốn làm gì từ nhỏ, rồi cứ thế theo đuổi – như Mozart chẳng hạn.

Nhưng cũng có những người – như Newton – thì cứ chuyển từ việc này sang việc khác một cách không yên. Nhìn lại sau này, chúng ta có thể nói “À, toán và vật lý mới là thiên hướng thực sự của ông, còn giả kim và thần học thì phí thời gian quá.” Nhưng đó chỉ là ảo giác do nhìn lại quá khứ, chứ thực tế thì ông không hề nghe thấy một tiếng gọi rõ ràng nào cả.

Vì vậy, có người tìm ra con đường của mình sớm, nhưng cũng có người cả đời không tìm thấy một “đích đến” rõ ràng. Và với những người như vậy, tìm xem mình nên làm gì không phải là bước đệm để bắt đầu chăm chỉ, mà chính là một phần trong quá trình làm việc chăm chỉ – như một hệ phương trình có nhiều ẩn số cần giải cùng lúc.

Với họ, quá trình làm việc gồm ba phần:

1. Xem mình đang nỗ lực đến đâu

2. Đánh giá kết quả mình đạt được

3. Và quan trọng không kém: xem xét có nên tiếp tục trong lĩnh vực này hay chuyển sang lĩnh vực khác.

Nếu bạn đang làm việc rất chăm chỉ nhưng kết quả không đủ tốt, thì có thể bạn nên đổi hướng. Nghe thì đơn giản, nhưng thực tế rất khó.

Bạn không thể bỏ cuộc ngay ngày đầu tiên chỉ vì làm việc chăm chỉ mà không thấy kết quả. Bạn cần cho bản thân một khoảng thời gian đủ dài để khởi động. Nhưng bao lâu là đủ? Nếu công việc từng diễn ra tốt đẹp rồi đột nhiên bế tắc – bạn nên cho bản thân thêm bao nhiêu thời gian nữa?

Đánh giá kết quả công việc

Ngay cả việc thế nào là “kết quả tốt” cũng không dễ đánh giá. Nếu bạn đang khám phá một lĩnh vực mà ít người từng làm, bạn có thể không biết kết quả tốt trông như thế nào. Lịch sử đầy rẫy những ví dụ về người làm việc miệt mài nhưng không nhận ra giá trị thật sự của điều họ đang làm.

Vậy thì thước đo đáng tin cậy nhất để biết có nên tiếp tục làm một việc gì đó không, là bạn có thấy nó thú vị không. Nghe có vẻ chủ quan nguy hiểm, nhưng thật ra đây là thước đo chính xác nhất mà bạn có thể có được. Chính bạn là người đang làm việc đó. Còn ai hiểu rõ hơn bạn về việc nó có giá trị hay không? Và còn chỉ báo nào tốt hơn là chính cảm giác hứng thú của bạn?

Nhưng để cách đo này hoạt động, bạn cần trung thực với chính mình. Thực ra, đây chính là điều nổi bật nhất trong toàn bộ câu chuyện về việc chăm chỉ: mọi thứ đều xoay quanh việc bạn có trung thực với bản thân hay không.

Làm việc chăm chỉ không phải là cái núm vặn mà bạn chỉ cần vặn lên mức 11 là xong. Nó là một hệ thống phức tạp, liên tục thay đổi – cần được điều chỉnh chính xác ở từng thời điểm.

Bạn cần:

• Hiểu rõ hình dạng của công việc thật sự

• Nhận ra loại công việc phù hợp nhất với mình

• Nhắm đến phần lõi quan trọng của công việc

• Đánh giá chính xác, tại mọi thời điểm: bạn đang cố gắng tới mức nào và kết quả bạn đạt được ra sao

• Và cuối cùng, dành số giờ mỗi ngày hợp lý – không quá ít để lười biếng, cũng không quá nhiều để kiệt sức và làm giảm chất lượng.

Hệ thống này quá phức tạp để có thể “qua mặt” nó. Nhưng nếu bạn trung thực và sáng suốt một cách nhất quán, nó sẽ tự động tìm đến trạng thái tối ưu, và bạn sẽ làm việc hiệu quả theo cách mà rất ít người có thể đạt được.

https://www.paulgraham.com/hwh.html

1. Phải biết phân biệt giữa “giàu có”, “tiền bạc” và “địa vị”

• Giàu có: Đây không phải là số tiền bạn đang nắm giữ, mà là những tài sản có khả năng tạo ra giá trị hoặc thu nhập thụ động, như một công ty, phần mềm, hoặc khoản đầu tư. Nó là thứ làm việc cho bạn ngay cả khi bạn đang ngủ.

• Tiền bạc: Là công cụ để trao đổi giá trị, thể hiện thời gian và công sức bạn đã bỏ ra. Nhưng tiền bạc không phải là mục tiêu cuối cùng.

• Địa vị: Là thứ liên quan đến vị trí xã hội của bạn, thường dựa vào sự công nhận của người khác. Tuy nhiên, địa vị không phải là sự tự do hoặc giàu có thực sự.

2. Làm giàu bằng cách tạo ra giá trị, không phải lấy đi giá trị

• Sự giàu có không phải là một trò chơi tổng bằng không, nơi ai đó phải thua để bạn thắng. Naval nhấn mạnh rằng bạn có thể trở nên giàu bằng cách giải quyết các vấn đề của xã hội hoặc tạo ra giá trị mà mọi người cần.

3. Thị trường tự do mang đến nhiều cơ hội

• Thị trường tự do là cách con người trao đổi giá trị và hợp tác với nhau. Nó mang đến cơ hội vô hạn để bạn thử nghiệm và tạo ra những thứ có giá trị. Mỗi giao dịch là sự đồng thuận từ hai phía, cho thấy nó mang lại lợi ích cho cả hai.

4. May mắn không quyết định tất cả

• Naval chia may mắn thành 4 loại:

  1. Ngẫu nhiên: Những cơ hội không thể kiểm soát.

  2. Từ nỗ lực: Bạn càng chăm chỉ, càng có nhiều cơ hội xuất hiện.

  3. Nhận biết cơ hội: Khi bạn có kiến thức và kỹ năng, bạn nhìn thấy cơ hội mà người khác bỏ qua.

  4. Danh tiếng và kỹ năng: Khi bạn trở thành chuyên gia trong một lĩnh vực, cơ hội tự tìm đến bạn.

5. Không thể làm giàu chỉ bằng cách bán thời gian

• Naval chỉ ra rằng nếu bạn chỉ đổi thời gian lấy tiền, bạn đang giới hạn khả năng kiếm tiền của mình. Cách duy nhất để vượt qua giới hạn này là sở hữu tài sản tạo ra thu nhập mà không cần sự hiện diện của bạn.

6. Chi tiêu thấp hơn thu nhập để tự do tài chính

• Đừng để việc nâng cấp lối sống làm giảm khả năng tích lũy tài sản. Sống dưới mức thu nhập và đầu tư thông minh sẽ giúp bạn đạt tự do tài chính nhanh hơn.

7. Tạo ra những gì xã hội cần mà chưa có

• Thành công nằm ở việc nhìn thấy nhu cầu chưa được đáp ứng. Naval nhấn mạnh rằng công nghệ, đặc biệt là internet, đã mở rộng khả năng tiếp cận toàn cầu, giúp bạn mang giá trị đến nhiều người hơn.

8. Chọn làm việc với người có tầm nhìn và đạo đức

• Làm việc lâu dài với những người đáng tin cậy, có đạo đức và cùng chí hướng sẽ giúp bạn xây dựng được thành công bền vững. Những mối quan hệ này là tài sản vô giá.

9. Phát triển kỹ năng độc nhất

• Naval khuyên rằng bạn nên tìm kiếm và phát triển những kỹ năng đặc thù mà người khác khó có thể thay thế. Đây thường là sự kết hợp giữa tài năng bẩm sinh và niềm đam mê cá nhân.

10. Biết bán hàng và tạo ra sản phẩm

• Hai kỹ năng quan trọng nhất:

  • Bán hàng: Giúp bạn thuyết phục mọi người rằng sản phẩm hoặc ý tưởng của bạn có giá trị.

  • Xây dựng sản phẩm: Tạo ra những thứ mang lại giá trị lâu dài và có thể mở rộng.

11. Tạo ra thói quen đọc sách để phát triển bản thân

• Đọc sách giúp bạn mở rộng góc nhìn và học hỏi từ kinh nghiệm của người khác. Hãy bắt đầu bằng những cuốn sách bạn yêu thích, rồi hình thành sư yêu thích đọc, và cuối cùng là hình thành thói quen học hỏi suốt đời.

12. Logic và toán học là nền tảng

• Hiểu biết về toán học và tư duy logic sẽ giúp bạn đưa ra quyết định tốt hơn, đặc biệt là trong kinh doanh và đầu tư.

13. "Kinh doanh" không phải là kỹ năng duy nhất

• Naval cho rằng "kinh doanh" thực chất là tổng hợp của nhiều kỹ năng như quản lý, bán hàng, chiến lược và tiếp thị. Thay vì học chung chung, hãy tập trung vào phát triển từng kỹ năng một cách chuyên sâu.

14. Chịu trách nhiệm để có thể được dùng đòn bẩy

• Đứng ra chịu trách nhiệm cho công việc và kết quả của mình giúp bạn nhận được phần thưởng lớn hơn. Xã hội luôn ưu ái những người dám chịu trách nhiệm.

15. Sử dụng đòn bẩy một cách thông minh

• Naval nhấn mạnh 3 loại đòn bẩy:

  1. Vốn: Dùng tiền để tạo thêm tiền.

  2. Lao động: Sử dụng sức lao động của người khác để mở rộng quy mô.

  3. Sản phẩm và truyền thông: Internet và phần mềm là những công cụ mạnh mẽ để tạo ra giá trị mà không cần phụ thuộc vào lao động trực tiếp.

16. Thời gian chính là tài sản quý giá nhất

• Mục tiêu cuối cùng của sự giàu có là tự do về thời gian. Bạn nên đầu tư thời gian của mình vào những thứ mang lại giá trị lâu dài và ý nghĩa.

Bài viết gốc: https://nav.al/rich