Qua một đợt hướng dẫn sinh viên làm bài tập lớn, đồ án, thực tập… mới thấy khả năng viết báo cáo của sinh viên quá kém. Rất nhiều lỗi trong các báo cáo, từ lỗi thông thường như chính tả, định dạng… cho đến các lỗi diễn đạt, trích dẫn tài liệu.

Để giúp nhận biết các lỗi thường gặp, tôi liệt kê những lỗi thường gặp nhất để tránh thành ba phần: Lỗi về ngôn ngữ, văn phong, lỗi về trình bày và lỗi về nội dung văn bản.

Lỗi về ngôn ngữ, văn phong

Lỗi chính tả

Đây là một lỗi căn bản nhưng thường gặp nhất trong các báo cáo. Lỗi này có nhiều nguyên nhân như trình độ tiếng Việt của người viết còn hạn chế (!!!), bất cẩn, nhầm lẫn, hoặc do đánh máy sai. Tuy nhiên, dù lý do gì thì lỗi này đều gây cho người đọc cảm giác khó chịu, đôi khi còn gây hiểu lầm.

Để tránh lỗi này không khó. Từ khi mới biết chữ, ta đã được rèn giũa về chính tả. Chỉ cần chú ý một chút khi viết, ta có thể hạn chế rất nhiều lỗi này. Đôi khi gặp những từ khó, dễ nhầm lẫn thì nên tra từ điển tiếng Việt (nhưng đối với sinh viên kỹ thuật thì đây là thứ hơi bị hiếm, có thể dùng các từ điển trực tuyến), tra cứu trên mạng (dùng Google), hoặc nhanh nhất có thể hỏi những người chung quanh (cách này thì không đảm bảo lắm nếu người kế bên cũng như mình ).

Sau khi viết, ta cố gắng bỏ một chút thời gian để đọc lại báo cáo. Việc này rất quan trọng, nó giúp phát hiện ra những lỗi đánh máy (thường thì ta chủ quan, nghĩ rằng mình đánh máy không bao giờ sai). Ngoài ra nó còn giúp sửa những lỗi khác như ngữ pháp, diễn đạt…

Lỗi dùng từ

Trong nhiều báo cáo dùng các từ không thích hợp cho một văn bản khoa học và kỹ thuật như các đại từ ngôi thứ nhất: tôi, ta, chúng ta, chúng tôi… Các từ cảm thán như nhé, được không… hoặc sử dụng các từ địa phương, văn nói trong báo cáo. Lỗi này làm cho một báo cáo kỹ thuật trở nên không nghiêm túc.

Ở các trường hợp dùng các đại từ ngôi thứ nhất, ta có thể sử dụng chuyển sang thể bị động để loại bỏ đại từ đi. Thí dụ: “Chúng tôi đã thực hiện công việc…” nên được viết lại thành “Công việc… đã được thực hiện”. Hoặc ta có thể dùng một cách khác (nhưng nên hạn chế) là thay thế các đại từ đó bằng các từ “đề tài”, “luận văn”…

Lỗi diễn đạt

Nhiều báo cáo có những đoạn văn mà người đọc không hiểu được ý tác giả muốn nói gì. Các đoạn văn đó có thể rất lủng củng, ý không rõ ràng, hoặc ý trước mâu thuẫn với ý sau. Có trường hợp người viết diễn giải lan man mà không có câu chủ đề cho đoạn văn. Hoặc trường hợp khác là câu văn rất dài, cấu trúc phức tạp làm người đọc bị rối, không hiểu được ý câu văn.

Lỗi này thường xảy ra khi người viết không đọc lại những gì mình đã viết. Nếu chịu khó đọc lại dù chỉ một lần, người viết sẽ nhận ra ngay các đoạn này. Do đó, lại có thêm một lý do nữa để bắt buộc thực hiện việc “đọc lại”.

