Giới thiệu

Một workflow Jira hiệu quả cần thể hiện rõ quy trình bàn giao thực tế của nhóm. Workflow nên cho thấy công việc đang chờ ở đâu, chuyên gia đang trực tiếp xử lý ở đâu và mục nào đã sẵn sàng tạo ra giá trị cho khách hàng. Mục tiêu không phải là tạo một sơ đồ phức tạp. Mục tiêu là giúp nhóm trả lời những câu hỏi thiết thực: Tiếp theo chúng ta nên làm việc gì? Công việc đang bị mắc kẹt ở đâu? Những mục nào sắp hoàn thành? Điều gì đang cản trở việc bàn giao?

Một lỗi thường gặp là sao chép workflow chung vào Jira rồi mong nhóm thích nghi với workflow đó. Nhóm phần mềm có thể cần các giai đoạn như Được chọn để phát triển, Đang thực hiện, Đánh giá mã, Kiểm thử và Hoàn tất. Nhóm vận hành marketing có thể cần các giai đoạn như Bản yêu cầu đã được phê duyệt, Đang sản xuất, Đánh giá của các bên liên quan, Đã lên lịch và Đã xuất bản. Không workflow nào mặc nhiên là đúng. Thiết kế phù hợp phải phản ánh các bước bàn giao thực tế, điểm phê duyệt, quyền ra quyết định và kết quả dành cho khách hàng.

Hãy bắt đầu với quy trình bàn giao bên ngoài Jira. Yêu cầu nhóm mô tả cách một yêu cầu điển hình chuyển từ lúc được thống nhất ưu tiên đến khi hoàn tất và tạo ra kết quả. Phân biệt các bước thông thường với các trường hợp ngoại lệ. Ví dụ, một yêu cầu được trả lại để làm rõ không nhất thiết phải là một giai đoạn cố định trong workflow. Có thể biểu thị trường hợp này bằng nhận xét, cờ đánh dấu hoặc trường ghi rõ lý do. Sự phân biệt này giúp workflow không trở thành nơi ghi lại mọi sự kiện bất thường.

Thiết kế workflow

Trạng thái workflow cần thể hiện một trạng thái công việc có ý nghĩa, chứ không chỉ là hoạt động do một người thực hiện. “Đang viết”, “Họp” hoặc “Đang chờ Sam” thường mô tả hành động hoặc người phụ trách, thay vì trạng thái giúp cả nhóm quản lý luồng công việc. Trạng thái tốt hơn cho biết mục đó đã sẵn sàng, đang được xử lý, đang chờ quyết định hay đã hoàn tất. Mỗi trạng thái cần trả lời được câu hỏi: “Hiện tại, điều gì đúng với công việc này?”

Giữ số lượng trạng thái đủ ít để nhóm có thể sử dụng nhất quán. Nhóm có thể cần trạng thái đánh giá riêng nếu hoạt động đánh giá tạo thành một hàng đợi dễ nhận thấy và đòi hỏi hành động khác với giai đoạn phát triển. Có thể không cần trạng thái riêng cho từng loại đánh giá nếu cùng một người thực hiện, cùng quy tắc và cùng bước tiếp theo được áp dụng. Trước khi tạo trạng thái, hãy xác nhận rằng trạng thái đó làm thay đổi cách nhóm ưu tiên, đo lường hoặc quản lý mục công việc. Nếu không, hãy dùng trường issue, nhãn, component, nhận xét hoặc checklist, với điều kiện cơ chế được chọn đã được hỗ trợ trong cấu hình Jira của nhóm.

Các bước chuyển trạng thái cần hỗ trợ những quyết định rõ ràng và bảo vệ các yêu cầu kiểm soát chất lượng quan trọng. Ví dụ, khi chuyển một mục từ Kiểm thử sang Hoàn tất, có thể cần bằng chứng cho thấy các tiêu chí chấp nhận đã đạt. Khi chuyển một mục từ Đánh giá của các bên liên quan trở lại Đang thực hiện, cần ghi rõ lý do phải chỉnh sửa. Quản trị viên Jira có thể cấu hình điều kiện, trình xác thực và hàm hậu xử lý cho các bước chuyển trạng thái, nhưng mức độ kiểm soát cần tương xứng. Hạn chế quá mức có thể dẫn đến cách xử lý đối phó, chẳng hạn như để issue ở sai trạng thái hoặc tạo issue trùng lặp.

