1.1 Hệ sinh thái “đầy đủ” quanh 3 loại dự án Jira
| Nhóm năng lực / Add-on | Team-managed Software | Team-managed Business | Jira Service Management (JSM) |
|---|---|---|---|
| Sản phẩm lõi Atlassian tích hợp 1-click | • Bitbucket (repo & CI/CD) • Compass (dịch vụ & kiến trúc) • Confluence (spec, retro, doc) | • Confluence (quy trình, OKR, form) • Atlas (điều phối OKR/liên phòng ban) | • Opsgenie (on-call, alert) • Statuspage (truyền thông sự cố) • Assets (CMDB – tên mới của Insight) Atlassian |
| Template chuyên biệt mặc định | Scrum, Kanban, DevOps, Bug tracking | Task tracking, Process management, Content approval | ITSM: Service Desk, Incident, Change, Problem, HR/Facilities Service, Customer Service |
| Khả năng SLA & Queue | Không có sẵn (=> App “Time to SLA”, “SLA PowerBox”… ) | Không có sẵn | Built-in: chính sách SLA, hàng chờ, cảnh báo, báo cáo vi phạm |
| Cổng yêu cầu (Portal) | ✖︎ | ✖︎ | ✔︎ Portal không giới hạn end-user, tự tra cứu KB |
| Quản lý tài sản / CMDB | Marketplace app (Device42, AssetIT…) | Marketplace app | Assets (Insight) – native bản Premium/Enterprise AssetIT |
| Báo cáo đặc thù | Burndown, Velocity, Control chart | Biểu đồ tiến độ, Calendar, Timeline | SLA report, CSAT, MTTR, Post-Incident Review, Change risk report |
| Automation | Rules/Branch cơ bản (IF-THEN) | Tương đương Software | Mạnh nhất: trigger theo SLA, đợt trực Opsgenie, asset trạng thái |
| Marketplace app “kinh điển” | Tempo Timesheets, Zephyr Scale, Xray Test | Projectrak, Checklist for Jira, ProForma | Assets Discovery, DevOps Automation, Lansweeper Asset Linker Lansweeper |
| Triển khai CI/CD & DevOps | Tích hợp Bitbucket Pipelines, GitHub, Jenkins; tự tạo Deployment panel | Không định hướng DevOps | Liên kết Incident ↔ Deployment; thông báo rollback qua Opsgenie |
| Phân quyền & Vai trò | Admin, Member, Viewer (đơn giản) | Tương tự Software | Khác biệt: Agent (tính phí), Admin, Customer (miễn phí) |
| Gói giá | Bao gồm trong Jira Software (Free → Premium) | Bao gồm trong Jira Work Management | Cần license JSM (Free ≤ 3 agent; Standard, Premium, Enterprise) |
| Tính khả dụng (Cloud / DC) | Cloud (free) & Data Center | Cloud (free) & Data Center | Cloud (free ≤ 3 agent) & Data Center (tách licence) |
| Use-case tiêu biểu | Sprint, release, dev backlog | Văn phòng, marketing, HR, IT-Ops hằng ngày | IT Helpdesk, DevOps incident, Change Advisory Board, HR/Fleet Service Desk |
Cách “lắp ghép” hệ sinh thái cho từng mục tiêu
| Nhu cầu của team | Tổ hợp đề xuất | Vì sao chọn |
|---|---|---|
| Phát triển & release sản phẩm | Team-managed Software + Bitbucket + Confluence | Vòng đời Agile đầy đủ, pull request kết nối issue, docs nằm cạnh code. |
| Vận hành tác vụ văn phòng, OKR, form phê duyệt | Team-managed Business + Confluence + Atlas | Template business, bảng Timeline/Gantt, biểu mẫu phê duyệt dễ cấu hình. |
| Helpdesk + CMDB + On-call | JSM + Opsgenie + Assets + Statuspage | Portal + SLA + trực ca, tự động dán tài sản, thông báo khách hàng. |
| DevOps + ITSM liên thông | JSM project (Incident/Change) liên kết với Software project (Dev backlog) | Ticket sự cố kéo thẳng commit/deploy; Change tự sinh trong board dev. |
Tip triển khai:
- Start small – kích hoạt đúng module cần (SLA, Assets…) để tránh rối.
- Dùng Automation đồng bộ trạng thái giữa Software ↔ JSM khi dev fix bug.
- Khuyến nghị đăng ký Premium nếu cần Assets CMDB hoặc lịch sử Deploy mở rộng.
1.2 Bộ 3 Công Cụ Quản Lý Dự Án
| Tiêu chí | Team-managed Software | Team-managed Business | Jira Service Management (JSM) |
|---|---|---|---|
| Mục đích chính | Quản lý phát triển phần mềm theo Agile/Scrum/Kanban | Quản lý công việc thường ngày, quy trình kinh doanh, hành chính | Quản lý dịch vụ IT, hỗ trợ kỹ thuật, xử lý yêu cầu của người dùng |
| Đối tượng sử dụng | Developer, kỹ sư phần mềm | Nhân sự, hành chính, IT support thường ngày | IT Helpdesk, DevOps, ITSM, CS/IT Support Team |
| Template khả dụng | Scrum, Kanban | Task Tracking, Process Management | IT Service Management (ITSM), Service Desk, Incident/Change Mgmt |
| Hỗ trợ SLA (Service Level Agreement) | ❌ Không có sẵn – phải dùng plugin hoặc workaround | ❌ Không hỗ trợ SLA trực tiếp | ✅ Có sẵn, thiết lập SLA linh hoạt theo mức độ ưu tiên |
| Cổng yêu cầu (Customer Portal) | ❌ Không có | ❌ Không có | ✅ Có – khách hàng/nhân viên có thể tạo ticket dễ dàng |
| Loại yêu cầu (Request Types) | ✔️ Issue type (Story, Bug, Task,…) | ✔️ Task, Custom issue type | ✅ Rất linh hoạt: Incident, Request, Change, Problem,… |
| Quản lý hàng chờ (Queue) | ❌ Không hỗ trợ | ❌ Không hỗ trợ | ✅ Có hàng chờ theo SLA, phân loại ticket tự động |
| Workflow tùy chỉnh | ✅ Dễ dùng, kéo thả từng issue type | ✅ Tùy biến đơn giản | ✅ Nâng cao với trạng thái, quy tắc phê duyệt, tự động hóa phức tạp |
| Tự động hóa (Automation) | ✅ Có – mức cơ bản (IF/THEN, chuyển trạng thái) | ✅ Có – đơn giản cho business flow | ✅ Rất mạnh – theo điều kiện, SLA, thời gian, người dùng,… |
| Phân quyền người dùng | ✔️ Dễ dùng, giới hạn đơn giản | ✔️ Tương tự, dễ phân quyền | ✅ Linh hoạt hơn: phân vai trò agent, admin, customer,… |
| Báo cáo và Dashboard | ✅ Agile reports (burnup, burndown, velocity,…) | ✔️ Dashboard đơn giản | ✅ SLA reports, satisfaction (CSAT), incident trends,… |
| Tích hợp KB (Confluence) | ✔️ Có thể tích hợp | ✔️ Có thể tích hợp | ✅ Tích hợp chặt chẽ – hiển thị bài viết trong cổng khách hàng |
| Quản lý tài sản (Asset Management) | ❌ Không hỗ trợ | ❌ Không hỗ trợ | ✅ Có – qua Insight (theo dõi thiết bị, CMDB) |
| Chi phí sử dụng | Bao gồm trong Jira Software | Bao gồm trong Jira Software | Cần mua giấy phép riêng cho JSM (theo số Agent) |
| Phù hợp cho | Dự án phát triển phần mềm Agile/Scrum | Quản lý công việc hành chính, nhân sự, tác vụ nội bộ | Quản lý dịch vụ IT, hệ thống hỗ trợ kỹ thuật chuyên nghiệp |
Tiêu Chí Lựa Chọn:
| Nhu cầu cụ thể | Nên chọn loại nào | Lý do |
|---|---|---|
| Quản lý IT Infrastructure & tác vụ kỹ thuật hằng ngày | ✅ Team-managed Business | Đơn giản, dễ cấu hình, phù hợp với task tracking & daily operation |
| Quản lý hỗ trợ kỹ thuật (Support ticket) | ✅ Jira Service Management (JSM) | Có SLA, hàng chờ, cổng yêu cầu, báo cáo chuyên biệt cho support |
| Quản lý dự án phát triển phần mềm (Agile) | ✅ Team-managed Software | Có backlog, board, estimation (story points), sprint planning |
| Cần quản lý vừa ticket vừa dự án | ➕ Kết hợp JSM + Software | JSM để xử lý ticket, Software để phát triển và triển khai giải pháp |
Trial 10 users
2. MINDSET KHI SỬ DỤNG CÔNG CỤ CỦA JIRRA
2.1. 5W+1H
Phương pháp 5W + 1H là một kỹ thuật cực kỳ hiệu quả để làm rõ và truyền đạt thông tin trong quản lý công việc – và đặc biệt hữu ích khi áp dụng trong Jira để viết Story, Task, Bug, hoặc các mô tả yêu cầu rõ ràng, dễ hiểu, dễ thực thi.
✅ Tổng quan 5W + 1H
| Thành phần | Ý nghĩa | Câu hỏi gợi ý |
|---|---|---|
| What | Việc gì? | Chúng ta cần làm gì? (chức năng, task?) |
| Why | Tại sao phải làm? | Mục tiêu, lợi ích, lý do kinh doanh? |
| Who | Ai liên quan? | Ai thực hiện? Ai phê duyệt / ảnh hưởng? |
| When | Khi nào? | Deadline? Ưu tiên thời gian? |
| Where | Ở đâu? | Môi trường nào? (dev/test/prod, server?) |
| How | Làm thế nào? | Quy trình cụ thể? Giải pháp? Hướng dẫn? |
✅ Cách dùng hiệu quả 5W+1H trong Jira
Khi tạo issue trong Jira (Story / Task / Bug / Epic), Tony có thể dùng 5W+1H ngay trong phần mô tả (Description) hoặc đặt chúng làm template mặc định. Cụ thể:
What (Việc gì?)
- Mô tả rõ ràng công việc cần làm
- Ví dụ: Thêm chức năng đăng nhập bằng Google
Why (Tại sao làm?)
- Giải thích lý do tồn tại của yêu cầu này
- Ví dụ: Giúp người dùng đăng nhập nhanh hơn, tăng tỷ lệ giữ chân
Who (Ai liên quan?)
- Người thực hiện: [Assignee]
- Người review: [QA/PO]
- Stakeholder: [Client/Team Lead]
When (Khi nào?)
- Deadline mong muốn: DD/MM/YYYY
- Ưu tiên: Cao / Trung bình / Thấp
Where (Ở đâu?)
- Môi trường áp dụng: staging/dev/prod
- Module liên quan: [Authentication module]
How (Làm thế nào?)
- Gợi ý kỹ thuật, tài liệu liên quan
- Link Figma: https://figma.com/…
- Mã nguồn liên quan:
/auth/login.js
Lợi ích khi áp dụng 5W+1H trong Jira
| Lợi ích | Mô tả |
|---|---|
| ✅ Giao tiếp rõ ràng | Giảm mơ hồ, giúp dev, tester, PO hiểu cùng một cách |
| ✅ Quản lý tiến độ tốt hơn | Biết rõ deadline, ai phụ trách, ưu tiên |
| ✅ Hạn chế sai sót | Nắm kỹ “how” sẽ giảm việc làm sai hoặc thiếu |
| ✅ Tự động hóa tốt hơn | Khi mô tả rõ ràng → dễ viết automation rules hoặc test cases |
| ✅ Thuận tiện onboarding / audit | Thành viên mới dễ hiểu lịch sử task, lý do tại sao đã làm việc đó |
Gợi ý: Tạo template mô tả 5W+1H mặc định trong Jira
- Vào Project settings → Issue types → Edit description field default value (nếu dùng team-managed).
- Dán template trên để mọi người đều viết theo format chuẩn.
2.2.Khái niệm: Phương pháp 3 WHYs
Phương pháp này đặt ra liên tiếp 3 câu hỏi “Tại sao?” (Why?) để đào sâu mục đích hoặc nguyên nhân, mỗi câu trả lời lại dẫn đến câu hỏi tiếp theo.
❝Việc hỏi “Tại sao?” liên tục 3 lần sẽ giúp lột bỏ lớp bề mặt và chạm đến giá trị cốt lõi hoặc vấn đề gốc rễ.❞
Ví dụ 1: Trong Jira – Mục tiêu tính năng
| Lần hỏi | Câu hỏi “Tại sao?” | Câu trả lời |
|---|---|---|
| 1 | Tại sao cần thêm tính năng xuất báo cáo doanh thu? | Vì ban giám đốc muốn theo dõi hiệu suất bán hàng hàng tháng |
| 2 | Tại sao họ cần theo dõi hiệu suất hàng tháng? | Vì họ cần biết bộ phận nào hoạt động tốt và điều chỉnh ngân sách |
| 3 | Tại sao phải điều chỉnh ngân sách theo hiệu suất? | Vì công ty đang tối ưu chi phí hoạt động để tăng lợi nhuận |
Insight: Mục tiêu thật sự không phải “export báo cáo” mà là tối ưu chi phí, nên team có thể đề xuất thêm dashboard realtime.
Khi nào nên dùng 3 WHYs?
| Trường hợp | Mục tiêu khi dùng 3 WHYs |
|---|---|
| Viết user story / yêu cầu tính năng | Đào sâu giá trị kinh doanh thực sự |
| Gặp yêu cầu mơ hồ từ stakeholder | Làm rõ ý định và mục tiêu đằng sau yêu cầu |
| Phân tích lỗi, sự cố IT | Tìm nguyên nhân gốc thay vì xử lý triệu chứng |
| Phân vân giữa nhiều hướng triển khai | Xác định đâu là lựa chọn đáp ứng mục tiêu cốt lõi |
Cách tích hợp 3 WHYs vào mô tả Jira hiệu quả:
Tony có thể thêm phần nhỏ sau vào Description:
WHY Analysis (3 WHYs)
1. **Tại sao cần tính năng này?** → [Trả lời]
2. **Tại sao điều đó lại quan trọng?** → [Trả lời]
3. **Tại sao không dùng cách khác?** → [Trả lời]
Kết hợp với 5W+1H:
- 5W+1H giúp định hình rõ công việc.
- 3 WHYs giúp làm rõ động lực và chiến lược đằng sau công việc đó.
2.3 OLA vs SLA
So sánh SLA vs OLA – Dạng bảng
| Tiêu chí | SLA (Service Level Agreement) | OLA (Operational Level Agreement) |
|---|---|---|
| Định nghĩa | Thỏa thuận cấp độ dịch vụ giữa IT và khách hàng cuối (internal hoặc external) | Thỏa thuận nội bộ giữa các bộ phận IT / nhóm kỹ thuật để hỗ trợ thực hiện SLA |
| Mục tiêu | Cam kết thời gian phản hồi, xử lý sự cố, chất lượng dịch vụ với người dùng cuối | Đảm bảo các bộ phận hỗ trợ thực hiện SLA đúng cam kết |
| Đối tượng ký kết | IT service provider ↔ Customer (User, Business Unit, External) | Bộ phận nội bộ IT với nhau: Helpdesk ↔ Network team, Infra team, DB team… |
| Ví dụ phổ biến | – 99.9% uptime mỗi tháng – Phản hồi ticket P1 trong 15 phút | – Network team restore xong router trong vòng 30 phút |
| Quản lý và theo dõi | Được đo lường, báo cáo và hiển thị thông qua dashboard SLA | Ít được báo cáo công khai; đo bằng KPI nội bộ hoặc quy trình liên phòng ban |
| Hiển thị trên Jira JSM | ✔️ Có module SLA sẵn – tự động tính và cảnh báo | ❌ Không có tính năng riêng – cần cấu hình automation hoặc quy ước nội bộ |
| Chế tài khi vi phạm | Có thể ảnh hưởng đến uy tín, hợp đồng, KPI cá nhân hoặc tổ chức | Thường không có chế tài pháp lý – chỉ ảnh hưởng đến nội bộ |
| Tính minh bạch | Hiển thị cho khách hàng qua portal hoặc báo cáo hàng tháng | Không hiển thị ra ngoài – dùng cho team vận hành biết trách nhiệm của mình |
Mối liên hệ giữa SLA và OLA
| Mối liên hệ | Giải thích |
|---|---|
| SLA phụ thuộc vào OLA | Để đảm bảo SLA được đáp ứng, OLA phải đảm bảo nội bộ vận hành đúng thời hạn. |
| OLA là “xương sống” cho SLA | Ví dụ: Nếu DB team không khôi phục đúng giờ, thì SLA của ticket P1 sẽ vi phạm. |
| OLA không công khai, nhưng rất quan trọng | Nếu không có OLA rõ ràng, việc blame giữa team sẽ diễn ra khi SLA fail. |
| Automation có thể hỗ trợ kiểm soát OLA | Có thể dùng Jira Automation để cảnh báo nếu sub-task kỹ thuật trễ thời gian cam kết OLA. |
Case Study Thực Tế
Case 1: Hỗ trợ sự cố P1 – Mất kết nối email
| Mức | Nội dung |
|---|---|
| SLA | Phản hồi trong vòng 15 phút, xử lý hoàn tất trong 1 giờ. |
| OLA | – Network team kiểm tra kết nối trong 10 phút – Email team xác minh cấu hình MX trong 15 phút |
Nếu network team không phản hồi đúng cam kết 10 phút (OLA), thì ticket trễ xử lý → SLA vi phạm.
Case 2: Triển khai tính năng mới cho khách hàng nội bộ
| Mức | Nội dung |
|---|---|
| SLA | Cam kết triển khai trong 5 ngày làm việc. |
| OLA | – Dev team phải hoàn tất code review trong 2 ngày. – QA kiểm tra trong 1 ngày. – Infra cấp quyền deploy trong 4 giờ sau khi test OK. |
Việc quản lý chặt OLA giúp đảm bảo đúng tiến độ SLA.
Case 3: Báo cáo backup không chạy
| Mức | Nội dung |
|---|---|
| SLA | Support phản hồi trong 30 phút, xử lý trong vòng 2 giờ. |
| OLA | – Backup team xác minh trạng thái job trong vòng 20 phút. – DB team kiểm tra lỗi SQL backup trong 30 phút. |
Dù Helpdesk trả lời sớm (SLA response OK), nếu OLA bị trễ → SLA resolution fail.
Mẹo triển khai trong Jira / ITSM
| Gợi ý kỹ thuật | Công cụ đề xuất |
|---|---|
| Đo SLA dựa trên độ ưu tiên, request type | SLA Policies trong Jira Service Management |
| Giao việc theo OLA → dùng sub-task gắn thời gian | Sub-task + Due Date + Automation |
| Theo dõi OLA trễ | App như Time to SLA, SLA PowerBox |
| Dashboard SLA + cảnh báo | JSM built-in dashboard / Opsgenie |