AI Use-case #1: Kiểm tra cách tính năng hoạt động và các dependencies của nó

Use-case thì dùng AI, nhưng email là hàng thủ công mỹ nghệ viết tay 100% nhé ;)

Hello bạn, đây là bài viết đầu tiên trong series chia sẻ cách mình dùng AI để cải thiện hiệu suất khi làm Product Manager. Hiện tại mình đã có khoảng ~10 ý tưởng cho các lá thư tiếp theo. Chúng ta sẽ bắt đầu với một ý tưởng đơn giản trước nhé.

Công cụ sử dụng: Claude Code (thông qua Terminal)

Thời gian tiết kiệm được: ~30-60 phút mỗi tuần

Công sức tiết kiệm được: Mình đã giảm rất nhiều thời gian chờ đợi các bạn engineers kiểm tra code rồi báo lại với mình, đồng thời cắt bớt thời gian chat chit qua lại nhiều mới ra được kết quả mình muốn tìm, trừ những thứ quá quá quá phức tạp (ví dụ: một tính năng rải rác ở nhiều codebase).

Use-case này cho ai: Các bạn Product Manager/ Designers đang làm việc với những hệ thống/ sản phẩm lớn và phức tạp (cả về Front-end và Back-end). Các bạn vào công ty khi rất nhiều các tính năng đã được shipped và không phải tính năng nào cũng được ghi chép lại cẩn thận.

Use-case:

Khi viết PRD cho một tính năng, mình thường phải kiểm tra xem tính năng đó (nếu cũ thì) đang hoạt động như thế nào, có liên quan hay phụ thuộc gì vào các tính năng khác hay không, (nếu mới thì) sẽ ảnh hưởng tới các tính năng xung quanh thế nào. Không phải mọi tính năng đều có thể kiểm tra dễ dàng thông qua UI, nhiều khi có các logic ẩn ở phía backend mà không có ai ghi chép lại hoặc hiện rõ cho khách hàng biết. Ví dụ: Ở trên UI có một permission có tên là User Administration - khá dễ hiểu - nó cho phép admin quản lý user. Tuy nhiên, “quản lý” nghĩa là gì? Là reset mật khẩu, đổi email, username, role… và gì khác nữa? Nếu chỉ thuần kiểm tra trên UI thì mình đã không thể biết được rằng User Administration còn cho phép tạo mới user hoặc là role nữa.

Trước khi dùng AI:

Khi có nhu cầu này, mình (trước đây) sẽ phải hỏi các bạn engineer để kiểm tra code rồi báo lại cho mình. Điều này có 2 bất cập:

1. Engineer sẽ phải bỏ qua công việc hiện tại (thường là sẽ có ưu tiên cao hơn) để làm giúp mình - nếu xét về prioritization thì điều này không hiệu quả.

2. Engineer và cả mình sẽ phải dành tương đối nhiều thời gian để nói chuyện qua lại. Nhiều khi engineer phát hiện ra gì đó, mình thấy sai sai, lại kiểm tra lại, rồi báo để engineer kiểm tra lại. Điều này sẽ lặp lại cho tới khi tìm ra được thứ mình cần, việc mà không phải lúc nào cũng suôn sẻ.

Như vậy chỉ để mình có thể viết thêm được mấy dòng trong PRD mà mất thời gian công sức của cả 2 người. Bản thân mình thì cảm thấy khá bức bối khi mà phải chờ đợi lâu.

Sau khi dùng AI (bây giờ):

Thay vì hỏi engineer, mình sẽ:

• Clone repository (từ giờ gọi tắt là repo) của tính năng/ sản phẩm từ Github về máy (nói một cách đơn giản là tải hết code của tính năng/ sản phẩm về máy)

• Đưa hết các PRD/ public documentations/ guidelines của công ty lên trên một repo khác trên Github, và cũng clone repo về máy luôn

• Sau khi Claude đã có hết các dữ liệu ở trên, mình sẽ hỏi những câu hỏi liên quan tới tính năng mình quan tâm. Ví dụ như “What actions would the User Administration allow a user to do”, hay “What permissions or features depend/ are depended on by, this feature”