Để tránh viết ra những đoạn như vậy, ta nên tuân thủ theo cách viết một văn bản tiếng Anh: mỗi đoạn văn có một câu chủ đề, các ý khác sẽ triển khai câu chủ đề đó. Trong văn bản khoa học, câu chủ đề nên đặt ở câu đầu tiên của đoạn văn, hoặc câu thứ hai trong đoạn văn. Các câu tiếp theo sẽ triển khai ý đã được nêu trong câu chủ đề. Các câu văn nên viết theo một cấu trúc đơn giản, dễ hiểu.

Lỗi trình bày

Việc trình bày một văn bản rõ ràng, mạch lạc giúp người đọc không bị rối khi đọc một báo cáo. Cách trình bày một văn bản đã được dạy trong môn Văn ở trung học, tuy nhiên chỉ nói một cách chung chung, không cụ thể. Tuy nhiên ta có thể quan sát cách trình bày trong báo chí, sách, báo cáo… để học hỏi thêm.

Những lỗi thường gặp khi trình bày:

Cách đánh số

Cách đánh số rất quan trọng để người đọc nắm được cấu trúc của bài viết. Cách đánh số cần phải được thống nhất và theo một trình tự lớn nhỏ và nhất quán.

Nhiều báo cáo đánh số không thống nhất. Thí dụ: đánh số báo cáo theo kiểu phân cấp (tiêu đề cấp 1: 1, tiêu đề cấp 2: 1.1, tiêu đề cấp 3: 1.1.1, …) nhưng đâu đó lại đánh số: 1., 1.1., a. hoặc đánh số không theo thứ tự (số La Mã, số nguyên, chữ cái hoa…).

Một số báo cáo bị lỗi nặng hơn: ở các chương đầu đánh số theo số La Mã, ở các chương sau lại đánh số theo chữ in hoa!!!

Khi chia bố cục báo cáo, các nội dung nào có liên quan với nhau sẽ được gom chung vào một mục. Trong một mục nếu nội dung không liên quan với nhau thì tách thành nhiều mục con. Thí dụ:

Chương 1 : xxxxx

Chương 2: yyyyyy

2.1. y1y1y1y1

2.2. y2y2y2y2

Chương 3: zzzzz

…

Có một lỗi mà các báo cáo cũng hay gặp: chỉ tạo một mục con. Thí dụ: có phần 2.1.1 nhưng không có phần 2.1.2. Trường hợp này nghĩa là chỉ có một nội dung trong mục này, ta không cần tạo mục con.

Để tránh lỗi này, ta nên sử dụng: (1) LaTeX; (2) Chức năng Style của Micro$oft Word.

1. Nếu dùng LaTeX thì việc đánh số và định dạng xem như không cần quan tâm, vì triết lý của TeX là: người dùng chỉ cần quan tâm về nội dung, hình thức đã có TeX lo.
2. Khi sử dụng style của Word, ta chỉ cần định nghĩa lần đầu cho các Heading về định dạng, font chữ, đánh số… Sau đó ta dùng các style này cho các tiêu đề. Nếu sau này ta muốn thay đổi định dạng, cách đánh số của các đề mục thì chỉ cần thay đổi style, tất cả sẽ được thay đổi theo. Sử dụng style cũng giúp ta dễ dàng trong việc sinh mục lục cho báo cáo sau này.

Hình ảnh, bảng biểu và công thức

Hình ảnh và bảng biểu là một phần quan trọng của báo cáo, nhất là các báo cáo trong ngành kỹ thuật. Nó giúp làm ngừoi đọc hiểu các vấn đề tốt hơn và minh họa cho báo cáo. Tuy nhiên việc sử dụng hình ảnh, bảng biểu và công thức cũng hay gặp các lỗi như không liên quan đến nội dung, không rõ ràng, không được giải thích…

