Inamori Kazuo được biết đến rộng rãi ở Việt Nam. Sách của ông được dịch nhiều và bán rất chạy. Cuốn “Nghĩ thiện” thậm chí còn mới đạt giải Sách hay. Bạn có thể tra wiki để biết thân thế và sự nghiệp của ông. Bạn cũng sẽ nhiều bài viết về ông, về hệ thống quản lí Amoeba Management trứ danh đã giúp ông gây dựng Kyocera thành công ty đa quốc gia hàng đầu thế giới, biến KDDI thành công ty viễn thông lớn mạnh số 2 Nhật Bản, giải cứu thành công Japan Airlines sau khủng hoảng tài chính toàn cầu. Hệ thống quản trị này cũng đã giúp hàng trăm doanh nghiệp Nhật Bản phát triển. Do đó, có nhiều lí do để mỗi nhà quản lí để ý tới những gì Inamori nói và làm.
Hệ thống quản trị của Inamori rất đặc sắc, bắt đầu bằng một triết lí nhất quán, tiếp theo là một hệ thống các nguyên lý có tính phổ quát có thể nhân rộng (do đó, việc quản trị sẽ dựa theo nguyên tắc), và một cơ cấu tổ chức linh hoạt có tên amoeba magement system (mà ngày nay các nhà quản trị phương Tây sẽ gọi là các tổ chức linh hoạt – Agile Organization).
Phần sau đây tôi xin giới thiệu 12 nguyên tắc quản trị của Inamori. Đây là một bộ nguyên tắc mà có thể ai đó vồ được sẽ coi như bảo bối. Nó đã được đúc rút qua nhiều thập kỉ, và được kiểm chứng qua nhiều thập kỉ khác để có thể trở thành nguyên lí vượt qua giới hạn địa lí, dân tộc, hay ngôn ngữ. Bài được dịch nguyên gốc ra từ trang riêng của Inamori, với sự trợ giúp tuyệt vời của Google Translate (nói đúng ra thì phải là tôi hiệu đính từ bản dịch của Google) :). Có một lưu ý nhỏ, 12 nguyên tắc này, được Inamori dựa trên một câu hỏi định hướng duy nhất, để kiểm chứng sự đúng đắn: “Ta phải làm điều gì đúng đắn với tư cách một con người?”.
Mời bạn đọc, suy nghĩ, thử nghiệm và cùng thảo luận.
The Age of Agile, Steve Denning (Về quản trị, Agile Mindset, Tổ chức Agile)
Khởi nghiệp tinh gọn, Eric Ries (Khởi nghiệp kiểu Agile, tư duy về đổi mới và sản phẩm mới)
Agile People, M. Thoren (Công tác nhân sự và lãnh đạo trong tổ chức Agile)
Tái tạo tổ chức, F Laloux (Linh hoạt hoá cấu trúc tổ chức và hệ tư duy đi kèm)
Quản trị dựa vào tri thức, I. Nonaka và cộng sự (Một trong những học thuyết nền tảng của Scrum; Nonaka cùng với Takeuchi được công nhận là “ông nội” của Scrum)
Phương thức Toyota, J K Liker (Nghiên cứu Toyota để hiểu hơn về Scrum trong và nhiều phương thức tổ chức sản xuất ngoài phần mềm)
Làm điều quan trọng, J Doerr (Không phải sách về Agile, nhưng lại hữu ích đối với việc tư duy linh hoạt về mục tiêu, teamwork)
Tâm lí học thành công, C. Dweck (sách này về growth mindset, chính là nền tảng của Agile mindset và Agile culture).
Cẩm nang Scrum, DT Tấn, NV Khoa, PA Đới, NK Nhật. (Tài liệu hướng dẫn thực hành Scrum cho các đối tượng khác nhau: quản lí, team leader, marketing team…)
Xưa nhà tôi làm ruộng, động mưa tí là tôi tìm cách ngồi nhà, trời nắng to là trốn tưới tắm cho rau.
Nhưng bầm mắng cho. Bầm giữ kỉ luật rất nghiêm. “Mưa vẫn phải ra đồng, cỏ nó đợi lúc mưa để mọc. Nắng vẫn phải đội mũ mà tưới tắm, vì lúc ấy cây nó đang đợi nước để lớn lên kịp lúc mà bán”.
Làm việc, tức là phải làm những việc cần phải làm, không phải là muốn thì làm không muốn thì thôi.
Như thế là chuyên nghiệp, là kỉ luật đấy.
Tưởng chuyện như vậy là hiển nhiên và chuyện nhỏ. Cho tới tuần rồi, trong khuôn khổ CLB Đọc sách thông minh, khi đọc lại các kinh điển của Peter Drucker, thấy cụ nói y chang lời bầm. “Nhà điều hành cần phải làm việc cần làm, không phải là việc muốn làm hay không”. Hoạt động phải hướng ra bên ngoài, xem khách hàng cần gì, sứ mệnh phải là sứ mệnh hướng ra bên ngoài, xem nó giải quyết vấn đề thị trường gì.
Theo định nghĩa rộng của Drucker, người điều hành (executive) có thể là bất cứ người lao động trí tuệ độc lập nào. Tôi nghĩ, quy tắc mà bầm tôi dạy thực ra có giá trị với mọi người, để có thể làm việc ra kết quả.
Sách Được việc cuối cùng cũng bắt đầu đến tay bạn đọc sau nhiều lần quảng cáo bìa 🙂
Tiếp nối các chương trình đào tạo giúp tăng hiệu quả các nhân và nhóm làm việc trong khuôn khổ tại Học viện Agile, cuốn sách này như một nỗ lực nhỏ của tôi giúp bạn gần xa có được những gợi ý tốt để cải thiện năng suất, làm được nhiều việc hơn, và làm chủ tốt hơn công việc của mình.
Sách này tôi thích nhất cái bìa, họa sĩ đã dành tặng tác giả và bạn đọc một cái bìa rất hiện đại, giản dị mà không kém phần tinh tế.
Thích thứ nhì là cái tít phụ. Có vài người phê tít này không hay, nên đặt là “làm nhân viên chuyên nghiệp” hoặc “làm thuê chuyên nghiệp”, hoặc “làm việc năng suất”. Nhưng tôi lại đặt là “bí kíp làm nhân viên bình thường”. Bạn thử nghĩ xem, cái tít hay thế chứ lị. Và nếu bạn đọc sách, bạn sẽ còn thích cái tít phụ này hơn nữa.
Thông tin chi tiết có ở trang riêng của Được việc.
<Ghi chú: Kẻ thế-mà-đần (dummy) không phải là kẻ
đần (idiot). Đó là kẻ biết để rỗng tâm trí của mình trước một cái mới hoặc cũ,
để học được những cái mới hoặc những góc nhìn mới của những cái đã biết. Chuỗi
bài “thế-mà-đần” cố gắng diễn giải các khái niệm theo cách dễ hiểu, nhưng đôi
khi vẫn rất khó hiểu. Bài viết thường dài, vì thế mong bạn kiên nhẫn và bao
dung nhé.>
Sức mạnh của mindset
Gần đây tập đoàn Microsoft được đánh giá là công ty có giá trị 1000 tỉ đô la
Mỹ (để so sánh về độ lớn: cả nước Việt Nam chúng ta một năm làm ra chưa đến 250
tỉ đô la). Một vị thế chưa từng có trong lịch sử. Trong ngày giá trị công
ty cán mốc 1000 tỉ đô la Mĩ, CEO của MS là Satya Nadella trả lời phỏng vấn tờ
Bloomberg “Tôi sẽ kinh tởm nếu ai đó ăn mừng giá trị vốn hoá của công
ty.”[1] Sao lại kì lạ vậy?
Ken mới xem video “Agile là gì?” của Học viện Agile. Xem xong không hiểu gì bèn lôi Sun ra hỏi.
Ken: Agile có đảm bảo sự thành công không? Sun: Không. Xạ thủ Hoàng Xuân Vinh rất giỏi bắn súng, có lúc được huy chương vàng Olympic, lại thất bại ở Asiad tầm thấp hơn. Thành công là kết quả mang tính thời điểm, sự chuẩn bị, năng lực, nhất là phong độ và may mắn nữa. Anh Vinh có đỉnh không, sao vẫn hỏng?
Ken: Sao bảo nhóm Agile có tỉ lệ thành công của dự án cao hơn? Sun: Thì cao hơn chứ có phải đảm bảo đâu. Thống kê ra con số trung bình, từ đó mà nhìn ra chủ yếu là tương quan, chứ không phải là cứ A thì B. Làm dự án phức tạp lắm, bao nhiêu thứ có thể tác động đến sự thành bại.
Ken: Agile có đảm bảo mình sẽ hơn đối thủ không? Sun: Không. Nhỡ đâu đối thủ cũng dùng Agile mà lại giỏi hơn thì sao? Lợi thế cạnh tranh đâu cớ đơn giản thế.
Ken: Thế vì sao tôi phải dùng Agile? Sun: Cái đó ông phải tự biết chứ. Agile có giúp ông được gì không? Nếu không giúp được gì thì dùng làm gì, hâm à.
Ken: Nghe đồn cứ làm Agile thì sản phẩm tốt. Có phải không? Sun: Phét đấy. Cái đấy phụ thuộc các năng lực làm ra sản phẩm và đảm bảo chất lượng. Agile không phải toàn bộ điều kiện cần duy nhất. Và trong nhiều cách thức để đạt được chất lượng, có thể có cách không cần Agile.
Ken: Nghe đồn nhóm Agile thì không phải làm việc quá giờ, cứ 5 giờ ra về trong vui sướng? Sun: Phét. Làm việc quá giờ liên quan rất ít đến Agile. Nó liên quan đến các tình huống cụ thể, có lúc cần lúc không, liên quan đến gu của leader và cả sở thích của nhân viên nữa hehe
Ken: Ơ, thế Agile có gì hay nhỉ? Sun: Ông xem lại video đi.
<Một lát cắt Agile> Các phương pháp dưới nhãn hiệu Agile nổi tiếng như XP, Scrum xuất hiện chính thức xung quanh mốc 1995. Mặc dù trước đó từ rất lâu đã có những nhóm làm phần mềm hao hao như các phương pháp này mô tả. Nhưng cứ tính từ lúc chính quy thì lấy tạm 1995. Lúc này người ta còn chưa viết cái nhãn Agile lên các phương pháp này, bởi vì nó chưa có.
Suốt thời kì từ 95 tới hết những năm 90 là giai đoạn cãi nhau ỏm tỏi. Phê phán đủ kiểu. Nào là “không học thuật”, “đơn giản chủ nghĩa”, “chỉ dành cho nhóm nhỏ và rất nhỏ, không có nghĩa lí gì”, vân vân. Nhưng các công ty vẫn thấy nó tạo ra kết quả tốt hơn nên cứ tự phát mà dùng, nhất là những ông khởi nghiệp. Chính lực lượng khởi nghiệp với nhu cầu đổi mới cao độ, tốc độ di chuyển chóng mặt mới làm khác đi, dùng cách khác bọn khủng long để mong vượt lên phía trước. 2001, các cha đẻ của những phương pháp có tính chất linh hoạt, ít quy trình nặng nề, có tính thích ứng cao, hỗ trợ tốt cộng tác, hướng đến khách mà sau này gọi chung là Agile ngồi lại và cùng viết ra “The Manifesto for software development”, sau này gọi tắt là Agile Manifesto (Cái kiểu gọi tắt này đã từng bị một trong các cha đẻ của manifesto phê bình, nhưng ai mà cấm được thiên hạ thích gọi tắt :-). Bây giờ người ta vẫn tiếp tục gọi tắt như thế). Nhãn hiệu Agile chính thức ra đời. Sau đó là phường hội ra đời, nào là Agile Alliance, rồi Scrum Alliance. Rồi hàng loạt hội thảo quy mô từ nghìn người đến chục nghìn người cũng ra đời Agile Conference, Scrum Gathering…. Scrum, Agile loang ra như một đại dịch.
Sách của Jeff Sutherland có ghi vào 2007, Microsoft bắt đầu đưa Scrum vào để đổi cách làm việc thuộc khuôn khổ dự án Visual Studio Online để hòng gia tăng tốc độ chuyển giao sản phẩm ra thị trường. Rồi từ chỗ thí điểm thành ra quy trình chính thức (khi quyết định mở rộng phạm vi áp dụng vào 2011), rồi thành quy trình chủ đạo. Theo báo cáo của Steve Denning vào năm 2015, thì quá trình chuyển đổi này có thể tính là đã hoàn tất vào năm 2014. Khoảng 4000 lập trình viên của microsoft được biên chế trong các nhóm nhỏ tầm 12,13 người, làm việc trong các cuh trình ngắn 3 tuần để liên tục chuyển giao sản phẩm có chất lượng tới khách hàng. Nếu trước kia Microsoft có thể mất vài năm để cho ra một phiên bản sản phẩm mới, thì nay thời gian đó rút ngắn xuống còn vài tháng, chất lượng thì khác hẳn. Vào khoảng cuối những năm 2000, nhiều người nhận rõ sự khác biệt về chất lượng phần mềm của MS viết ra so với các đối thủ chính của nó. Ngày nay thì ít còn thấy những so sánh kiểu như vậy nữa. Có thể nói, đế chế phần mềm số 1, con khủng long lớn nhất đã học cách khiêu vũ trong gần 1 thập kỉ. Trước MS vài bước, Google, Amazon, Yahoo!(lúc đó còn hùng mạnh), rồi cậu trẻ Facebook.. đều đã Agile xong xuôi rồi và đang tính những cái khác rồi.
Thập kỉ 2000s có thể được coi là thập kỉ Agile dậy thì thành công. Đến nay, ở các nơi tiên tiến (trừ Nhật, bây giờ người ta cũng đặt câu hỏi về tính tiên tiến của nước Nhật rồi, ít nhất là trong khu vực đổi mới sáng tạo), Agile đã mainstream. Và các vùng trũng cũng bắt đầu vận dụng Agile ở diện rộng. Không chỉ trong phạm vi thực hành ở các công ty, mà còn xuất hiện như đề tài nghiên cứu khoa học, và sinh viên thì được dạy từ lúc còn trên ghế nhà trường (thậm chí đã loang xuống các dự án học tập ở cấp 2).
Ngay ở Việt Nam, trong vòng gần 1 thập kỉ “làm Agile” của tôi, cũng phản ánh một cái hình ảnh hao hao như kể trên, ở quy mô hẹp hơn. Được du nhập hơi muộn, Agile ở VN chỉ được “tiếp nhận” bài bản và chính quy chỉ từ đầu những năm 2010s. Và cũng từ chỗ cãi nhau xem nó có đúng hay không, đến nó hay chỗ nào dở chỗ nào, liệu có đúng ở VN không, đến chỗ mạnh dạn làm thử (và có nhiều ca thất bại), và mạnh dạn thuê dịch vụ tư vấn huấn luyện để làm cho bằng được. Từ vài chục doanh nghiệp có một chút hiểu biết và vận dụng Agile, đến nay thì Việt Nam đã có hàng trăm (và có thể là hàng nghìn, do tôi không có con số chính xác) doanh nghiệp chủ động vận dụng Agile. Nhiều doanh nghiệp thì đã mạnh dạn đẩy sang mức độ enterprise giống như cách Microsoft chuyển mình như kể trên. Ngày nay nhiều trường ĐH ở VN cũng bắt đầu có nhắc đến Agile. Một số nơi thì đã bài bản lắm. Nhưng nhìn chung thì cũng dường như mới bắt đầu thôi. Học viện Agile ra đời cách đây hơn 2 năm, nhưng giờ làm không hết việc. Có lẽ là một một dấu hiệu của bước chuyển từ giai đoạn “tinh hoa” sang giai đoạn “phổ cập” chăng? Như thế cũng đã hơn chục năm để một nhãn hiệu đi vào đời sống.
Hình như không có lối tắt cho đổi mới căn bản và toàn diện. Nhất là khi nó đụng phải những hệ thống có tính quan liêu rất cao độ.
Còn nhớ cũng mới chỉ cách đây có hai năm thôi, khi đến thăm doanh nghiệp để học hỏi, một chủ doanh nghiệp rất trẻ và tài năng (cựu sinh viên đi về từ đất nước mặt trời mọc) rất hồn nhiên nói với tôi “em rất ghét bọn Agile”, vì bọn nó hay khen vống lên, nghĩ là “Agile giải quyết đợc mọi vấn đề”, chả khác gì cuồng tín. Tôi nói lại “đấy là do chứ chưa gặp anh thôi. Anh cũng là một trong bọn Agile đấy”. Thế rồi cùng nói chuyện. Cuộc gặp gỡ ấy kết thúc trong hoan hỉ và thân ái. Chủ doanh nghiệp khách sáo tiễn đưa tôi ra cầu thang và nói “em đã đổi cái nhìn về Agile, không còn ghét nữa rồi”. Chả biết sau này những người anh em thiện lành ấy có tiến lên Agile tí nào không. Cùng thời điểm ấy, Phó tổng giám đốc FSOFT, Mr. Khắc đẹp trai và thư sinh đã khẳng định trên VTV2 “fsoft chủ yếu làm Agile rồi, vì khách hàng yêu cầu như thế”. Có lẽ hiện nay đế chế FSOFT là nơi giữ nhiều chứng chỉ quốc tế về Agile nhất VN. Trong cùng một thành phố phù hoa Paris xứ Đông Lào này, vẫn tồn tại nhiều hơn 2 thế hệ “hệ điều hành quản trị”, giống như trên thế giới này tồn tại những “văn minh” khác nhau. Tương tự như vẫn tồn tại một nước Mỹ tốc độ có một nhà nước hiện đại, và một vùng đâu đó ở New Guinea vẫn còn chủ yếu sống theo kiểu thị tộc hết sức sơ khai. Hình như chúng vẫn chung sống hòa bình.
Trong khóa học Agile Management do Học viện Agile tổ chức, tôi thường gợi ý một số cuốn sách tốt để làm chất liệu cho tư duy và thực hành quản lí.
Danh sách dưới đây là tổng hợp danh mục những cuốn sách tốt dành cho nhà quản lí nhâm nhi mỗi ngày, có thể đủ cho ít nhất 1 năm đọc và học nghiêm túc.
Thứ tự không phản ánh một ưu tiên nào, chỉ là đánh số cho dễ tra cứu. Với một số cuốn sách, tôi có một bài điểm ngắn. Bạn đọc có thể theo đường dẫn để đọc thêm. Hãy dùng Google nếu bạn muốn biết nơi nào bán những cuốn sách này.
Tôi ưu tiên những sách của các tác giả quan trọng, những thought leader trên thế giới, những cuốn sách chứa nhiều thông tin khoa học hơn là sách hướng dẫn kiểu gạch đầu dòng (mặc dù cũng có ngoại lệ). Tôi ưu tiên sách đã được xuất bản bằng tiếng Việt, nhưng cũng để vài cuốn chưa được dịch, biết đâu có ai đọc được lại nảy sinh lòng ham muốn dịch nó ra :-).
Chúng ta là những con người phàm tục với kiến thức hạn chế và ý chí độc lập.
Môi trường kinh doanh là không thể đoán trước và không chắc chắn, vì vậy chúng ta nên mong đợi điều bất ngờ và không nên lập kế hoạch vượt quá hoàn cảnh mà chúng ta có thể thấy trước.
Trong phạm vi hạn chế của kiến thức hạn hẹp của mình, chúng ta nên cố gắng xác định những yếu tố căn bản của một tình huống và lựa chọn những gì cần thiết nhất để đạt được.
Để cho phép mọi người hành động có hiệu quả, chúng ta phải đảm bảo họ hiểu họ sẽ đạt được điều gì và tại sao lại phải như vậy.
Sau đó họ nên giải thích những gì họ sẽ làm như là một kết quả, xác định các nhiệm vụ cần thiết, và kiểm tra lại với chúng ta.
Sau đó họ sẽ phân công nhiệm vụ đã xác định cho những cá nhân có trách nhiệm đạt được chúng và chỉ định ranh giới trong đó họ được tự do hành động.
Mọi người đều phải có kỹ năng và nguồn lực để làm những gì cần thiết và một không gian để có những quyết định và hành động độc lập khi sự kiện bất ngờ xảy ra, như nó sẽ xảy ra.
Khi tình hình thay đổi, mọi người nên được dự kiến sẽ điều chỉnh hành động của mình theo sự đánh giá tốt nhất của họ để đạt được kết quả mong muốn.
Mọi người sẽ chỉ cho thấy mức độ yêu cầu bắt buộc nếu họ tin rằng tổ chức sẽ hỗ trợ họ.
Cái gì không được làm cho thành ra đơn giản thì không thể nói rõ ràng được, và những gì không rõ ràng thì sẽ không được thực hiện.
<Siêu tóm tắt từ The art of action, Stephen Bungay>
Mấy vị lập trình viên phần mềm dùng Agile Software Development để làm ra phần mềm thay đổi thế giới. Việc này nhiều người đã biết. Kể từ 2001 với bản Tuyên ngôn Agile ra đời, Agile đã trở thành lối làm việc mới ưa thích của dân phần mềm. Nhưng Agile đã không chịu dừng ở đó.
