# Xây công cụ cho chính mình

Từ một bất tiện cụ thể đến một công cụ đáng giữ lại: mô tả tình huống sử dụng, thử trong công việc thật và tính cả quyền rời đi lẫn công sức chăm sóc.

URL: https://laban.cc/posts/xay-cong-cu-cho-chinh-minh
Biên soạn: La Bàn Editorial (AI-assisted)
Nguồn: A Return to Code — https://nav.al/code

Một ý tưởng ứng dụng thường bắt đầu từ một lần thấy bất tiện: tìm mãi không ra ghi chú cũ, quên lý do đã chọn một phương án, hay phải nhập lại cùng một thông tin. Khi việc tạo phần mềm dễ tiếp cận hơn, khoảng cách từ sự bất tiện đến một giao diện chạy được có thể rất ngắn.

Khoảng cách từ giao diện ấy đến một thói quen sử dụng bền vững lại là câu chuyện khác. Bạn có thể thích cảm giác xây dựng hơn chính công cụ vừa xây. Nhận ra sự khác nhau đó sẽ giúp dự án cá nhân giữ được giá trị sau buổi hứng khởi đầu tiên.

## Nhu cầu riêng xứng đáng được mô tả cho rõ

Trong “A Return to Code” trên nav.al, ngày 28/04/2026, Naval kể về việc trở lại lập trình với coding agent và tạo ứng dụng cho nhu cầu của mình. Ông phân biệt công cụ tùy biến cá nhân với những sản phẩm phổ thông được chăm chút cho nhiều người dùng. Từ điểm gợi mở ấy, La Bàn bàn về cách xác định, thử và duy trì một công cụ nhỏ; các tình huống dưới đây là minh họa độc lập.

Lợi thế khi xây cho mình là được tiếp xúc trực tiếp với vấn đề. Bạn biết thời điểm nó xuất hiện, cách mình đang xoay xở và mức khó chịu đủ để muốn thay đổi. Nhưng sự gần gũi cũng tạo ra một điểm mù: những điều bạn làm theo thói quen thường không được nói ra khi mô tả sản phẩm.

Một yêu cầu như “làm ứng dụng ghi chú tốt hơn” chưa giúp chọn thiết kế. Một mô tả như “trước buổi trao đổi với khách, tôi cần tìm lại quyết định gần nhất và lý do đã đưa ra” cho thấy cả thời điểm, thông tin cần có và kết quả mong muốn.

## Đi theo một tình huống, đừng bắt đầu từ danh sách tính năng

Hãy hình dung một người làm dự án tự do thường đồng thời trao đổi với vài khách hàng. Họ có ghi chú trong nhiều cuộc trò chuyện, nhưng mỗi lần quay lại một dự án lại phải nhớ vì sao trước đó đã bỏ một phương án. Đây là tình huống giả định để làm rõ cách thiết kế.

Một công cụ dành cho tình huống ấy có thể bắt đầu bằng ba trường: quyết định, lý do và lúc nào cần xem lại. Luồng sử dụng là mở dự án, đọc quyết định gần nhất rồi ghi một thay đổi nếu có. Danh bạ, lịch họp, quản lý hợp đồng và mạng xã hội chưa giúp giải quyết chỗ vướng đang được mô tả.

Phạm vi nhỏ không chỉ giúp xây nhanh. Nó làm cho thất bại dễ đọc hơn. Nếu người dùng vẫn không mở công cụ trước cuộc họp, ta có thể hỏi liệu thông tin không đủ hữu ích, thao tác nhập quá nặng hay công cụ xuất hiện sai thời điểm. Với một sản phẩm chứa quá nhiều chức năng, tín hiệu ấy dễ bị che khuất.

## Biến lời nhắc thành một cuộc trao đổi về thiết kế

Khi nhờ agent triển khai, hãy đưa tình huống và ví dụ trước hình thức giao diện. Một bản mô tả có thể nói: người dùng cần xem quyết định mới nhất của một dự án trong một màn hình; mỗi quyết định lưu lý do, ngày ghi và dấu hiệu khiến nó cần được xem lại; dữ liệu mẫu gồm một quyết định đã đổi và một quyết định vẫn còn hiệu lực.

Tiếp đó, yêu cầu agent chỉ ra những câu hỏi chưa được trả lời. Có cần lịch sử chỉnh sửa? Một quyết định có thể gắn với nhiều dự án không? Có thực sự cần đồng bộ giữa thiết bị hay giai đoạn đầu chỉ sử dụng ở một nơi? Các câu trả lời sẽ ảnh hưởng đến mức phức tạp cần gánh.

Đây là lúc nên nói rõ điều sẽ chưa làm. Một nguyên mẫu cá nhân có thể chưa cần tài khoản, phân quyền nhiều người hoặc bảng điều khiển tổng hợp. Việc giữ phạm vi là một quyết định sản phẩm, không phải một thiếu sót cần được sửa bằng cách thêm tính năng ngay.