Trong một số báo cáo, các bảng biểu, hình ảnh và công thức không được đánh số. Việc không đánh số làm việc tham khảo đến các hình ảnh/bảng biểu/công thức khó khăn, dễ bị nhầm lẫn. Thông thường do người viết nghĩ hình ảnh đó chỉ được sử dụng ngay bên dưới đoạn văn nên chỉ cần nói “hình bên dưới” là đủ. Tuy nhiên trong các báo cáo kỹ thuật và khoa học thì cần phải đặt tên để việc tham khảo đến từ các tài liệu khác được dễ dàng hơn. Ngoài ra ta cũng không nên sử dụng cách thao chiếu “xem hình bên dưới”, mà nên sử dụng “xem hình x”. Khi sử dụng cách tham chiếu “hình bên dưới”, ta thường gặp việc thừa một nửa trang giấy trống bên dưới do hình quá lớn phải qua trang nhằm đảm bảo cụm từ “xem hình bên dưới” đúng!!! Thay vào đó, khi ta dùng cách gọi “xem hình x” thì ta có thể đưa hình đến một ví trí nào thích hợp cho việc dàn trang.

Cách đánh số của hình/bảng/công thức có thể sử dụng cách đánh số tuần tự từ đầu báo cáo trở đi (1, 2, 3…) hoặc dùng cách đánh số theo chương (Chương 1: hình 1.1, 1.2,… Chương 2: hình 2.1, 2.2…). Khi đánh số ta cũng cần lưu ý những lỗi như ở phần “Cách đánh số” đã nhắc tới.

Đối với bảng biểu và hình ảnh thì cần phải được đặt tên. Tên của hình ảnh, bảng biểu giúp người đọc hiểu được vấn đề mà hình ảnh hoặc bảng biểu đó muốn nói. Nếu ta không thể đặt tên cho hình ảnh/bảng biểu đó tức là nó chưa đủ rõ ràng, ta cần xem xét lại.

Hình ảnh, bảng biểu và công thức khi được đưa vào báo cáo thì cần phải được sử dụng và giải thích. Rất nhiều báo cáo chỉ để hình ảnh/bảng biểu vào để “lấp đầy” báo cáo. Người đọc sẽ hoàn toàn không hiểu ý đồ tác giả muốn nói ở hình ảnh đó là gì, hoặc đoạn nào mô tả hình ảnh đó.

Chất lượng của hình ảnh thấp cũng là một lỗi thường gặp. Các hình ảnh được chụp từ các báo cáo khác, hoặc lấy từ một nguồn trên mạng thường có độ phân giải thấp. Người đọc sẽ rất khó chịu khi xem các hình ảnh này. Nếu chất lượng quá kém thì người dùng không thể đọc được hình. Trong trường hợp này, nếu ta không thể tìm được hình ảnh có chất lượng tốt hơn thì nên vẽ lại. Hình ảnh được đưa vào báo cáo nên ở dạng vector, không bị ảnh hưởng khi co dãn và sẽ giữ được chất lượng khi in. Nếu không thể có hình vector thì có thể dùng ảnh bitmap, nhưng độ phân giải phải đạt khoảng 300 dpi để đảm bảo chất lượng khi in.

Lỗi về hình ảnh và bảng biểu khác là quá chi tiết. Thí dụ: một bảng có khoảng 20 cột, hoặc một bản vẽ ERD có khoảng 20 thực thể và đầy đủ các thuộc tính của các thực thể. Những hình ảnh này hầu như vô nghĩa với người đọc, vì họ không có khả năng nắm bắt được. Những trường hợp này ta nên loại bỏ bớt các thông tin không quan trọng, làm các tổng kết hoặc chia nhỏ thành nhiều bảng/hình nhỏ hơn với chi tiết cho từng loại thông tin. Nếu bắt buộc phải có các hình ảnh hoặc bảng biểu đó, ta nên in với các khổ giấy lớn hơn.

Lỗi sử dụng khoảng trắng (space), dấu câu

Có báo cáo viết một đoạn văn rất dài, trong đó hoàn toàn không có một dấu chấm câu! Đoạn văn viết như vậy chắc chỉ có Minh Vương hoặc Lệ Thủy mới đủ hơi để đọc. Lỗi này không bàn nữa.

Một lỗi rất phổ biến là sử dụng khoảng trắng (space) không đúng. Việc sử dụng tùy tiện hoặc thiếu khoảng trắng làm văn bản trở nên xấu và khó nhìn. Ta cần phải biết một số nguyên tắc sử dụng khoảng trắng:

