Hệ Sinh Thái Jira và Tư Duy Áp Dụng

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