Khi dùng AI, mình sẽ có thể có câu trả lời trong vài giây thay vì cả chục phút như trước kia. Nếu AI chưa rõ cái gì, mình có thể trả lời lại ngay. Cái hay của AI là ở chỗ nó sẽ đọc mọi ngóc ngách mà có thể người bình thường có thể bỏ qua/ sót, và do đó từ khi mình dùng AI thì mình hiểu được kĩ và sâu về sản phẩm hơn rất nhiều so với việc hỏi người chay trước đây.

Nhiều khi mình không phải là người có câu hỏi, mà là người được kì vọng trả lời câu hỏi. Những lúc này sử dụng AI rất có ích:

Dĩ nhiên sau khi hỏi thì một bước không thể thiếu là double-check. Dù sao như vậy cũng nhanh hơn rất nhiều so với việc (engineer) phải tự ngồi mò mẫm code như ngày xưa. Mà cái này lại càng hữu dụng với mấy người mới vào công ty như mình - nhiều khi cũng ngại hỏi, hoặc không biết hỏi ai. Giờ thì biết hỏi AI rồi ;)

Tip

1. Câu hỏi rõ ràng thì sẽ nhanh nhận được câu trả lời hơn: Do codebase và lượng docs rất lớn nên nếu mình chỉ đơn giản nhắc tới một thứ rất cụ thể thì Claude sẽ mất rất lâu để tìm ra. Do vậy, mình thường sẽ thêm một số ngữ cảnh như: “In the Role & Permission page, each Role has many permissions and User Administration is one of them, what actions would…”

2. Bạn có thể sử dụng cách này để viết các public/internal docs để giới thiệu về một tính năng nào đó. Nhiều khi các tính năng được release nhưng các behavior của nó lại không được ghi chép cụ thể (đặc biệt trong trường hợp các tính năng đó phục vụ một số use-case đặc thù và một số khách hàng ít ỏi). Good tip ở đây là bạn có thể ném vào AI một số những yêu cầu về việc viết lách (e.g. “chỉ sử dụng từ ngữ dễ hiểu, ít học thuật”) hoặc các tiêu chuẩn viết lách (writing standards)/ quy chuẩn thương hiệu (brand guideline) mà công ty bạn đã tạo ra.

3. Hỏi theo kiểu khác + Follow-up thật nhiều: Đôi khi AI đưa ra những câu trả lời hơi chung chung, làm cho mình cảm giác (nếu nó là người) nó đang không chắc chắn về câu trả lời của nó lắm. Thế nên mình thường hay hỏi lại để bắt nó đưa ra dẫn chứng, và đặt ra một số câu hỏi rộng hơn câu hỏi gốc để hiểu thật chắc vấn đề. Ví dụ ở trên anh engineer đó hỏi mình mấy API (API là gì?) đó được gọi từ đâu, sau khi nhờ AI kiểm tra thì mình còn hỏi thêm là tại sao công ty lại có API riêng rành cho một số loại khách hàng, lúc đó mới phát hiện ra một vài kiến thức liên quan tới mảng của mình. Whoop!

4. Bắt AI giải thích cách làm: Có một lần mình hỏi AI và nó đưa ra một câu trả lời cực kì chắc chắn. Tuy nhiên khi đối chiếu với một số kiến thức sẵn có thì mình biết rằng AI đã trả lời sai - lý do là vì cách nó tìm ra câu trả lời đang dựa trên một số giả định mà nó không nói cho mình. Vụ này rất nhiều anh em trong công ty cũng gặp. Cái này sẽ rất nguy hiểm vì mình không hiểu codebase nên nhiều khi sẽ thiếu kiến thức để kiểm tra tính đúng sai. Do vậy, thêm một bước “Explain to me how you found out xyz” là một cách tốt để tăng khả năng chúng ta bắt được lỗi.

Bạn có đang dùng AI để kiểm tra cách một tính năng đang hoạt động thế nào không? Theo bạn mình có thể cải thiện gì nữa không? Để lại một comment hoặc reply lá thư này cho mình biết nhé. Hẹn bạn ở lá thư lần sau!