các loại “thông tin” trong dự án

Trong một kế hoạch làm tài liệu training (lại training) lần thứ n….

Đề bài đặt ra là làm sao bạn quản lý được các trao đổi trong công việc, không bị bỏ sót hay nói trước quên sau …

Tự dưng tôi tò mò không biết nếu dán nhãn các trao đổi trong công việc dự án của mình và gom tất cả lại thì nó sẽ thành ra thế nào nhỉ?

I. Liệt kê

Chả hiểu sao nỗi tò mò ấy cứ bám lấy tâm trí, thành ra tôi đành chiều nó mà list up ra một chút naming các thể loại, bắt đầu từ những thứ hay gặp hàng ngày,

Yêu cầu : mới, đang phát triển, done

yêu cầu của cty, ISMS, Mgr. …

QA , Spec

lịch chạy batch

Vấn đề

Vận hành

Tác vụ

các tài liệu isms (xin dùng thông tin cá nhân, NDA  ….)

….

Mới chỉ là một danh sách rời rạc, chưa có gì thú vị

Ngoài ra tôi để ý thấy sự trùng lặp trong danh sách bên trên, khi một thứ có thể liên quan hoặc bao gồm những thứ khác

Ví dụ Vấn đề cũng có thể là vấn đề phát triển cũ/ mới/ đã done giờ đào mộ lại

Vấn đề có thể liên quan đến Vận hành hay Spec, hay lịch chạy batch, hoặc nảy sinh từ Tác vụ nào đó. Tác vụ thì cũng đủ kiểu cả, cũng có thể là các tác vụ phát triển cũ, mới, ….

Những thứ rời rạc tôi list up ra ở trên rõ ràng không có cùng độ lớn, cái này có thể bao gồm cái kia. Chúng lại quan hệ tương tác đa chiều, cùng lúc tương tác với nhiều thứ khác nữa, khá rối rắm.

Thế là tôi nghĩ đến sơ đồ, đến mô hình. Chắc xu hướng của tôi là thế, thấy đống khái niệm là lại muốn truy tìm mô hình. Có vẻ kẻ săn mô hình trong tôi lại tìm thấy một tình huống vừa quen vừa lạ với nó, và sẵn sàng để thử challenge việc sắp xếp cái đống rời rạc trên vào một Sơ đồ.

II. Nhóm và cấu trúc hoá

Thế là để chiều lòng tay thợ săn bên trong, tôi đi tiếp. Tiếp tục cứ brain storm, list up cho hết đi đã, list up cho đến khi cảm thấy cũng không còn lại gì (exhaustive) đi.

Sau khi list up hòm hòm, cố gắng group chúng lại trong một dạng cấu trúc logic nào đó

Sau vài ngày vật lộn thì tôi ra được đoạn text bên dưới thể hiện tàm tạm một cấu trúc ban đầu với các khái niệm nghĩ ra được:

Lĩnh vực communicate quan tâm đến nhiều loại thông tin, các thông tin đó chia thành vài category lớn

Yêu cầu

nguồn gốc: Từ khách hàng, từ công ty, từ ban ISMS, từ Mgrs …

các loại Yêu cầu:

. Nhóm Yêu cầu liên quan đến phát triển: phát triển mới, đang phát triển, đã phát triển xong (1)

. Nhóm Yêu cầu liên quan đến vận hành: điều tra, báo cáo, monitor error, API bên thứ 3, dịch vụ Infra …. (2)

Vấn đề

là các vấn đề phát sinh trong quá trình phát triển hoặc vận hành đã mô tả ở (1) và (2)

nguồn gốc có thể từ tất cả: khách hàng, từ công ty, từ ban ISMS, từ Mgrs, từ bên thứ 3, từ dịch vụ Infra, từ resource  …

Yêu cầu và Vấn đề được giải quyết thông qua các Tác vụ

Có các tác vụ cho Phát triển, các tác vụ cho vận hành

Các tác vụ được sắp xếp thực hiện theo Quy trình: Điều tra, Làm rõ scope, lên kế hoạch, estimate, approve, dựng hạ tầng, thực hiện dev, thực hiện test, release, bảo trì …

Ngoài ra, Resource (team, có PM, Dev., QA, …) được phân công để thực hiện các tác vụ

Resource plan thường được ổn định quyết định trước ít nhất vài tháng cho đến một năm

Với thông tin tàm tạm trên, giờ tôi lôi AI ra hỏi đáp

III. Bàn luận cùng AI

Câu chuyện với AI cũng khá dài dòng.

Đầu tiên, tôi muốn ăn sẵn nên nhờ vả bằng prompt:

Hãy viết lại đoạn sau cho đầy đủ đồng thời hệ thống hoá lại cho có cấu trúc dễ hiểu, highlight các từ lặp lại vì chúng sẽ là các keyword cần chú ý: …. (paste đoạn tàm tạm ở trên vào)

Tôi hy vọng AI có thể bổ sung thêm các khái niệm mới cho đoạn mà nó nhận được, nhưng nó chẳng làm được như vậy, chỉ giỏi xuống dòng cho mỗi từ và viết lại vào một cấu trúc phân cấp mà thôi. Bảo AI vẽ ra một cái sơ đồ mindmap dạng visual thì chỉ nhận được một cái ảnh nhìn thì ra vẻ đấy nhưng nội dung khá linh tinh,

Haizz, thôi đành bảo nó vẽ lại cái cấu trúc hiện tại và tự suy nghĩ thêm.

