Ba phương pháp quản lí
Software Engineering
36
White

Ngoc Dao viết ngày 23/03/2016

Nếu là team leader, giám đốc công ty hay tướng chỉ huy quân đội, vấn đề cơ bản bạn gặp phải là “hướng mọi người đi theo con đường bạn chỉ ra”.

Thử nghĩ mà xem, nếu đội của có hơn một người, sẽ có nhiều chí hướng khác nhau. Họ muốn những thứ khác bạn. Nếu là giám đốc, bạn muốn kiếm được càng nhiều tiền càng nhanh càng tốt, để có thể nghỉ hưu sớm và tham gia hội thảo “blogger nữ” :P. Do đó, bạn có thể dành phần lớn thời gian của mình, lái xe lòng vòng quanh Sand Hill Road, nói chuyện với các nhà đầu tư mạo hiểm, những người có thể sẽ mua công ty của bạn và tống cho Yahoo!

Nhưng Janice, một trong số những nhân viên lập trình viên của bạn, không quan tâm về việc công ty được bán cho Yahoo!, bởi cô ấy không muốn kiếm nhiều tiền theo cách đó. Điều cô quan tâm là viết những dòng code đẹp đẽ bằng một ngôn ngữ mới, bởi học một một điều mới thật tuyệt với cô.

Trong khi đó, CFO của bạn chỉ muốn ra khỏi phòng chung với anh quản trị hệ thống, anh ta sẽ cố gắng đưa ra dự thảo ngân sách rằng công ty có thể chuyển tới một nơi rộng rãi hơn, cách nhà anh ta 2 phút đi đường, thật là trùng hợp!

Tất nhiên, làm cho mọi người đi theo con đường của mình không phải chỉ là vấn đề của riêng bạn. Đó cũng là vấn đề mà các chính khách gặp phải khi họ được bỏ phiếu, sau khi hứa chấm dứt lãng phí, tham nhũng, lừa đảo trong chính phủ. Đó cũng là vấn đề mà các chỉ huy quân đội gặp phải. Họ luôn muốn những người lính của mình “nhằm thẳng quân thù mà lao”, nhưng cá nhân mỗi người lính thực sự chỉ muốn núp sau tảng đá, chờ người khác lao lên trước.

Có 3 giải pháp bạn có thể quan tâm:

  • Phương pháp ra lệnh và điều khiển (Command and Control method)
  • Phương pháp Econ 101
  • Phương pháp đồng nhất (Identity method)

Chúng ta sẽ xét từng phương pháp, phân tích những điểm mạnh, yếu trong các bài sau.

(*) Sand Hill Road: một con phố ở Silicon Valley có rất nhiều các công ty đầu tư mại hiểm trong lĩnh vực high-tech

Phương pháp Command and Control

Phương pháp này dựa trên cách quản lí trong quân đội.

Về cơ bản, phương pháp này như sau: bạn ra lệnh cho cấp dưới, nếu anh ta không làm, quát vào mặt anh ta cho tới khi anh ta nghe lời. Nếu vẫn không chịu làm thì ném anh ta vào mũi tàu, bắt ngồi bóc hành dưới tàu ngầm, ở chung phòng với 1 gã chẳng bao giờ biết đến khái niệm đánh răng :P

Có hàng triệu cách để làm điều này, bồ có thể thuê phim “Biloxi Blues” hay “An officer and a Gentleman” mà mà học hỏi.

Có một vài manager sử dụng cách này bởi nhiều lí do: họ đã học được khi còn ở trong quân đội, họ sinh ra trong một gia đình/đất nước độc đoán mà với họ “phàn nàn là đương nhiên”, hay cũng có thể do họ không biết cách nào hay hơn. Này nhé, cách này chỉ dùng được trong quân đội thôi !

