Tài liệu ra quyết định sinh ra để giải quyết đúng chuyện đó. Gọi là ADR, RFC hay decision log cũng được, cái tên không quan trọng. Quan trọng là ghi lại bối cảnh, các phương án và lập luận ngay tại thời điểm lựa chọn. Năm nay, khi quản lý một đội lập trình viên, tôi càng thấm giá trị của loại tài liệu này hơn bao giờ hết: có nó thì tổ chức có trí nhớ thật, không có thì chỉ còn lại những lời truyền miệng.

Vì sao đáng bỏ công

#

Cái lợi dễ thấy nhất là không phải cãi nhau về cùng một chuyện hai lần. “Ơ, chiến lược quản lý phiên bản (versioning) cho API mình chốt rồi mà nhỉ?” Khi có một bản ghi rõ ràng về điều đã quyết và lý do, chuyện gì đã xong sẽ nằm yên, và cả đội dồn sức vào làm thay vì quay lại đi con đường cũ.

Cái lợi âm thầm hơn thì phải một thời gian mới lộ ra. Dự án kéo dài hàng tháng, hàng năm, người đến rồi người đi, thứ còn lại chỉ là mã nguồn. Mã nguồn cho bạn biết điều gì đã được quyết, nhưng không bao giờ cho biết vì sao. Tài liệu ra quyết định thì giữ lại được lập luận: lúc đó có những ràng buộc gì, phương án nào đã bị loại, ai là người chốt. Người mới vào có bối cảnh để hiểu, thay vì chỉ nghe kể lại. Những quyết định liên quan tới nhiều đội cũng nhận được sự đồng thuận thật, vì ai cũng thấy các yếu tố đã được cân nhắc thế nào, chứ không chỉ thấy kết luận cuối cùng. Và khi tài liệu ghi rõ ai ra quyết định, ai đóng góp ý kiến, thì phần việc tiếp theo sẽ có người thật sự chịu trách nhiệm.

Khi nào nên viết

#

Không phải quyết định nào cũng đáng một tài liệu. Tôi chỉ viết khi quyết định đó:

• Tốn kém nếu muốn quay đầu: chọn bộ công nghệ (tech stack) như framework, cơ sở dữ liệu hay nhà cung cấp điện toán đám mây; chọn mẫu kiến trúc (vi dịch vụ (microservices) hay nguyên khối (monolith), hướng sự kiện hay yêu cầu-phản hồi); chọn nhà cung cấp bên thứ ba; hay cách tiếp cận về bảo mật và tuân thủ
• Có tác động lâu dài: hợp đồng API mà các hệ thống bên ngoài phụ thuộc vào, mô hình dữ liệu trải qua nhiều dịch vụ, hoặc những thay đổi phá vỡ các mẫu thiết kế đã thành nếp
• Liên quan tới nhiều đội: bất cứ thứ gì cần nhiều đội hoặc các bên liên quan không làm kỹ thuật cùng đồng ý, các quyết định về phân bổ nguồn lực và thứ tự ưu tiên
• Là kết quả của một đợt spike: khi một đợt tìm hiểu có giới hạn thời gian vừa kết thúc, hãy ghi lại những gì tìm được và quyết định rút ra trước khi mọi người quên sạch

Với những quyết định dễ đảo ngược, những chi tiết triển khai nội bộ trong đội, hay những thứ gần như không ảnh hưởng ra ngoài phạm vi trực tiếp của bạn, thì bỏ qua thủ tục. Một tài liệu không ai cần tới thì chỉ là bài tập về nhà.

Vòng đời

#

┌─────────────┐     ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Draft     │ ──► │   Review    │ ──► │  Approved   │ ──► │ Implemented │
│  Proposed   │     │  Feedback   │     │  Accepted   │     │  Completed  │
└─────────────┘     └─────────────┘     └─────────────┘     └─────────────┘
                           │
                           ▼
                    ┌─────────────┐
                    │  Rejected/  │
                    │  Superseded │
                    └─────────────┘