• Đối với các dấu câu như chấm, phẩy, hai chấm, chấm hỏi, chấm than: không được đặt khoảng trắng phía trước dấu câu, và có một khoảng trắng phía sau dấu câu.
• Đối với các dấu ngoặc đơn hoặc ngoặc kép: phía ngoài dấu ngoặc có một khoảng trắng (trừ khi phía sau dấu đóng ngoặc làm một dấu câu thì không có khoảng trắng); phía trong dấu ngoặc không có khoảng trắng.

Lỗi định dạng

Nhiều báo cáo bị lỗi về sử dụng font chữ. Font chữ thường được sử dụng để viết báo cáo là loại font Serif (font chữ có chân). Font chữ Serif phổ biến nhất của Windows là font Times New Roman. Ngoài ra có thể dùng những font Serif khác như Georgia hay Palatino (trên Mac OS). Đối với các tiêu đề, ta có thể sử dụng thêm loại font Sans-Serif (font chữ không chân). Có nhiều font chữ Sans-Serif trên Windows như Arial, Tahoma, Verdana… và những font khác như Helvetica, Gotham. Khi cần mô tả các đoạn mã nguồn, ta phải sử dụng các loại font Monospace (font có chiều rộng bằng nhau đối với tất cả ký tự) như: Courier New, Lucida Console hoặc Monaco (trên Mac OS).

Kích thước font trong báo cáo không được quá lớn, cũng không được quá nhỏ. Thông thường font với kích thước 12 pt được sử dụng nhiều nhất. Đối với các tiêu đề thì có thể lớn hơn, nhưng không nên lớn quá 16 pt.

Đối với định dạng đoạn văn: giữa các đoạn văn không nên cách nhau bằng một dòng trống (chỉ nhấn enter), mà nên sử dụng thuộc tính “Space before” vả “Space after” của Paragraph Properties. Khoảng cách phía trước và sau mỗi đoạn văn nên là 6pt và 0pt.

Lỗi nội dung

Lỗi này rất khó sửa đối với một bài báo cáo. Nó phụ thuộc rất nhiều vào nội dung mà người viết muốn nói tới. Đối với lỗi này, ta có thể tránh bằng cách lập một dàn ý chi tiết cho bài báo cáo, sau đó dựa theo dàn ý đó để viết.

Các báo cáo thường gặp trường hợp sinh viên không biết diễn đạt công việc của mình làm mà chỉ nói về nội dung khác. Mặc dù phần kiến thức mình tìm hiểu được thông qua một đề tài rất quan trọng, nhưng nó chỉ là phần hỗ trợ cho mình để hoàn thành đề tài. Tuy nhiên, do không biết cách trình bày nên thường thì phần nội dung liên quan rất dài dòng, và đôi khi cũng không liên quan đến đề tài của mình. Trong khi đó phần việc mình làm thì nói rất sơ sài.

Các thông tin liên quan đến đề tài ta chỉ nên nêu cô đọng, nổi bật lên những phần có liên quan trực tiếp đến đề tài. Những phần khác, nếu cần thiết, ta có thể đưa vào phần phụ lục để người đọc tham khảo khi cần thiết.

Một thói quen của nhiều người khi viết báo cáo ngành Máy tính là để mã nguồn chương trình vào báo cáo. Điều này rất vô nghĩa, bởi vì người đọc không phải là một trình biên dịch! Người đọc chỉ có thể hiểu được phần mềm thông qua các sơ đồ, biểu đồ mô tả hệ thống.

Kết luận

Để viết một báo cáo thành công, ngoài việc nắm rõ cách trình bày một văn bản, cách diễn đạt nội dung thì cách tốt nhất là cố gắng viết thường xuyên. Hỏi những sinh viên có những bản báo cáo đầy lỗi, thì tất cả đều cho biết đây là lần đầu tiên viết báo cáo! Như vậy, dù có đọc qua bao nhiêu sách vở, học bao nhiêu khóa, nhưng không thực hành thì sẽ khó làm tốt được. Vì vậy, ngay bây giờ hãy tạo một trang blog, và cố gắng viết một cách đàng hoàng nhất (tức là không sử dụng ngôn ngữ mạng) để học dần cách viết.