Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng một buổi sáng thứ Hai điển hình trong một công ty công nghệ tại TP.HCM. Anh Product Manager họp với team engineering để chuẩn bị sprint mới. Anh nói: "Team ơi, tuần này mình cần làm tính năng thanh toán qua ví MoMo nhé." Anh Tech Lead gật đầu rồi hỏi lại: "Ok anh, mà anh tạo ticket trên Jira chưa? Priority nào? Nằm trong epic nào? Acceptance criteria là gì?" Anh PM lúng túng: "À... để anh nhờ bạn nào tạo giúp." Và thế là toàn bộ thông tin về tính năng ấy sống trong đầu anh, trong tin nhắn Slack, trong file Excel cá nhân — chứ không nằm ở nơi cả team thực sự làm việc.
Đây là khoảnh khắc mà rất nhiều PM Việt Nam gặp phải, và nó phơi bày một sự thật khó chịu: nếu bạn không thành thạo công cụ nơi công việc thực sự diễn ra, bạn sẽ luôn là người đứng bên ngoài quá trình delivery. Bạn "đặt yêu cầu" bằng miệng, rồi phụ thuộc hoàn toàn vào engineer để biến ý tưởng thành thứ có thể theo dõi được.
Bài học này không dạy bạn click nút nào trên Jira (những bài sau sẽ làm điều đó rất kỹ). Thay vào đó, nó định hình lại tư duy (mindset) và vai trò của một PM khi làm việc với Jira — nền tảng quản lý công việc phổ biến nhất thế giới, được hơn 100.000 tổ chức sử dụng, từ startup ở Hà Nội đến các tập đoàn như Grab, Tiki, VNG. Hiểu đúng vai trò của mình trong Jira chính là nền móng cho toàn bộ hành trình 60 bài của khóa học này.
Khái niệm cốt lõi
Jira là "backbone" của delivery, không phải một cái to-do list
Sai lầm đầu tiên của nhiều PM là xem Jira như một danh sách việc cần làm cho vui. Thực chất, trong một tổ chức làm phần mềm nghiêm túc, Jira là xương sống của toàn bộ quá trình delivery — nơi mọi quyết định về "làm gì, ai làm, khi nào xong, trạng thái ra sao" được ghi lại và trở thành nguồn sự thật duy nhất (single source of truth).
Điều này có nghĩa: khi một tính năng không tồn tại trên Jira, với engineering team, tính năng đó không tồn tại. Nó không được lên kế hoạch, không được ước lượng, không được theo dõi. Bạn có thể nói chuyện với team suốt cả tuần, nhưng nếu không có ticket, công việc ấy không bao giờ chính thức bước vào dòng chảy delivery.
PM "đặt yêu cầu" qua Jira, không qua lời nói
Vai trò cốt lõi của PM trong Jira là người khởi tạo và làm rõ yêu cầu (requirement) dưới dạng có cấu trúc, có thể hành động được. Khi bạn tự tay viết một user story rõ ràng, đặt priority, gắn context, thêm acceptance criteria — bạn đang "nói cùng ngôn ngữ" với engineering.
Ngược lại, khi bạn chỉ mô tả bằng miệng hoặc nhờ người khác tạo ticket hộ, ba vấn đề xuất hiện:
- Tam sao thất bản. Ý bạn muốn A, engineer hiểu thành B, đến khi demo mới phát hiện lệch.
- Mất quyền kiểm soát ưu tiên. Nếu bạn không tự sắp xếp backlog, ai đó khác sẽ quyết định thay bạn thứ tự công việc được làm.
- Không có dấu vết. Không ai biết vì sao một tính năng lại được ưu tiên, dẫn đến tranh cãi và mất niềm tin.
Không thuộc tool = lệ thuộc engineer
Đây là điểm mấu chốt cần khắc cốt ghi tâm. Khi PM không thành thạo Jira, mỗi lần cần tạo ticket, đổi trạng thái, lọc danh sách công việc, hay xem tiến độ, bạn đều phải nhờ vả. Điều này tạo ra ba hệ quả nguy hiểm:
- Bạn trở thành nút thắt cổ chai (bottleneck) — công việc chờ bạn nhờ người khác thao tác.
- Bạn mất uy tín (credibility) trước team — một PM không biết dùng công cụ cơ bản khó được engineer tôn trọng.
- Bạn mù thông tin — không tự truy vấn được dữ liệu, bạn phải tin vào những gì người khác báo cáo lại.
Ranh giới vai trò: PM sở hữu "cái gì" và "tại sao", không phải "làm thế nào"
Một mindset quan trọng: Jira giúp bạn thể hiện rõ ranh giới trách nhiệm. PM sở hữu what (làm gì) và why (tại sao) — được thể hiện qua việc tạo story, đặt priority, viết mô tả và acceptance criteria. Engineer sở hữu how (làm thế nào) — được thể hiện qua ước lượng, sub-task kỹ thuật, giải pháp implementation.
PM thạo Jira không có nghĩa là bạn nhảy vào chia sub-task kỹ thuật hay áp đặt cách code. Thạo tool nghĩa là bạn biết dừng đúng ranh giới của mình, và tin tưởng để engineer làm phần của họ. Đây là sự khác biệt giữa một PM trưởng thành và một PM micromanage.
Tình huống thực tế
Tình huống 1: Chị PM ở startup fintech Hà Nội và cái giá của việc "nhờ người tạo ticket"
Chị Lan là PM tại một startup fintech khoảng 25 người ở Hà Nội. Trong 6 tháng đầu, chị không dùng Jira trực tiếp — chị viết yêu cầu vào Google Docs rồi gửi cho anh Tech Lead, người sẽ "dịch" thành ticket Jira.
Kết quả sau một quý: trong buổi review với CEO, chị bị hỏi "Vì sao tính năng đối soát giao dịch chậm 3 tuần?" Chị không trả lời được, vì chị không tự truy cập được lịch sử ticket. Chị mở Jira lên nhưng không biết lọc, không hiểu các trạng thái, phải gọi anh Tech Lead giữa cuộc họp. Tệ hơn, khi vào xem, chị phát hiện có 4 story chị nghĩ đã hoàn thành thực ra vẫn ở trạng thái "In Review" suốt 2 tuần — vì chị chưa bao giờ tự kiểm tra.
Diễn giải: Vì chị không sở hữu công cụ, chị mất hoàn toàn tầm nhìn về tiến độ. Chị tin vào "cảm giác" thay vì dữ liệu thật.
Bài học: PM phải tự mình mở Jira mỗi ngày, tự tạo ticket, tự đọc trạng thái. Sau khi được coach, chị Lan dành 2 tuần học Jira cơ bản. Đến quý sau, chị có thể trả lời mọi câu hỏi tiến độ trong vài giây, và mối quan hệ với engineering team cải thiện rõ rệt vì họ thấy chị "nói cùng ngôn ngữ".
Tình huống 2: Anh PM tại công ty e-commerce và bài học về acceptance criteria mơ hồ
Anh Minh là PM tại một công ty thương mại điện tử tại TP.HCM (khoảng 150 nhân sự). Anh đã tự tạo ticket trên Jira, nhưng cách anh "đặt yêu cầu" vẫn có vấn đề. Một ticket điển hình của anh chỉ ghi vỏn vẹn: "Làm tính năng lọc sản phẩm theo giá."
Team dev nhận ticket, làm ra bộ lọc giá với hai ô nhập "từ - đến". Đến sprint review, anh Minh phản ứng: "Ơ, sao không có mấy khoảng giá gợi ý sẵn như dưới 200k, 200k-500k, trên 500k?" Team dev đáp: "Anh đâu có viết trong ticket." Cả hai bên đều đúng, nhưng mất 1 sprint và niềm tin.
Diễn giải: Anh Minh đã dùng Jira, nhưng chưa dùng nó đúng vai trò của PM. "Đặt yêu cầu qua Jira" không phải là ghi một dòng mơ hồ, mà là truyền đạt đủ context và acceptance criteria để engineer không phải đoán.
Bài học: Sở hữu công cụ chỉ là bước đầu. PM phải học cách viết yêu cầu đủ rõ để không cần giải thích thêm. Từ đó, anh Minh đổi thói quen: mỗi story đều có phần "Mô tả", "Vì sao cần", và "Điều kiện chấp nhận" gạch đầu dòng cụ thể. Số lần rework giảm khoảng 40% trong hai tháng.
Tình huống 3: PM tại một scale-up Singapore và ranh giới what/how
Chị Thảo chuyển từ một công ty Việt Nam sang làm PM tại một scale-up ở Singapore với văn hóa engineering rất mạnh. Với thói quen cũ, chị tạo story rồi tự chia luôn cả sub-task kỹ thuật: "Tạo API endpoint", "Viết migration cho database", "Thêm index cho bảng orders".
Anh Staff Engineer nhẹ nhàng phản hồi trong một buổi 1:1: "Chị Thảo, chị cho tụi em biết cần gì và tại sao là đủ rồi. Còn chia nhỏ kỹ thuật thế nào để tụi em lo — vì đôi khi giải pháp chị nghĩ không tối ưu về mặt hệ thống."
Diễn giải: Chị Thảo thạo tool, nhưng dùng nó để lấn sang phần "how" của engineer. Điều này vừa làm giảm quyền tự chủ của team, vừa dễ tạo ra giải pháp kém tối ưu.
Bài học: Thạo Jira nghĩa là biết dừng đúng chỗ. PM viết story ở tầng "vấn đề cần giải quyết", engineer sở hữu cách giải. Sau khi điều chỉnh, chị Thảo tập trung vào việc viết story và acceptance criteria thật sắc, để phần kỹ thuật cho team — và được đánh giá là "PM dễ làm việc nhất" trong khảo sát nội bộ.
Hướng dẫn từng bước
Đây là quy trình tư duy để bạn chuyển từ "PM đứng ngoài" sang "PM sở hữu công cụ". Chưa cần đi sâu thao tác — điều đó ở các bài sau — nhưng đây là mindset cần có ngay:
- Cam kết dùng Jira mỗi ngày. Đặt Jira thành tab đầu tiên mở mỗi sáng. Tự mở board của mình, đọc trạng thái các ticket. Biến việc này thành thói quen như đọc email.
- Tự tay tạo mọi ticket của mình. Nguyên tắc: nếu đó là yêu cầu sản phẩm, PM tạo — không nhờ người khác. Việc tạo ticket buộc bạn phải suy nghĩ rõ ràng về what và why.
- Xác định trước ranh giới what/how. Khi viết ticket, tự hỏi: "Điều mình đang ghi là mô tả vấn đề cần giải quyết (đúng vai trò PM) hay là chỉ định giải pháp kỹ thuật (thuộc engineer)?" Nếu là cái sau, hãy lùi lại.
- Luôn kèm ba yếu tố trong mỗi yêu cầu: Cái gì cần làm (mô tả), Vì sao cần (giá trị/mục tiêu), và Khi nào coi là xong (điều kiện chấp nhận). Ba yếu tố này là "hợp đồng" giữa PM và engineer.
- Tự truy vấn thay vì hỏi người khác. Khi cần biết tiến độ, tập thói quen tự lọc, tự xem trên Jira thay vì nhắn tin hỏi Tech Lead. Mỗi lần tự làm được là một lần bạn bớt lệ thuộc.
- Coi Jira là kênh giao tiếp chính thức. Quyết định quan trọng nên được ghi vào comment của ticket, không chỉ trong chat Slack sẽ trôi mất. Ticket là nơi lưu giữ lịch sử và ngữ cảnh lâu dài.
Lỗi thường gặp & mẹo
Lỗi 1: Xem Jira là "việc của engineer, không phải của PM". Đây là tư duy tai hại nhất. Jira là công cụ chung, và PM là một trong những người dùng quan trọng nhất. Mẹo: hãy tự đặt mục tiêu trong tuần đầu — tự tạo 100% ticket sản phẩm của mình, không nhờ ai.
Lỗi 2: Viết yêu cầu quá mơ hồ. "Cải thiện trang chủ" là một câu vô nghĩa với engineer. Mẹo: luôn tự hỏi "Nếu mình là dev đọc dòng này, mình có biết chính xác phải làm gì và khi nào coi là xong không?"
Lỗi 3: Micromanage bằng cách lấn sang phần kỹ thuật. Chia sub-task kỹ thuật thay engineer là dấu hiệu bạn chưa tin tưởng team. Mẹo: dừng ở tầng "vấn đề và giá trị", để engineer tự quyết cách giải.
Lỗi 4: Dùng Jira như nơi ra lệnh một chiều. Jira không phải bảng phân công để "giao việc rồi biến mất". Mẹo: coi ticket là nơi đối thoại — đọc comment của dev, trả lời câu hỏi, cập nhật khi context thay đổi.
Lỗi 5: Để thông tin quan trọng nằm ngoài Jira. Quyết định trong Slack, yêu cầu qua điện thoại, ưu tiên trong đầu bạn — tất cả sẽ biến mất. Mẹo: nguyên tắc "nếu chưa có trên Jira thì chưa tồn tại", áp dụng cho chính bạn trước.
Mẹo vàng cho PM mới: Hãy xin quyền "watcher" hoặc theo dõi board của team trong tuần đầu để quan sát cách engineer thực sự dùng Jira — họ đặt ticket thế nào, comment ra sao, chuyển trạng thái khi nào. Học từ dòng chảy thực tế của team nhanh hơn nhiều so với đọc lý thuyết.
Bài tập thực hành
- Tự kiểm tra sự lệ thuộc: Trong 3 ngày làm việc gần nhất, hãy đếm số lần bạn nhờ người khác thao tác trên Jira thay mình (tạo ticket, đổi trạng thái, xem tiến độ). Con số càng cao, mức độ lệ thuộc càng lớn. Đặt mục tiêu giảm về 0 trong 2 tuần.
- Viết lại một yêu cầu mơ hồ: Lấy một yêu cầu sản phẩm gần đây bạn từng mô tả bằng miệng hoặc ghi qua loa. Viết lại thành một story hoàn chỉnh với đủ ba yếu tố: mô tả (cái gì), giá trị (tại sao), và điều kiện chấp nhận (khi nào coi là xong). So sánh độ rõ ràng giữa hai phiên bản.
- Phân loại what vs how: Lấy 5 dòng bạn từng viết trong ticket. Đánh dấu mỗi dòng là "what/why" (thuộc PM) hay "how" (thuộc engineer). Nếu có dòng thuộc "how", hãy viết lại để trả phần đó về cho engineer.
- Bài tập quan sát: Chọn một PM giỏi trong công ty (hoặc một ticket được đánh giá cao). Đọc kỹ cách họ viết mô tả, đặt priority, tương tác trong comment. Ghi lại 3 điều bạn học được để áp dụng.
Tóm tắt
Bài học này đặt nền móng tư duy cho toàn bộ hành trình làm chủ Jira của bạn với vai trò PM. Những điểm cốt lõi cần nhớ:
- Jira là xương sống của delivery, không phải to-do list. Với engineering, thứ gì không có trên Jira thì không tồn tại.
- PM đặt yêu cầu qua Jira, không qua lời nói. Tự tay tạo ticket rõ ràng chính là cách bạn "nói cùng ngôn ngữ" với team.
- Không thuộc tool = lệ thuộc engineer. Sự lệ thuộc biến bạn thành nút thắt cổ chai, làm mất uy tín và tầm nhìn.
- PM sở hữu "cái gì" và "tại sao", engineer sở hữu "làm thế nào". Thạo tool nghĩa là biết dừng đúng ranh giới của mình.
- Mindset thực hành: dùng Jira mỗi ngày, tự tạo mọi ticket của mình, luôn kèm ba yếu tố (cái gì, vì sao, khi nào xong), và tự truy vấn thay vì hỏi người khác.