3 lí do để xa lánh phương pháp này :

  • Không ai thích bị quát tháo. Nhân viên của bạn là những lập trình viên thông minh, dòng code của họ luôn đẹp hơn của những người khác, họ sẽ cảm thấy phiền khi bị ra lệnh !
  • Bạn không có đủ thời gian để quản lí vi mô đến thế. Trong quân đội, thường một mệnh lệnh được ra cho rất nhiều người cùng làm một lúc. Ví dụ: “Lau súng” – 28 người cùng lau, hay nhiều hơn: “Bước đều, bước”. Trong một high-tech team, bạn không thể áp dụng điều này. “Bật máy, bật” hẳn là câu chán nhất mà một team leader có thể nói ra.
  • Trong các công ty high-tech , leader thường có ít thông tin hơn các cộng sự, vì vậy boss nên để các cộng sự của mình đưa ra quyết định trong các vấn đề kĩ thuật. Khi xếp lang thang quanh chỗ hai developer đang tranh cãi về cách tốt nhất để nén ảnh, người có ít thông tin nhất chính là boss, vì vậy ông ta là người sau cùng có thể nghĩ đến khi cần ra một quyết định kĩ thuật.

Nếu phương pháp “Command and control” tệ đến vậy, tại sao quân đội lại dùng ? Tôi học được điều này khi ở trong NCO, khi tôi ở trong đội lính dù ở Israel (tầm năm 1986). Đó có lẽ là đội lính dù dở nhất!

Chuyện kể rằng…

Họ có một vài qui tắc:

  1. Nếu đứng giữa bãi mìn -> đứng yên (và bạn được huấn luyện để đứng yên khi đứng giũa bãi mìn)
  2. Khi tấn công, vừa bắn, vừa lao thẳng vào quân thù. Bắn để quân địch phải núp và không chông trả được, chạy tới là để tiếp cận sát quân địch và do đó bắn chính xác hơn.

Rồi, giờ là một câu hỏi: “Bạn làm gì khi ở giữa bãi mìn và quân địch lại đang ở trước mặt ?”

Đấy không chỉ là tình huống giả định, đây là một vấn đề rắc rối có thể gặp phải trong một cuộc phục kích.

Câu trả lời hoá ra lại là: đừng nghĩ đến bãi mìn, chạy thẳng tới quân thù mà bắn. Cơ sở của câu trả lời này là: nếu đứng yên, tất cả sẽ bị bắn tới khi chết, còn nếu chạy tới thì chỉ một số chết do dính mìn, còn lại vẫn lao lên được. Vấn đề ở đây là không một người lính có lí trí nào muốn chạy trong tình huống này. Ai cũng muốn “ăn gian”, chờ người khác chạy trước.

Trước tình huống một mất một còn, chỉ huy quân đội cần phải đảm bảo rằng tất cả những người lính phải nghe lệnh, ngay cả khi lệnh đó đưa họ vào chỗ chết.

Tóm lại, quân đội sử dụng “Command and Control” bởi đó là cách duy nhất khiến chàng tân binh 18 tuổi chạy ngang qua bãi mìn, chứ không phải bởi họ nghĩ đó là cách tốt nhất trong mọi tình huống.

Trong thực tế, trong các đội phát triển phần mềm, nơi mà những developer giỏi làm việc với nhau, chơi trò chơi “làm anh bộ đội” thật chán, và nếu bạn, 1 team leader, muốn mọi người chơi trò đấy, bạn sẽ không còn ai hết.

Phương pháp Econ 101

Tiếu lâm:

Có một người do thái sống ở Shtetl, Nga thế kỉ 19. Một người Cô-dắc cưỡi ngựa đến.

“Mày cho gà ăn gì thế” – Người Cô-dắc hỏi.

“Chỉ một vài mẩu bánh mì” – Người Do Thái trả lời.

” Làm sao mày có thể cho một con gà Nga khoẻ mạnh ăn ít thức ăn thế” – Người Cô-dắc quát và quất roi.

...

Hôm sau người Cô-dắc trở lại và hỏi: “Nào, hôm nay mày cho gà ăn gì ?”

“Vâng, 3 món. Cỏ tươi, cá muối và một bát nhỏ kem sô cô la Pháp tráng miệng.”

“Đồ ngu!” – Người Cô-dắc lại quát và quất roi, “sao mày lại cho những con gà còi ăn thức ăn hảo hạng vậy”

Ngày thứ ba, người Cô-dắc hỏi: “Hôm nay mày cho gà ăn gì?”

“Không gì cả”, người Do Thái đáp, “tôi cho nó một đồng Kopeck để nó mua thứ nó muốn”

...

Tại sao lại có tên Econ 101 ? Ở Mĩ, lớp 101 là lớp giới thiệu khi bạn bắt đầu một lĩnh vực nào đó. Econ viết tắt của Economic.

