Chúng ta thường thấy từ Tri thức xuất hiện trong rất nhiều bối cảnh: quản trị tri thức, nền kinh tế tri thức, xã hội tri thức hay người lao động tri thức. Nhưng liệu từ “tri thức” có cùng được hiểu theo một kiểu hay không? Hóa ra câu chuyện rắc rối hơn mức “hiển nhiên” rất nhiều.

 Học tập là chìa khóa để con người trở nên khác biệt, có bản sắc và mở rộng khả năng sáng tạo và cống hiến. Đó cũng là chìa khóa để một doanh nghiệp không ngừng lớn mạnh về năng lực, đóng góp vào sự phát triển chung của tổ chức. Trong nền kinh tế tri thức, nguồn nhân lực chất lượng cao và tài sản tri thức (knowledge assets) là nguồn lực quan trọng bậc nhất tạo nên sức cạnh tranh của cá nhân và tổ chức. Thậm chí có người, như chủ tịch của Analog Devices Strata, từng nhận định “Tốc độ học hỏi có thể là lợi thế cạnh canh bền vững duy nhất.

Tạo dựng một tổ chức học tập chính là một bước đi chiến lược trong việc thúc đẩy luôn luôn mở rộng đường biên tri thức và năng lực của tổ chức hướng đến các tầm nhìn của tổ chức. Hơn thế, việc hướng tổ chức thành “tổ chức sáng tạo tri thức” sẽ giúp tổ chức không ngừng gia tăng tài sản tri thức, đóng góp vào sự đổi mới và sáng tạo vượt bậc một cách bền vững. Đây là một ý tưởng lớn đáng chú ý. Trung tâm của ý tưởng này nằm ở câu nói của nhà thông thái quản trị Peter Drucker “Cần một học thuyết  đặt tri thức vào trung tâm của sự  thịnh vượng”.

Chúng ta sẽ lần lượt đi qua bốn mức độ cơ bản của một tổ chức học tập: cá nhân học tập, nhóm học tập, tổ chức học tập, tổ chức sáng tạo tri thức.

SECI bắt đầu với bước đầu tiên: Xã hội hóa. Trong đó, tri thức ẩn được truyền giao từ người này sang người nọ. Việc này có thể thực hiện như thế nào? Nonaka nhắc tới từ khóa apprenticeship.

Thầy dạy kinh tế nói rất ngắn gọn: đồng tiền đứng im không sinh lợi, phải để nó quay vòng. Tri thức cũng vậy, phải để nó lưu chuyển liên tục. Thế nên mới sinh ra SECI: tạo dòng chảy cho tri thức để sáng tạo 🙂

Trong Scrum Guide (Hướng dẫn sử dụng Scrum), có một mẩu thông ting đáng chú ý thế này nhưng ít người quan tâm:

Scrum được xây dựng dựa trên lý thuyết quản lý tiến trình thực nghiệm , hay “thực nghiệm luận”(empiricism, hay “duy nghiệm”). Lý thuyết này chỉ ra rằng tri thức đến từ kinh nghiệm và việc ra quyết định được dựa trên những gì đã biết. (“Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. “)

Điều này có hệ trọng gì không?

Người thực hành (practictioner) thường quan tâm đến các phương pháp thực hiện (practices) hơn là lí lẽ rườm rà. Chính vì thế đôi khi quên mất môt vài giả định lí thuyết quan trọng. Và lí thuyết EMPIRICISM (thực nghiệm luận), cái đặt nền móng cho các biện pháp thực hành của Scrum chính là một thứ hay bị bỏ quên như vậy.

Vậy, trước hết, thực nghiệm luận là gì?

Như trong phần trích dẫn Scrum Guide trên đây, triết thuyết này tin rằng mọi tri thức trên đời đều phát sinh từ kinh nghiệm, một nhận thức nào đó là đúng hay sai cần được kiểm định qua bằng chứng. Đi xa hơn, các nhà thực dụng luận (pragmatism) còn nói rõ hơn về sự liên hệ giữa các ý tưởng và kinh nghiệm. Một ý tưởng là đúng nếu nó có tác dụng. Các ý tưởng đúng là các ý tưởng chúng ta có thể tiếp thu, chứng minh giá trị, củng cố và kiểm chứng.

