KHEN và THƯỞNG nhóm AGILE sao cho thoả đáng?

Tôi đang giúp một công ty cải thiện cấu trúc giữa hai loại tưởng thưởng gồm incentives và bonuses như một phần quy trình của tổ chức để trở nên Agile hơn. Bất kể quá trình chuyển đổi sang Agile diễn ra tốt đẹp và trơn tru như thế nào, nếu cơ chế tưởng thưởng & khích lệ khuyến khích hành vi phi-Agile, mọi người sẽ không làm theo.

Trong cuốn “Thành công với Agile”, tôi có đề cập đến điều này như là trọng lực của tổ chức (organizaional gravity). Nếu văn hoá công ty không thay đổi để trở nên Agile hơn, thì trọng lực của tổ chức sẽ kéo công ty quay trở lại điểm xuất phát.

Cả hai loại tưởng tưởng nếu như không hợp lý sẽ trở thành căn nguyên của lớn của trọng lực tổ chức.

Phân biệt Incentive và Bonus

Trước khi cân nhắc xem làm thế nào để có thể tạo nên một cấu trúc tưởng thưởng hợp lý, tôi muốn làm rõ sự khác nhau giữa hai phần thưởng trên.

Incentive là phần thưởng cho cá nhân hoặc đội nhóm vì hoàn thành một mục tiêu đã được đặt ra trước đó. Incentive sẽ được thông báo ngay từ đầu để khuyến khích hành vi được dự đoán trước. Khi con gái út của tôi còn nhỏ, tôi bảo cháu rằng nếu con dọn xong phòng mình vào lúc 3 giờ chiều, bố sẽ đưa con đi xem phim. Với nghĩa đó, ta có thể hiểu Incentive là phần thưởng đạt được do hoàn thành tốt nhiệm vụ.

Ngược lại, bonus không được thông báo trước mà được đưa ra vào thời điểm mục tiêu vừa được hoàn thành. Trở lại với ví dụ cô con gái của tôi, khi con bé đạt được điểm số cao và tôi biết chắc rằng con bé đã học hành rất chăm chỉ để đạt được, tôi tuyên bố rằng hai bố con sẽ ăn mừng thành quả này bằng việc đi ăn kem. Vì vậy bonus là phần thưởng thêm dành để khích lệ người khác bởi họ đã hoàn thành một công việc tốt hơn mong đợi.

Về cơ bản Incentives và Bonuses đều là khen thưởng, chỉ khác nhau về thời điểm thực hiện.

Một vài vấn đề rắc rối của tưởng thưởng

Incentives và Bonuses có thể đi ngược lại mục tiêu của Agile. Ví dụ khen thưởng cá nhân có thể ảnh hưởng đến tinh thần làm việc nhóm. Tôi từng nhận ra vấn đề này trong các giải thưởng như “Lập trình viên của năm”, “Thành viên nhóm của năm”. “Thành viên đóng góp nhiều giá trị nhất”, v.v…

Các dạng tưởng thưởng khác có thể dẫn đến những hành vi không tích cực. Rất nhiều người trong số chúng ta đều biết đến câu chuyện chuyên viên kiểm thử được thưởng dựa trên số lỗi mà họ tìm ra. Dạng khen thưởng này dẫn tới ví dụ điển hình một chuyên viên kiểm thử mà tôi gặp đã nhập đến hơn 200 mục vào hệ thống giám sát lỗi cho một bug.

Bug này chỉ đơn giản là một giá trị bị tính toán sai và được chiếu lên màn hình. Tuy nhiên sản phẩm này chạy trên 4 hệ điều hành khác nhau (phiên bản hiện tại và trước đó của Windows và Mac OS X), 8 trình duyệt web khác nhau (phiên bản hiện tại và trước đó của 4 trình duyệt) và được hỗ trợ tới 7 ngôn ngữ khác nhau. Vậy nên 1 bug được báo cáo với Firefox v59 trên Windows 8.1 bản tiếng Pháp. Một bug tương tự được báo cáo với Safari 6.2 trên MacOS 10.8 bản tiếng Anh, v.v…

