Kỹ năng làm việc nhóm

Tiger Nguyen

5 years ago

Series kỹ năng mềm dành cho BrSE :

Cũng lâu rồi mới ngồi viết lại. Đợt này làm 1 lúc mấy dự án nên cảm nhận rất rõ kỹ năng làm việc nhóm nó quan trọng mức nào. Trước đây không quan tâm lắm, thậm chí hơi có phần hời hợt. Nhưng vừa rồi xảy ra một số chuyện không hay, cũng may vẫn nằm trong tầm kiểm soát nên mọi sự vẫn đang đi theo hướng tốt hơn rất nhiều so với tưởng tượng. Mình note lại vài chữ cho anh em tham khảo. Nội dung thì không ngắn không dài, nhưng như mọi khi, mình sẽ viết một cách cụ thể và đơn giản nhất để ai cũng có thể hiểu được. Còn nếu … không hiểu thì chắc do kỹ năng trình bày mình có vấn đề :))))

Kỹ năng làm việc nhóm là một bộ gồm nhiều thứ : chịu nhục, ôm việc – đá việc, cãi nhau – đập nhau …

Giỡn đấy, nó như sau :

Xác định vai trò – nhiệm vụ của mình ở đâu – là gì trong team
Xem làm cách nào để hoàn thành nhiệm vụ
Suy nghĩ – hỏi han mọi người cần giúp gì
Làm sao để hoàn thành mục tiêu chung của nhóm

Nó chỉ có 4 ý vậy thôi. Mạn phép cụ thể hoá như dưới, a em thấy cần gì thì góp ý bổ sung thêm nhé.

Biết mình là ai – đây là đâu

Thực sự có không hiếm case bị assign (phân việc) nhầm team, nhầm chỗ. Cái này lỗi thuộc về sếp, và một phần do bản thân không cho cấp trên biết rõ mình mạnh yếu chỗ nào. Khi vào làm mới gặp trắc trở vì kỹ năng chả map gì với yêu cầu cả, ca này khó. Để giải quyết thì có 2 phương án, báo luôn vs PM – Manager về tình trạng, 1 là để thay người hoặc nếu không thay được thì sẽ đưa cái này vào Risk Managament (quản lý rủi ro). Trường hợp tiếp tục làm thì tất nhiên sẽ không bị ép quá đáng và có đối sách hỗ trợ – backup cũng như động viên tinh thần kẻo mem nản :)))

Còn khi được phân công, việc trước tiên để làm sao team hoạt động được trơn tru thì chỉ có một nguyên tắc cơ bản và duy nhất : biết việc của mình là gì. Khi đó ko dẫm chân nhau, đồng thời không làm ảnh hưởng tiến độ của người khác vì output – input của mọi người liên quan mật thiết. VD code frontend-code backend, code function – UT, code-testcase-test-report bug … ai cũng phải tự biết nhiệm vụ.

Đối với BrSE, thường nội dung công việc không được định hình sẵn, và có khả năng thay đổi thường xuyên. Do vậy hãy giữ vững tôn chỉ : CẦU NỐI. Từ đó nghĩ ra mọi task nhằm phục vụ mục đích truyền thông tin qua lại thật nhanh – thật chính xác, đồng thời liệt kê ra được tất cả mọi việc, đặt tên cho cả những việc không tên và xếp theo thứ tự ưu tiên (dựa vào kinh nghiệm + phán đoán + hỏi), rồi làm dần. Đồng thời có 1 task mà các bạn thường hay không để ý : lấp khoảng trống. Dev thì Code, QA test, PM quản lý … nhưng 1 dự án thường sẽ có nhiều việc khác rất aimai không biết nó thuộc trách nhiệm của bộ phận nào, vậy nên 1 là mình xác định và phân việc, nếu ko phân được thì tự lo mà làm :))))

Chủ động tìm giải pháp để hoàn thành task

