Skip to content
Nhiều người vẫn tin rằng hoàn thành dự án đúng hạn, đúng ngân sách và đủ phạm vi là bằng chứng của thành công, trong khi thực tế có những dự án giao hàng đúng từng cột mốc nhưng doanh nghiệp không hề thu được giá trị kinh doanh như kỳ vọng.
Khi nào nên ưu tiên độ ổn định – 0210
Để trả lời cho câu hỏi làm thế nào để tạo ra kết quả nhanh hơn và tốt hơn, trước hết cần nhìn nhận trực diện vào bản chất của dòng công việc trong thực thi dự án. Câu trả lời nằm ở việc tối đa hóa tốc độ di chuyển của giá trị qua hệ thống thay vì tối đa hóa công suất làm việc của từng cá nhân hay từng phòng ban riêng lẻ. Khi dòng chảy công việc bị nghẽn ở một khâu, việc đẩy nhanh tốc độ ở các khâu khác chỉ làm tích tụ thêm hàng đợi, tốn thêm chi phí lưu kho trung gian và làm chậm trễ thời điểm thương mại hóa sản phẩm.
Hiện trường của một quản lý giao hàng và quản lý xuất sắc vận hành thường xoay quanh những áp lực chồng chất về thời gian và nguồn lực. Trong một dự án tổng hợp về phát triển nền tảng dịch vụ số cho khách hàng doanh nghiệp, đội ngũ triển khai đang bị kẹt giữa yêu cầu rút ngắn thời gian bàn giao xuống một nửa và áp lực phải kiểm soát chặt chẽ ngân sách. Trưởng nhóm phát triển phần mềm báo cáo công suất hoạt động đạt một trăm phần trăm, nhân sự làm việc quá giờ liên tục, các bảng theo dõi công việc trên công cụ trực tuyến luôn trong trạng thái kín đặc thẻ nhiệm vụ. Tuy nhiên, thời gian từ khi một ý tưởng tính năng được đưa vào nghiên cứu cho đến khi được đưa lên môi trường thử nghiệm thực tế lại kéo dài ba mươi ngày, trong đó có tới hai mươi lăm ngày nằm chờ ở các hàng đợi phê duyệt, kiểm thử bảo mật và kiểm tra chất lượng thủ công. Áp lực tiến độ đè nặng lên vai những người thực hiện trực tiếp, trong khi các bên liên quan ở tầng quản lý cấp cao liên tục yêu cầu bổ sung thêm tính năng mới mà không chịu cắt giảm các yêu cầu cũ.
Sai lầm phổ biến hình thành từ tư duy tối ưu từng bộ phận thay vì toàn hệ thống. Tư duy này xuất phát từ cách quản trị truyền thống, nơi người quản lý đo lường hiệu suất bằng khối lượng công việc hoàn thành của từng cá nhân hoặc từng phòng ban thay vì đo lường tốc độ tạo ra giá trị cho toàn bộ chuỗi cung ứng sản phẩm. Khi phòng kỹ thuật đạt năng suất cao bằng cách liên tục viết mã nguồn mới mà không quan tâm đến khả năng tiếp nhận của phòng kiểm thử, họ đang tối ưu hóa cục bộ. Sai lầm này rất hợp lý vào lúc mới bắt đầu triển khai, bởi vì nó dễ đo lường, dễ giao chỉ tiêu và tạo ra cảm giác an toàn giả tạo rằng mọi người đều đang làm việc hết công suất. Người quản lý trực tiếp được khen thưởng vì giữ cho nhân viên của mình luôn bận rộn, các phòng ban đều đạt chỉ số hoàn thành nhiệm vụ trên giấy tờ. Nhưng cái giá phải trả theo chuỗi là cực kỳ lớn: mã nguồn tồn đọng không được kiểm thử kịp thời trở nên lỗi thời, lỗi hệ thống tích tụ ở giai đoạn cuối, thời gian đưa sản phẩm ra thị trường bị kéo dài, và chi phí sửa lỗi tăng theo cấp số nhân khi phát hiện muộn.
Để mổ xẻ vấn đề này dưới góc độ hiệu suất, cần áp dụng lý thuyết về giới hạn hệ thống kết hợp với các nguyên tắc dòng chảy công việc. Trong bất kỳ hệ thống sản xuất hay triển khai dự án nào, tốc độ của toàn bộ hệ thống bị chi phối hoàn toàn bởi điểm nghẽn duy nhất có năng lực thấp nhất. Mọi nỗ lực tăng tốc ở các khâu không phải là điểm nghẽn đều là lãng phí tài nguyên và làm trầm trọng thêm tình trạng tắc nghẽn.
Dưới đây là một mô hình tính toán minh họa cho thấy tác động của việc tối ưu cục bộ so với tối ưu toàn hệ thống (minh họa). Giả sử một quy trình phát triển sản phẩm gồm ba bước liên tiếp: phân tích yêu cầu, lập trình, và kiểm thử. Bước phân tích có năng lực xử lý mười đơn vị công việc mỗi ngày. Bước lập trình có năng lực xử lý mười lăm đơn vị công việc mỗi ngày. Bước kiểm thử có năng lực xử lý năm đơn vị công việc mỗi ngày.
Khi bộ phận lập trình cố gắng tối ưu hóa hiệu suất cá nhân bằng cách chạy hết công suất mười lăm đơn vị mỗi ngày, kết quả là bước kiểm thử chỉ nhận và xử lý được năm đơn vị. Mười đơn vị công việc còn lại bị ùn tắc thành hàng đợi trước cửa phòng kiểm thử, chiếm dụng bộ nhớ, làm mất giá trị thông tin và tiêu tốn chi phí duy trì trạng thái chờ. Tốc độ thực tế của toàn hệ thống vẫn bị kẹt ở mức năm đơn vị mỗi ngày, bị giới hạn hoàn toàn bởi điểm nghẽn ở khâu kiểm thử. Nếu áp dụng tư duy cải tiến liên tục để loại bỏ lãng phí, người quản lý phải dừng việc đẩy nhanh tốc độ ở khâu lập trình, chuyển nguồn lực dư thừa sang hỗ trợ khâu kiểm thử hoặc tự động hóa quy trình kiểm tra chất lượng, nâng năng lực của điểm nghẽn này lên bằng hoặc vượt mức mười đơn vị, từ đó trực tiếp tăng gấp đôi tốc độ dòng chảy của toàn hệ thống mà không cần tuyển thêm nhân sự.
Hệ quả hệ thống của việc sai lầm trong tối ưu hóa lan rộng từ cấp độ dự án lên cấp độ chương trình và danh mục đầu tư. Sai lầm này thường chỉ lộ ra sau ba đến sáu tháng triển khai, khi các sản phẩm cuối cùng không thể ra mắt đúng hạn và ngân sách cạn kiệt do chi phí sửa đổi phát sinh. Dấu hiệu sớm có thể nhận biết từ rất lâu trước khi dự án thất bại: số lượng công việc đang dang dở trên hệ thống tăng đột biến, thời gian chờ đợi giữa các bước phê duyệt dài hơn thời gian thực hiện công việc thực tế, nhân sự phàn nàn về việc bị quá tải nhưng các chỉ số báo cáo tiến độ hàng tuần vẫn hiển thị màu xanh. Khi các dự án riêng lẻ bị nghẽn dòng công việc, toàn bộ danh mục đầu tư dự án bị đình trệ, vốn bị giam giữ trong các hạng mục chưa thể thương mại hóa, làm suy giảm năng lực cạnh tranh chiến lược của toàn doanh nghiệp.
Để giải quyết triệt để bài toán tạo ra kết quả nhanh hơn và tốt hơn, việc ra quyết định phải tuân theo khung nguyên tắc rõ ràng, gắn liền với các điều kiện và ngưỡng cụ thể.
Bảng 1: Bảng quyết định tối ưu hóa dòng công việc và phân bổ nguồn lực (minh họa)
– Điều kiện: Tỷ lệ công việc đang dang dở vượt quá một trăm phần trăm định mức cho phép của điểm nghẽn.
– Lựa chọn: Tạm dừng nhận yêu cầu mới, dồn toàn bộ nguồn lực giải phóng hàng đợi tại điểm nghẽn.
– Ngưỡng kích hoạt: Thời gian chờ tại một bước trong quy trình vượt quá năm ngày làm việc.
– Người chịu đánh đổi: Giám đốc bộ phận chức năng phải chấp nhận hoãn tiến độ giao việc mới của phòng mình.
– Điều kiện: Tốc độ kiểm thử hệ thống đạt yêu cầu nhưng tỷ lệ lỗi phát hiện sau khi bàn giao vượt ba phần trăm.
– Lựa chọn: Chuyển đổi từ kiểm thử thủ công sang kiểm thử tự động một phần, siết chặt tiêu chí nghiệm thu đầu vào.
– Ngưỡng kích hoạt: Chi phí sửa lỗi trong giai đoạn vận hành vượt mười phần trăm ngân sách phát triển.
– Người chịu đánh đổi: Trưởng nhóm phát triển phần mềm phải giảm tốc độ viết mã nguồn mới để viết mã kiểm thử.
– Điều kiện: Nguồn lực tổng thể của danh mục đầu tư bị phân tán quá mười dự án song song với năng lực hiện tại.
– Lựa chọn: Tạm dừng hoặc hủy bỏ các dự án có mức ưu tiên thấp nhất, tập trung vốn cho ba dự án trọng điểm.
– Ngưỡng kích hoạt: Tỷ lệ sử dụng nhân sự chủ chốt vượt một trăm hai mươi phần trăm liên tục trong hai tháng.
– Người chịu đánh đổi: Người bảo trợ dự án của các dự án bị dừng sẽ mất quyền phân bổ ngân sách trong kỳ.
Bảng này giúp người quản lý quyết định chính xác thời điểm nào cần can thiệp dừng việc nhận thêm công việc mới để giải quyết điểm nghẽn thay vì tiếp tục bơm thêm nguồn lực vào những khâu không cần thiết.
Trong quá trình triển khai, những người bảo trợ dự án thường sẽ phản đối kịch liệt việc tạm dừng dự án hoặc cắt giảm phạm vi vì họ sợ mất uy tín với ban điều hành cấp cao. Lý lẽ của họ dựa trên cam kết ban đầu về danh mục tính năng đã được phê duyệt trong kế hoạch vốn. Tuy nhiên, lập luận này dựa trên giả định sai lầm rằng mọi tính năng đều có giá trị ngang nhau và việc giao hàng chậm nhưng đủ tính năng tốt hơn là giao hàng nhanh với giá trị cốt lõi. Giới hạn của cách tiếp cận này lộ rõ khi thị trường đã thay đổi và các tính năng được làm ra không còn đáp ứng đúng nhu cầu thực tế của người dùng cuối.
Để duy trì hiệu suất vượt trội trong suốt vòng đời dự án, cần áp dụng một công cụ quản lý trực quan và có tính ứng dụng cao. Mẫu sản phẩm dưới đây cung cấp một khung làm việc chuẩn xác để đo lường và tối ưu hóa năng suất dòng công việc (minh họa).
Mẫu sản phẩm: Bảng kiểm soát dòng chảy công việc và hiệu suất thực thi (minh họa)
– Tên dòng công việc hoặc dự án: [Ghi rõ tên hạng mục đang phân tích]
– Cột 1 – Tên bước công việc trong quy trình: [Phân tích yêu cầu] | [Lập trình] | [Kiểm thử] | [Triển khai]
– Cột 2 – Số lượng công việc đang dang dở thực tế: [Nhập số liệu, ví dụ: 25] | [Nhập số liệu, ví dụ: 40] | [Nhập số liệu, ví dụ: 12] | [Nhập số liệu, ví dụ: 5]
– Cột 3 – Năng lực xử lý tối đa mỗi ngày: [Nhập số liệu, ví dụ: 10] | [Nhập số liệu, ví dụ: 15] | [Nhập số liệu, ví dụ: 5] | [Nhập số liệu, ví dụ: 20]
– Cột 4 – Thời gian chờ trung bình của một đơn vị: [Tính toán, ví dụ: 2.5 ngày] | [Tính toán, ví dụ: 2.6 ngày] | [Tính toán, ví dụ: 2.4 ngày] | [Tính toán, ví dụ: 0.25 ngày]
– Cột 5 – Trạng thái điểm nghẽn hệ thống: [Bình thường] | [Quá tải cấp độ 1] | [Điểm nghẽn nghiêm trọng] | [Bình thường]
Cách điền và cách đọc mẫu sản phẩm này đòi hỏi người quản lý phải cập nhật số liệu thực tế hàng tuần thay vì đợi đến kỳ họp báo cáo tháng. Cột hai và cột ba được so sánh trực tiếp với nhau để phát hiện ngay lập tức khâu nào đang có lượng công việc dang dở vượt quá năng lực xử lý. Bước nào có tỷ lệ giữa lượng công việc dang dở và năng lực xử lý cao nhất chính là điểm nghẽn cốt lõi của toàn hệ thống. Người đọc chỉ cần nhìn vào cột năm để biết chính xác nguồn lực cần được điều chuyển ngay lập tức về đâu, thay vì dựa vào cảm tính hoặc yêu cầu phàn nàn từ các trưởng bộ phận.
Bảng 2: Bảng dấu hiệu sớm và rủi ro trong quản lý dòng công việc (minh họa)
– Dấu hiệu: Tỷ lệ công việc bị trả lại từ khâu kiểm thử về khâu lập trình vượt hai mươi phần trăm tổng số lượng bàn giao.
– Cơ chế: Tiêu chí kỹ thuật ban đầu không rõ ràng, lập trình viên vội vã hoàn thành chỉ tiêu số lượng mà bỏ qua chất lượng mã nguồn.
– Hậu quả nếu bỏ qua: Lỗi hệ thống tích tụ trầm trọng, chi phí sửa chữa tăng vọt, thời gian đưa sản phẩm ra thị trường chậm trễ nhiều tháng.
– Phản ứng: Thiết lập ngay quy định bắt buộc kiểm tra mã nguồn chéo trước khi chuyển giao, tạm dừng nhận tính năng mới cho đến khi tỷ lệ lỗi giảm dưới năm phần trăm.
– Dấu hiệu: Thời gian họp điều phối tiến độ kéo dài hơn hai giờ nhưng không đưa ra được quyết định xử lý vướng mắc kỹ thuật nào.
– Cơ chế: Thiếu sự phân quyền rõ ràng, người tham gia họp không có thẩm quyền quyết định ngân sách hoặc thay đổi phạm vi công việc.
– Hậu quả nếu bỏ qua: Mất niềm tin giữa các bên liên quan, đội ngũ thực hiện mệt mỏi, các quyết định quan trọng bị trì hoãn vô thời hạn.
– Phản ứng: Thu hẹp thành phần tham gia họp, chỉ giữ lại những người có quyền quyết định trực tiếp, áp dụng giới hạn thời gian phát biểu cho từng vấn đề.
– Dấu hiệu: Ngân sách dự phòng của dự án đã cạn kiệt năm mươi phần trăm trong khi mới hoàn thành chưa tới ba mươi phần trăm khối lượng công việc.
– Cơ chế: Ước tính chi phí ban đầu quá lạc quan, phạm vi công việc bị mở rộng ngầm qua các yêu cầu nhỏ không đi kèm kiểm soát thay đổi.
– Hậu quả nếu bỏ qua: Dự án rơi vào tình trạng cạn kiệt vốn trước khi bàn giao sản phẩm, buộc phải đình chỉ hoặc xin cấp thêm vốn bổ sung thủ tục phức tạp.
– Phản ứng: Kích hoạt quy trình kiểm toán độc lập, đóng băng ngay lập tức các hạng mục chưa thực sự cốt lõi, đàm phán lại phạm vi với nhà tài trợ vốn.
Bảng này giúp người quản lý định hình rõ các phản ứng cần thiết khi xuất hiện những dấu hiệu rủi ro đầu tiên, ngăn chặn việc xử lý chậm trễ dẫn đến hậu quả hệ thống.
Tình huống nghiên cứu tổng hợp thứ nhất minh họa cho việc làm sai quy trình và hậu quả tất yếu. Trong một dự án chuyển đổi quy trình nghiệp vụ nội bộ, đội ngũ quản lý quyết định tăng tốc độ bằng cách giao KPI hoàn thành số lượng tài liệu thiết kế cực lớn cho từng cá nhân lập trình viên. Để đạt chỉ tiêu, mỗi người tự viết thiết kế theo cách hiểu riêng mà không thông qua buổi họp thống nhất kiến trúc tổng thể. Kết quả là khi các bộ phận ráp nối lại với nhau vào giai đoạn cuối, các module hệ thống hoàn toàn không tương thích. Lượng công việc dang dở ùn tắc ở mức cao chưa từng thấy, thời gian sửa lỗi kéo dài gấp ba lần thời gian viết mới, ngân sách dự án vượt mức cho phép và người bảo trợ buộc phải cắt giảm một nửa tính năng cốt lõi để giữ lại phần khung cơ bản. Tư duy tối ưu hóa từng cá nhân thay vì dòng chảy tổng thể đã phá hủy toàn bộ giá trị kinh doanh dự định ban đầu.
Tình huống nghiên cứu tổng hợp thứ hai minh họa cho việc làm đúng nhưng phải trả giá trước mắt. Trong một dự án phát triển sản phẩm công nghệ tài chính, người quản lý quyết định áp dụng nghiêm ngặt nguyên tắc giới hạn công việc dang dở, chỉ cho phép tối đa ba tính năng được phát triển song song tại một thời điểm. Ngay tuần đầu tiên áp dụng, các lập trình viên phàn nàn vì họ có những khoảng thời gian rảnh rỗi chờ đợi kết quả kiểm thử từ khâu trước đó, các chỉ số đo lường hiệu suất cá nhân trên hệ thống giảm sút rõ rệt, và các trưởng bộ phận chức năng khiếu nại rằng đội ngũ của họ không được tận dụng hết công suất tối đa. Tuy nhiên, người quản lý kiên quyết bảo vệ quyết định này, hướng dẫn nhân sự dùng thời gian rảnh để tự động hóa quy trình kiểm tra và tối ưu hóa mã nguồn cũ. Chỉ sau ba tuần, thời gian hoàn thành một tính năng từ ý tưởng đến thực tế giảm xuống còn một phần ba, không có lỗi nghiêm trọng phát sinh khi đưa lên hệ thống thật, và sản phẩm được thương mại hóa sớm hơn hai tháng so với kế hoạch ban đầu, mang lại lợi thế cạnh tranh lớn trên thị trường. Cái giá phải trả ban đầu là sự bất mãn tạm thời và áp lực tâm lý từ các chỉ số năng suất cá nhân suy giảm đã được bù đắp hoàn toàn bởi hiệu suất vượt trội của toàn hệ thống.
Kết quả nhanh hơn và tốt hơn chỉ có thể đạt được khi toàn bộ hệ thống từ bỏ ảo tưởng về việc ép mọi cá nhân phải bận rộn một trăm phần trăm thời gian, thay vào đó tập trung toàn lực vào việc khơi thông dòng chảy công việc, kiểm soát nghiêm ngặt các điểm nghẽn và sẵn sàng đánh đổi hiệu suất cục bộ để lấy tốc độ giao nộp giá trị thực tế cho doanh nghiệp. Điều kiện đảo chiều của nguyên lý này nằm ở cấu trúc hợp đồng và ràng buộc pháp lý: nếu hợp đồng ràng buộc chặt chẽ theo từng mốc sản phẩm chi tiết với chế tài phạt nặng cho từng hạng mục nhỏ, việc áp dụng dòng chảy liên tục sẽ gặp rào cản pháp lý lớn, đòi hỏi phải đàm phán lại cơ chế nghiệm thu dựa trên giá trị gia tăng tổng thể thay vì khối lượng công việc rời rạc.
Các việc cần làm phân theo vai trò trong dự án:
– Người bảo trợ dự án: Phê duyệt giới hạn công việc dang dở cho toàn bộ danh mục, chấp nhận hoãn các yêu cầu phát sinh ngoài phạm vi để bảo vệ điểm nghẽn hệ thống.
– Quản lý giao hàng: Theo dõi sát sao thời gian chờ tại các điểm nghẽn hàng tuần, chủ động điều phối nguồn lực hỗ trợ khâu có năng lực thấp nhất.
– Chủ sở hữu sản phẩm: Sắp xếp lại thứ tự ưu tiên của danh sách tính năng dựa trên giá trị thực tế mang lại cho người dùng, kiên quyết cắt bỏ các yêu cầu kém hiệu quả.
– Đội ngũ thực hiện: Dừng ngay việc nhận nhiệm vụ mới khi chưa hoàn thành nhiệm vụ đang dang dở, chủ động tham gia cải tiến tự động hóa quy trình.
Câu hỏi tự kiểm tra năng lực thực thi:
– Hệ thống hiện tại của bạn đang bị tắc nghẽn ở khâu nào, và làm thế nào để chứng minh rằng đó là điểm nghẽn quyết định tốc độ của toàn bộ dự án?
– Bạn sẵn sàng cắt giảm bao nhiêu phần trăm số lượng công việc đang dang dở trên hệ thống để đổi lấy việc rút ngắn thời gian bàn giao sản phẩm xuống một nửa?
– Khi các bên liên quan yêu cầu bổ sung tính năng mới trong lúc hệ thống đang quá tải, bạn dùng số liệu nào từ dòng công việc để từ chối mà không làm ảnh hưởng đến quan hệ hợp tác?
– Việc tối ưu hóa hiệu suất làm việc của từng cá nhân trong đội ngũ của bạn đang vô tình tạo ra những loại lãng phí nào ở các khâu tiếp theo trong quy trình?
#QuanLyDuAn #ToiUuHeThong #DinhHuongGiaTri #QuanTriVanHanh #ReboostLab