Người viết phác thảo vấn đề và các giải pháp có thể chọn. Sau đó các bên liên quan đọc và góp ý. Đây là giai đoạn làm nên giá trị của cả quá trình, vì đây là lúc các giả định bị chất vấn và những điểm mù lộ ra. Người ra quyết định (thường là trưởng nhóm kỹ thuật, kiến trúc sư hoặc người phụ trách sản phẩm) chốt lần cuối, đội bắt tay triển khai, và nếu thực tế buộc phải thay đổi giữa chừng thì tài liệu được cập nhật theo. Có tài liệu chết ngay ở vòng góp ý, có tài liệu về sau bị thay thế khi hoàn cảnh đổi khác. Trường hợp nào cũng phải đánh dấu cho rõ, vì một tài liệu “accepted” đã lỗi thời chính là cái bẫy cho người tiếp theo tìm thấy nó.

Tài liệu thế nào thì đáng đọc

#

Bắt đầu từ vấn đề, đừng bắt đầu từ giải pháp bạn thích nhất. Mình đang giải quyết chuyện gì, vì sao lúc này chuyện đó quan trọng, và nếu không làm gì thì sẽ ra sao? Khi mọi người còn chưa thống nhất vấn đề là gì, thì tranh luận về giải pháp chỉ là diễn kịch.

Tiếp theo, đưa ra các phương án thật sự, ít nhất hai hoặc ba, kể cả khi bạn đã nghiêng hẳn về một cái. Mỗi phương án cần có: mô tả ngắn, ưu và nhược điểm, ước lượng công sức sơ bộ (ước theo cỡ áo S/M/L/XL là đủ), cùng các rủi ro và cách bạn sẽ giảm thiểu chúng. Có ghi lại các phương án thay thế thì người đọc sau này mới hiểu vì sao phương án được chọn lại thắng.

Nói thẳng ra những đánh đổi. “Chúng tôi chọn ra thị trường nhanh hơn, chấp nhận kiến trúc không được đẹp.” “Chúng tôi chấp nhận vận hành phức tạp hơn để đổi lấy khả năng mở rộng quy mô tốt hơn.” “Chúng tôi ưu tiên trải nghiệm của lập trình viên hơn hiệu năng thuần.” Chỉ vài câu như vậy thôi đã giúp người đọc sau này nhiều hơn cả chục trang phân tích.

Neo cuộc thảo luận vào những thứ cụ thể: đoạn mã minh hoạ giải pháp sẽ trông ra sao, sơ đồ tương tác giữa các hệ thống, liên kết tới các bản thử nghiệm khái niệm (proof of concept) từ những đợt spike. Thảo luận chung chung thì chỉ sinh ra quyết định chung chung.

Cuối cùng, đặt hạn chót: khi nào phải ra quyết định, ai phải góp ý trước ngày nào, và những việc gì đang bị kẹt lại trong lúc chờ. Quyết định mà không có hạn chót thì sẽ bị treo mãi.

Ví dụ: Architecture Decision Record (ADR)

#

Dưới đây là một ví dụ thực tế về tài liệu ra quyết định:

# ADR-001: API Authentication Strategy

**Status:** Accepted
**Date:** 2024-11-15
**Decision Maker:** Sarah Chen (Platform Architect)
**Contributors:** Backend Team, Security Team, Mobile Team

## Context

Our public API currently uses API keys for authentication. As we expand to
support third-party integrations and mobile apps, we need a more robust
authentication mechanism that supports:
- Token expiration and refresh
- Scoped permissions
- User-level authentication (not just service-level)

## Decision

We will implement OAuth 2.0 with JWT tokens for API authentication.

## Options Considered

### Option 1: OAuth 2.0 with JWT (Recommended)
**Description:** Industry-standard protocol with self-contained tokens

| Pros | Cons |
|------|------|
| Industry standard, well-documented | More complex initial implementation |
| Self-contained tokens reduce database lookups | Tokens cannot be revoked instantly |
| Broad library support | Requires refresh token management |

**Effort:** Medium (2-3 sprints)

### Option 2: Session-based Authentication
**Description:** Traditional server-side sessions with cookies

| Pros | Cons |
|------|------|
| Simple to implement | Not suitable for mobile apps |
| Easy to revoke sessions | Requires sticky sessions or shared session store |
| Familiar to most developers | Doesn't scale as well |

**Effort:** Small (1 sprint)

### Option 3: Custom Token System
**Description:** Build our own token-based authentication

| Pros | Cons |
|------|------|
| Fully customizable | Reinventing the wheel |
| No external dependencies | Security risks from custom implementation |

**Effort:** Large (4+ sprints)

## Consequences

- Mobile team can implement standard OAuth flows
- We'll need to set up a token refresh mechanism
- API documentation will need updates for OAuth flows
- Existing API key users will need a migration path (6-month deprecation)