Hiện tại, phần Tác vụ đã được mô tả chúng xuất phát từ đâu, liên hệ với các khái niệm nào, theo quy trình nào, nhưng chưa có phần đầu ra (output). vì thế tôi tự liệt kê thêm các kết quả đầu ra ấy.

Đưa nội dung đã bổ sung cho AI, hỏi nó có hợp lý không? Nó không trả lời mà chỉ phản ánh nội dung bổ sung vào cấu trúc trước đó nó từng trả lời và bổ sung một nhận xét về bản thân cấu trúc do nó tổng hợp:

Cấu trúc này làm rõ hơn mối quan hệ giữa Yêu Cầu – Vấn Đề – Tác Vụ – Resource, giúp dễ theo dõi hơn. Bạn thấy cách viết này ổn chứ?

OK, cũng coi như đồng ý được với ông bạn AI cái khung.

III. Lên sơ đồ

Sau một hồi yêu cầu AI vẽ mindmap với nội dung cấu trúc do chính nó tạo ra, tôi thấy khá thất vọng với trình độ vẽ vời của nó, đành để đó và tự mình dành thời gian vẽ bằng một công cụ online cùi bắp

Đây là kết quả, cũng gọi là tàm tạm.

Phần mũi tên thì không vừa lòng lắm, đôi khi tôi muốn có một mũi tên 2 đầu nhưng tool cùi bắp không có option này

Dù sao thì tôi cũng đã ra được một mô hình.

Rồi sao? Nó có tác dụng gì? Dùng để làm gì? Thậm chí đơn giản hơn là đọc sơ đồ này như thế nào?

Tôi còn chưa nghĩ đến điều những điều đó. Hãy cứ vui vẻ với kết quả tự do sáng tạo trong hiện tại đi đã. Còn tương lai kiểu gì cũng sẽ đến, cứ để nó đến theo cách của nó.

Cảm ơn đã đọc bài và hẹn gặp lại bạn ở tương lai.

Hết bài

— ghi lại cấu trúc bằng text bởi AI —-

Communicate
│
├── Thông tin
│ ├── Yêu cầu
│ │ ├── Nguồn gốc
│ │ │ ├── Khách hàng
│ │ │ ├── Công ty
│ │ │ ├── Ban ISMS
│ │ │ ├── Managers (Mgrs)
│ │ │ ├── Bên thứ 3 (đối tác, vendor)
│ │ │ ├── Dịch vụ hạ tầng (Infra)
│ │ │ ├── Resource nội bộ (PM, Dev, QA, …)
│ │ │
│ │ ├── Phân loại Yêu cầu
│ │ │ ├── Liên quan đến Phát triển (1)
│ │ │ │ ├── Phát triển mới
│ │ │ │ ├── Đang phát triển
│ │ │ │ ├── Đã phát triển xong
│ │ │ │
│ │ │ ├── Liên quan đến Vận hành (2)
│ │ │ ├── Điều tra nguyên nhân
│ │ │ ├── Báo cáo & Logging
│ │ │ ├── Monitor lỗi hệ thống
│ │ │ ├── API bên thứ 3
│ │ │ ├── Dịch vụ hạ tầng (Infra)
│ │ │ ├── Yêu cầu nâng cấp / bảo trì hệ thống
│
│ ├── Vấn đề
│ ├── Định nghĩa: Là những lỗi hoặc khó khăn phát sinh trong quá trình phát triển và vận hành.
│ ├── Phát sinh từ:
│ │ ├── Yêu cầu phát triển (1)
│ │ ├── Yêu cầu vận hành (2)
│ │
│ ├── Nguồn gốc Vấn đề
│ ├── Khách hàng
│ ├── Công ty
│ ├── Ban ISMS
│ ├── Managers (Mgrs)
│ ├── Bên thứ 3 (đối tác, vendor)
│ ├── Dịch vụ hạ tầng (Infra)
│ ├── Resource nội bộ (PM, Dev, QA, …)
│
├── Giải quyết Yêu cầu & Vấn đề
│ ├── Các loại Tác vụ
│ │ ├── Tác vụ cho Phát triển
│ │ ├── Tác vụ cho Vận hành
│ │
│ ├── Quy trình thực hiện
│ │ 1. Điều tra nguyên nhân
│ │ 2. Làm rõ scope & yêu cầu cụ thể
│ │ 3. Lập kế hoạch triển khai
│ │ 4. Estimate tài nguyên và thời gian
│ │ 5. Approve kế hoạch
│ │ 6. Dựng hạ tầng & chuẩn bị môi trường
│ │ 7. Thực hiện phát triển (Dev)
│ │ 8. Thực hiện kiểm thử (Test)
│ │ 9. Release phiên bản mới
│ │ 10. Bảo trì & theo dõi vận hành
│ │
│ ├── Kết quả đầu ra
│ ├── Schedule / Timeline
│ ├── Kế hoạch tổng thể (Plan)
│ ├── Q&A logs
│ ├── Đặc tả yêu cầu (Spec)
│ ├── Danh sách lỗi & sự cố (Bug/Error list)
│ ├── Lịch trình vận hành
│ ├── Deliverables (Tài liệu bàn giao)
│ ├── Release note (Ghi chú phát hành)
│ ├── Operation notes (Hướng dẫn vận hành)
│
└── Resource (Nhân sự thực hiện)
├── Thành phần đội ngũ
│ ├── PM (Project Manager)
│ ├── Dev (Developer)
│ ├── QA (Quality Assurance)
│ ├── Các team hỗ trợ khác
│
├── Resource Plan
├── Lập kế hoạch nhân sự từ trước
├── Quyết định trước tối thiểu vài tháng → một năm
├── Đảm bảo phân bổ nguồn lực hợp lý