Từ hồi tháng 8 năm , tôi làm việc với một vài nhóm ảo (virtual team) trong một số dự án Agile và tôi thực sự thích mà họ dùng để giữ cho quá trình làm việc trở nên đơn giản và tập trung hơn. Có nhiều loại bảng công việc khác nhau nhưng nhìn chung, chúng đều có nhiều đặc điểm tương tự.
Việc tiếp xúc với nhiều dạng sản phẩm khiến tôi nghĩ đến việc quản lý các dự án ảo/dự án từ xa sao cho hiệu quả khi không có sự hỗ trợ của các loại công cụ này. Nếu bạn chưa quen thuộc với cách sử dụng STB, dưới đây sẽ là bản tóm tắt ngắn gọn về cách thức hoạt động và những gì STB cho phép bạn làm.
Các STB thường trông như thế nào?
Tuỳ loại sản phẩm/công cụ, các STB có thể hơi khác nhau một chút nhưng chúng đều có những đặc điểm tương đồng. Một số công cụ cho phép chúng ta xác định các gói công việc lớn với thời lượng dài (epic) rồi chia thành các công việc (task)/nhiệm vụ (assignments), mà sau này được thực hiện trong các Sprint. Hầu hết các STB bằng phần mềm đều hỗ trợ các giao diện đồ họa được thiết kế đẹp mắt và dễ sử dụng.
Đặc điểm điển hình của STB
- STB được trình bày theo cột với mỗi giai đoạn của Sprint được đặt trong một cột riêng
- Các cột trong STB thường bao gồm:
- Backlog
- Analysis/Design (Phân tích)
- Development (Phát triển)
- Testing (Kiểm thử)
- User Acceptance Testing (Kiểm tra chấp nhận người dùng)
- Deployment (Triển khai)
- Review/Assessment (Đánh giá)
• Mỗi một công việc/nhiệm vụ (user story/task) đều được hiển thị công khai và toàn bộ thành viên có thể mở, chỉnh sửa, kết nối với các thông tin chi tiết.
• Các thành viên có thể kéo các công việc/nhiệm vụ (user story/task) qua lại giữa các cột và phần mềm sẽ tự động điều chỉnh các giai đoạn tương ứng của công việc.
Quá trình hoạt động STB điển hình
- Các yêu cầu mới được xác định và thêm vào cột backlog của STB
- Trong suốt quá trình lên kế hoạch cho sprint (spint planning), nhóm (bao gồm giám đốc dự án – PM, người dùng – users, chuyên viên phân tích nghiệp vụ – BA, lập trình viên – developers, …) sẽ xem lại backlog và xác định những hạng mục (item) nào được đưa vào trong những sprint tiếp theo. Việc này thường dựa trên mức độ khẩn cấp của yêu cầu cũng như nguồn lực của nhóm lúc đó.
- Sau khi lựa chọn các yêu cầu (story) cần làm, chúng ta sẽ xem xét và sắp xếp thứ tự ưu tiên của chúng, đồng thời xác định các yêu cầu ban đầu với mức độ phức tạp và nguồn lực ước tính.
- Các yêu cầu (story) này sau đó được chuyển thành công việc (task) và giao cho các thành viên trong nhóm thực hiện.
- Dựa trên cơ sở hợp tác đối thoại, nhóm sẽ hoàn thành các yêu cầu trong sprint và đẩy các hạng mục không được thực hiện trở lại backlog hoặc thêm vào sprint kế tiếp.
- Các cuộc họp daily standup được thực hiện hàng ngày để xem xét tiến độ, xác định các vấn đề, điều chỉnh công việc và để đạt được các cam kết.
- Các nhiệm vụ được chuyển từ giai đoạn này sang giai đoạn tiếp theo trên STB khi từng phần của nhiệm vụ được hoàn thành (phân tích, phát triển, chứng minh, thử nghiệm, kiểm tra người dùng, triển khai).
- Khi tất cả các nhiệm vụ được chuyển đến giai đoạn kiểm tra người dùng, việc triển khai sẽ được lên lịch và hoàn thành.
- Toàn bộ nhóm sẽ họp để đánh giá lại kết quả công việc đã triển khai và thiết lập quy trình lặp lại cho sprint tiếp theo.
Thông thường, các sprint được giới hạn thời gian để hoàn thành công việc từ hai đến bốn tuần, điều này tạo nên sự độc đáo cho mô hình triển khai/cải tiến liên tục này.
Điều làm cho các STB bằng phần mềm trở nên tuyệt vời là chúng trở thành tâm điểm trong các phiên làm việc, cho phép mọi người thảo luận cởi mở về dữ liệu, các tài liệu được chia sẻ,… trong thời gian thực bằng các công cụ họp/hội nghị như Teams và Skype. Việc tương tác trên bảng hấp dẫn hơn nhiều so với làm việc thông qua các kế hoạch hoặc lịch trình như khi quản lý dự án theo cách truyền thống.
Tuy nhiên, các bảng STB thích hợp cho các sprints có khoảng 12 thay vì hơn 30 nhiệm vụ/công việc (vì lúc đó, chúng sẽ trở nên khó sử dụng để điều hướng).
Trong trường hợp một sprint có quá nhiều nhiệm vụ, chúng ta có thể chia nó thành nhiều sprint với phạm vi nhỏ hơn. Điều này sẽ cải thiện tốc độ cải tiến và triển khai công việc liên tục.
Một hạn chế khác của các STB là chúng không cung cấp khả năng quản lý tài nguyên mạnh mẽ cho các dự án và sprint. Một cách lý tưởng, một người được giao cho một sprint sẽ chỉ làm việc trong sprint đó và không cố gắng làm đồng thời các công việc của dự án hoặc sprint khác. Do vậy, khi thực hiện nhiệm vụ, người được giao việc có khả năng thực hiện nhiệm vụ trong thời hạn cho phép.
Cách tạo STB khi bạn chỉ có các công cụ dạng bảng tính đơn giản
Chắc chắn có rất nhiều các công cụ hỗ trợ tuyệt vời trên Internet, tất cả đều có nhiều tính năng thú vị với các mức chi phí khác nhau. Nhưng nếu bạn không có quyền truy cập các công cụ này thì sao? Làm cách nào bạn có thể ứng biến bằng cách sử dụng các công cụ Office truyền thống để tạo một STB cho riêng mình? Liệu bạn có thể sử dụng bảng tính để tạo STB của mình không?
Sau khi suy nghĩ, tôi tin rằng câu trả lời là có – trong giới hạn. Để minh chứng, tôi đã thử làm dựa trên mẫu Excel và dưới đây là ảnh chụp nhanh mẫu cơ bản:
Bảng này bao gồm phần tiêu đề, cột để phân chia các thành viên trong sprint và sau đó là cột để quản lý các nhiệm vụ trong sprint.
Đây là dạng xem mở rộng của hộp nhiệm vụ (task box):
Ban đầu, STB có tất cả các nhiệm vụ trong cột “Backlog”. Khi các nhiệm vụ được thực hiện, hộp nhiệm vụ được chuyển đến cột “Đang tiến hành – In Progress”, sau đó được chuyển đến các cột tiếp theo và được mã hóa theo đúng màu khi nhiệm vụ tiến đến từng giai đoạn hoàn thành.
Các thành phần trong STB minh hoạ này bao gồm các thành phần và quy tắc sau:
- Mỗi cột được mã hóa theo màu sắc để dễ xem/nhìn (giống như trong Kanban)
- Mỗi yêu cầu/nhiệm vụ bao gồm:
- Mã yêu cầu (Story ID)
- Mã nhiệm vụ (Task ID)
- Ngày đến hạn
- Mức độ nỗ lực
- Mô tả yêu cầu/nhiệm vụ
- Công việc cần làm để hoàn thành giai đoạn
- Tình trạng hiện tại
- Khi cần thêm không gian trong phần “Mô tả” và/hoặc “Việc còn lại cần làm”, ta có thể thêm dữ liệu qua tệp Excel, PowerPoint và/hoặc Word và liên kết chúng với mã yêu cầu/nhiệm vụ.
- Sử dụng các tab để lưu lịch sử chạy sprint hoặc cho các dữ liệu hỗ trợ khác.
- Sử dụng các bộ lọc để nhắm mục tiêu dữ liệu, chẳng hạn như “Đã giao cho” hoặc “Tình trạng giai đoạn”.
Dưới đây là một ví dụ đơn giản về STB phản ánh các nhiệm vụ ở các giai đoạn hoàn thành khác nhau:
Mục đích của ví dụ trên là để chỉ ra cách xem sơ lược một STB để biết tiến độ của một sprint.
Rõ ràng, mẫu minh hoạ ở trên không sinh động như các công cụ JIRA, Azure Boards, Trello, Asana, Airtable, Monday.com, Bitrix24, Zoho,... Đó là một số công cụ STB được sử dụng miễn phí, bạn có thể dùng thử (chỉ để hiểu rõ hơn cách chúng hoạt động thôi). Ngay cả MS Project hiện nay cũng hỗ trợ các mô hình sprint.
Nhưng nếu bạn không truy cập được các công cụ STB, bạn có thể lấy mẫu minh hoạ này để thử cải tiến nó lên hoặc tạo ra một STB của riêng bạn. Nếu bạn chọn cách tự làm, hãy nhớ làm nó thật đơn giản và dễ dàng để duy trì. Việc sử dụng các liên kết để kết nối các nhiệm vụ với tài liệu và tạo tác (artifact) hỗ trợ cũng rất dễ thực hiện và sử dụng khả năng để đi sâu vào biểu đồ SBT.
Ngoài ra, hãy cân nhắc việc sử dụng STB theo các cấp bậc, trong đó, cấp trên cùng là danh mục các dự án, tiếp theo là khu vực dành cho dòng thời gian của sprint và cuối cùng là các sprint cụ thể (cấp độ yêu cầu/nhiệm vụ). Kết hợp điều hướng các liên kết từ danh mục tới sprint khá đơn giản – và thậm chí là tạo ra chút đột phá ấn tượng trong việc quản lý. Về cơ bản, hãy thử nghiệm và nắm bắt những bài học đến từ việc thử và mắc lỗi.
Bây giờ bạn đã có STB, kể cả bản có sẵn hay là bản tự làm. Dù là bản nào, tôi tin rằng bạn sẽ thấy chúng hoàn hảo trong việc quản lý các dự án với các nhóm ảo (virtual team) (nó chắc chắn đánh bại các tờ giấy ghi chú dán trên tường đấy). Tôi hy vọng bạn sẽ có những trải nghiệm tuyệt vời và ấn tượng.
Bạn sử dụng công cụ quản lý dự án nào? Cái nào bạn thích nhất? Bạn sẽ thay đổi (cải thiện) điều gì từ mẫu được cung cấp? Tôi rất mong chờ sự quan sát, ý tưởng và cả nhận xét của bạn. Hãy bình luận cho tôi biết.
Tác giả bài viết: Michael R. Wood là nhà tư vấn độc lập về Chiến lược Công nghệ Thông tin & Cải tiến Quy trình Kinh doanh. Ông là người sáng tạo ra phương pháp cải tiến quy trình kinh doanh được gọi là HELIX và là người sáng lập The Natural Intelligence Group – một công ty tư vấn chiến lược, cải tiến quy trình và công nghệ. Ông cũng là một CPA, đã từng là Giáo sư Trợ giảng trong chương trình Quản trị Kinh doanh của Pepperdine, Phó Giáo sư tại Đại học California Lutheran, và là thành viên hội đồng quản trị của nhiều tổ chức nghề nghiệp. Ông cũng là người dẫn chương trình được săn đón tại các hội thảo HELIX ở cả Hoa Kỳ và Châu Âu.
Nguồn: Write Your Own Story(board): How to Keep Remote PM Processes on Point
Lược dịch: Bích Phạm -Masterskills
Quản lý dự án kết hợp: Sự lựa chọn tự nhiên
Từ Data Analyst lên Project Manager, bạn cần gì?
Góc nhìn PMI: Nhu cầu về năng lực chiến lược để đảm bảo triển khai dự án thành công
