Cả tuần nay tôi cứ nghĩ về việc thử nghiệm Improvement Kata trong bối cảnh doanh nghiệp.
Từ khi chuyển sang làm công tác tư vấn huấn luyện, tôi vẫn thường xuyên nhìn thấy các bất cập:
- Các vấn đề thể hiện ra thường khá đa dạng, giải quyết mãi vẫn nhiều
- Các vấn đề nhìn chung khá cơ bản, hay lặp lại
- Các vấn đề chỉ được fix khi đã phát sinh, dù cảnh báo trước đó không ít lần
Tôi vẫn hỏi, liệu có phương pháp nào khắc phục được mà đủ hiệu quả, dễ nhân rộng?
Liệu Scientific thinking (kết hợp với PDCA, Continuous Improvement) có phải là lời giải hợp lý?
Sách của Mike Rother nói kỹ về Improvement Kata, nhưng chủ yếu trong bối cảnh sản xuất. Tôi chưa tìm được các ví dụ cụ thể trong bối cảnh của các doanh nghiệp dịch vụ, nên tạm tưởng tượng. Sẽ tiếp tục tìm kiếm.
(Bạn cần đọc bài viết MTMB #10: Scientific thinking để nắm bắt về bối cảnh, nếu chưa từng đọc)
Thử nghiệm Improvement Kata
Mike Rother bảo, mô hình tốt thôi chưa đủ, cần có cách thức rèn luyện cụ thể. Thông qua các việc làm cụ thể có chủ đích, thực hiện hàng ngày thì mới thay đổi được hành vi và cải thiện được tư duy khoa học. Cần đâu đó khoảng 2 tháng, và có một người coach. Đẹp nhất chính là người quản lý, vì có cơ hội gặp mặt thường xuyên và hiểu bối cảnh công việc.
Trong bối cảnh một công ty IT Outsourcing, tôi tưởng tượng có thể Improvement Kata trong việc rèn luyện kỹ năng suy nghĩ về các câu hỏi căn bản. Hình thành thói quen đó sẽ giúp nhân sự quen với việc tư duy những điều quan trọng, năng lực được nâng cao thường xuyên. Nhờ đó họ sẽ dần tự tìm ra lời giải cho các vấn đề của mình.
Tôi hình dung về cách triển khai cho 2 vị trí cơ bản: PM và Dev.
Dành cho PM
PM (Project manager) chịu trách nhiệm cuối cùng cho việc hoàn thành dự án, đạt các yêu cầu đề ra. Tuy vậy, không ít bạn PM chỉ chú tâm đến hoàn thành các đầu việc. Đấy là nguồn cơn của mọi vấn đề, vì phạm vi của dự án trong công ty làm dịch vụ phần mềm rộng hơn rất nhiều.
Các vấn đề dễ gặp
- Không hiểu được bối cảnh và kỳ vọng của khách hàng để có điều chỉnh hoạt động quản lý cho phù hợp. Khách hàng là công ty startup, cần thử nghiệm nhiều và kết quả nhanh, sẽ rất khác so với công ty lớn cần quy trình chặt chẽ.
- Không tư duy quản trị dự án một cách tổng thể, chỉ xử lý khi vấn đề phát sinh. Các vấn đề nối tiếp nhau, và dần cứ thế quay cuồng.
- Nhu cầu của các stakeholder khác (như quản lý cấp trên hoặc member trong dự án) có thể bị bỏ qua
Với các tiếp cận theo Improvement Kata, có thể đặt ra các câu hỏi sau:
- Kỳ vọng của khách hàng với dự án là gì? Và nó quan trọng như thế nào với họ?
- Tình trạng hiện tại đang thế nào?
- Để hướng tới việc đạt kỳ vọng, điều kiện mục tiêu (*) cần đạt trong 2 tuần tới là gì? (Mốc thời gian nên đủ ngắn để có nhịp khẩn trương).
Trở ngại của việc đạt được điều kiện mục tiêu là gì? Đâu là trở ngại cần tập trung giải quyết trong thời gian tới? - Team sẽ thử nghiệm gì tiếp theo? Đến khi nào? Kết quả có thể kỳ vọng là gì?
- (Đến thời điểm dự kiến có kết quả) Độ lệch của kết quả so với kỳ vọng thế nào? Có thể học được gì?
- Lặp lại bước 4,5 cho đến khi hoàn thành điều kiện mục tiêu. Tiếp tục với điều kiện mục tiêu tiếp theo, cho đến khi hoàn thành được kỳ vọng ở bước 1.
Với câu 1, chỉ cần thay thế “khách hàng” bằng “sếp”, “member của dự án” sẽ thêm các điểm cần giải quyết. Tất nhiên mỗi thời điểm cần có sự ưu tiên nhất định.
(*) Ở đây Mike Rother dùng từ “Điều kiện mục tiêu” (target condition), chứ không chỉ là target. Chữ condition ở đây bao hàm ý cả các tính chất khác cần đạt được để dẫn tới target. Chẳng hạn, nếu chỉ có target là giảm số lượng lỗi của giao diện mà không thay đổi bất kỳ cách làm nào thì cũng không tốt.
Ví dụ minh họa ở bên dưới, còn câu chuyện thực tế sẽ phức tạp hơn nhiều.
| 1. Kỳ vọng của khách hàng với dự án là gì? Và nó quan trọng như thế nào với họ? | Khách hàng kỳ vọng năng suất của team phải nhanh hơn hiện tại, đủ đáp ứng các mục tiêu bàn giao. Họ đánh giá tốc độ ra tính năng đang thua kém đối thủ trực tiếp, ảnh hưởng đến khả năng cạnh tranh. Không được tăng nhân sự, do quy mô đang tương đương đối thủ. |
| 2. Tình trạng hiện tại đang thế nào? | Các phần việc hay phải lùi lịch bàn giao, do có sự thay đổi yêu cầu thường xuyên từ phía khách hàng. Kế hoạch ban đầu không tính đến việc đó. Chất lượng của dự án chưa ổn định, vẫn còn gặp các lỗi cơ bản. |
| 3. Để hướng tới việc đạt kỳ vọng, điều kiện mục tiêu cần đạt trong 2 tuần tới là gì? Trở ngại của việc đạt được điều kiện mục tiêu là gì? Đâu là trở ngại cần tập trung giải quyết trong thời gian tới? | Giảm 1/2 tỷ lệ lỗi đang gặp, qua đó nâng cao được 5% năng suất. Dev cần giảm tỷ lệ lỗi tương ứng. Trở ngại: Dev vẫn làm ra nhiều lỗi cơ bản, dù đã được nhắc nhở… => Chỗ này cần có sự phân tích kỹ càng. Trở ngại cần giải quyết: kỹ năng testing của dev chưa đáp ứng được yêu cầu. |
| 4. Team sẽ thử nghiệm gì tiếp theo? Đến khi nào? Kết quả có thể kỳ vọng là gì?(Đến thời điểm dự kiến có kết quả) | Dev sử dụng test case của tester để tự kiểm tra. Kỳ vọng: không để lọt các lỗi căn bản, đang chiếm 1/3 số lượng lỗi.Thời hạn thử nghiệm: 2 ngày |
| 5. Độ lệch của kết quả so với kỳ vọng thế nào? Có thể học được gì? | Số lỗi đơn giản giảm đáng kể, đạt 90% so với kỳ vọng.Vẫn còn một số lỗi sót do test case phức tạp, nên dev hiểu sai.Bài học:Thay đổi quy trình có thể tạo ra kết quả sớmCần nhờ các bạn dev đọc trước test case và phản hồi nếu không hiểu. |
| 6. Các thử nghiệm tiếp theo | – Tạo ma trận đánh giá ảnh hưởng- Leader đánh giá solution từ sớm- Leader review lại kết quả- Phân tích chi tiết các lỗi để tìm ra nguyên nhân…. |
Dành cho Dev
Anh Hiển Nguyễn, CEO của zen8labs và là tác giả quyển DevUp, từng kể với tôi một nhận định. Dev của Việt Nam năng lực lập trình nhìn chung không kém dev tây, code rất nhanh. Có điều dev Việt làm nhanh nhưng công bỏ ra để đi dọn dẹp vẫn rất nhiều. Dev Tây thủng thẳng làm rõ đề bài, tìm kiếm đánh giá solution cẩn thận rồi mới bắt tay vào làm. Và thường làm là gọn.
Tôi ít có cơ hội làm với dev tây. Nhưng vế của dev ta thì quả thật rất dễ gặp, nhất là với các bạn chưa đủ cứng.
Phải chăng là do người Việt Nam từ bé quen với việc học và ghi nhớ, thay vì phải tư duy giải quyết bài toán?
Các câu hỏi một bạn dev nên tự đặt ra cũng tương tự như bộ câu hỏi của PM ở trên. Ngoài PM, có thể đặt ra câu hỏi đó với các thành viên khác trong dự án có liên quan.
- PM kỳ vọng gì ở mình khi làm những task như thế này? Tại sao lại là kỳ vọng đó?
- Tình trạng hiện tại đang thế nào?
- ….
Bộ câu hỏi khác có thể giúp dev rèn luyện tư duy:
- Điểm mấu chốt của task là gì?
- Làm thế nào để task hoàn thành đúng deadline? Rủi ro có thể gặp phải là gì?
- Làm thế nào đảm bảo chất lượng?
- Làm cách nào để phòng ngừa các vấn đề mình hay gặp phải gần đây?
Đặt được câu hỏi ắt sẽ tự tìm ra được giải pháp. Không nghĩ ra ngay thì cũng có thể đi hỏi anh chị đi trước. Quan trọng là phải tự đặt ra câu hỏi.
Vai trò của quản lý trực tiếp
Dev cần được PM hỗ trợ. Và PM cũng vậy.
Quản lý trực tiếp sẽ giúp cấp dưới đặt ra các câu hỏi, lắng nghe và phản hồi thêm thông tin nếu cần thiết. Điểm chính là cần rèn thói quen đặt câu hỏi. Ban đầu có thể quản lý sẽ hỏi. Khi thành thói quen thì người được huấn luyện cần tự hỏi và tự trả lời. Một cách hỗ trợ là dùng một template nào đó có sẵn các bộ câu hỏi, và lưu lại được toàn bộ các lần trả lời.
Mục tiêu không chỉ là cải thiện chất lượng công việc, mà phải bao gồm việc giúp người được huấn luyện làm chủ quá trình đặt câu hỏi và cải thiện chất lượng câu trả lời.
Kết luận
Tôi có thử thảo luận với một vài bạn quản lý, các bạn thấy có vẻ thú vị. Sẵn sàng áp dụng đến đâu thì tôi không chắc ^^
Để thành kỹ năng cần nhiều hướng dẫn chi tiết. Thực tế sách của Mike Rother cũng gần 300 trang và rất hấp dẫn. Có điều, bắt tay vào thử nghiệm sớm quan trọng hơn nhiều so với việc tìm hiểu kỹ lưỡng về phương pháp. Suy cho cùng, bạn phải xuống bể mới biết bơi.