Theo em thì phải giao thời hạn cho từng công việc của từng thành viên. Mà giao thì giao chứ hiện tượng trễ, câu giờ cũng diễn ra. Tới lúc đó thì trưởng nhóm phải ra tay :))
Một nhóm lập trình làm thế nào hoạt động tốt với một project được giao!
Hồi học quản lý dự án thầy mình nói thế này: Một team hoạt động tốt là một team có cùng mục tiêu. Chẳng hạn mục tiêu của bạn là đạt 9 10 trong môn đó, mà trong nhóm bạn có một đứa chỉ mong qua môn là nhóm bạn chết chắc .
Do đó nếu mục tiêu của bạn là điểm thì bạn cần cẩn thận trong việc chọn nhóm, nếu mục tiêu của bạn là kỹ năng làm việc nhóm thì việc một nhóm có đa dạng thành viên sẽ đem lại cho bạn nhiều trải nghiệm hơn, nếu mục tiêu của bạn là kiến thức thì… gánh team là lựa chọn số 1 :v.
Thực ra mình rất kỵ hình thức tổ chức nhóm có nhóm trưởng, vì rất dễ xảy ra nhóm trưởng lạm quyền, nhóm trưởng không được tìn nhiệm của thành viên, nhóm trưởng gánh team (vì nó là thằng chịu trách nhiệm), nếu nhóm trưởng bỏ thì cả nhóm sẽ bỏ luôn. Một vấn đề khác là sự phân cấp thường không mang lại hiệu quả, do cả nhóm đều là sinh viên và ít có sự ràng buộc về mặt kỷ luật (một thằng không làm, nó là bạn mình, chẳng lẽ đá nó ra khỏi team?). Bạn có thể xem cách tổ chức nhóm của scrum, không có một nhóm trưởng có quyền phủ quyết mà vai trò quyết định được dàn đều cho mọi thành viên, scrum master chỉ đóng vai trò tư vấn, điều phối.
Scrum còn khó thực hiện hơn là mô hình nhóm trưởng, scrum cần các thành viên phải tự chủ với công việc của mình.
Scrum Đạt nghĩ chỉ phù hợp với môi trường chuyên nghiệp.
Ở trường e còn dạy Scrum cho các nhóm dự án áp dụng. Riêng cái khoản báo cáo hàng ngày vận động đã khó rồi
Làm việc nhóm mình thấy ở Nhật có một phương pháp là Horenso ( liên lạc - thảo luận - báo cáo ).
Các bạn nên tích cực áp dụng.
Bác cụ thể thêm tí
Horenso là viết tắt của 3 từ tiếng Nhật :
- Liên lạc
- Thảo luận
- Báo cáo.
Đó là 3 việc cần phải duy trì để làm việc nhóm hiệu quả.
- Liên lạc : phải đảm bảo việc liên lạc và trao đổi thông tin giữa các thành viên. Công việc của nhóm sẽ bị đình trệ khi không thực hiện việc này.
- Thảo luận : các thành viên trong nhóm phải cùng thảo luận để đưa ra giải pháp giải quyết vấn đề. Trong thảo luận cần tuân thủ 2 việc là không phản đối ý kiến trái chiều và kích thích động não tập thể ( brain storming).
- Báo cáo : phải báo cáo ngay khi có vấn đề để các thành viên khác nắm được để cùng có phương hướng giải quyết. Không nên một mình cố sức tự giải quyết để đến khi không giải quyết được cũng không còn thời gian để khắc phục được nữa.
Khi đảm nhiệm một nhiệm vụ cần nhiều thời gian thì cũng cần báo cáo về tiến độ đang thực hiện.
Đơn giản hiệu quả, Đạt sẽ thử áp dụng cái này
Ở bài trên mình có nói đến một keyword là : “Brain Storming”. Dịch ra có nghĩa là kích thích não hoặc động não tập thể. Nó được thực hiện khi chúng ta thảo luận đưa ra ý tưởng giải quyết vấn đề. Nó được thực hiện như sau :
- Khuyến khích các thành viên đưa ra ý tưởng mà không quan trọng ý tưởng đó có hiệu quả hay không.
- Khuyến khích đưa ý tưởng dựa trên ý tưởng của thành viên khác, hoàn thiện ý tưởng của thành viên khác.
- Các ý tưởng đều được ghi nhận và tuyệt đối tránh việc phản đối các ý tưởng, ý kiến của thành viên khác.
Mục đích của việc này là nhận được nhiều nhất các ý tưởng, ý kiến. Càng có nhiều ý tưởng ý kiến thì càng nhìn nhận được vấn đề từ nhiều mặt và có nhiều phương pháp hay để giải quyết vấn đề.
làm project nhóm mà bị kiểu máy thằng này chạy đc mà thằng kia không chạy đc là nát
Một mình 1 DA Java. Đang học Jav. Giống như điếc không sợ súng!
Ai cho t lời khuyên gì không?
Kiếm người bác, cái bác làm có giống phần mêm katapro không nhỉ, cũng vẽ kết cấu này nọ
Nó giống cái này
Nhưng định hướng có nhiều điểm khác.
Hôm nay hơi sad vì mình mang App đi animate với ô senior cũ. Chả thấy tí excitements nào cả, toàn thấy hỏi với exam về app. Cuối cùng ổng bảo cty a mới mua rùi.
Đang đến đoạn vừa dev vừa mang Animate để build team, tìm đầu tư.
Dân ngoại đạo, nói suông chả ai tin. Show up mà còn có đầy hoài nghi.
Uhm. Nhiều người trong nghành xây dựng cũng không phân biệt được. Lắm ông khi nói đến cũng bảo vác CAD, Revit… bọn nó viết Lisp đầy, ngoằng một phát là ra.
Khác nhau cơ bản là đám kia Định hướng Engineering
Còn cái này định hướng Quantity supervision. Base cho Cost management trong giai đoạn thi công xây dựng.
Cũng khó nhằn nhỉ. bởi công trinh xây dựng, vẽ kết cấu đồ toàn mấy thằng to to, kiếm đươc 1 thằng trong đó cũng ngon.
Cái này không có vai trò như mấy cái phần mềm vẽ kết cấu kia mà.