Có 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.
10 trang |
Chia sẻ: maiphuongdc | Lượt xem: 1985 | Lượt tải: 3
Bạn đang xem nội dung tài liệu Ba phương pháp quản lý, để tải tài liệu về máy bạn click vào nút DOWNLOAD ở trên
Ba phương pháp
quản lý
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 (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), 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...
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ạn 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!)
Có 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:
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)
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 đó
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.
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!
(Theo Joel on Software/CNTT.TV)
Các file đính kèm theo tài liệu này:
- ba_phuong_phap_quan_ly_7637.pdf