Là một người tiên phong trong đổi mới, bạn liên tục phải thuyết phục mọi người rằng con đường mình đang theo đuổi là đáng giá. Điều này thường được thể hiện ra dưới dạng những phê phán và những câu hỏi khó mà tôi thường gặp khi huấn luyện một nhóm Agile, hay khi tôi giới thiệu Kanban với mọi người.
Tuy nhiên, tôi thấy xuất hiện những câu hỏi khó hơn ở cấp độ lãnh đạo và quản lý khi mọi người đã được giới thiệu căn bản về Kanban và bắt đầu tự tìm hiểu thêm. Ví dụ như: “Làm sao ta có thể lập kế hoạch nếu như ta đo lường thay vì ước lượng?”
Những câu hỏi mà Kanban đưa đến dường như khó mà trả lời được nếu không mất cả tiếng đồng hồ thảo luận. Tôi đoán điều này là bình thường bởi vì Kanban có ít hướng dẫn hơn các phương pháp khác, ví dụ như Scrum. Là huấn luyện viên, để thuyết phục được bạn cần đào sâu các câu hỏi đến những nguyên lý của Kanban, vốn bắt nguồn từ tư tưởng Tinh gọn.
Đó là lý do tại sao tôi viết một cuốn e-book miễn phí liệt kê 5 tranh cãi thường gặp về Kanban và các câu trả lời của tôi.
Nội dung bài viết
Sẽ tốn nhiều thời gian hơn
Một tranh cãi phổ biến về Kanban là sẽ tốn nhiều thời gian hơn để tạo ra sản phẩm. Lý luận này bị hằn sâu vào cuộc sống hằng ngày của chúng ta. Nó liên quan tới hệ thống giáo dục và hệ thống quản trị kinh doanh trong hằng thiên niên kỉ qua. Ta thấy rằng Kanban tập trung vào sử dụng dữ liệu thực tế để đưa ra quyết định. Nó giúp ta quản lý con người và sản phẩm bằng cách đo lường luồng.
Điều này hoàn toàn ngược với điều chúng ta thường làm. Quản lý học cách kiểm soát nhân viên bằng cách giao việc và theo dõi quá trình làm việc. Bạn nhận một đầu việc và hoàn thành nó đúng hạn hoặc bạn phải giải trình tại sao không thể hoàn thành đúng hạn. Tình huống tương tự cũng diễn ra tại trường học. Học sinh được giao bài cùng một kỳ hạn, nếu không hoàn thành đúng hạn chúng sẽ bị phạt dưới dạng điểm thấp. Có bao nhiêu lần bạn được giao bài mà không kèm theo kỳ hạn? “Đây là điều thầy muốn em làm, đừng lo lắng về thời hạn, chúng ta sẽ đo lường kết quả sau khi xong.”
Hãy cùng tìm hiểu cách Kanban dùng các đo lường như một công cụ quản lý cốt lõi mà không bị mất sự tập trung.
Luật Parkinson
“Lượng thời gian cần để hoàn thành công việc bằng với khoảng thời gian một người bị ép phải làm xong nó.”
Rất nhiều người làm việc theo định nghĩa đơn giản trên. Nếu chúng ta không đặt một kỳ hạn nào, người lao động sẽ mất nhiều thời gian hơn để hoàn thành công việc. Anh ta sẽ thư giãn và chỉ bắt đầu làm việc khi anh ta muốn. Thời gian là tiền bạc vì vậy chúng ta không thể cho phép điều này, đúng không nhỉ?
Việc quản trị dự án vẫn theo cách này hàng thập kỉ nay. Một kế hoạch dự án được tạo bởi người quản trị dự án và senior developer. Dựa trên những ước lượng, một thời gian biểu được tạo ra cho nhóm phát triển, dù nó có thực tế hay không. Lý do khá đơn giản, nhóm cần một kỳ hạn để giữ tập trung. Quản trị dự án sẽ thêm chút thời gian đệm vào trong kế hoạch của chính mình, phòng trường hợp nhóm không hoàn thành đúng kỳ hạn. Nhưng sau đó thì nhóm sẽ đạt được đến 90%. Nếu không có sự tập trung này nhóm thậm chí không thể đạt được 50%…
Chỉ tính về mặt chi phí, ì đây là một cách làm tốt. Nhìn về mặt giá trị, đây là cách làm tệ. Bởi vì điều gì sẽ xảy ra khi mọi người bị stress? Họ làm ẩu, cố gắng làm nhiều hơn trong thời gian ngắn hơn và tạo ra lỗi do làm việc không đến nơi đến chốn.
Từ góc nhìn của người làm nhân sự, đây cũng là một cách làm tệ. Mọi người làm việc quá sức, bị stress và rời công ty nếu phải chịu áp lực quá lớn.
Bạn thấy rằng cần cân bằng giữa tự do và kiểm soát. Để cân bằng, bước đầu tiên trong quản trị dự án là cho cả nhóm cùng tham gia ước tính công việc. Điều này giúp nhóm có tiếng nói đầu tiên trong mặt quản trị của dự án và tăng động lực tự thân của nhóm. Sau đó với Agile, có thể đạt được thêm bước nữa bằng cách đo lường kết quả một nhóm có thể chuyển giao trong một phân đoạn lặp và dùng những con số đó để lập kế hoạch thay vì dựa vào ước lượng ban đầu. Điều này giúp chất lượng và giá trị của công việc tăng lên rất nhiều.
Kanban làm cách nào để giữ sự tập trung lành mạnh giữa kiểm soát và tự do?
Một sự cân bằng lành mạnh của Kanban
Trong một luồng Kanban, thành viên nhóm kéo những chức năng mới từ một hàng đợi đã đánh thứ tự. Nhiều khi những chức năng này chưa được ước tính trước. Tốt nhất thì chúng đã được sắp xếp theo cỡ to nhỏ. Đo lường luồng là công cụ quản lý chính được dùng để kiểm soát hiệu suất. Bằng cách liên tục giám sát lead time (thời gian từ khi xuất hiện yêu cầu tới khi bàn giao) và cycle time (thời gian từ khi bắt đầu làm tới khi bàn giao), ta thấy rõ được tiến độ của nhóm. Những số liệu này trở thành mục tiêu của mỗi người tham gia luồng làm việc. Nếu thời gian hoàn thành trung bình là 5 ngày, nhóm sẽ vô thức tập trung để đạt được con số này khi bắt đầu làm một chức năng mới.
Cái hay của cách làm này là nó dựa trên dữ liệu thực tế thay vì ước muốn. Nếu mất 5 ngày để hoàn thành một chức năng mới, khả năng cao là nó cũng sẽ mất khoảng 5 ngày cho một chức năng khác. Sự tập trung không được tạo ra bởi sự quản lý bên ngoài mà được phát triển từ bên trong nhóm. Do vậy tự bản thân nhóm sẽ tích cực cố gắng hơn để tập trung. Mọi người sẽ ít làm ẩu hơn, sẽ chuyển giao các chức năng có chất lượng và giá trị cao hơn.
Từ góc nhìn của người quản lý, phong cách quản lý được chuyển từ mệnh lệnh và kiểm soát sang kiểu giúp nhóm cải tiến. Chấp nhận rằng hệ thống có thể chuyển giao chức năng mới trong 5 ngày là chấp nhận thực tế. Theo đó tất cả mọi người tham gia luồng Kanban có thể tham gia quá trình cải tiến liên tục. Mọi người đều có trách nhiệm nghĩ cách để cải tiến luồng, giảm nút thắt cổ chai và sai sót. Thời gian chờ và thời gian hoàn thành sẽ thay đổi, cùng với mức tập trung của nhóm. Mức tập trung mới của nhóm sẽ là mức thực tế bởi vì nó dựa vào những đo lường thực sự từ một luồng được cải tiến.
Tôi thấy rằng Lý thuyết điểm hạn chế rất có ích trong việc cải tiến luồng Kanban.
Lý thuyết điểm hạn chế trong cải tiến quy trình
Lý thuyết điểm hạn chế (TOC – theory of constraints) là một triết lý quản trị được Eliyahu Goldratt đưa ra trong cuốn sách “The Goal” của ông xuất bản năm 1984. Nó dựa trên ý tưởng: “Một sợi xích không khỏe hơn mắt xích yếu nhất của nó”. Nếu áp dụng ý này vào Kanban, ta có thể hiểu rằng giai đoạn yếu nhất trong luồng sẽ quyết định tốc độ tạo ra giá trị của toàn bộ hệ thống.
Ví dụ, nếu ta để ý rằng giai đoạn kiểm thử chấp nhận của người dùng (UAT – User Acceptance Test) không thể theo kịp với các giai đoạn trước, nó sẽ làm chậm kết quả của toàn bộ luồng Kanban xuống bằng với tốc độ của nó.
Bằng cách trực quan hóa công việc trên một bảng Kanban, điểm hạn chế sẽ lộ ra rõ ràng dưới dạng một nút thắt cổ chai làm tắc hệ thống. Trong quá trình làm việc, nhóm cũng sẽ thấy được điểm hạn chế nhờ giới hạn công việc đang làm (giới hạn WIP – Limit Work In Progress), được biểu thị bằng một con số ở mỗi giai đoạn của luồng Kanban, chỉ ra số hạng mục công việc tối đa có thể tồn tại trong một giai đoạn.
Ví dụ nếu ta đặt giới hạn WIP ở cột UAT là 3, nghĩa là không có chức năng nào của các giai đoạn trước được phép bắt đầu khi cột UAT bị đầy. Bạn có thể tưởng tượng điều này sẽ gây khó chịu. Chúng ta đều muốn nhanh chóng bắt đầu một chức năng mới, đặc biệt khi thời điểm phát hành đang đến gần. Mọi người cảm thấy khó chịu khi không làm gì vì sợ mọi người nghĩ xấu về mình. Chúng ta phải luôn luôn bận rộn. Tình huống khó chịu này rất nhanh sẽ xảy ra. Nhưng điều đó thật ra lại là việc tốt. Bởi vì chúng ta muốn tìm ra nút thắt cổ chai càng nhanh càng tốt.
Điều này thường dẫn đến một phiên họp để cải tiến. Làm sao để ngăn việc này tái diễn? Chúng ta đã đăt giới hạn WIP đúng chưa? Nguyên nhân gốc rễ của nút thắt cổ chai này là gì, làm sao để khai thông nó? Phiên họp này tương tự một phiên Cải tiến nhưng phạm vi rộng hơn. Hầu hết các phiên Cải tiến chỉ gồm các thành viên Nhóm Phát triển, thi thoảng mới có Product Owner tham gia. Trong Kanban, phiên cải tiến thường có rất nhiều người với nhiều vai trò tham gia bởi vì phạm vi cải tiến là toàn bộ luồng làm việc, từ ý tưởng đến lúc cài đặt sản phẩm. Những người này gồm cả chuyên viên phân tích nghiệp vụ, kĩ sư hệ thống, đôi khi có cả nhân viên kinh doanh.
Sự tập trung cải tiến liên tục của tất cả vai trò trong tổ chức tạo ra một áp lực ngang hàng lành mạnh và thêm các cơ hội để chia sẻ kiến thức. Giới hạn WIP sẽ phát lộ ra những nút thắt cổ chai nhanh chóng và tạo đà giúp mọi người bắt đầu chu trình cải tiến liên tục. Khả năng cải tiến liên tục mạnh mẽ của Kanban sẽ giúp bạn cải thiện luồng công việc, do đó bạn chuyển từ cảm giác mất nhiều thời gian hơn sang cảm giác hiệu suất cao hơn. Và bạn còn có các phép đo để chứng minh nó.
Luồng
Kanban dựa trên nguyên lý của hệ thống kéo, tiên phong trong sản xuất tinh gọn (Lean manufacturing). Mục đích là đạt được luồng một sản phẩm (Single Piece Flow), khi đó công ty chỉ sản xuất những sản phẩm đã được khách hàng đặt trước. Tại sao lại cần điều này và điều này thì liên quan gì đến phát triển phần mềm?
Lý do chúng ta chỉ muốn sản xuất theo yêu cầu khách hàng là bởi vì chúng ta muốn loại bỏ lãng phí, tức là loại bỏ những hoạt động mà không mang đến bất kì giá trị nào cho khách hàng. Tạm thời chưa nói đến lĩnh vực đổi mới sáng tạo, bởi vì trong đó không có yêu cầu của khách hàng để kích hoạt hệ thống kéo. Không làm việc hoàn toàn dựa trên yêu cầu khách hàng nghĩa là bạn đang suy đoán điều khách hàng muốn trong tương lai, tức là bạn đang tạo ra một kho sản phẩm đang chờ được mua. Điều này gây ra lãng phí bởi hai lý do. Thứ nhất là do tốn tiền vào những thứ mà không mang lại lợi nhuận. Ngoài ra những thứ này có nguy cơ không bán được hoặc không thỏa mãn được nhu cầu khách hàng, khiến ta bị mất tiền. Trong phát triển phần mềm cũng có những vấn đề tương tự. Những chức năng phải mất nhiều tháng mới phát hành được thì tốn tiền và ẩn chứa rủi ro.
Giới hạn WIP giảm hàng tồn kho và tạo ra một hệ thống kéo ngược. Nếu bạn hoàn thành một tác vụ, bạn kéo một tác vụ mới từ giai đoạn phía trước, tạo chỗ trống để nó có thể kéo thêm tác vụ khác. Quá trình kéo này tiếp tục đến danh sách đầu vào đầu tiên.
Chỉ trích hay gặp nhất về giới hạn WIP đó là nó làm giảm hiệu suất. Tất nhiên mọi người sẽ nhàn rỗi mỗi khi giới hạn WIP đạt tối đa. Điều gì xảy ra nếu mọi người bỏ qua giới hạn WIP? Hàng tồn kho sẽ từ từ tăng lên, vượt quá mức luồng công việc có thể xử lý. Con người không thể bận rộn làm việc 100% thời gian. Niềm tin cho rằng con người nên bận rộn 100% thời gian xuất phát từ rất lâu trước đây, từ khi bắt đầu thời kì công nghiệp hóa khi các nhà máy bắt đầu phát triển mạnh và máy móc đắt đỏ được tạo ra để tăng năng suất. Những máy móc này quá đắt đỏ đến nỗi chúng phải chạy liên tục để giữ giá thành sản phẩm thấp. Điều này dẫn đến dòng sản phẩm không ổn định và tăng hàng tồn kho. Thời đó, một sản phẩm không phải tùy biến theo từng người dùng, khách hàng không có nhiều lựa chọn, do vậy rủi ro không thỏa mãn mong muốn khách hàng không tồn tại. Công ty chỉ cần đảm bảo bán hết hàng tồn kho. Ngày nay, với nhiều công ty, sản phẩm được tùy biến cho người dùng cuối, khiến cho hàng tồn kho trở thành một rủi ro lớn. Điều này cũng là vấn đề trong IT, bởi vì phần lớn hệ thống phải được tùy biến cho một khách hàng hay một phân khúc khách hàng nhất định,…
Một Sprint liên tục
Luồng làm việc liên tục của Kanban dẫn đến quan niệm rằng nhóm không có cơ hội để dừng lại và phản tỉnh. Rằng Kanban là một Sprint không bao giờ kết thúc trong đó nhóm bị thúc phải chuyển giao càng ngày càng nhanh. Mà chúng ta đều biết rằng một nhịp điệu ổn định rất quan trọng đối với chất lượng của sản phẩm cuối và sức khỏe của nhóm. Vài khoảng chùng là cần thiết để nhìn lại mình hay suy nghĩ về tương lai của sản phẩm, giúp nhóm đưa ra quyết định tốt hơn trong quá trình chuyển giao.
Việc đo lường luồng công việc dễ rơi vào bẫy micromanagement. Thúc ép nhóm làm việc nhiều hơn qua từng chức năng. Đây là lúc một huấn luyện viên thể hiện vai trò quan trọng của mình. Anh ta phải giúp thành viên nhóm hiểu rằng để đi nhanh hơn, họ phải dành thời gian phản tỉnh về quy trình chứ không phải về tốc độ làm việc. Kanban tập trung vào luồng hoàn chỉnh. Thúc ép một bước nhanh hơn thường gây vấn đề cho toàn bộ phần còn lại của luồng, tạo ra lỗi, các nút thắt cổ chai và những quyết định vội vàng. Điều này được nhắc đến trong Lý thuyết điểm giới hạn, rằng vấn đề sẽ xuất hiện ở phía sau nếu chúng ta thúc ép một bước trong quy trình đi nhanh hơn.
Một nhóm Kanban mới bắt đầu với hiệu suất hiện tại và liên tục thanh tra sự cộng tác để tiến hành. Không phải bằng cách làm nhanh hơn mà bằng cách tối ưu hóa luồng. Cách này giúp dễ dàng đảm bảo một luồng liên tục, bởi vì chúng ta đều đồng ý rằng hệ thống quan trọng hơn cá nhân, và chúng ta có thể đạt kết quả tốt hơn bằng cách cải tiến cùng nhau.
Tóm tắt
Thật kì lạ khi cho rằng thay vì đặt ra các kỳ hạn, đo lường luồng công việc lại giúp công việc hoàn thành một cách hiệu quả. Kanban giúp ta ý thức được sự quan trọng của mỗi giai đoạn của quy trình. Thay vì thúc đẩy từng giai đoạn đi nhanh hơn, chúng ta tối ưu hóa toàn bộ quy trình. Bởi vì, đây mới là điều người dùng cuối quan tâm. Họ không quan tâm bằng cách tuyệt vời nào những lập trình viên của chúng ta đáp ứng được kỳ hạn, họ chỉ cần sản phẩm được chuyển giao. Ngay khi quy trình đi vào ổn định, nhóm có thể bắt đầu cải thiện hiệu suất của mình. Không phải của một giai đoạn mà là từ đầu đến cuối quy trình. Không phải bằng cách thúc ép mỗi người làm việc nhiều hơn, mà bằng cách giảm thiểu các nút cổ chai và tối ưu hóa luồng. Môi trường làm việc được điều chỉnh phù hợp với nhu cầu mỗi người. Một nhịp ổn định cho người lao động, một mối quan hệ đáng tin cậy với khách hàng và lợi nhuận kinh doanh cho người chủ.
Theo Hocvienagile.com