Phương pháp Econ 101 chỉ ra rằng mọi người đều được thúc đẩy bởi đồng tiền, và cách tốt nhất để khiển ai đó làm điều mà ta muốn họ làm là dành cho họ món tiền thưởng.

Chẳng hạn như cách mà AOL thưởng cho các nhân viên thuyết phục khách hàng không từ bỏ dịch vụ của công ty. Hay một công ty phần mềm có thể thưởng cho các lập trình viên viết ra những chương trình ít bug nhất.

* Vấn đề đối với phương pháp này là ở chỗ : NÓ THAY THẾ “ĐỘNG LỰC BÊN TRONG” BỞI “ĐỘNG LỰC BÊN NGOÀI”

Động lực bên trong là của bạn, là mong muốn làm một cái gì đó một cách tự nhiên, xuất phát từ bên trong bạn. Con người thường bắt đầu với rất nhiều động lực bên trong. Họ muốn làm một công việc tốt. Họ muốn viết chương trình thất ít bug…

Động lực bên ngoài là các động lực đến từ bên ngoài (:P), chẳng hạn như khi bạn được thưởng khi đạt được một cái gì đó đặc biệt.

Động lực bên trong bao giờ cũng mạnh mẽ hơn động lực bên ngoài. Lí do khiến ai đó chăm chỉ làm việc hơn thường là vì họ muốn thế <- không phải bàn cãi về điều này. Nhưng khi bạn thưởng tiền để ai đó làm công việc mà họ thích, họ sẽ trải qua cái gọi là trạng thái quá độ (1). “Tôi phải viết chương trình ít bug hơn vì tôi muốn khoản tiền đó”, họ sẽ nghĩ như vậy, và bây giờ, động cơ bên ngoài đã thay thế động cơ bên trong! Bởi động cơ bên ngoài luôn yếu hơn nhiều so với động cơ bên trong nên kết quả là, bạn đã làm giảm mong muốn làm việc của họ. Sau này, khi bạn thôi không thưởng tiền cho họ nữa, họ sẽ không còn nghĩ đến chuyện bug biếc gì ở đây nữa!

Một vấn đề lớn khác của phương pháp Econ 101 là khiến cho các nhân viên của bạn cố gắng đạt cái mà bạn thưởng cho họ chứ không thực sự là cái bạn muốn ở họ.

Ví dụ vơi các nhân viên ở trung tâm khách hàng. Nhân viên của bạn vì muốn kiếm tiền thưởng đã cố nài khiến khách hàng phát điên lên, đến mức tờ “Hà Nội mới” dành một trang về dịch vụ khách hàng khó chịu của công ty bạn.

Hay khi bạn muốn thưởng cho developer viết chương trình ít bug nhất. Giờ đây, các tester sẽ cố gắng report thật nhiều lỗi, khiến nảy ra cả cãi nhau.

Developer: “Cái đó mà gọi là bug à.”,

Tester: “Ừ đấy”, ...

Vấn đề lớn nhất của Econ 101 là nó khiến mọi người làm theo cách của riêng họ, thay vì cố gằng làm việc tôt hơn.

Nếu bạn từng học một khoá học về Kinh tế, trước khi thầy giáo giải thích cho bạn rằng “tiện ích không tính bằng dollar”, bạn có thể đã nghĩ rằng dùng những phần thưởng nhỏ là một cách quản lí tốt. Nhưng không phải. Hãy quản lí thực sự, chứ đừng bắt chước người Do Thái, đưa những đồng Kopeck cho con gà! Quản lí là xây dựng hệ thống mà mọi người có thể làm việc trong đó, cần phải tránh việc thay thế động cơ bên trong bằng động cơ bên ngoài.

Bây giờ, như bạn đã thấy, hai phương pháp “Command and Control” và Econ 101 đã bị loại, chỉ còn một cách có thể giúp bạn khiến mọi người đi đúng hướng, đó là phương pháp “Identity” mà chúng ta sẽ nói đến trong phần sau.

(1) Overjustification

Phương pháp Indentity

Giờ chỉ còn lại phương pháp quản lí Indentity (tạm dịch là “thống nhất”). Mục đích của phương pháp này là khiến mọi người nhận biết và đồng cảm với mục đích mà bạn muốn đạt tới. Phương pháp này khó hơn hai phuơng pháp trước nhưng nếu bạn làm được, bạn sẽ thấy nó rất hiệu quả.