Hãy xác định ý nghĩa của Hoàn tất trước khi cấu hình bước chuyển trạng thái cuối cùng. Với một tính năng hướng đến khách hàng, Hoàn tất có thể nghĩa là các tiêu chí chấp nhận đã được đáp ứng, quá trình kiểm thử bắt buộc đã hoàn tất, tài liệu đã được cập nhật và quyết định phát hành đã được ghi nhận. Với một tài sản chiến dịch nội bộ, Hoàn tất có thể nghĩa là tài sản đã được phê duyệt, lưu tại vị trí đã thống nhất và sẵn sàng cho đối tượng dự kiến sử dụng. Định nghĩa Hoàn tất dùng chung giúp dữ liệu Jira đáng tin cậy hơn vì trạng thái cuối cùng mang một ý nghĩa kinh doanh nhất quán.

Ánh xạ quy trình làm việc vào các cột trên bảng

Bảng là công cụ quản lý trực quan, không phải bản sao đầy đủ của quy trình làm việc. Có thể gộp nhiều trạng thái quy trình vào cùng một cột khi nhóm quản lý chúng như một giai đoạn thống nhất. Ví dụ, Đánh giá kỹ thuật và Đánh giá nghiệp vụ có thể cùng được xếp vào cột Đánh giá nếu nhóm theo dõi chúng với cùng một mục tiêu. Ngược lại, một trạng thái quy trình có thể cần một cột riêng nếu đó là nút thắt lớn cần được chú ý rõ ràng.

Hãy thiết kế các cột xoay quanh việc bàn giao cho khách hàng và các quyết định của nhóm. Một bảng hữu ích thường có hàng đợi bắt đầu rõ ràng, khu vực xử lý công việc đang diễn ra, một hoặc nhiều khu vực đánh giá hoặc xác thực có giới hạn, và khu vực hoàn tất cuối cùng. Tránh tạo cột chỉ để cho biết ai đang làm việc. Việc phân công thuộc về thông tin người được giao và quy trình làm việc của nhóm; bảng chủ yếu cần thể hiện trạng thái công việc và hành động tiếp theo.

Với mỗi cột, hãy xác định tiêu chí để chuyển vào và chuyển ra. “Đang thực hiện” không nên có nghĩa là ai đó đã mở issue. Trạng thái này cần cho biết nhóm đã dành năng lực xử lý và công việc đang được đẩy tiến độ. “Sẵn sàng đánh giá” cần có nghĩa là người tạo đã hoàn tất khâu chuẩn bị theo thỏa thuận và người đánh giá có thể bắt đầu mà không phải tìm kiếm thông tin còn thiếu. Các tiêu chí này giúp giảm tranh luận về vị trí của công việc trên bảng và cải thiện chất lượng của các chỉ số luồng công việc.

Hãy xem xét bảng từ góc độ khách hàng. Nếu một hạng mục nằm trong một cột suốt nhiều ngày vì đang chờ phê duyệt từ bên ngoài, bảng cần thể hiện rõ thời gian chờ đó. Che giấu độ trễ trong một cột “Đang thực hiện” quá rộng khiến nhóm có ấn tượng sai lệch rằng công việc vẫn đang tiến triển và gây khó khăn cho việc cải thiện quy trình.

Áp dụng giới hạn công việc đang thực hiện

Giới hạn công việc đang thực hiện (WIP) quy định số lượng hạng mục tối đa có thể cùng lúc nằm trong một giai đoạn hoặc một nhóm giai đoạn. Mục đích là bảo vệ khả năng tập trung và làm lộ rõ các nút thắt. Khi cột Đánh giá có giới hạn là ba và đã có đủ ba hạng mục, người tiếp theo nên hỗ trợ hoàn tất hoặc gỡ vướng cho công việc hiện có trước khi bắt đầu hạng mục khác. Cách làm này chuyển trọng tâm của nhóm từ tối đa hóa mức độ bận rộn của từng cá nhân sang cải thiện thông lượng tổng thể.

