Họp rút kinh nghiệm khi kết thúc dự án phát triển game

Bài viết được dịch từ blog Coding Horror

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:

Cuộc họp rút kinh nghiệm khi kết thúc dự án game là rất cần thiết.Cuộc họp rút kinh nghiệm khi kết thúc dự án game là rất cần thiết.

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.

Học lập trình trực tuyến cơ bản đến nâng caoTạ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.

Các bài viết liên quan:

Về tác giả bài viết:

Jeff_atwood_coding_horrorJeff Atwood là một chuyên gia công nghệ tại Mỹ, hiện đang sinh sống và làm việc tại Berkeley, CA. Anh là một kỹ sư phần mềm chuyên về công nghệ Microsoft .NET, và là một blogger nổi tiếng trong cộng đồng công nghệ với blog Coding Horror, anh là người sáng lập và kiêm Giám đốc điều hành (CEO) của trang web hỏi đáp uy tín Stack Overflow và cũng là đồng sáng lập của Stack ExchangeDiscourse.

Gửi phản hồi

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Log Out / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Log Out / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Log Out / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Log Out / Thay đổi )

Connecting to %s