Nếu vấn đề của Econ 101 là nó làm lu mờ động cơ bên trong thì *Identity lại là phương pháp tạo ra động cơ bên trong.

Để trở thành người quản lí theo phương pháp Identity, bạn phải vận dùng tất cả các kĩ năng mềm của mình để khiến nhân viên nhận thức và đồng cảm với mục đích của tổ chức, khiến họ được thúc đẩy mạnh mẽ, sau đó, bạn phải cung cấp cho họ những thông tin họ cần để có thể đi đúng con đường đó

  1. Làm thế nào để nhân viên đồng cảm với tổ chức? Có một cách rất tốt là ăn uống cùng nhau. Ở Fog Creek, chúng tôi luôn ăn trưa cùng nhau, trên một cái bàn lớn. Điều này đã khiến công ty giống như một gia đình vậy, và trong 6 năm, không ai rời công ty cả. Cũng có một vài cách khác mà chúng tôi đã làm là tổ chức hội New Yorker, tổ chức những hoạt động hè: Broadway shows, hành trình lên đỉnh núi, chèo thuyền quanh Manhattan, chơi trò Yankees, đi bảo tàng, tổ chức Party… Tóm lại, phương pháp Identity đòi hỏi bạn tạo ra một đội đoàn kết, khiến mọi người cảm giác như một gia đình, thân thiết với nhau.
  2. Cung cấp cho mọi người những thông tin cần để đưa tổ chức đi đúng hướng: Hôm trước, Brett vào phòng tôi và thảo luận về ngày ra sản phẩm FogBugz 6.0. Anh ấy đưa ra thời điểm tháng 4, 2007 còn tôi: tháng 12, 2006. Tất nhiên nếu là tháng 4, 2007, chúng tôi sẽ có thêm thời gian để gọt dũa, phát triển sản phẩm; còn nếu là tháng 12, 2006 thì chung tôi sẽ phải cắt bỏ một số tính năng của sản phẩm. Tôi giải thích với Brett về động cơ tài chính của việc ra sản phẩm sớm hơn, và khi anh ấy biết điều đó, tôi tin là anh ấy sẽ có quyết định đúng đắn cho riêng mình. Nếu sử dụng cách “Command and Control”, Brett vẫn sẽ làm, nhưng anh ấy sẽ ghét công việc này và sớm muộn cũng sẽ rời bỏ nó.

Kết luận: mỗi manager có cách quản lí khác nhau. Tôi xếp các cách ấy vào ba loại chính: hai dễ, một khó. Cách Indentity là hiệu quả hơn cả. Tuy nhiên nó có thể không hiệu quả với một số người, ở một số thời điểm!

Nguồn: Lược dịch từ Joel on Software

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Ngoc Dao

102 bài viết.
285 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
62 8
Làm thế nào để nâng cấp trang web mà không làm gián đoạn dịch vụ? Đây là câu hỏi phỏng vấn các công ty lớn thường hỏi khi bạn xin vào vị trí làm lậ...
Ngoc Dao viết hơn 2 năm trước
62 8
White
40 1
Bài viết này giải thích sự khác khác nhau giữa hai ngành khoa học máy tính (computer science) và kĩ thuật phần mềm (software engineering), hi vọng ...
Ngoc Dao viết hơn 2 năm trước
40 1
White
21 1
SVVN số 29/2008] Theo GS làm thế nào để đào tạo được những sinh viên là lực lượng lao động có thể đáp ứng được thực tế rất bất trắc, rất dễ thay đổ...
Ngoc Dao viết hơn 2 năm trước
21 1
Bài viết liên quan
White
1 1
Lập trình đôi (pair programming) là hình thức lập trình trong đó 2 người cùng hợp tác làm việc trên cùng màn hình (có thể khác bàn phím v.v.). Bài ...
Ngoc Dao viết hơn 2 năm trước
1 1
White
7 1
Trong quyển sách Beyond Java, xuất bản vài năm trước có đoạn:Java has characteristics that many of us take for granted. You can find good Java deve...
Ngoc Dao viết hơn 2 năm trước
7 1
White
5 0
Lập trình viên quá cố người Mỹ Phil Karlton có câu nổi tiếng: There are only two hard things in Computer Science: cache invalidation and naming th...
Ngoc Dao viết hơn 2 năm trước
5 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
102 bài viết.
285 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!