Báo lỗi như thế này thì chỉ làm phí phạm thời gian của mọi người mà thôi. Nhưng chuyên viên kiểm thử đó chắc chắn có thể đạt thứ hạng cao trong cuộc thi “Người soát lỗi của tháng”.

Vậy tiền thưởng thì sao?

Phần thưởng về tài chính hầu như luôn là một ý tưởng tồi. Chúng thường được một vị sếp có thiện chí tốt đưa ra với mong muốn đội nhóm của mình hoàn thành một hạn chót đầy thách thức nào đó. Vị sếp sẽ đưa ra một khoản thưởng lớn nếu nhóm hoàn thành tốt.

Mọi thứ nhìn chung vẫn ổn cho đến khi có vấn đề phát sinh trong dự án tiếp theo. Nhóm có thể bắt đầu đúng hạn, tuy nhiên họ dần quen rằng nếu họ trễ chút đỉnh (hoặc chỉ trừ khi họ báo cáo rằng họ đang trễ một chút), vị sếp nọ lại đưa ra một khoản thưởng thêm (ở đây sẽ là bonus). Chu trình này trở thành một vòng xoáy nguy hiểm.

Bên cạnh đó, phần thưởng tài chính không thật sự tạo ra động lực bên trong của nhân viên. Tiền không sai. Hầu hết mọi người sẽ không đến công ty làm việc, nếu họ không nhận được tiền lương. Tuy nhiên, điều chúng ta muốn là chạm được vào động lực ẩn sâu bên trong chứ không đơn thuần là về mặt vật chất.

Nhóm đã dạy tôi về các phần thưởng tài chính

Tôi học được rất nhiều điều từ một nhóm mà nhiều năm trước tôi đã trao một khoản thưởng lớn. Nhóm được chia làm hai đội với 12 lập trình viên và tôi thưởng thêm cho họ một khoản 75.000 $, vị chi là hơn 6.000 $/người.

Và đó chính là vấn đề. Tôi đã điều chỉnh khoản thưởng này nằm trong ngân sách do vậy tôi có một khoản tiền để trao cho họ. Vấn đề là đến lúc trao tiền tôi không thể quyết định sẽ đưa cho họ như thế nào.

Tôi có nên:

• Chia đều cho mỗi người? Nếu tôi cho mỗi người 6.000$ thì như thế có vẻ như không công bằng với những người hưởng lương cao và lại quá hào phóng với một số khác.
• Chia tỷ lệ dựa theo lương mỗi người đang nhận? Thế thì lại có vẻ hơi ngược.
• Chia theo số tháng mà người đó đã theo dự án? Có vẻ không công bằng nếu đưa cùng một khoản tiền cho một lập trình viên mới tham gia 1 tháng trước và một người đã làm việc được 6 tháng.
• Đưa cho những lập trình viên đã từng làm việc cho dự án này nhưng bị luân chuyển đi? Cũng có vẻ không công bằng lắm khi loại họ, thế nhưng nếu họ không ở đây trong những thời khắc khó khăn nhất, liệu họ có xứng đáng được nhận nhiều thế không?

Tôi không thể nào ra quyết định được. Tôi cứ suy đi tính lại mãi. Một vài người chủ chốt trong dự án biết rằng tôi đang định trao thưởng và suy tư với quyết định này. Họ đưa ra những lời khuyên. Tuy nhiên mỗi người lại có những gợi ý giúp họ được thưởng nhiều nhất.

Vậy là tôi bỏ cuộc.

Tôi nói với đội của mình rằng tôi sẽ cho họ 75.000$ tuy nhiên quyết định là ở họ xem nên chia tiền thưởng như thế nào.

Tôi nói với họ những vấn đề mà tôi đang gặp và nói bất kể họ quyết định như thế nào, tôi đều tôn trọng điều đó. Tuy nhiên, tất cả đều phải đồng ý với quá trình mà họ chọn và sự phân bổ số tiền đó.

Chúng tôi có một cuộc họp một tuần sau khi chuyển giao vấn đề hóc búa này. Họ nói với tôi rằng họ không thể tìm ra cách để chia số tiền thưởng. Họ tranh luận và tất cả đều cảm thấy rằng tiền làm ảnh hưởng đến mối gắn kết chặt chẽ mà họ đã xây dựng khi là một đội.