Hãy chọn giới hạn dựa trên dữ liệu thực tế và năng lực của nhóm. Nhóm có năm người không có nghĩa là mọi cột đều cần giới hạn là năm. Hãy cân nhắc số người có thể thực hiện công việc, mức độ làm song song giúp tạo ra tiến triển hữu ích và quy mô điển hình của các hạng mục. Nếu khâu đánh giá cần một chuyên gia duy nhất, giới hạn hai hoặc ba có thể phù hợp hơn giới hạn dựa trên tổng số thành viên nhóm. Hãy bắt đầu với một giới hạn tạm thời và đánh giá kết quả qua vài chu kỳ bàn giao.

Giới hạn là tín hiệu để trao đổi, không phải hình phạt. Khi đạt đến giới hạn, nhóm nên xem xét liệu có thể hoàn tất một hạng mục nào đó, công việc có bị chặn hay không, hoặc liệu cam kết ban đầu có thiếu thực tế. Có thể tạm thời vượt giới hạn khi xảy ra sự cố khẩn cấp, nhưng cần nêu rõ lý do. Việc thường xuyên vượt giới hạn cho thấy cần xem xét lại giới hạn, quy trình làm việc, mô hình nhân sự hoặc quy tắc ưu tiên.

Đừng dùng giới hạn WIP để che giấu nhu cầu công việc. Nếu các yêu cầu khẩn cấp thường xuyên bỏ qua bảng, nhóm sẽ không thể nhìn thấy khối lượng công việc thực tế. Hãy thiết lập chính sách xử lý ưu tiên rõ ràng, bao gồm người có quyền phê duyệt, công việc nào sẽ bị dời lại và cách đánh giá tác động. Nhờ đó, các trường hợp ngoại lệ được quản lý minh bạch thay vì để mỗi bên liên quan tự ý thay đổi thứ tự ưu tiên.

Sử dụng bộ lọc và đánh giá hiệu suất

Bộ lọc bảng cần hiển thị những công việc mà nhóm chịu trách nhiệm quản lý. Bộ lọc nên bao gồm dự án hoặc các dự án liên quan, loại issue và phạm vi đã thống nhất. Một bộ lọc bao gồm mọi issue trong một dự án lớn có thể khiến bảng trở nên nhiễu và làm giảm độ tin cậy. Ngược lại, bộ lọc loại trừ các phần phụ thuộc, lỗi hoặc công việc vận hành có thể tạo ra bức tranh sai lệch về năng lực. Hãy xác nhận phạm vi với nhóm và ghi lại các quy tắc đưa công việc vào bộ lọc bằng ngôn ngữ nghiệp vụ dễ hiểu.

Sử dụng bộ lọc để hỗ trợ các góc nhìn quản lý khác nhau mà không thay đổi workflow bên dưới. Bảng theo dõi bàn giao có thể tập trung vào các mục trong sprint hiện tại hoặc backlog. Góc nhìn dịch vụ có thể tập trung vào các issue chưa được xử lý và đang ảnh hưởng đến khách hàng. Dashboard dành cho lãnh đạo có thể tóm tắt thông lượng, thời gian tồn đọng và rủi ro. Các góc nhìn này nên dựa trên dữ liệu issue nhất quán. Tránh tạo nhiều bảng gần như trùng lặp nếu chỉ cần một vài góc nhìn được xác định rõ là đủ để hỗ trợ quyết định của từng nhóm đối tượng.

Kiểm tra dữ liệu thường xuyên, nhưng đừng tối ưu chỉ để biểu đồ trông đẹp mắt. Theo dõi thời gian chu kỳ từ lúc bắt đầu xử lý đến khi chuyển sang Done, thời gian chờ ở bước review hoặc phê duyệt, thông lượng trong các giai đoạn có thể so sánh, thời gian tồn tại của các mục chưa được xử lý và tần suất công việc bị mở lại. Số issue hoàn tất tăng lên vẫn có thể che giấu trải nghiệm khách hàng đang xấu đi nếu các mục nhỏ hơn, số lỗi tăng hoặc công việc tồn đọng lâu vẫn bị chặn.

