Buzz
Nhân dịp dự án của mình vừa được giải “Dự Án Xuất Sắc Nhất Năm” của công ty, hôm nay mình muốn chia sẻ một chút kinh nghiệm và bài học trong quá trình thực hiện dự án. Mặc dù sản phẩm chưa ra mắt nhưng đến thời điểm này có thể coi là thành công vì đã hoàn thành công việc, làm hài lòng khách hàng, không tăng ca, và đảm bảo môi trường làm việc thoải mái cho mọi người.
Nguồn: Freepik
1. Quản lý Change Request là yếu tố quyết định sự thành bại của dự án
Ngày nay chúng ta ít làm việc theo mô hình Waterfall, và hầu hết làm việc theo mô hình Agile, hoặc kết hợp giữa Waterfall và Agile. Nói về Agile, chúng ta không thể quên nguyên tắc số 2:
CHÀO ĐÓN CÁC YÊU CẦU THAY ĐỔI, DÙ Ở GIAI ĐOẠN MUỘN CỦA PHÁT TRIỂN. QUY TRÌNH AGILE TẬN DỤNG SỰ THAY ĐỔI ĐỂ ĐEM LẠI LỢI THẾ CẠNH TRANH CHO KHÁCH HÀNG.
Chúng ta luôn chào đón sự thay đổi trong thông số kỹ thuật. Tuy nhiên, điều đó không có nghĩa là cứ có thay đổi là làm ngay. Quản lý yêu cầu thay đổi là yếu tố quan trọng quyết định sự thành công của dự án. Mọi thay đổi từ khách hàng, chúng ta nên chủ động thảo luận để làm rõ vấn đề, lý do tại sao lại cần thay đổi, thay vì chỉ biết tuân thủ làm theo. Những thay đổi tốn nhiều thời gian càng cần được xem xét kỹ lưỡng, vì không chỉ thêm effort và cost, mà còn có thể gây ra những hậu quả không lường trước nếu chúng ta vội vàng làm theo khách hàng.
Kinh nghiệm cá nhân
Có 3 điều chúng tôi thực hiện xuyên suốt dự án khi làm việc với yêu cầu thay đổi:
Tất cả các yêu cầu thay đổi đều được gom lại dưới một ticket lớn để có cái nhìn tổng thể và dễ dàng thống kê thời gian ước tính. Bạn có thể có cách thực hiện khác, nhưng nguyên tắc là làm sao có thể nhìn thấy những thay đổi này nhanh nhất có thể.
Thái độ đầu tiên đối với yêu cầu thay đổi không phải là “ngoan ngoãn” vâng lời, mà là bình tĩnh nghiên cứu, nghĩ đến những khó khăn lớn nhất có thể xảy ra để thương lượng với khách hàng.
Tuyệt đối không vội vàng thực hiện ngay. Kể cả khi thấy thay đổi đó là hợp lý thì cũng cần xem xét độ ưu tiên trước khi quyết định thực hiện. Và điều may mắn là, có khá nhiều yêu cầu thay đổi, sau 1-2 tuần chưa làm đến, khách hàng đã tự hủy. Thử tưởng tượng nếu chúng ta làm ngay thì sẽ tốn công như thế nào.
2. Xây dựng quy trình là điều cực kỳ quan trọng
Quy trình là yếu tố không thể thiếu, đặc biệt là với các dự án lớn có cơ cấu con người đa dạng và thông số kỹ thuật phức tạp. Trước khi dự án bắt đầu, tôi có khoảng 1 tháng để nghiên cứu thông số kỹ thuật, lên kế hoạch và xây dựng quy trình cho toàn bộ dự án.
Quy trình quản lý ticket trên Redmine, quy trình review code, quy trình deploy, quy trình Q&A,… cho đến quy trình thêm thành viên mới vào dự án đều được chuẩn bị sẵn để đảm bảo mọi thứ vận hành trơn tru.
Giai đoạn lập kế hoạch và xây dựng quy trình thường bị xem nhẹ, nhưng chính điều này lại gây ra hậu quả khôn lường sau này. Chúng ta thường mải làm và nghĩ rằng làm càng sớm càng tốt, trong khi với góc nhìn của nhà quản lý, đặc biệt là quản lý hệ thống lớn, việc xây dựng quy trình mới thực sự quan trọng. Làm sớm đôi khi chỉ dẫn đến việc phải làm lại sớm, trong khi một quy trình tốt sẽ giúp hạn chế rủi ro từ con người.
Con người sinh ra không ai là hoàn hảo, công việc của con người không bao giờ hoàn thiện tuyệt đối, chính vì vậy quy trình được tạo ra để hạn chế sai sót của con người!
Nguồn ảnh: Internet
Tôi chia sẻ với các bạn hình trên là một quy trình của chúng tôi, quy trình Q&A. Bạn có thể thấy người trực tiếp tham gia vào quá trình Q&A là Questioner (Dev hoặc QA) và BrSE. Nhưng người cập nhật specs lại là một người trung gian, Comtor. Tại sao lại như vậy?
Chúng tôi chọn một người trung gian trong quá trình Q&A để cập nhật specs, đó là comtor. Điều này đảm bảo rằng một người thứ ba khi đọc file Q&A cũng hiểu vấn đề đang trao đổi là gì và khi cập nhật thì có cái nhìn khách quan, giúp ai cũng có thể hiểu vấn đề.
Còn nhiều quy trình khác trong dự án, tuy nhiên cá nhân tôi thấy chúng vẫn chưa thực sự hoàn thiện và trong sự nghiệp của mình, tôi sẽ cố gắng tìm hiểu để hoàn thiện chúng hơn.