## Thử trong đúng lúc công cụ đáng lẽ phải hữu ích

Dùng thử ngay sau khi xây thường cho cảm giác tốt, vì mọi chi tiết còn ở trong trí nhớ. Bài kiểm tra có ý nghĩa hơn xuất hiện vài ngày sau, khi bạn đang bận và vấn đề thật quay lại. Bạn có tự nhớ đến công cụ không? Mở nó có nhanh hơn cách đang làm không? Đọc lại thông tin có giúp quyết định rõ hơn không?

Trong ví dụ trên, hãy dùng công cụ trước vài cuộc trao đổi thật. Ghi lại những lần bạn bỏ qua nó, thay vì chỉ đếm những bản ghi đã tạo. Nếu người dùng vẫn tìm trong lịch sử tin nhắn, có thể công cụ đang thiếu một chi tiết quan trọng hoặc phải đi qua quá nhiều bước để mở.

Mỗi vòng chỉ cần sửa điểm cản trở lớn nhất. Thêm biểu đồ không giải quyết được một ô nhập liệu khó dùng. Thay màu sắc không bù được việc dữ liệu bị mất khi đóng cửa sổ. Quan sát một lần vấp cụ thể thường cho hướng sửa rõ hơn một buổi tự nghĩ thêm tính năng.

## Quyền rời đi cũng là một phần của thiết kế

Một công cụ cá nhân sẽ giữ những dữ liệu ngày càng có giá trị với người sử dụng. Vì thế, khả năng lấy dữ liệu ra cần được nghĩ đến sớm. Nếu tuần sau muốn đổi công cụ, bạn có thể mang theo các quyết định và lý do của mình dưới một định dạng đọc được không?

Bản thử cũng nên giúp phân biệt dữ liệu đã lưu với dữ liệu chỉ đang hiển thị. Có thể kiểm tra bằng thông tin mẫu: tạo một bản ghi, đóng ứng dụng, mở lại, sửa và xuất ra tệp. Một giao diện thuyết phục chưa nói được điều gì về độ bền của dữ liệu bên dưới.

Với thông tin của khách hàng hoặc người khác, hãy chọn cách lưu và công cụ phù hợp với thỏa thuận sử dụng dữ liệu của mình. Một bản thử bằng dữ liệu giả thường đã đủ để kiểm tra luồng chính, trước khi quyết định có nên đưa thông tin thật vào hay không.

## Tự xây, dùng sản phẩm có sẵn hay tiếp tục với ghi chú?

Tự xây hợp lý khi nhu cầu có một nét riêng quan trọng mà cách hiện tại phục vụ kém. Một sản phẩm có sẵn có thể phù hợp hơn nếu nó đã làm tốt việc cốt lõi và bạn cần sự ổn định, đồng bộ hoặc khả năng cộng tác mà mình chưa muốn duy trì.

Còn nếu vấn đề chỉ xuất hiện hiếm và một biểu mẫu ghi chú đã giải quyết được, việc dùng biểu mẫu ấy có thể là lựa chọn nhẹ nhất. Số dòng mã đã tạo ra không làm cho ứng dụng trở nên cần thiết hơn.

Cũng nên tính phần chăm sóc về sau. Khi có lỗi, bạn có đủ hiểu để mô tả lại và kiểm tra cách sửa không? Khi một thư viện thay đổi, ai sẽ dành thời gian cập nhật? Nếu bỏ dự án một tháng, bạn có thể quay lại từ một hướng dẫn ngắn không? Những câu hỏi ấy thuộc về sản phẩm ngay từ đầu.

## Một tiêu chuẩn nhỏ để giữ hoặc dừng

Trước khi bắt đầu, viết một điều sẽ khiến bạn giữ công cụ sau một tuần. Chẳng hạn: trước mỗi cuộc họp, tìm được quyết định cần nhớ mà không phải lục lại nhiều nơi. Đây là một hành vi có thể quan sát, gần với vấn đề ban đầu.

Cuối tuần, xem lại những lần dùng, những lần bỏ qua và công sức cần để giữ dữ liệu cập nhật. Nếu công cụ chưa giúp ích, bạn có thể thu nhỏ, đổi cách tiếp cận hoặc dừng. Dừng một nguyên mẫu không cần thiết giúp giữ thời gian cho một vấn đề đáng làm hơn.

Công cụ tốt cho chính mình thường không bắt đầu bằng tham vọng phục vụ mọi người. Nó bắt đầu từ việc hiểu thật rõ một khoảnh khắc trong ngày, rồi làm cho khoảnh khắc ấy bớt vướng víu.

---
Phân tích độc lập của La Bàn, biên soạn cùng AI. Các tình huống và khung thực hành do La Bàn phát triển; bài không phải bản dịch toàn văn hay phát ngôn chính thức của tác giả nguồn.