Và họ trả lại toàn bộ số tiền. Họ quyết định rằng họ không cần đến nó nữa.

Tôi không nghĩ tôi có thể tự hào hoặc ngạc nhiên hơn nữa bởi một nhóm như vậy!

Cuối cùng, chúng tôi quyết định rằng sẽ dành số tiền này cho một chuyến đi chơi ngoài thành phố dành cho mỗi người và nửa kia của mình. Số còn lại được trả về ngân sách.

Và đó là phần thưởng tài chính cuối cùng tôi đề nghị dành cho một nhóm.

Vậy thì chúng ta nên tưởng thưởng một nhóm agile như thế nào?

Vậy chúng ta nên khen thưởng một nhóm Agile như thế nào? Điểm quan trọng ở đây là việc tưởng thưởng nên khuyến khích tinh thần làm việc nhóm hơn là thành tích cá nhân. Tôi thích phần thưởng (bao gồm cả  incentive và bonus) được chia cho tất cả mọi người trong nhóm.

Điều này không có nghĩa là không có chỗ cho khen thưởng cá nhân. Tôi thích khen thưởng cá nhân ở mức nhỏ hơn so với khen thưởng nhóm.

Hãy cùng xem một ví dụ. Tôi đã từng làm việc với một vài Product Owner cầm vài tờ 5$ đi và thưởng cho các thành viên nhóm, nếu họ có thể thuật lại tiêu chí hoặc 3 mục tiêu chính của dự án khi được hỏi. Chắc chắn rằng họ sẽ không có gì tiến triển hơn sau khi nhận được 5$. Nhưng đó là số tiền họ đạt được nhờ kiến thức của họ. Có ít nhất một thành viên nhóm thậm chí đính tờ 5$ này lên nơi làm việc của mình.

Tương tự, một tờ giấy ghi chú viết tay có thể tạo nên điều kỳ diệu trong thời đại tràn ngập email này. Hãy dành thời gian viết ghi chú mọi lúc và dùng nó để cảm ơn một thành viên về một điều cụ thể, một điều đặc biệt nào đó mà họ đã làm.

Một trong những cách thưởng ưa thích của tôi là thời gian. Thời gian là thứ xem chừng ai cũng thiếu. Tôi thưởng cho nhóm “thời gian” theo những cách khác nhau và được đón nhận khá nồng nhiệt. Ví dụ bạn có thể thưởng đội của mình nghỉ một tuần nếu họ đạt được một vài thành tựu nào đó.

Hoặc nếu nghỉ một tuần có vẻ quá nhiều, thưởng đội của mình một tuần (hoặc một Sprint) có thể làm bất cứ phần việc nào mà họ muốn. Họ có thể tái cấu trúc mã nguồn cũ mà Product Owner vẫn e ngại duyệt nếu họ đề xuất. Họ có thể thử nghiệm những công nghệ mới. Họ có thể quay lại việc đọc nếu họ muốn. Bất kể họ chọn gì đều ổn.

Lựa chọn khác có thể là cung cấp cho đội nhóm thêm kiến thức. Nếu họ hoàn thành một mục tiêu nào đó, cho cả tham gia một hội thảo. Nếu phù hợp, có thể cho tất cả đi chung một hội thảo. Đặc biệt tốt nếu bạn có thể tổ chức khoảng thời gian giải trí vui vẻ trước hoặc sau chương trình. Hoặc có thể cho các thành viên tự do lựa chọn các hội thảo mà họ muốn tham gia trong năm.

Tặng cho mọi người một ngân sách dùng cho việc mua sách (đây cũng là phần thưởng tài chính nhưng có đôi chút khác biệt). Ngân sách riêng cho việc học tập trên mạng. Đăng ký thành viên một khu vui chơi giải trí. Thậm chí là một trong những khóa học với video của tôi. Có rất nhiều lựa chọn khác nhau.

Incentives và bonuses có một vai trò trong các nhóm Agile. Tuy nhiên, chúng cần phải được thiết kế cẩn thận để phù hợp với trọng tâm của Agile về làm việc nhóm. Nếu làm tốt thì việc khen thưởng bằng cả hai hình thức incentives và bonuses sẽ rất có lợi đối với nhóm và tổ chức.