- Đây là câu hỏi về các công cụ và kỹ thuật hiệu quả để truyền đạt cho người khác và cùng phát triển mô hình tư duy nhằm hiểu một hệ thống hoặc sản phẩm
- Một cách được nêu ra để phát triển mô hình tư duy là trải nghiệm trực tiếp xây dựng và bảo trì hệ thống
- Cách truyền đạt thường gần với những giải thích phi chính thức như vẽ nguệch ngoạc trên khăn giấy, giải thích bằng cử chỉ khi ngồi cạnh nhau, hay cùng suy nghĩ và diễn giải bằng lời
- Tài liệu liệt kê đầy đủ danh sách tính năng hoặc các phạm vi bề mặt có thể mang tính bao quát, nhưng có thể chưa đủ để tạo ra hoặc truyền đạt mô hình tư duy về chủ đề đó
- Trải nghiệm trực tiếp sử dụng một công cụ hoặc sản phẩm được thiết kế tốt có thể đồng thời hỗ trợ quá trình phát triển và truyền đạt mô hình tư duy
Trọng tâm của câu hỏi
- Điểm cốt lõi là công cụ hay kỹ thuật nào hiệu quả trong việc truyền đạt và phát triển mô hình tư duy
- Câu hỏi đồng thời đề cập đến hai hướng
- Cách phát triển mô hình tư duy
- Cách truyền đạt mô hình tư duy cho người khác
Ví dụ và vấn đề đặt ra
- Ví dụ về việc phát triển mô hình tư duy là cách xây dựng và bảo trì hệ thống
- Cách truyền đạt mô hình tư duy là hình thức cùng nhau căn chỉnh hiểu biết ngay tại hiện trường, chẳng hạn như
- Vẽ nguệch ngoạc trên khăn giấy
- Giải thích bằng cử chỉ khi ngồi cạnh nhau
- Giải thích trong tình huống cùng nhau suy nghĩ
- Tài liệu liệt kê tính năng hoặc lập danh mục phạm vi bề mặt có thể mang tính bao quát
- Tuy nhiên, những tài liệu như vậy có thể không dẫn đến việc tạo ra hoặc truyền đạt mô hình tư duy về chủ đề đó
- Trải nghiệm trực tiếp sử dụng công cụ hoặc sản phẩm được thiết kế tốt được xem như một cách có thể đạt được cả việc phát triển lẫn truyền đạt mô hình tư duy
- Câu hỏi cuối cùng hỏi mỗi người đã thấy công cụ và kỹ thuật nào hiệu quả, cũng như vì sao chúng hiệu quả
1 bình luận
Các ý kiến trên Lobste.rs
Olog là một hình thức luận tốt để truyền đạt ontology
Nếu là một tiến trình chạy dài có nhiều trạng thái nội bộ, sơ đồ trạng thái và statechart sẽ hữu ích để tài liệu hóa hệ thống
Người dùng hệ thống thường không nhận thức được cấu trúc hệ thống thực sự. Một lý do là Nakatomi space chỉ hiện ra với những người dùng lạm dụng/sử dụng sai hệ thống, và vì có những vùng không gian trạng thái riêng cho các hành vi ngoài ý muốn như weird machines
Một lý do khác là, theo quan điểm the purpose of a system is what it does, người dùng có thể chỉ nhìn vào những gì hệ thống làm cho họ và tự tạo ra lý do tồn tại mang tính cá nhân, nhưng có thể không nhận ra toàn bộ mục đích mà nhà thiết kế và người bảo trì đã định
Viết một cuốn sách, rồi thuê biên tập viên là được
Tôi nghĩ đây gần như là vấn đề cốt lõi của giáo dục. Đã nêu hai phạm trù là học qua thực hành và được chuyên gia hướng dẫn, còn phạm trù thứ ba là giảng dạy
Câu hỏi quan trọng hơn là liệu có thể tạo ra các mô hình dễ tiếp thu hơn bằng cách tái sử dụng các nguyên lý và thiết kế tương tự, hoặc thông qua trừu tượng hóa để giảm nhu cầu phải tiếp thu đầy đủ hay không. Tuy vậy, cần định nghĩa rõ chỗ nào abstraction bị rò rỉ
Liên quan đến chuyện này, The Programmer's Brain của Felienne Hermans khá thú vị. Điều gây ấn tượng là cách “hãy xem tôi giải nhiều ví dụ” khi dạy toán v.v. cho trẻ nhỏ cũng khá hiệu quả trong việc dạy lập trình
Trong môi trường công việc, khi onboarding có lẽ sẽ là kiểu “hãy xem tôi điều tra bug này như thế nào” hoặc “hãy xem tôi tìm hiểu lại subsystem mà lâu rồi không đụng tới này ra sao”
Trong kỹ nghệ phần mềm, sẽ hữu ích nếu chia mô hình tinh thần thành user story và triển khai kỹ thuật
Thông thường user story là yêu cầu bậc một, tức là giá trị muốn đạt được, còn triển khai kỹ thuật là các yếu tố bậc hai cần thiết để đạt mục tiêu đó
User story mô tả giá trị được chuyển giao cho khách hàng, còn triển khai kỹ thuật mô tả các ràng buộc của hệ thống đã xây dựng giới hạn user story như thế nào
Đôi khi hai phần này chồng lấn, khiến user story bị ràng buộc bởi triển khai kỹ thuật, hoặc ngược lại, ta chọn triển khai kỹ thuật để đạt được user story. Nhưng nhiều hành vi hệ thống có thể được đóng khung theo một trong hai loại này
Tiếp theo là chọn công cụ phù hợp nhất. UML phù hợp để vẽ bản đồ các thực thể, flowchart phù hợp để giải thích luồng. Sơ đồ trạng thái phù hợp để mô tả các trạng thái được phép/không được phép và các chuyển tiếp, còn bảng biến và trạng thái phù hợp để liệt kê tất cả các giá trị khả dĩ
Cách tốt nhất để học cách vẽ hệ thống là yêu cầu ba người khác nhau vẽ ra hình dung của riêng họ. Cùng một ý tưởng nhưng cách biểu đạt có thể đa dạng đến đáng ngạc nhiên, và phần lớn đều hợp lệ như nhau nhưng làm lộ ra các khía cạnh khác nhau của chủ đề. Nó giống nghệ thuật
Chủ yếu tôi dùng sơ đồ hóa trang trọng hơn. Dù vậy, khi vẽ nguệch ngoạc trực tiếp trong lúc chia sẻ màn hình, đôi khi tôi mở jspaint, và nếu nội dung đáng để người khác xem về sau thì tôi dùng cả những thứ như Figjam
Sơ đồ hóa và chỉ tay hoạt động tốt vì đó là những công cụ dẫn hướng chú ý lâu đời nhất mà ta có, và đến nay vẫn hữu dụng. Trước khi biết nói, ta đã biết chỉ trỏ và khóc; trong định vị và điều hướng, chỉ trỏ tức thời hơn ngôn ngữ rất nhiều, nên thị trường bút laser vẫn còn tồn tại
The Geometry of Meaning: Semantics of Conceptual Spaces của Peter Gårdenfors bàn khá chi tiết về chủ đề này. Barbara Tversky cũng có nhiều nghiên cứu về sơ đồ hóa và cấu trúc hóa không gian nhận thức, còn “What Constitutes an Effective Representation?” của Peter Cheng đưa ra các tiêu chí khá định lượng cho một biểu diễn hiệu quả
Shadowing, pairing và các buổi whiteboard rất tốt. Khi đó cả hai bên đều phải vẽ và đặt câu hỏi
Cũng có các cách như cùng chọn và thực hiện một dự án mở rộng hoặc thay đổi mô hình, làm quiz, để người học dạy lại, học thuộc rồi viết tay
Ghi nhớ đơn thuần luôn phải dùng kèm với phương pháp khác, không được để nó trở thành phương pháp duy nhất. Sơ đồ hóa hoặc vẽ nguệch ngoạc ngoài whiteboard, phân tích khoảng cách bằng cách so sánh với các mô hình/giải pháp khác, và kiểu suy ngẫm có tính chiêm nghiệm, nửa vô thức như hammock time cũng hữu ích
Tôi nghĩ cần phân biệt biểu diễn để truyền đạt với biểu diễn để thực sự thực hiện tác vụ. Cái sau không được nhắc đến ở đây, nhưng gần với “thực thi” hơn
Mô hình có thể thực thi thường có khả năng truyền đạt kém, đa phần vì ranh giới trừu tượng hóa không tốt. Trong điện toán, gần như luôn là abstraction bị rò rỉ
Việc nắm bắt một thứ làm gì có thể bị che khuất bởi núi nỗ lực đã được đổ vào để khiến nó làm việc đó hiệu quả. Vì vậy mới cần nguệch ngoạc lên khăn giấy và giải thích rằng “ở mức trừu tượng phù hợp với mô hình tinh thần hiện tại của bạn, hệ thống này hoạt động như thế này”
Tài liệu là một sản phẩm riêng nên có xu hướng tụt hậu so với mô hình thực thi, và để ngăn điều đó thì phải bảo trì rất công phu. Cách khó hơn là gắn tài liệu trực tiếp vào code, hoặc đặt tài liệu lên trước code như trong literate programming
Vì vậy, khi truyền đạt mô hình tinh thần, thường đúng nhất là chọn cách tốn ít công sức và bảo trì tối thiểu: vẽ nguệch ngoạc trên khăn giấy và cùng thao tác với hệ thống thực qua thời gian
Có lý do khiến người mới thường bắt đầu bằng việc sửa bug dễ chứ không phải viết tài liệu thiết kế
Người mới cần học qua thực hành, nên tutorial có thể là phù hợp nhất. Nhưng sau khi đã động tay vào một thời gian, nhiều khả năng họ sẽ có vài hiểu lầm, và ta có thể gỡ chúng bằng phần giải thích trên hình vẽ nguệch ngoạc trên khăn giấy
Vì vậy nếu quyết định viết tutorial, đừng cố tạo một tài liệu “mọi thứ”, mà hãy viết một tutorial tốt với trọng tâm rõ ràng
Viết lách là câu trả lời
Phần mềm khá thú vị vì nó là một phương tiện động mang tính cá nhân
Tôi nghĩ hệ thống tương tác sẽ hữu ích. Ví dụ như Python và một trình gỡ lỗi trực quan để dạy về các biến được đóng hộp