## References

- [OAuth 2.0 RFC 6749](https://tools.ietf.org/html/rfc6749)
- Internal spike document: [Authentication Options Spike](/spikes/auth-spike-2024)
- Security team review: SEC-2024-042

Mẫu tài liệu, cứ lấy về mà dùng

#

Lấy mẫu (template) này làm điểm xuất phát, rồi cắt gọt cho vừa với đội của bạn:

Mô tả vấn đề

#

Mình đang giải quyết vấn đề gì? Vì sao nó quan trọng? Không làm gì thì phải trả giá thế nào?

Bối cảnh

#

Nêu bối cảnh, lịch sử và các chi tiết liên quan. Dẫn liên kết tới những tài liệu liên quan, các quyết định trước đó, hoặc kết quả spike.

Ràng buộc

#

Giải pháp nào cũng phải tuân theo những giới hạn hay yêu cầu gì?

• Ràng buộc về ngân sách
• Yêu cầu về tiến độ
• Ràng buộc kỹ thuật (hệ thống hiện có, kỹ năng của đội)
• Yêu cầu về tuân thủ hoặc bảo mật

Các giải pháp đã cân nhắc

#

Đề xuất

#

Nêu phương án bạn đề xuất, và tóm tắt vì sao với các ràng buộc và đánh đổi hiện có, đó là lựa chọn tốt nhất.

Quyết định

#

Chốt xong thì ghi lại quyết định cuối cùng. Nếu khác với đề xuất, giải thích lý do.

Hệ quả

#

Quyết định này kéo theo những gì? Cần làm tiếp những việc gì?

Việc cần làm

#

Tài liệu tham khảo

#

Liên kết tới các tài liệu liên quan, nguồn bên ngoài, kết quả spike, hoặc các quyết định trước đó.

Làm sao để thói quen này bám rễ

#

Lưu tài liệu ở một chỗ cố định, chẳng hạn một thư mục riêng trong kho mã nguồn (repo) hay một không gian trên wiki, vì một quyết định không ai tìm thấy thì cũng như chưa từng có. Viết thật gọn nhẹ thôi; tài liệu mà mất cả mấy ngày mới viết xong thì sẽ chẳng bao giờ có ai viết. Nhắc tới chúng trong chú thích trong mã, thông điệp commit và pull request, để phần “vì sao” luôn đi liền với phần “cái gì”. Khi một quyết định bị thay thế, đừng xoá tài liệu cũ, mà hãy đánh dấu nó là superseded rồi dẫn liên kết sang tài liệu mới; giữ lại lịch sử mới là mục đích. Và hãy mang các quyết định cũ ra xem lại trong những buổi họp nhìn lại (retrospective): cái nào vẫn còn đứng vững, cái nào bây giờ bạn sẽ quyết khác đi.

Những kiểu thất bại thì cũng dễ đoán y như vậy. Phân tích mãi mà không quyết được: hãy đặt hạn chót, quyết dựa trên thông tin đang có, và nhớ rằng phần lớn quyết định đều có thể xem xét lại. Góp ý cho có, chỉ để đóng dấu mà không bao giờ có phản biện thật, thì chỉ thêm quy trình chứ không thêm giá trị. Tài liệu viết xong rồi bỏ đó, không dẫn tới hành động nào, còn tệ hơn là không có tài liệu. Quá nhiều chi tiết cũng là một lỗi: tài liệu nên nói về vì sao và cái gì, không phải làm thế nào; phần triển khai là việc của bản đặc tả kỹ thuật. Và khi các bên liên quan bất đồng, hãy ghi lại ý kiến phản đối. Quyết định có thể vẫn giữ nguyên, nhưng chính lời phản đối đó là bối cảnh mà một năm sau sẽ có người cần tới.

Hãy bắt đầu từ quyết định quan trọng tiếp theo của bạn. Cứ viết ra, dù còn thô, rồi vừa làm vừa chỉnh lại quy trình. Mỗi cuộc họp “sao hồi đó mình chọn X?” không cần diễn ra nữa vì ai đó chỉ việc mở ADR ra đọc, là thêm một tiếng đồng hồ đội bạn lấy lại được.

Đọc thêm

#

Bài viết liên quan trên blog này:

• Tìm hiểu về spike trong phát triển phần mềm Agile - làm một đợt spike để thu thập thông tin trước khi chốt quyết định lớn
• Họp nhìn lại: sức mạnh của vòng lặp phản hồi - xem lại các quyết định cũ như một phần của quá trình cải tiến liên tục
• Lên kế hoạch cho một API - áp dụng tư duy tài liệu ra quyết định vào thiết kế API
• Dùng GitHub để quản lý dự án - để tài liệu ra quyết định nằm ngay cạnh mã nguồn

Tài liệu bên ngoài:

• Documenting Architecture Decisions - Michael Nygard - bài viết gốc đã giúp ADR trở nên phổ biến
• ADR GitHub Organization - công cụ, mẫu tài liệu và ví dụ cho Architecture Decision Record
• Design Docs at Google - cách Google viết tài liệu thiết kế
• Quy trình RFC của Rust - quy trình RFC của ngôn ngữ Rust, được ghi chép rất kỹ
• Mẫu Decision Record của Spotify - góc nhìn của Spotify về chuyện khi nào nên viết ADR

Vì sao họ bỏ họp

#

Điểm xuất phát của họ chắc bạn cũng thấy quen. Không ai chuẩn bị gì, họp thì bắt đầu muộn, và ai nói to nhất thì người đó thắng, bất kể đúng hay sai. Một tiếng sau bạn bước ra còn rối hơn lúc bước vào, và bắt đầu lục ngăn kéo xem còn viên paracetamol nào không.

Ban đầu Alan thử sửa lại cách họp: tối đa 15 phút, chương trình họp rõ ràng, họp xong bắt buộc phải có quyết định. Nhưng không duy trì được. Thảo luận cứ lan man, chẳng ai nhớ ai đã nói gì, còn người vắng mặt hay làm việc từ xa thì coi như chịu thiệt. Thế là họ chuyển hẳn sang viết.

Những lợi ích họ nêu ra, tôi thấy đều đúng. Viết buộc bạn phải chậm lại và suy nghĩ thật sự, nên cuộc thảo luận sâu hơn và lập luận chặt chẽ hơn. Mọi thứ được ghi lại rõ ràng, thay vì mỗi người nhớ một ít. Tranh luận không còn là cuộc thi xem ai ăn nói giỏi hơn. Và vì diễn đàn mở cho cả công ty, ai cũng có thể góp ý, chứ không chỉ những người tình cờ có mặt trong phòng họp.

GitHub làm diễn đàn chung của công ty

#

Diễn đàn đó chính là GitHub, một nền tảng vốn sinh ra để rà soát mã (code review), và Alan cứ thế vui vẻ “mượn” nó cho việc khác. Cách thiết lập đơn giản đến mức hơi ngại:

1. Tạo một tài khoản GitHub.
2. Tạo một kho mã (repository) riêng tư không chứa dòng mã nào (kho của họ tên là “Topics”).
3. Thêm một hệ thống nhãn (label) để phân loại các cuộc thảo luận.
4. Dùng tab Issues: issue đang mở là thảo luận đang diễn ra, issue đã đóng là quyết định đã chốt.

Họ đã vượt mốc 17,000 issue. Tức là có ngần ấy cuộc họp không bao giờ phải diễn ra, và, phần tôi thích nhất, họ có cả một lịch sử tra cứu được về lý do vì sao mỗi quyết định lại đi theo hướng đó. Nếu muốn lật lại một quyết định cũ, bạn có thể đọc trước xem lần trước những lập luận nào đã thắng.

Khi nào nên mở issue

#

Không phải quyết định nào cũng đáng mở một issue. Họ lọc bằng bốn câu hỏi: ai sẽ bị ảnh hưởng? có dễ quay lại không? gấp đến mức nào? mình có cần thêm bối cảnh trước khi quyết không?

Đại khái, quyết định nào tác động lớn và khó quay lại thì đưa lên diễn đàn, còn lại cứ để trên Slack. Họ dựa vào cách phân biệt “cửa một chiều” và “cửa hai chiều”. Quyết định một chiều là loại muốn quay lại thì quá tốn kém hoặc quá đau (ví dụ của họ là tăng giá), nên được xử lý đầy đủ bằng văn bản. Quyết định hai chiều thì dễ quay lại, tệ nhất cũng chỉ mất chút công sức, nên không cần thủ tục rườm rà.

LOCI: ai làm gì

#

Mỗi cuộc thảo luận đều phân vai theo mô hình LOCI: Lead, Owner, Consulted, Informed.

Lead chịu trách nhiệm về thành công của quyết định và đảm bảo cả đội hiểu rõ bối cảnh. Ngay từ đầu, Lead nói rõ mình muốn tham gia sâu đến đâu, sau đó tin tưởng giao cho Owner, chịu trách nhiệm về những gì đội làm ra, và chỉ lên tiếng khi thực sự không đồng ý. Mỗi thảo luận chỉ có đúng một Lead.

Owner là người chốt quyết định cuối cùng và kéo dự án đi tới. Owner giữ cho những người tham gia luôn nắm được tình hình và góp ý đúng hạn, tìm hiểu vấn đề, mở và đóng issue, rồi thông báo quyết định. Nếu vướng một bức tường không tự vượt qua được thì Owner tìm đến Lead. Mỗi quyết định chỉ có đúng một Owner.

Consulted là những người mà ý kiến của họ thực sự ảnh hưởng tới việc cân nhắc được mất. Họ phải góp ý kịp thời, dù chỉ để nói “tôi không có gì thêm”, và phải lên tiếng cảnh báo (đẩy lên Lead nếu cần) khi thấy quyết định đang sai nghiêm trọng. Alan giới hạn nhóm này khoảng sáu người, vì càng thêm người góp ý thì càng tốn thêm thời gian.

Informed thì đơn giản là những người được báo tin, thường là sau khi quyết định đã chốt. Đây là giao tiếp một chiều, không ai chờ họ phản hồi. Owner là người quyết định ai bị ảnh hưởng đủ nhiều để cần được thông báo.

Đó là cách làm cho từng quyết định. Với cả một dự án, tôi ghi những điều này ra một lần, thành một kế hoạch truyền thông dự án: ai cần được biết điều gì, bao lâu một lần, và ai là người báo cho họ.

Một issue gồm những gì

#

Issue nào cũng dùng chung một mẫu (template). Mẫu này vừa giúp suy nghĩ rõ ràng hơn, vừa ngầm dạy các bạn mới vào nghề cách bóc tách một vấn đề:

• Phạm vi (Scope): lý do có cuộc thảo luận này, kèm một dòng hay bị xem nhẹ là “issue này KHÔNG bàn về…”
• Bối cảnh và tài liệu: đường dẫn tới các thảo luận và tài liệu trước đó
• LOCI: ai là Lead, Owner, Consulted, Informed
• Hạn chót: góp ý trước khi nào, khi nào đóng issue, khi nào cần có giải pháp
• Đề xuất giải pháp: một phương án cụ thể, hoặc vài lựa chọn để cân nhắc
• Câu hỏi: hỏi thẳng từng người cụ thể để xác nhận hoặc bác bỏ từng giả định cụ thể, để issue không thành lá thư bỏ vào chai thả trôi

Quy tắc viết để mọi thứ không bị ì

#

Tranh luận bằng chữ cũng có thể lê thê y như tranh luận bằng miệng, nên họ đặt ra quy tắc. Viết ngắn gọn. Họ trích lời Boileau: “Điều gì đã nghĩ thấu thì sẽ nói ra rõ ràng.” Nếu bạn không viết được nó ra một cách đơn giản, tức là bạn vẫn chưa thực sự chắc. Mọi thứ viết ra đều phải qua phép thử “Thì sao?”: nếu bình luận của bạn dẫn tới hệ quả gì mà người đọc chưa thấy ngay, hãy nói thẳng ra.

Với Owner, việc theo sát về sau quan trọng không kém lúc mở đầu. Phải giữ cho cuộc thảo luận bám vào “câu hỏi triệu đô”, tức đúng cái điểm vướng thực sự quan trọng, thay vì để nó tan vào tiểu tiết. Thường xuyên tóm tắt lại những gì đã thống nhất và những gì còn bỏ ngỏ. Còn nhắc nhở qua Slack thì chỉ là phương án cuối cùng, dành cho những phần góp ý đã quá hạn hoặc chuyện thực sự gấp.

Owner cũng ẩn đi những bình luận không giúp cuộc thảo luận tiến lên. Ai cũng phải thạo cách định dạng trên GitHub, từ tiêu đề, chú thích cuối trang, bảng cho tới phím tắt, vì khi viết thì hình thức gần như quan trọng ngang nội dung.

Không cần đồng thuận, không có khán giả

#

Có hai quy tắc giữ cho cách làm này không biến thành kiểu quyết định theo hội đồng.

Thứ nhất, Owner ra quyết định theo kiểu mà Alan gọi là “nhà độc tài sáng suốt”. Họ tìm hiểu các ý tưởng, cân nhắc rủi ro, chất vấn đồng nghiệp, nhưng không đi tìm sự đồng thuận và cũng không bắt buộc phải làm theo mọi điều người khác nói. Alan nói thẳng họ không phải một nền dân chủ: nhân viên nào cũng là cổ đông, và lợi ích của công ty đặt trên lợi ích của một đội hay một cá nhân. Khi Owner đã khá chắc về một hướng đi, họ quyết, mọi người cùng làm thử, và khi đã thấy được tác động thì cùng nhìn lại xem quyết định đó đúng hay sai.

Thứ hai, số người tham gia được kiểm soát. Quy tắc “hai chiếc pizza” của Jeff Bezos cũng đúng với cách làm việc bất đồng bộ (async): issue càng đông người thì mỗi người càng góp ít. Quá khoảng sáu người là hiệu ứng khán giả xuất hiện, và chất lượng góp ý đi xuống. Chuyện thông báo cũng theo cùng tinh thần đó. Alan tin rằng ai cũng đã tự cấu hình thông báo GitHub cho mình (vào Settings, rồi tick “Web and Mobile” ở cả “Participating” lẫn “Watching”), nên việc gắn thẻ (tag) thẳng tên người trong phần Câu hỏi được giữ ở mức tối thiểu.

Những gì tôi học được

#

Bạn không bao giờ kể lại được trọn vẹn một cuộc họp cho người vắng mặt, nhưng một quyết định đã viết ra thì ai cũng đọc được. Alan không nói đây là hệ thống tốt nhất hay duy nhất, chỉ là hệ thống hợp với họ: ít bị ngắt quãng hơn, ít hiệu ứng khán giả hơn, và quyết định được đưa ra sau khi đã lùi lại một bước để nhìn, với đầy đủ dữ kiện trên giấy. Tôi chưa định chuyển mọi quyết định của đội mình sang GitHub issue, nhưng cái mẫu dưới đây thì sẽ vào thẳng kho mã của chúng tôi.

Mẫu đề xuất, dùng làm mẫu issue (issue template) trên GitHub

#

Hãy lưu nội dung dưới đây thành tệp .github/ISSUE_TEMPLATE/decision.md trong kho mã mà bạn dùng làm diễn đàn, và mỗi lần có người mở issue mới, GitHub sẽ gợi ý sẵn mẫu này. Các mục trong mẫu là của Alan; phần LOCI và nhãn là tôi thêm vào.

---
name: Quyết định
about: Đề xuất một quyết định và thu thập góp ý bằng văn bản
title: "[Quyết định] "
labels: decision
---

## Phạm vi
- Mục tiêu của issue này là ...
- Issue này KHÔNG bàn về ...

## Vì sao tôi mở issue này

## LOCI
- Lead:
- Owner:
- Consulted:
- Informed:

## Mốc thời gian
- Góp ý trước ngày:
- Chốt quyết định trước ngày:

## Bối cảnh và tài liệu

## Đề xuất

## Câu hỏi

Nên dùng GitHub Issues hay GitHub Projects?

#

Nếu bạn đang tính dùng GitHub để quản lý dự án theo nghĩa rộng hơn, thì nên biết hai phần này làm hai việc khác nhau. GitHub Issues là nơi diễn ra cuộc thảo luận, và khi issue đã đóng thì là nơi lưu lại quyết định. Còn một GitHub Project là một bảng công việc, ở dạng cột kiểu Kanban (board) hoặc dạng bảng tính (table), đặt chồng lên các issue của một hay nhiều kho mã, với các trường (field) do bạn tự định nghĩa như trạng thái, người phụ trách hay hạn chót. Với một diễn đàn ra quyết định như của Alan, chỉ cần nhãn và danh sách issue là đủ. Hãy thêm một Project khi bạn muốn thấy mọi quyết định đang mở trên cùng một màn hình, sắp xếp theo ngày phải chốt, và khi bạn bắt đầu theo dõi cả các đầu việc phát triển, bàn giao sản phẩm ở cùng chỗ đó. Đó cũng là lúc phần lớn các đội rốt cuộc dùng cả hai.

Vì sao người ta lại muốn những thứ họ muốn? Tôi nghĩ về câu hỏi này nhiều hơn mình tưởng. Lúc mới viết bài này, tôi đang làm cho một nền tảng mà người dùng bàn chuyện mỹ phẩm suốt cả ngày, và chuyện vì sao một sản phẩm được săn lùng còn một món gần như y hệt lại chẳng ai ngó ngàng thì gần như là toàn bộ bài toán kinh doanh. Gu thì dĩ nhiên mỗi người mỗi khác, nhưng những quy luật nằm bên dưới lại nhất quán đến bất ngờ.

Desirability, feasibility và viability

#

Cách nhìn qua ba lăng kính này bắt nguồn từ tư duy thiết kế (design thinking), và đã trở thành cách phổ biến để các đội sản phẩm kiểm tra một ý tưởng trước khi dồn sức vào nó. Điểm hữu ích là mỗi lăng kính thất bại theo một kiểu khác nhau. Một sản phẩm làm ra được, có lãi, mà không ai muốn dùng là kiểu thất bại kinh điển của startup: kỹ thuật chỉn chu, giá cả hợp lý, và bị ngó lơ. Còn một sản phẩm ai cũng muốn nhưng không làm ra được, hoặc không kiếm ra tiền, thì ít ra cũng thất bại vì một lý do mà bạn có thể thấy trước.

Desirability là lăng kính mà các đội hay bỏ qua nhất, vì nó khó đo nhất và cũng dễ bị mặc định nhất. Ai trong đội cũng đã muốn thứ mình đang làm rồi. Điều đó chẳng nói lên được gì về những người khác.

Phần còn lại của bài viết nói về những yếu tố tạo nên desirability, rồi đến cách kiểm chứng nó.

Phải dùng được, và dùng được lâu

#

Mong muốn thường bắt đầu từ công dụng rất giản dị: món đồ bếp giúp bạn tiết kiệm được mười phút thật, chiếc điện thoại cứ thế giữ cho bạn luôn kết nối. Nhưng chỉ hữu dụng thôi thì mới dừng ở mức “cũng được”. Những thứ người ta thật sự thèm muốn phải làm tốt vượt trội việc của chúng, và giữ được phong độ đó lâu dài. Chất lượng và độ bền là thứ biến một món hàng mua về thành một vật sở hữu mà người ta sẵn sàng bênh vực, như một chiếc xe cổ hay một con dao dùng lâu hơn cả đời chủ. Chẳng ai mê mẩn một thứ mà họ biết trước là sẽ hỏng.

Phải khiến bạn cảm thấy điều gì đó

#

Thẩm mỹ có sức hút mạnh hơn ta muốn thừa nhận. Đường nét của một chiếc xe thể thao hay cách bày biện một món ăn ngon đã hút mắt bạn trước cả khi lý trí kịp lên tiếng. Và những mong muốn mạnh nhất là mong muốn thuộc về cảm xúc: niềm vui, nỗi hoài niệm, cảm giác được thuộc về một nơi nào đó. Một món đồ chơi sờn cũ từ thời thơ ấu chẳng qua được bài kiểm tra công năng nào, vậy mà vẫn không tài nào vứt đi được. Cá nhân hoá cũng đánh vào đúng bản năng ấy. Một thứ được làm riêng cho bạn thì mang cảm giác là của bạn, điều mà bản đại trà không bao giờ có được.

Người khác quyết định nhiều hơn ta tưởng

#

Sự khao khát một phần là do xã hội tạo nên. Trào lưu, sự tán thưởng của những người xung quanh và chuẩn mực văn hoá lặng lẽ định hướng những gì ta muốn. Sự khan hiếm cũng vậy: phiên bản giới hạn, đá quý hiếm, món đồ chỉ có một. Độ hiếm ngầm báo rằng muốn có thứ này là bạn đã bước chân vào một câu lạc bộ nhỏ. Rồi danh tiếng lại khuếch đại tất cả. Những lời khen nức nở trong phần đánh giá và lời truyền miệng khiến người ta thấy muốn thứ đó là an toàn. Ở nền tảng mỹ phẩm đó, ngày nào tôi cũng thấy vòng lặp này diễn ra: một người review được nhiều người yêu thích, một sản phẩm chỉ sản xuất số lượng ít, và một tuần sau là cháy hàng.

Bài toán tiền nong vẫn phải hợp lý

#

Giá cao không giết chết mong muốn, nhưng cảm giác bị hớ thì có. Người ta sẵn lòng trả thêm cho đồ xa xỉ, nhưng vẫn quay lưng với bất cứ thứ gì có vẻ không đáng đồng tiền mồ hôi nước mắt. Và ngày càng nhiều người đưa cả giá trị sống của mình vào cùng phép tính đó: một món đồ có được làm ra theo cách bền vững, có đạo đức hay không giờ có thể đẩy nó lên hoặc kéo nó xuống trong danh sách mong muốn của rất nhiều người. Kể cả tôi.

Làm sao kiểm chứng một thứ có thực sự được khao khát

#

Cái bẫy của desirability là hỏi thẳng người ta thì không ăn thua. Hỏi “Bạn có dùng thứ này không?” thì gần như ai cũng lịch sự trả lời có, vì nói có thì chẳng tốn gì. Những phép thử hiệu quả đều yêu cầu người ta bỏ ra một thứ gì đó, như thời gian, tiền bạc, địa chỉ email hay một thói quen, rồi quan sát xem họ có chịu bỏ ra không.

Hỏi về quá khứ, đừng hỏi về tương lai. Câu “Kể tôi nghe lần gần nhất bạn gặp vấn đề này, và lúc đó bạn đã xử lý ra sao” sẽ cho bạn thấy hành vi thật. Nếu không ai nhớ nổi lần gần nhất là khi nào, thì vấn đề đó chưa đủ nhức nhối để người ta muốn có giải pháp.

Dựng một “cánh cửa giả” (fake door). Đó là một trang đích (landing page), hoặc một nút bấm trong sản phẩm hiện có, dành cho một thứ chưa hề tồn tại, rồi bạn đếm xem bao nhiêu người bấm vào hoặc để lại email. Nghe thì hơi láu cá, nhưng đây là tín hiệu trung thực rẻ nhất mà bạn có được. Chỉ cần nói rõ ở phía bên kia cánh cửa rằng thứ này sắp ra mắt.

Đề nghị một cam kết. Danh sách chờ thì là tín hiệu yếu, còn đặt hàng trước hay đặt cọc thì mạnh. Người ta sẵn sàng đăng ký đủ thứ, nhưng chỉ trả tiền cho thứ họ thực sự muốn.

Với một thứ người ta đã dùng rồi, hãy hỏi họ sẽ cảm thấy thế nào nếu không được dùng nó nữa. Trong giới làm sản phẩm có một quy tắc kinh nghiệm khá phổ biến: nếu khoảng 40% người dùng trả lời là sẽ “rất thất vọng”, thì bạn đang có một thứ người ta thực sự muốn. Thước đo này khá thô, nhưng vẫn tốt hơn nhiều so với việc hỏi người ta có thích nó không.

Và hãy nhìn vào những gì người ta làm, thay vì những gì người ta nói. Tính năng nào được dùng đến lần thứ hai, tính năng nào người ta tự quay lại mà không cần nhắc, và họ phàn nàn điều gì khi nó bị hỏng. Những lời phàn nàn ở đây bị đánh giá thấp. Chẳng ai phàn nàn vì mất đi một thứ mà họ vốn không muốn.

Ghép tất cả lại với nhau

#

Không đặc điểm nào tự mình gánh nổi một sản phẩm. Nhưng hội tụ được vài cái, như thật sự hữu ích, làm chắc chắn, đẹp mắt, hơi hiếm một chút, được những người bạn tin tưởng đứng ra bảo chứng, là bạn có những món người ta sẵn sàng xếp hàng để mua. Phần còn lại phần lớn là nhờ tiếp thị (marketing).

Tóm lại

#

Desirability là mức độ người ta muốn có một thứ gì đó, vượt ra ngoài chuyện họ có cần nó hay không. Trong thiết kế sản phẩm, đó là lăng kính “người ta có muốn thứ này không?”, đứng cạnh tính khả thi và tính bền vững về kinh doanh. Nó đến từ sự hữu ích bền lâu, sức hút về cảm xúc hay thẩm mỹ, sự bảo chứng từ người khác cùng sự khan hiếm, và một mức giá khiến người ta thấy xứng đáng. Bạn không thể tìm ra nó bằng cách hỏi người ta có dùng thứ đó không. Hãy kiểm chứng bằng cách đề nghị họ bỏ ra một thứ có thật, rồi quan sát xem họ làm gì.