[Personal Development - #WEGREEN]
- Phillip G. Amour -
Trong một bài báo trên tạp chí “The Business of Software”, giáo sư Phillip G. Amour, một chuyên gia phần mềm đã đề cập đến việc phát triển phần mềm như một quá trình thu thập kiến thức và giảm sự ngu dốt, thay vì đơn thuần là quá trình tạo ra một sản phẩm.
Với một ví dụ hơi cường điệu về quá trình testing một phần mềm, khi những đoạn mã không có nghĩa – được xem như những đoạn phi-kiến-thức – được tìm ra và thay thế bởi những đoạn mã có nghĩa – những phần chứa tri thức – lặp đi lặp lại đến khi hệ thống được hoàn thiện và hoạt động ổn định, những tri thức chứa trong phần mềm này và quá trình tạo lập nó, được xem như một quá trình thu thập tri thức và chuyển hóa nó vào phần mềm – công cụ thứ 5 lưu trữ thông tin của nhân loại sau 4 phương tiện lưu trữ truyền thống: DNA, não bộ, sách và phần cứng máy tính. Hơn thế, nó còn vượt trội hơn những phương tiện kia bởi sự bền vững, nhưng linh hoạt và tránh được những sai sót như vẫn xảy ra đối với các phương tiện lưu trữ thông tin kiểu cũ, và đặc biệt, những tri thức chứa trong phần mềm còn có khả năng vận động (active), tương tác với người dùng.
Từ quá trình thu thập kiến thức khi phát triển phần mềm, Phillip G. Amour xây dựng hệ thống 5 mức độ ngu dốt, trong đó chỉ ra những mức độ của sự thiếu nhận thức mà con người có thể mắc phải về một vấn đề cụ thể nào đó.
NĂM MỨC ĐỘ NGU DỐT
Dựa trên những gì chúng ta biết và không biết, chúng ta có thể phân loại sự thiếu hiểu biết của chúng ta thành những lớp khác nhau. Tôi gọi chúng là “5 mức độ của sự ngu dốt”. Chúng rất hữu ích trong việc học tập để giảm thiểu sự ngu dốt và xây dựng một hệ thống có khả năng hoạt động tốt. Nó cũng giúp giải thích một số tạo tác của môi trường phát triển phần mềm, và một số hành vi của chúng ta trong môi trường này:
NGU DỐT CÂP 0: (0OI) – Không ngu dốt. Tôi thuộc 0OI khi tôi có kiến thức về một vấn đề và có thể diễn đạt kiến thức của mình một cách cụ thể, ví dụ như bằng cách giải thích hiệu quả và rõ ràng hệ thống kiến thức của mình. 0OI tương đương với kiến thức. Ví dụ với tôi, tôi có 0OI trong việc lái thuyền buồm, và với một con thuyền và một cái hồ, tôi có thể dễ dàng chứng minh điều này.
NGU DỐT CẤP 1: (1OI) - Thiếu kiến thức. Tôi thuộc 1OI khi tôi không biết điều gì đó và có thể dễ dàng nhận ra là điều ấy. 1OI là sự thiếu kiến thức căn bản. Ví dụ: Tôi không biết tiếng Nga - một thiếu sót tôi sẵn sàng bù đắp bằng việc đi học, đọc sách, nghe các loại băng đĩa, hoặc chuyển đến Nga trong một thời gian dài.
NGU DỐT CẤP 2: (2OI) - Thiếu nhận thức. Tôi thuộc 2OI khi tôi không biết rằng mình ngu dốt về điều gì đó. Có nghĩa là tôi không chỉ thiếu kiến thức về một vấn đề (như khi có 1OI), tôi còn không có nhận thức được sự thật này. Tôi không đủ kiến thức để hiểu rằng tôi không đủ kiến thức. Ví dụ: tôi không thể đưa ra một ví dụ tốt về 2OI (tất nhiên).
NGU DỐT CẤP 3: (3OI) - Thiếu quá trình. Tôi thuộc 3OI khi tôi không có một cách nào đủ hiệu quả để nhận ra rằng tôi không-biết mình còn chưa biết điều gì. Đó là sự thiếu phương pháp, và nó đẩy tôi vào một vấn đề lớn: Nếu tôi có 3OI, tôi không-có-cách-nào để tìm ra những-điều-tôi-không-biết-
NGU DỐT CẤP 4: (4OI) – Siêu dốt. Tôi có 4OI khi tôi không biết về “5 mức độ của sự thiếu hiểu biết”. Tôi không còn ở cấp dốt này, và tất nhiên bây giờ bạn cũng vậy.
Ứng dụng “5 mức độ ngu dốt” trong phát triển hệ thống.
Mỗi mức độ của thiếu hiểu biết đều có một vai trò quan trọng trong việc phát triển các hệ thống
• 0OI: Vì 0OI là kiến thức, đây là phần hoạt động chính xác của hệ thống mà tôi hiểu và đưa vào hệ thống thành công. Khi tôi có 0OI, tôi có câu trả lời.
• 1OI: Đây là những biến số đã xác định, tôi biết về sự hiện diện của chúng, nhưng chưa biết giá trị của chúng. Khi tôi có 1OI, tôi có câu hỏi. Thông thường, việc có một câu hỏi tốt là con đường ngắn dẫn đến câu trả lời.
• 2OI: Đây thực sự là vấn đề. Tôi không chỉ không có câu trả lời tôi cần, mà còn không có cả câu hỏi. Đây là điểm khởi đầu của rất nhiều dự án. Khi chúng ta bắt đầu một dự án, chúng ta biết, bằng kinh nghiệm, rằng chúng ta có rất nhiều điều cần học hỏi. Chúng ta chỉ không biết chúng là gì. 2OI giải thích cho phần lớn những biến số nằm trong ước tính của dự án và khái niệm “sự kiện bất ngờ” (dành cho những gì chúng ta chưa nghĩ đến). 2OI cũng giải thích “hiện tượng hoàn thiện 90%” mà ta vẫn biết, khi một lập trình viên khẳng định với sự chắc chắn rằng anh ta/cô ta đã hoàn thành 90% công việc, rồi đôi khi phải đến hàng tháng trời mới xong nổi phần còn lại. Lập trình viên đó không “nói dối”, nhưng chắc chắn là không chính xác. Cơ bản là lập trình viên đó không biết anh ta/cô ta đã hoàn thiện được bao nhiêu công việc. Vì sao? Vì với 2OI, lập trình viên không thể biết những điều họ không biết. 2OI cũng giải thích cho những giai đoạn làm lại, những phát kiến ở cuối công đoạn phát triển, và điều mà nhà điều hành dự án và tác giả Fred Brooks gọi là “hiện tượng hệ thống thứ hai”.
• 3OI: Cùng với 2OI, 3OI đặt ra một mối nguy hiểm thực sự (tôi không có cách giải quyết sự thiếu hiểu biết của mình trong thời gian cho phép). Về cá nhân, tôi cho rằng tất cả những phương pháp phát triển phần mềm đều là những quy trình 3OI, nơi mà công việc chính là cho ta thấy những mặt của quy trình hoặc sản phẩm mà tôi thiếu kiến thức. Có một điều cần lưu ý: Câu trả lời tôi tìm kiếm không thể nằm trong phương pháp. Ngoại trừ một vài cá biệt, phương pháp chỉ đơn giản cung cấp một hướng xác định câu hỏi và cách nhận diện những khu vực mà tôi có 2OI. Nhưng tôi không thể biết tôi đang cố gắng làm gì. Câu trả lời phải đến từ một nơi khác.
• 4OI: Đây không phải là một vấn đề quá nghiêm trọng, mặc dù tôi thấy rằng suy nghĩ theo cách tiếp cận này rất có ích. Chúng tôi đã tìm ra những cách để giải quyết sự thiếu hiểu biết của mình, ví dụ như sử dụng các biện pháp đối phó bất ngờ cho 2OI. Tôi đưa 4OI vào mô hình này vì kiến thức, bản thân nó, mang tính đệ quy.
Những mức độ quan trọng dường như là 2OI và 3OI. Tôi cho rằng phần lớn những việc chúng ta làm là giảm thiểu 2OI và sự phát triển các phương thức phần mềm và hệ thống là các quy trình 3OI. Công việc của một quy trình 3OI là làm sáng tỏ phần 2OI. Việc áp dụng 3OI vào 2OI sẽ cho 1OI - hoặc hiếm hơn là 0OI. Đây là một trong những lý do chính của quy trình và là vai trò quan trọng của phương pháp và mô hình.
Điểm cốt yếu là việc áp dụng quay trình 3OI (các phương pháp và quá trình) không cho ta câu trả lời; mà cho ta câu hỏi. Như một mô hình kinh doanh, chúng ta đang sử dụng chúng cho một mục đích sai lầm. Chúng ta hy vọng có được câu trả lời, và đó không phải là những gì chúng làm. Sẽ rất khó chịu khi tìm kiếm một câu trả lời nhưng lại nhận được một câu hỏi; sử dụng một phương pháp để giảm thiểu khối lượng công việc, trong khi rõ ràng tăng nó lên; hoặc áp dụng một quy trình phức tạp chỉ để biết được rằng chúng ta thiếu hiểu biết cỡ nào. Nhưng đó là thực tế trong công việc phát triển phần mềm. Một hệ thống hoạt động được là sản phẩm phụ của quá trình tìm hiểu. Hệ thống đó là minh chứng cho việc tôi có kiến thức. Nhìn một cách thực tế, mục đích là đưa mức độ của sự thiếu hiểu biết của chúng ta về 0OI. Chúng ta dành phần lớn năng lượng của mình để thu thập kiến thức. Vì tìm ra câu trả lời cho 1OI tương đối đơn giản, chúng ta phải dành phần lớn sức lực phát triển ở 2OI, và phần lớn sức lực quy trình ở 3OI. Chúng ta có thể dùng các mức độ của sự thiếu hiểu biết để phân loại những gì mình biết, để phỏng đoán khả năng chúng ta không biết những gì chúng ta không biết, và đặt những quy trình và phương pháp vào đúng chỗ của chúng.
__________________________
Nguồn: Phillip G. Armour, COMMUNICATIONS OF THE ACM October 2000/Vol. 43, No. 10, 17-21.
Biên dịch: [CTV Khánh]
Biên tập và hình ảnh: [Admin TKN]
Bản quyền © Wegreen Vietnam
#WegreenVietnam, #Personaldevelopment, #nammucdongudot, #5ordersofignorance, #PhillipG.Amour
No comments:
Post a Comment