Viết document cho một project

Em đang muốn tìm hiểu về cách viết document cho một project, như là phải viết những gì? Có phải trình bày theo mẫu nào không?
Em có search trên google nhưng không tìm thấy bài viết nào hướng dẫn thực sự cho newbie như e. Mong a/c giúp đỡ

1 Like

Bạn định nghĩa rõ 2 cái: “viết document” là víết cái gì? “project của bạn là cái gì”. Bởi vì 2 chữ đó rất chung chung, không có tình huống cụ thể thì sẽ rất khó để người ta trả lời bạn.

Khi ngay cả bạn cũng không biết bản thân đang hỏi gì, cái bạn nhận được cũng là… không có gì.

Theo ý mình hiểu thì project có rất nhiều biểu hiện trong thực tế, quy mô khác nhau, có những cái cụ thể là một sản phẩm phần mềm, nhưng có những cái nó là một kế hoạch chuyển đổi số cho cả một công ty, rồi có trường hợp project lại chỉ là… hello world.

Document thì có nhiều thứ: tài liệu kỹ thuật, tài liệu hướng dẫn người dùng, tài liệu đặc tả về kỹ thuật, các quy định…

Trường hợp bạn cũng chẳng biết phân biệt thì nên tìm hiểu hoặc kể lại toàn câu chuyện của bạn lên đây để người khác thử xem bạn đang muốn hỏi cái gì.

11 Likes

Tuỳ vào các thức quản lý, quy trình, tiêu chuẩn của mỗi công ty mà cần có những document khác nhau.

Và trong dự án, với sự tham gia của nhiều bộ phận thì sẽ có nhiều thể loại document hơn nữa.
Ví dụ,

  • bên team PM với BA, thì ngoài cái đống documments để về “paperworks” như resource/time planning, memo với khách hàng, release notes cho mỗi version, … , thì sẽ có những thứ như documents thể hiện requirements thô từ khách hàng, requiremetns analysis documents, use cases
  • bên team dev thì sẽ có 1 đống document khác nữa, từ architecture/design, database design, TDD…
  • team QA/QC thì sẽ có test plan, test cases, …
  • team design (nếu có)
  • team sysadmin/devops
  • rồi user guides và implementation guide …

Tóm lại là nhiều lắm.

Mình đoán là bạn muốn làm một project bài bản, nên muốn hỏi vụ document này. Nên mình suggest bạn chia documents làm 2 loại:
#1 là process documentation
#2 là product documentation

Cái #1 là để lưu lại thông tin về dự án (yêu cầu thô từ khách hàng, yêu cầu đã được phân tích, uses cases thực tế suy ra được từ những yêu cầu đó), về code (Tất tần tật về code luôn, cách thức tổ chức, design, note những thay đổi qua từng version)… Tóm lại, giờ đùng cái bạn/team bạn khhông làm dự án đó nữa, và bàn giao cho 1 team khác, thì họ có thể tiếp tục hay maintanace project đó mà không cần liên lạc bạn để hỏi này nọ

Cái 2, là thông tin về sản phẩm. Tức bạn làm xong, đưa cho team triển khai, họ có đầy đủ documents để có thể cài đặt/sử dụng phần mềm của bạn mà không cần alo bạn để hỏi cái này cài ra làm sao, cài trên linux hay windows, … và tất nhiên là bao gồm hướng dẫn sử dụng cho end-user

Tên từng loại documents thì bạn cứ google, sẽ có nhiều mẫu
(những dự án lớn, có có riêng 1 người hoặc 1 team nhỏ chuyên xử lý món documents này luôn đó)

12 Likes

Cảm ơn câu trả lời của bạn.
Nó thực sự hữu ích đối với mình.
Chắc là với người hỏi cũng vậy :smiley:

83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?