Sau vài chu kỳ bàn giao, hãy rà soát workflow. Tìm hiểu những trạng thái nào thường bị hiểu nhầm, cột nào đang tích tụ công việc, giới hạn WIP có được tuân thủ không và bộ lọc có bao gồm những công việc thực sự tiêu tốn năng lực hay không. Nếu có thể, mỗi lần chỉ thay đổi một hoặc hai yếu tố, sau đó so sánh kết quả với giai đoạn trước. Cách làm này tạo thành một vòng lặp cải tiến thiết thực và tránh việc thiết kế lại Jira chỉ dựa trên một tuần bất thường.

Sai lầm thường gặp và quyết định thực tiễn

Sai lầm thường gặp nhất là thiết kế workflow theo các phòng ban trong tổ chức. Một chuỗi như Sản phẩm, Thiết kế, Kỹ thuật và Vận hành có thể mô tả những ai tham gia xử lý một issue, nhưng không nhất thiết cho biết công việc đã sẵn sàng, đang được thực hiện, bị chặn hay đã hoàn tất. Nếu nhiều phòng ban cùng làm một mục vào một thời điểm, các trạng thái dựa trên phòng ban cũng có thể khuyến khích việc bàn giao thay vì cộng tác.

Một sai lầm khác là xem mọi bước phê duyệt như một giai đoạn cố định. Phê duyệt nên có trạng thái riêng khi tạo thành một hàng đợi có thể đo lường, có chủ sở hữu riêng biệt hoặc quyết định liệu công việc có thể tiếp tục hay không. Nếu việc phê duyệt diễn ra ngay lập tức và được xử lý trong cùng một hoạt động, thêm trạng thái có thể làm tăng công việc hành chính mà không cải thiện khả năng quan sát. Hãy đưa ra quyết định dựa trên độ trễ và rủi ro thực tế, thay vì mong muốn có một sơ đồ chi tiết hơn.

Các nhóm cũng có thể gặp vấn đề khi cho phép quá nhiều mục chuyển sang In Progress. Kết quả là bảng đầy những công việc mới hoàn thành một phần, thời gian chu kỳ kéo dài và việc chuyển đổi ngữ cảnh diễn ra thường xuyên. Cách xử lý tốt hơn là hoàn tất mục có giá trị lâu nhất, giải quyết yếu tố đang chặn mục đó hoặc thương lượng lại phạm vi. Bắt đầu một mục khác cần là quyết định có chủ đích, đi kèm sự đánh đổi được thể hiện rõ.

Cuối cùng, đừng nhầm lẫn việc cấu hình Jira với cải tiến quy trình. Một cột mới không thể giải quyết các ưu tiên chưa rõ ràng, tình trạng thiếu người review, tiêu chí nghiệm thu yếu hoặc nhu cầu vượt quá khả năng đáp ứng. Hãy dùng bảng để làm lộ rõ những vấn đề đó, sau đó giao quyết định vận hành cho người phụ trách phù hợp. Một workflow đơn giản mà nhóm tuân thủ nhất quán hữu ích hơn một workflow cầu kỳ nhưng tạo ra dữ liệu thiếu tin cậy.

Tóm tắt

Thiết kế workflow Jira xoay quanh những trạng thái có ý nghĩa trong quy trình bàn giao thực tế của nhóm. Dùng trạng thái cho các quyết định và điều kiện quan trọng, dùng cột để thể hiện luồng công việc trực quan, và dùng bộ lọc để có góc nhìn đáng tin cậy về công việc đang được quản lý. Đặt giới hạn WIP tại những nơi hình thành hàng đợi, sau đó dùng các trường hợp vượt giới hạn để khởi đầu cuộc trao đổi tìm giải pháp thay vì quy trách nhiệm.

Chất lượng thiết kế cần được đánh giá dựa trên giá trị nghiệp vụ. Nhóm có xác định được hành động tốt nhất tiếp theo không? Quản lý có nhìn ra khâu nào đang làm chậm tiến độ bàn giao không? Các bên liên quan có hiểu được điều gì thực sự đã hoàn tất không? Hãy xem xét những câu hỏi này cùng với dữ liệu bàn giao sau vài chu kỳ, rồi đơn giản hóa mọi phần cấu hình không hỗ trợ việc ra quyết định. Mục tiêu là một bảng giúp cải thiện luồng công việc và trách nhiệm giải trình, chứ không phải một workflow chỉ trông có vẻ đầy đủ.