Làm trong nhóm ghét nhất mấy ông cái gì cũng hỏi. Tất nhiên hỏi không xấu nhưng trước khi hỏi 1 là phải động não, nghĩ trước, nghĩ không ra thì tìm google, anh em hay nói đùa là google không tính phí 😀 và cuối cùng mới dùng đến quyền trợ giúp người thân. Chỗ này đừng bắt bẻ mà tội, mấy requirement nội bộ không có trên mạng thì cách 1 + 3 mà xài, ko dùng google, và tuyệt đối cũng đừng up source dự án lên các forum để nhờ trợ giúp. Trong quá khứ từng có mấy case (mình biết) bị khách cắt hợp đồng vì vi phạm bảo mật thông tin liên quan share source rồi.

Có ý thức giúp đỡ đồng đội

Trong 1 team thường sẽ có 1 hoặc vài người cứng làm nhiệm vụ xử task khó và support mem yếu. Có một thực tế thường xuyên xảy ra đó là việc support không được coi là 1 task, vì vậy dẫn tới mức độ liên lạc giữa các mem trong nhóm thấp, thậm chí rời rạc, vì ai cũng chỉ lo task mình. Vậy nên PM (or BrSE) phải làm sao cho mọi người hiểu được giúp người khác cũng là nhiệm vụ và phải được đưa vào bảng thành tích (nói thật đấy, ko đùa đâu).

Vì mục tiêu chung

Cái này nói ra dễ chứ vào thực tế ko đơn giản. Vì lúc làm sẽ có động chạm lợi ích, mà cái chung vs riêng khi đặt lên bàn cân thì nhiều người chọn cái riêng, cha chung không ai khóc là vậy. Cũng một phần thuộc về bản tính, giáo dục, môi trường các thứ, khó mà trách được. Nhưng cứ ngẫm lại coi, người mà chịu thiệt một chút cuối cùng sẽ bị thiệt … ah ko, cuối cùng sẽ được đền đáp, nên đừng lo.

Trong 1 team thường sẽ có rất nhiều cá tính, có người cong người thẳng (ý là thẳng tính). Mà thẳng thắn thường hay mất lòng, nếu là bản thân thì nên hạn chế, còn trường hợp mem khác quật thẳng vào mặt mình thì trước tiên phải bình tĩnh, thật bình tĩnh … xem thử họ quật có đúng không, mình sai thì chấp nhận sai mặc dù hơi khó khăn, nhận nhiều sẽ quen :))) hoặc nếu không nhịn được thì nghĩ theo hướng khác, xem thử hành động – lời nói cuả mem kia có vì mục tiêu chung – vì tốt cho cả team hay ko, nếu tốt cho team thì ok, thẳng mấy cũng được, ok hết. Còn nếu không ? đến nước này thì vả lại đi chứ hỏi gì nữa, vì mục tiêu chung mà.

Kết

Xưa có đọc truyện cười (ra nước mắt), vứt 3 người Nhật xuống hố thì 1 tiếng sau cả 3 lên được, vứt 3 thằng Việt xuống thì 3 ngày sau vẫn chưa thằng nào ngoi lên. Chuyện bậy bạ ko hà, xưa rồi, giờ là thời đại gờ lô bồ, ai cũng chuyên nghiệp hết trơn nên không có chuyện kéo quần kéo áo nhau vậy nữa, ít nhất cũng 1 thằng lên (2 thằng oẳng) 😀 giỡn chứ lên được hố hết, vì phải nương tựa nhau chứ không xuống hố cả nút.

Phá team thì dễ, xây team mới khó. Kỹ năng làm việc nhóm nó chả có cái gì cao siêu cả, biết việc mình làm, biết giúp người khác vì mục tiêu chung vậy là 90% thành công rồi, 10% còn lại cứ đọc mấy sách dạy làm giàu … lại nhầm, sách kỹ năng sống ấy, có hết. Còn mấy ông tinh tướng, làm màu (tiếng anh là make color), có “ý thức” phá hoại, nếu là người đứng đầu nên cứng, loại luôn để khỏi ảnh hưởng cả đội. Làm chung biết nhu cương đúng lúc, nhu riết thì vô dụng, mà lúc nào cũng cương thì … đau. Nên dung hoà.

4.6/5 - (9 votes)