Thực nghiệm luận ra đời trong sự phê phán thuyết duy lí (rationalism, với dấu ấn lớn của của Descartes). Các nhà lí luận duy lí cho rằng lí trí của con người có khả năng nắm bắt chân lí cơ bản về thế giới mà không cần sự giúp đỡ của giác quan. Đây là thế giới quan nổi bật trong suốt một thời gian dài từ thời đại cách mạng công nghiệp, thời kì cơ giới hóa tại châu Âu. Quan điểm cơ giới hóa còn ảnh hưởng mạnh mẽ lên cách tư duy, làm việc suốt một thời gian dài sau đó tới đầu thế kỉ 20. Chủ nghĩa Taylor về quản lí (được biết tới với cái tên Scientific Management) là một đại diện tiêu biểu.

Các nhà sáng tạo Scrum chịu ảnh hưởng quan điểm của Nonaka, vốn quan niệm việc phát triển phần mềm là một công việc tạo tri thức mới (creating knowledge), một nhóm Scrum là một tổ chức kiến tạo tri thức (creating knowledge organisation), thì các nhóm Scrum cần phải tiến hành quản lí tiến trình thực nghiệm (empirical process control) để liên tục phát sinh tri thức mới qua thời gian thông qua các kinh nghiệm trực tiếp với công việc, các bằng chứng về tri thức đã được kiến tạo. Thay vì sử dụng cách thức quản lí tiến trình dưới hình thức võ đoán (predictive), việc quản lí tiến trình thực nghiệm rút ngắn các phân đoạn hoạt động để có được nhiều phản hồi về công việc đang làm hòng kiểm chứng việc nào là đúng, việc nào là hiệu quả để tính các bước tiếp theo. Các bước nhỏ này giúp cho quá trình phát triển vừa chắc chắn, vừa linh hoạt; đúng ngay từ sớm, và càng ngày càng đúng.

Đối lập với cách thức tổ chức công việc theo lối thực nghiệm này là hình thức mang nặng hình thức cơ giới (mechanism), theo đó việc phát triển phần mềm được coi là một quá trình cơ giới, có thể tự động hóa được(engineering). Kế hoạch sẽ được lập chi tiết, giải pháp được tính toán trước, mọi việc “thi công” theo sau là tự động, xếp đúng người đúng chuyên môn đúng việc, thì việc hoàn thành công việc được cho là sẽ hiển nhiên (plan-driven). Như Peter Drucker chỉ ra từ rất sớm, lối tiếp cận theo chủ nghĩa Taylor này gặp nhiều thử thách và bất ổn trong các công việc đòi hỏi sáng tạo (như phần mềm chẳng hạn).

Mô hình SECI về kiến tạo tri thức của Nonaka

Thế thì, giả định về “thực nghiệm” quan trọng như thế nào?

Điều quan trọng là thế này: nếu lấy “thực nghiệm” là gốc, ta sẽ phải từ bỏ các quán tính truyền thống về kế hoạch chi tiết và làm việc dựa theo kế hoạch dài hơi (plan-driven), cũng như từ bỏ các nỗ lực để đạt các thiết kế hoàn chỉnh ngay từ đầu (big design up-front). Thêm nữa, đã giả định là “thực nghiệm” thì các nỗ lực phát triển sẽ phải theo thiên hướng baby-steps, làm đến đâu kiểm thử đến đấy (TDD/BDD/ATDD), chuyển giao và phản hồi liên tục, phải chuyển giao theo hình thức tăng trưởng (increment) và tiến hóa (evolutionary)…Các định hướng này thể hiện bản chất việc phát triển phần mềm (nói cách khác: kiến tạo tri thức mới) là quá trình học hỏi, lập kế hoạch và thích ứng dựa trên các kinh nghiệm thực tiễn mà chính đội ngũ phát triển phải thực hiện.

Do vậy, những người nào làm Scrum mà vẫn bám lấy Waterfall thì thực ra là đang dùng động cơ V8 gắn vào một chiếc xe bò vốn không tương thích về cách vận hành. Những nỗ lực này chỉ giúp an ủi phần nào về tính hiệu quả hay linh hoạt ngắn hạn,  chứ không thể dẫn đến một hiểu biết và năng lực đầy đủ về Scrum.

Câu hỏi thử thách cuối cùng, giả định về duy nghiệm đó có thực sự cần giữ hay không khi mà cái người thực hành quan tâm là kết quả công việc? Scrum cũng chỉ là công cụ cho một business nào đó thôi, chứ có phải cái đích đâu? Tôi thấy ScrumBut là đủ chứ sao?

Vâng, giữa bạt ngàn các công cụ và phương pháp, bạn luôn có quyền lựa chọn. Nhưng hãy sử dụng cho đúng, nếu không thỉ chỉ tổ phí thì giờ.