Trước đây tôi đã có bài viết nói về giá trị của cuộc họp rút kinh nghiệm khi kết thúc dự án. Tuy nhiên, việc tổ chức một buổi họp kết thúc dự án (hoặc, bạn có thể thích gọi nó bằng một thuật ngữ hấp dẫn hơn, một cái nhìn lại dự án) có thể là một công việc khá tẻ nhạt. Bài viết về các tiêu chí của một buổi họp kết thúc dự án trên tờ tạp chí Game Developer Magazine đã đưa ra một khuôn mẫu rất hữu ích để hướng dẫn bạn có thể thiết lập cho mình một cuộc họp như vậy:
Nội dung chính của một buổi [họp kết thúc dự án] nên xoay quanh khái niệm “5 sai, 5 đúng” sau đây:
Giải thích về 5 mục tiêu, tính năng hoặc các khía cạnh của dự án đã diễn ra mà không gặp phải một sự vướng mắc hoặc đạt được kết quả tốt hơn so với kế hoạch. Có bất kỳ giai đoạn phát triển nào mà bạn nghĩ rằng nó dễ hơn so với kế hoạch bạn đã chuẩn bị? Một lập trình viên mới tham gia vào nhóm và đóng góp những ý tưởng tuyệt vời hay khả năng lập trình sáng chói vào nỗ lực đó? Liệu đã có một công nghệ mới nào đó được chấp nhận rộng rãi bởi người dùng mà giúp giải quyết một vấn đề phát triển đặc biệt gai góc? Những công cụ phát triển mới trở nên có sẵn cho phép bạn bổ sung phần đồ họa hoặc âm thanh tốt hơn? Bạn đã tiết kiệm được tiền trong những cách nhất định mà bạn không mong đợi? Bạn đã giảm được số ngày/tuần/tháng so với lịch trình trong một số cách mà bạn không ngờ tới? Có phải nhóm marketing hoặc PR giúp cho sản phẩm của bạn xuất hiện trên trang bìa của một tạp chí người tiêu dùng?
Giải thích về 5 mục tiêu, tính năng hoặc các khía cạnh của dự án gặp phải vấn đề hoặc thất bại hoàn toàn. Có phải trưởng nhóm lập trình (lead programmer) xin nghỉ việc giữa chừng? Việc áp dụng các công nghệ mới (ví dụ, MMX, DirectX, một thư viện đồ họa mới hay thuật toán AI) tạo ra các vấn đề không lường trước được đối với các nhà phát triển? Các công cụ phát triển bạn dùng có nhiều vấn đề chứ không được như kỳ vọng? Có những chi phí phát sinh trong dự án, và nếu như vậy, chúng đến từ đâu? Dự án không kịp tiến độ vì một số lý do? Kiểm thử cấu hình hoặc chu kỳ kiểm thử beta gặp vấn đề vì một số lý do? Các tính năng đã bị bỏ bớt vì áp lực hoàn thành đúng kế hoạch? Một nhân lực nòng cốt bỏ việc ngang xương? Có phải nhóm marketing hoặc PR giới thiệu không đúng về trò game ra công chúng, gây ra những ảo tưởng? Hãy cụ thể trong vấn đề này – cuộc họp nhằm làm nổi bật “cái gì đã đi đúng” và “cái gì đã đi sai”. Hãy trung thực, đó là tất cả những gì chúng tôi yêu cầu.
Những phần rút kinh nghiệm này dường như được coi là rất quan trọng đối với các nhà phát triển game khác, bởi vậy họ đăng thành một câu chuyện dài trong tờ tạp chí đó. Tôi nghĩ rằng đó chính xác là mức độ ưu tiên mà các cuộc họp rút kinh nghiệm này nên có; nếu bạn không học được từ những sai lầm của bạn, hoặc thậm chí tốt hơn, học từ những sai lầm của người khác, thì dự án tiếp theo của bạn sẽ có một tương lai thảm hại.
Tạp chí Game Developer không có ấn bản trực tuyến để bạn đăng ký theo dõi, nhưng nhiều nội dung về các cuộc họp rút kinh nghiệm (postmortem) từ tạp chí này đã được biên soạn vào một cuốn sách có tên là: Postmortems from Game Developer: Insights from the Developers of Unreal Tournament, Black and White, Age of Empires, and Other Top-Selling Games.
Tuy nhiên, Gamasutra, một tạp chí khác dành cho các nhà phát triển game, đã đăng nội dung những cuộc họp (postmortem) trực tuyến. Như tôi đã đề cập trước đây, nội dung postmortem yêu thích của tôi đó là cho trò game Trespasser, đó là một trong những thất bại nổi tiếng nhất trong lịch sử game PC. Nhưng qua đó chúng ta thu được bài ​​học về nguyên nhân thành công cũng như thất bại. Dưới đây là một vài nội dung về các cuộc họp rút kinh nghiệm (postmortem) trên trang Gamasutra mà tôi khuyên bạn nên đọc (yêu cầu đăng ký thành viên):
Tất cả các cuộc họp rút kinh nghiệm sau khi dự án kết thúc (postmortem) là điều đáng làm, và bạn chắc chắn sẽ nhận ra rất nhiều những khó khăn và chiến thắng mà nội dung của nó mô tả. Thậm chí nếu bạn không quan tâm một chút nào về phát triển game, thì cũng nên đọc các postmortem này, bởi vì phát triển game là một trong những lĩnh vực khó nhất trong phát triển phần mềm, nó giống như là nồi áp suất vậy. Có những thử thách phát triển phần mềm không thể tin nổi, với những mục tiêu không rõ ràng (ví dụ, “mang lại niềm vui”) theo thời hạn deadline rất gắt gao. Mỗi vấn đề mà bạn đang có khả năng nhìn thấy trên dự án phần mềm của mình, có thể đã xuất hiện từ lâu trên một hoặc nhiều những trò game này.
Axact

Administrator:

Xin chào, tôi là Nguyễn Quý Quang Huy. Tôi 14 tuổi và sinh sống tại Hoài Đức, Hà Nội. Tôi lập ra Rinne-IT Blog này nhằm chia sẻ những kiến thức mình có và những bài viết hay trên mạng do tôi tổng hợp. Blog đang trong giai đoạn phát triển nên nếu có lỗi mong các bạn bỏ qua. Tôi luôn chào đón những ý kiến phát triển từ từ các bạn. Giờ thì hãy khám phá blog của tôi nào ^_^

Bình Luận:

0 bình luận: