Làm thế nào để có một dự án hoàn thành tốt đẹp, làm sao để dự án ít bị rủi ro, và làm sao để bạn có thể quản lí dự án thật tốt.
Để có thể đưa dự án trở nên tốt đẹp thì bạn cần hiểu được dự án đó sẽ có quy trình vận hành như thế nào. Hôm nay. Hoccanban sẽ chia sẻ kinh nghiệm quản lí dự án của bản thân mình.
Khi vào một dự án thì bạn tự đặt câu hỏi sẽ bắt đầu tư đâu và cần những gì, mình xin chia ra 4 mục như sau:
 |
| Hình ảnh WBS |
1. Chuẩn bị dự án
2. Khởi động dự án
3. Trong quá trình chạy dự án (Thực thi dự án)
4. Kết thúc dự án
1. Chuẩn bị dự án
Khi cấp trên giao cho bạn 1 dự án thì việc chuẩn bị cho dự án sẽ là khó khăn nhất, vậy bạn cần chuẩn bị những gì.
Đầu tiên, cần xác nhận thể chế, tiến hành và xác nhận nhân sự.
Xác nhận thể chế dự án như thế nào, số lượng các thành viên: leader(người quản lí), Subleader(người hỗ trợ quản lí), Comtor(người phiên dịch), Checker(Người kiểm tra kết quả đầu ra, Member(người tạo ra sản phẩm).
 |
| Hình minh họa |
Thứ hai, Xác định năng lực nhân sự
Cách nhìn người và chọn người vào dự án khá quan trọng khi bạn phải điều chỉnh ai sẽ là người đảm nhiệm phù hợp các vị trí đó dựa vào kinh nghiệm, sức lực và tầm nhìn.v.v.
Trong thời gian training, chạy thử dự án nếu có thành viên năng lực yếu hoặc không phù hợp với công việc dự án thì nên cân nhắc,báo tình hình và bàn bạc với trưởng bộ phận loại ngày từ đầu để đỡ mất công đào tạo và ảnh hưởng dự án sau này
Thường ban đầu sẽ ưu tiên chọn người đã có kinh nghiệm và khả năng quản lý nhóm đảm nhận vai trò checker,super checker sau quá trình làm việc xác nhận lại năng lực để thay đổi vai trò nhân sự hợp lý, và luân chuyển nhân sự để cân bằng năng lực giữa các nhóm check
2. Khởi động dự án
Khi khởi động dự án, bạn cần phải lên kế hoạch setup những gì cần thiết.
2.1 Xác nhận môi trường: phòng, thiết bị, vấn đề bảo mật, nơi đặt thư mục dự án, cấu trúc thư mục
Xác nhận chỗ ngồi của dự án, thiết bị sử dụng, vấn đề bảo mật (cần phòng riêng, cửa khóa thẻ hay không…)
Xác nhận account, ip, quyền truy cập của các thành viên trong dự án
Xác nhận nơi đặt thư mục dự án, tạo cây thư mục, và tạo sơ đồ thư mục để yêu cầu IT admin phân quyền
2.2 Tạo file WBS
WBS là file không thể thiếu trong khi chạy dự án, WBS có nghĩa là lịch trình công việc mà bạn đưa ra bao gồm Nội dung công việc, người đảm nhận, thời gian bắt đầu, thời gian kết thúc, tiến độ.v.v.
|
| Hình ảnh WBS |
Thực hiện theo lộ trình đã đưa ra, nếu có thay đổi thì cần cập nhật và chia sẻ với các thành viên liên quan dự án.
Thảm khảo cách tạo File WBS ở:
2.3. Xác nhận tiêu chuẩn, tool, cách làm, file quản lý
Những thứ liên quan đến tài liệu(tiêu chuẩn, QA), Tool(công cụ), quy trình làm, tạo file quản lí.v.v. cần rõ ràng và cần trao đổi với những người có kinh nghiệm trước đó.
Sau khi đã có các tài liệu trên, bạn cần chia sẻ thật kĩ(Training) cho các thành viên trong dự án, đặc biệt là những người chưa có kinh nghiệm.
 |
| Các phím tắt trong Excel |
Tiêu chuẩn ban đầu có thể chưa chi tiết hoặc có những điểm không rõ ràng, trong thời gian làm thử cố gắng trao đổi, bàn bạc, và xác nhận kĩ với các thành viên trong dự án để có thể tạo ra các file QA xác nhận với Khách hàng. Tránh trường hợp hiểu sai sẽ làm chất lượng đi xuống và mất niềm tin với Khách hàng.
Tool lúc đầu có thể chưa tối ưu, nên xem xét và xin cải thiện nếu được
Cách làm, file quản lý đưa ra có thể chưa phù hợp với tình hình phía thực tế dự án, nếu thấy gây khó khăn cho phía Leader điểm gì nên trao đổi để thay đổi.
2.4. Xác nhận quy trình vận hành dự án, tạo quy trình làm việc
Cần xác nhận quy trình tải dữ liệu, tài liệu : tải ở đâu, bằng cách nào, tài liệu và dữ liệu làm việc sẽ nhận bao gồm những file gì
Xác nhận quy trình tạo và gửi QA: xác nhận quy tắc đặt tên file, đặt QA ở đâu, báo cáo qua đâu (skype, hay mail chẳng hạn)
Xác nhận quy trình nhập file quản lý: xác nhận quy tắc nhập file quản lý, nhập ở những cột nào, ý nghĩa của các cột
Xác nhận quy trình nộp kết quả và báo cáo kết quả: xác nhận kết quả nộp bao gồm những file gì, quy tắc đặt tên file, cách tập hợp file, thời điểm nộp file, dữ liệu nộp đặt ở đâu, nội dung báo cáo kết quả nộp như thế nào, báo cáo qua đâu (skype/ mail)
Xác nhận quy tắc nộp feedback, nơi nhận và nộp, thời điểm nhận feedback và nộp kết quả sửa feedback
Xác nhận và tạo quy trình làm việc của người làm, người check, người super checker
Đối với tất cả các quy trình nếu thấy không phù hợp hay khó khăn, mất thời gian ở điểm nào thì nên bàn bạc với các bên để đưa ra giải pháp tối ưu nhất.
2.5 Tiến hành làm thử, thống nhất tiêu chuẩn và mục tiêu hợp lý
Tiến hành làm thử xem có đạt được số lượng dự định hay không
Cho các thành viên thử làm, check, sau đó dựa vào con số làm được cao nhất, thấp nhất của mỗi người và trung bình của dự án để tính toán mục tiêu có thể đạt được.
Nên phân biệt thời gian làm mới và thời gian sửa, thời gian check để xác định rõ năng suất
Nên đo trên càng nhiều dữ liệu khó dễ khác nhau càng tốt để có thể dự tưởng được tỉ lệ xuất hiện của đối tượng và ảnh hưởng của dữ liệu đến sản lượng chính xác hơn , nếu được cùng 1 dữ liệu nên nhiều người tiến hành làm để lấy được con số theo năng lực trung bình
Nếu dự án có nhiều đối tượng thì nên phân biệt thời gian cho từng đối tượng riêng biệt và tính trên đơn vị nhỏ nhất để việc tính toán mục tiêu chính xác hơn
Nếu được nên thử tiến hành làm theo nhiều cách, quy trình khác nhau để xem phương pháp nào sẽ tối ưu, đem lại hiệu quả cao, rút ngắn thời gian nhất
Nếu số lượng làm thử thấp hơn số lượng mục tiêu yêu cầu thì phải xác nhận nguyên nhân, thảo luận lại với phía Khách hàng ngay từ đầu để thống nhất mục tiêu phù hợp với thực tế.
Nên thống nhất tiêu chuẩn và mục tiêu hợp lý trong quá trình làm thử để tránh những khó khăn về sau
Mỗi lần thay đổi tiêu chuẩn, nên tính toán lại xem có ảnh hưởng đến mục tiêu hiện tại hay không, nếu có ảnh hưởng phải trao đổi với phía Khách hàng để thay đổi số mục tiêu và deadline ở file kế hoạch hợp lý
2.6. Tạo file kế hoạch và xác nhận với phía Khách hàng
 |
| Ví dụ File kế hoạch |
Xác nhận số lượng và chất lượng mục tiêu dự án cần đạt được, thời gian training, thời gian chạy dự án (bao gồm thời gian làm mới, thời gian check và sửa Feedback)
So sánh với số lượng mục tiêu có thể đạt được đã tính toán ở phần làm thử đo thời gian để thảo luận và đưa ra kế hoạch, deadline phù hợp
Từ kết quả làm thử dự tưởng xem có thể đạt được mục tiêu chất lượng đưa ra hay không và thảo luận thống nhất, suy nghĩ phương án để đạt được chất lượng mục tiêu đó
Sau khi thảo luận tạo file kế hoạch phù hợp và xác nhận với Khách hàng để thống nhất
Lưu ý:
Số lượng và chất lượng mục tiêu kế hoạch nên đưa ra tăng dần từ thấp đến cao theo từng giai đoạn
Số liệu thực tế nên cập nhật tự động từ bảng quản lý để tránh sai sót và mất thời gian
3. Trong quá trình chạy dự án (Thực thi dự án)
3.1 Triển khai, hướng dẫn, phân chia công việc cho các thành viên dự án
Tổ chức những buổi training cho toàn bộ dự án để mọi người có thể nắm tiêu chuẩn, cách làm, cách sử dụng tool, file quản lý, thư mục dự án, kết quả giao…
Khi triển khai tiêu chuẩn, chỉ thị, yêu cầu của phía Khách hàng nên triển khai một lần cho toàn bộ thành viên dự án, tránh tam sao thất bản, hoặc qua nhiều người sẽ có suy nghĩ lệch lạc, khác với nội dung cần triển khai. Cần thiết thì đưa ra ví dụ cụ thể, hình ảnh minh họa để người nghe dễ hiểu hơn.
 |
| Sơ đồ mô phỏng trả FB |
Xác nhận đúng và triển khai rõ ràng dễ hiểu yêu cầu, cần xác nhận lại xem tất cả mọi người đã hiểu rõ nội dung chưa, hạn chế trường hợp có người không hiểu nhưng không hỏi lại, sẽ hoang mang khi thực hiện công việc, dẫn đến làm sai yêu cầu
Trong buổi triển khai mong muốn được nhận ý kiến ở các thành viên, và mọi người cùng nhau suy nghĩ để đưa ra ý kiến, phương án và xác nhận, thảo luận với Khách hàng.
Nên phân nhóm quản lý theo team hay theo nhóm check, mỗi teamleader hay checker, super checker chịu trách nhiệm về tiến độ, chất lương sản phẩm, vấn đề của mỗi nhóm. Và có cuộc họp hàng ngày để các checker hay teamleader báo cáo công việc, tình trạng của mỗi nhóm lên trưởng dự án để xác nhận, và giải quyết, cũng như chia sẻ thông tin các nhóm với nhau. Mục đích cùng nhau bàn luận để không chỉ trưởng dự án mà các nhóm đều có thể nắm tình hình cả dự án, hợp nhất nhận thức giữa các nhóm và hỗ trợ nhau khi có vấn đề
3.2 Quản lý tiến độ và chất lượng dự án.
3.2.1 Quản lý tiến độ
Tạo file để phân tích và quản lý tiến độ của từng người, từng nhóm check và cả dự án. Nên có thêm biểu đồ để tiện theo dõi biến động
Theo dõi số lượng hàng ngày chặt chẽ, xem xét tỉ lệ biến động của từng người/nhóm/dự án, phân tích nguyên nhân và báo cáo kịp thời cho cấp trên.
Nếu như số lượng tăng, xem nguyên nhân để phát huy điểm tốt
Nếu số lượng giảm, phân tích nguyên nhân để hạn chế điểm chưa tốt, đưa ra đối sách cải thiện tốc độ làm việc, đảm bảo đạt được kế hoạch
Tính toán số lượng, dự tưởng có ảnh hưởng đến kế hoạch thì cần thông báo sớm cho bên Khách hàng, đưa nguyên nhân, đối sách cải thiện, thảo luận vấn đề để đưa ra phương án phù hợp, thống nhất giữa 2 bên
 |
| Sơ đồ tiến độ |
3.2.2 Quản lí chất lượng
Xác nhận feedback các bên, cập nhật tỉ lệ lỗi của mỗi người/nhóm/dự án hàng ngày, phân tích biến động, và nguyên nhân lỗi, tìm đối sách khắc phục để hạn chế lỗi (Thường sẽ tập trung xử lý những lỗi chiếm tỉ lệ lỗi cao trước).
Đầu tiên những lỗi nghiêm trọng mang tính hệ thống, do sai lệch nhận thức cần xử lý triệt để, để không lặp lại, sau đó đi sâu vào phân tích lỗi của từng nhóm, từng cá nhân
Hạn chế những vấn đề phụ thuộc vào mắt nhìn, cảm tính của từng người. Nếu có cần tập hợp các hình ảnh có cách nhìn khác nhau vào 1 file để thống nhất cách nhìn nhận giữa các bên, giữa các nhóm, giữa checker và member để kết quả của phía VN-yêu cầu của Khách hàng thống nhất một cách nhìn, tránh trường hợp mỗi nhóm check sẽ theo cách nhìn của mỗi người check khác nhau
 |
| Sơ đồ quản lí chất lượng |
Báo cáo tiến độ và chất lượng hàng ngày, hàng tuần, hàng quý cho phía cấp trên và phía Khách hàng.
4. Kết thúc dự án
4.1 Nhìn nhận dự án
Tạo file nhìn nhận dự án KPT(Keep-Problem-Try) cho các thành viên dự án phân tích điểm tốt, chưa tốt của dự án -> phân tích nguyên nhân, cải thiện và đề xuất.
Chia sẻ file nhìn nhận dự án, vấn đề và cách giải quyết vấn đề của dự án mình để những dự án khác có thể rút kinh nghiệm
Viết hướng dẫn sử dụng những tool có ích khác của dự án (dùng để phân chia dữ liệu, kiểm tra file, tập hợp file…), đặt ở nơi lưu trữ nào đó để khi cần thiết sẽ áp dụng cho dự án kì tương tự.
Ghi chú lại những thuận lợi, khó khăn, vấn đề phát sinh, quy trình quản lý của dự án hay kinh nghiệm học hỏi được trong quá trình đảm nhận dự án để chia sẻ cho mọi người khi thích hợp hoặc trong các buổi họp, training bộ phận.
Từ những điểm trên thì bạn có thể quản lí được một dự án dù lớn hay nhỏ mà sẽ không bị rủi ro gì, chúc các bạn quản lí dự án thành công nhé!