📌Đọc tại đây:
Để có trải nghiệm đọc tốt hơn một chútSarthology.com
Tôi không ngụ ý rằng Quản lý Sản phẩm là tồi hay họ không giỏi công việc của mình.
Mặc dù tôi đã thấy những người bạn kỹ sư của mình lúc nào cũng ghét Quản lý Sản phẩm và Người kiểm thử 😄.
Là một Quản lý Sản phẩm có nền tảng kỹ thuật, tôi đã thấy cả hai mặt của vấn đề.
May mắn thay, khi tôi là trưởng nhóm kỹ thuật, PM của tôi cũng có nền tảng kỹ thuật.
Thay vì căng thẳng,đã có sự tôn trọng lẫn nhau và thậm chí là cảm hứng.
Nếu bạn hỏi tôi, tôi có một quan điểm về nó.
Vì vậy, nếu một Nhà phát triển là mộtPokémon, họ có thể tiến hóa thành Quản lý và sau đó là Trưởng nhóm Kỹ thuật và sau đó là Phó chủ tịch Kỹ thuật—nếu họ cũng thích làm người sáng lập.
Nhưng điều này không có nghĩa là tất cả chúng ta sẽ, hoặc thậm chí nên làm vậy.
Rồi đây, AI và sự trớ trêu xuất hiện…
Nếu bạn nghĩ về nó, lập trình theo cảm hứng không chỉ thay đổi bối cảnh công nghệ mà còn lật ngược tình thế, phải không?
Đột nhiên bạn có thể thấy mình trong vai trò của một người kiểm thử 😅, và viết một gợi ý tốt cảm giác y hệt như viết một câu chuyện người dùng chi tiết.
Tính năng hoạt động = Đặc tả Được xác định rõ ràng x Kiểm thử Nghiêm ngặt
Bây giờ bạn đang đeo ba chiếc mũ:Quản lý Sản phẩm + Người kiểm thử + Nhà phát triển.🤯
Nội dung chính
🌓 Bối cảnh Công nghệ Đang Thay đổi
Tôi không muốn là Baba Vanga hay gì đó, nhưng cuộc di cư việc làm công nghệ đang ở phía chân trời rồi.
Khi những người được tôi cố vấn trước đây hỏi tôi lời khuyên, tôi nói với họ rằng họ là những nhà phát triển tuyệt vời, nhưng đã đến lúc Pokémon phải tiến hóa.
Tôi bảo họ hãy phát triển cảm nhận sản phẩm.
Nhưng câu hỏi là—liệu tất cả mọi người có thể thích nghi với nó không?
Nếu tôi phảiphân loại các nhà phát triển, tôi sẽ xếp họ vào ba loại rộng:
1. Có Tư duy Sản phẩm 🧙🏻:
Đặc điểm nổi bật:Bạn tự nhiên suy nghĩ như một người dùng.
Bạn viết câu chuyện trước khi viết mã.
Bạn nhận thấy sự cản trở, đề xuất luồng tốt hơn và thường dự đoán lỗi bằng các bài kiểm thử chu đáo.
Ví dụ:Bạn có thể đã thấy những nhà phát triển OSS gốc—vâng, tôi đang nói về họ.
Họ liên hệ đến một vấn đề ở cấp độ người dùng.
Hầu hết các nhà phát triển OSS (theo kinh nghiệm của tôi) đang cố gắng giải quyết một vấn đề cho chính họ.
Vì vậy, việc lập kế hoạch trở nên dễ dàng;
xác định câu chuyện người dùng là dễ dàng.
Một số người trong số họ có cảm nhận thiết kế tốt, và họ cuối cùng tạo ra các sản phẩm được yêu thích và lan truyền.
Không chỉ giải quyết vấn đề, mà còn giải quyết vấn đề với phong cách.
Họ giống như những chủ nhà hàng Michelin, nướng một trải nghiệm tốt trên đường đi.
🤔 Nó trông như thế nào tại nơi làm việc:Bạn đẩy một câu chuyện từ“hoạt động”đến“cảm thấy đúng.”Người kiểm thử hiếm khi tìm thấy bất ngờ.
✨ Tại sao điều này phát triển mạnh bây giờ:AI tăng cường sức mạnh cho những người cung cấp cho nócác đặc tả rõ ràng như pha lê.
🚀 Quỹ đạo:PM/Trưởng nhóm Kỹ thuật đến một cách tự nhiên—bạn đã làm công việc đó mà không có chức danh.
2. Người Giải quyết Vấn đề 🥷🏻:
Đặc điểm nổi bật:Bạn yêu thích các vấn đề khó, mẫu hình và giải pháp sạch sẽ.
LeetCode là sân chơi của bạn.
Độ hoàn thiện Giao diện người dùng không phải lúc nào cũng là bản năng đầu tiên của bạn, nhưng bạn có thể linh hoạt khi cần.
🤔 Nó trông như thế nào tại nơi làm việc:Bạn nghiền nát các nhiệm vụ hóc búa, đôi khiđầu tư không đủ vào UX.
💊 Viên thuốc đắng:Nếu bạn không phát triển thànhđặc tả rõ ràng + lăng kính người dùng, bạn sẽ vật lộn với AI ngày càng giỏi trong việc giải quyết vấn đề thuần túy.
🚀 Quỹ đạo:Với một chút đồng cảm người dùng hơn và kiểm thử đầu cuối, bạn sẽ trôi dạt vào Loại 1.
3. Người Giữ Việc 👻:
Đặc điểm nổi bật:Bạn giao hàng số lượng nhưng bỏ lỡ tiêu chí chấp nhận, chuyển lỗi cho QA, và coi các câu chuyện như vé thay vì kết quả người dùng.
Đáng buồn thay, những nhà phát triển này có số lượng nhiều hơn, phát triển mạnh trong môi trường doanh nghiệp lớn.
Họ không quan tâm đọc câu chuyện người dùng và thường bỏ lỡ các tiêu chí chấp nhận.
Về cơ bản, đây là những nhà phát triển cấp dưới với chức danh công việc hào nhoáng, mà họ có được chỉ vì thời gian của họ trong ngành.
Họ không có động lực để tiến hóa và đáng buồn là đang vắt sữa tiền lớn vì họ đã như vậy trong hơn 5 năm.
Trời mới biết tại sao các công ty đánh giá số lượng hơn chất lượng.
Họ có giá trị vì có một hệ sinh thái hỗ trợ họ:lập trình viên tồi → nhiều người kiểm thử hơn → thời gian sản phẩm kéo dài → nhiều tiền hơn để vắt từ khách hàng.
Vì vậy, mọi người đều thắng ngoại trừ khách hàng của những công ty này (xin lỗi vì tôi đã phàn nàn ở đó 😅 và tôi cũng thừa nhận đôi khi lãnh đạo tồi cũng dẫn đến thực hành này).
🤔 Nó trông như thế nào tại nơi làm việc:Dự án đình trệ, chu kỳ kéo dài và nợ chất lượng tăng.
🤷🏻 Kiểm tra thực tế:Mô hình này sẽ không tồn tại lâu.
🚀 Quỹ đạo:Hãy bắt đầu với đặc tả, tiêu chí chấp nhận và danh sách kiểm tra thử nghiệm của riêng bạn—hoặc thị trường sẽ thực hiện việc sàng lọc cho bạn.
Nếu bạn không bao giờ ngừng học hỏi, bạn đã nghiêng tỷ lệ có lợi về phía mình rồi.
Tiến hóa là một phần của sự tồn tại con người, nhưng ngày nay nó đã trở thành hơn thế—nó là về sự sinh tồn.
Vậy bắt đầu hành trình của bạn từ đâu….
Tất cả điều này giả định bạn có thể đọc và viết code với tính rõ ràng về ngữ nghĩa.
Những nguyên tắc cơ bản vẫn không thể thương lượng;
tư duy sản phẩm là một lớp bổ sung, không phải sự thay thế.
📜 Công Cụ AI Hướng Đặc Tả (Tại Sao ‘Vibe Coding’ Hiệu Quả)
Vibe coding:
sử dụng AI với ngữ cảnh phong phú và đặc tả rõ ràng để các mô hình tạo ra đầu ra có thể dự đoán và kiểm thử được.
Hiệu suất của AI tăng hay giảm phụ thuộc vào cách bạn xác định vấn đề rõ ràng đến đâu.
Và điều đó không chỉ dành cho viết code—hãy xem bài viết của tôi vềkỹ thuật ngữ cảnh (để tối ưu prompt với AI).
Nhưng tư duy này có thể không dễ dàng với tất cả mọi người, và đó là lý do tại sao các công cụ vibe coding tự chúng đang chuyển hướng sự chú ý của bạn đến đó.
Một vài công cụ đáng chú ý bao gồm:
- Kiro(bởi Amazon):
tập trung vào phát triển ưu tiên đặc tả, thúc đẩy bạn suy nghĩ rõ ràng về yêu cầu trước khi viết code.
AI có thể phác thảo đặc tả cho bạn, nhưng bạn vẫn cần xem xét chúng để tránh ảo tưởng. - Agents.md:giúp cấu trúc prompt và nhiệm vụ một cách có hệ thống.
- Spec Kit(bởi GitHub):
một bộ công cụ mã nguồn mở cho phát triển hướng đặc tả.
Đọc thêm về nótại đây.
Hãy chọn một công cụ và chạy thử nghiệm trong 1 sprint.
Bắt đầu với một mẫu đặc tả 5 phút, sau đó so sánh số lượng lỗi và chu kỳ đánh giá trước/sau.
✨Mẹo
Tư Duy Sản Phẩm →chính thức hóa với Spec Kit;
Người Giải Quyết Vấn Đề →kể lại sự chấp nhận của người dùng với Agents.md;
Người Giữ Việc →thực thi tiêu chí chấp nhận với Kiro trước khi viết code.
🧠 Phát Triển Tư Duy Sản Phẩm
Một số người có thể nói tư duy sản phẩm là một tính năng có sẵn ở hầu hết mọi người, nhưng tôi không đồng ý.
Với sự chăm chỉ, mọi thứ đều có thể học và thành thạo.
Bước đầu tiên rất đơn giản:QUAN SÁT.Mỗi ngày chúng ta tương tác với vô số ứng dụng và sản phẩm với tư cách người dùng.
Việc học của bạn có thể bắt đầu từ đó.
Những ứng dụng này chứa đầy những viên ngọc ẩn.
Hãy hỏi:
Tại sao bạn yêu thích một sản phẩm hơn các đối thủ cạnh tranh?
Tính năng nào bạn yêu thích và tại sao?
Những lựa chọn thiết kế nào là tài tình?
Đó là nơi bạn phát triển cảm nhận về điều gì có thể hiệu quả và điều gì không.
Quan sát → Định hình → Kiểm thử → Triển khai → Đo lường
1️⃣Quan sát:Chụp ảnh màn hình hai khoảnh khắc bạn yêu thích hoặc ghét trong các ứng dụng bạn đã dùng hôm nay và viết một câu về lý dotại sao.
2️⃣Định hình:Biến mỗi khoảnh khắc thành mộttuyên bố vấn đềvà mộtkết quả mong muốn.
3️⃣Kiểm thử:Phác thảotiêu chí chấp nhận(Given/When/Then) để “hoàn thành” là rõ ràng.
4️⃣Triển khai:Xây dựng thay đổinhỏ nhất nhưng mạch lạcđể chứng minh ý tưởng.
5️⃣Đo lường:Chọn một chỉ sốHEART(Happiness, Engagement, Adoption, Retention, Task success) và theo dõi nó trong hai tuần.
Cuối cùng, hãy xây dựng một dự án mã nguồn mở của riêng bạn—một vấn đề cá nhân với bạn và là điểm then chốt mà người khác cũng muốn có một công cụ hoặc ứng dụng.
Ra mắt nó trên Product Hunt và yêu cầu người dùng phản hồi.
Chẳng mấy chốc, bạn sẽ phát triển được tư duy sản phẩm—và biết đâu, bạn có thể xây dựng một doanh nghiệp xung quanh nó.
Nguyên tắc đáng học hỏi:Bắt đầu từ vấn đề.
Nghĩ lớn, bắt đầu nhỏ, học hỏi nhanh.
Triển khai thường xuyên.
📌 Sổ Tay Lập Trình Viên Tư Duy Sản Phẩm (6 Bước) 📚
Đây là một sổ tay nhỏ để phát triển với tư duy sản phẩm 👉
- Câu chuyện người dùng:Người dùng là ai?
Nỗi đau là gì?
Công việc cần hoàn thành? - Tiêu chí chấp nhận:Given/When/Then, bao gồm các trường hợp biên.
- Kiểm thử trước:Đỏ → Xanh → Tái cấu trúc.
(Ngay cả một kiểm thử nhỏ!) - Tạo:Yêu cầu AI triển khai nhỏ nhất để thỏa mãn các kiểm thử.
- Đánh giá:Đọc sự khác biệt như một PM—liệu điều này có khớp vớiý địnhkhông?
- Triển khai & đo lường:Thêm phân tích hoặc mộtđại diện có thể đo lường cho giá trị.
📌 Hai Danh Sách Kiểm Tra Bỏ Túi 📋
Danh sách kiểm tra cần ghi nhớ, nếu bạn muốn tạo đặc tả hoàn hảo cho AI:
👉 Danh sách kiểm tra đặc tả
- Người dùng → Vấn đề → Kết quả trong một câu.
- 3–5tiêu chí chấp nhậnvới các trường hợp biên.
- Mục tiêu không hướng đến (những gì điều này sẽ không làm).
- Khả năng quan sát (làm thế nào chúng ta biết nó hoạt động).
- Kế hoạch hoàn tác (nếu nó thất bại thì sao?).
Danh sách kiểm tra nếu bạn đang làm việc trên một tính năng nhỏ và thích vibe coding:
👉 Danh sách kiểm tra prompt
- Xác địnhvai tròvàràng buộc(ngôn ngữ, phong cách, phụ thuộc).
- Cung cấpví dụ(kiểm thử, đầu vào/đầu ra).
- Yêu cầu mộtdiffhoặc tệp đơn, không phải bài luận.
- Yêu cầu rõ ràng vềgiả địnhvàsự không chắc chắn.
- Giới hạn phạm vi (“chỉ triển khai X để làm cho kiểm thử vượt qua”).
📌 Sự Thay Đổi Tư Duy Sản Phẩm (Nâng Cấp Tư Duy) 🧠
- Từ đầu ra sang kết quả:“Tôi đã đóng 5 ticket” → “Tôi đã giảm tỷ lệ bỏ cuộc đăng ký 12%.”
- Từ tính năng sang công việc:Gắn mọi PR với mộtcông việc cần hoàn thành của người dùng.
- Từ hoàn hảo sang lặp đi lặp lại:Triển khai một bộ khung cơ bản, sau đó xây dựng chất lượng từng lớp.
- Từ đơn lẻ sang phối hợp:Coi AI/agents nhưđồng đội.
- Từ trực giác sang đo lường:Thêm một chỉ số vào mọi đặc tả.
✨ Một Tương Lai Lạc Quan
Con đường an toàn nhất là tiến hóa:
mở rộng tác động của bạn vượt ra ngoài code để sự nghiệp của bạn được nhân lên.
🤞 Đây là lý do tôi lạc quan:
Các nhà phát triển có lợi thế chiến thuật trong thời đại AI này.
Nếu họ hiểu sản phẩm, kiểm thử nó, hướng dẫn AI sửa lỗi trong code—hoặc tự sửa nó—họ có thể trở thành một lực lượng nhân đôi đơn lẻ.
Họ sẽ triển khai các sản phẩm tốt hơn, nhanh hơn và tạo ra nhiều việc làm hơn trên thị trường.
SaaS sẽ được xây dựng và lặp lại như thời trang nhanh—chu kỳ ngắn, phản hồi nhanh, pha trộn liên tục.
Mã nguồn mở và ưu tiên cục bộ đang tăng tốc;
các nhóm nhỏ hơn có thể triển khai các bản sửa lỗi có ý nghĩa nhanh hơn.
Hãy chọn một dự án mã nguồn mở bạn sử dụng, khắc phục một lỗi nhỏ trong tháng này và ghi chép lại trước/sau trong một bản ghi thay đổi 5 dòng.
Phát triển lĩnh vực của bạn:chính thức hóa đặc tả (Tư Duy Sản Phẩm), kể lại sự chấp nhận (Người Giải Quyết Vấn Đề), hoặc thực thi tiêu chí (Người Giữ Việc)—sau đó triển khai.
💪Thử Thách 30 Ngày: Trở Thành Lập Trình Viên Tư Duy Sản Phẩm (Trong Khi Vẫn Viết Code)
- Tuần 1– Chọn một nỗi đau người dùng;
viết một đặc tả sắc nét;
triển khai một bộ khung cơ bản. - Tuần 2– Thêm kiểm thử, khả năng quan sát và một kết quả có thể đo lường.
- Tuần 3– Chạy một đợt kiểm tra người dùng nhỏ (1–3 người dùng/các bên liên quan);
sửa đổi đặc tả;
triển khai phiên bản 2.
điều gì đã tạo ra thay đổi?
Điều gì không?
Hãy xuất bản nó.
Chúc may mắn.
Lời cuối
Tôi rất muốn nghe câu chuyện của bạn—bạn đã hướng về sản phẩm, tiếp tục đào sâu vào code, hay tạo ra một con đường kết hợp?
Kỹ năng nào thực sự tạo ra thay đổi cho bạn?
Hãy để lại bình luận 👇
Hẹn gặp lại lần sau.
Cho đến lúc đó.
Tiến hóa, đừng chờ đợi.⚡️
