- Các doanh nghiệp chi rất nhiều để bắt kịp năng lực vận hành như năng lực sản xuất kiểu Toyota, chất lượng six-sigma, hay chuỗi cung ứng kiểu Dell, nhưng hiếm khi các chương trình cải tiến tạo ra kết quả bền vững
- TQM là một ví dụ từng được dùng rộng rãi rồi nhanh chóng thoái trào; trong Fortune 1000, số doanh nghiệp có chương trình TQM phát triển tốt chiếm dưới 10%
- Nguyên nhân thất bại không nằm nhiều ở việc chọn công cụ nào, mà ở cách chương trình mới ăn khớp với các cấu trúc vật lý, kinh tế, xã hội và tâm lý; vì thế cải tiến rốt cuộc trở thành vấn đề hệ thống
- Khi khoảng cách hiệu suất tăng lên, tổ chức phải chọn giữa Work Harder là làm việc nhiều hơn và Work Smarter là nâng cao năng lực, nhưng phương án sau dễ bị lép vế vì độ trễ và rủi ro thất bại
- Shortcuts giúp giảm thời gian dành cho cải tiến nên hấp dẫn trong ngắn hạn, nhưng khi sự suy giảm năng lực bộc lộ muộn rồi tích lũy dần, tổ chức có thể bị mắc kẹt trong Capability Trap
Nghịch lý khiến các chương trình cải tiến thất bại
- Doanh nghiệp tích cực đầu tư vào cải tiến quy trình để phát triển năng lực vận hành như sản xuất, chất lượng, hiểu biết khách hàng và quản lý chuỗi cung ứng
- Năm 1997, tổng chi tiêu của các doanh nghiệp Mỹ cho tư vấn quản trị và đào tạo vượt 100 tỷ USD, và một phần lớn được dùng để bắt kịp năng lực vận hành của các công ty xuất sắc
- Dù có một số thành công rất ấn tượng, nhiều chương trình cải tiến vẫn không tạo ra kết quả có ý nghĩa
- TQM cho thấy rõ nghịch lý này
- Trong thập niên 1980, nó bùng nổ mạnh mẽ trong các doanh nghiệp Mỹ sau khi bị thôi thúc bởi thành công của các công ty Nhật Bản
- Đến giữa thập niên 1990, sự quan tâm từ giới học thuật và truyền thông kinh doanh suy giảm, và nó bị các đổi mới mới như re-engineering lấn át
- Những doanh nghiệp cam kết nghiêm túc với kỷ luật và phương pháp của TQM đạt hiệu quả cao hơn đối thủ
- Một nghiên cứu cho thấy trong Fortune 1000, số doanh nghiệp có chương trình TQM phát triển tốt là dưới 10%
- Một nghiên cứu khác cho thấy TQM là công cụ kinh doanh được dùng nhiều thứ ba vào năm 1993, nhưng đến năm 1999 đã rơi xuống hạng 14
- Các kỹ thuật cải tiến trong quá khứ đôi khi quay trở lại dưới tên mới
- Các kỷ luật cốt lõi của kiểm soát quy trình bằng thống kê và giảm biến thiên tiếp nối thành six-sigma
- quality circle được gọi lại là high-performance work team
Điều khó hơn công cụ là cấu trúc triển khai
- Các công cụ và kỹ thuật cải thiện hiệu suất tăng lên rất nhanh, và nhờ công nghệ thông tin cùng sự gia tăng của các nhà tư vấn, việc học xem ai đang dùng kỹ thuật nào cũng trở nên dễ hơn
- Với phần lớn nhà quản lý, rào cản lớn hơn không phải là biết phương pháp mới, mà là triển khai thành công nó vào công việc hằng ngày
- Những năng lực như chương trình chất lượng six-sigma không thể mua như một sản phẩm trọn gói, mà phải được phát triển bên trong tổ chức
- Trong hơn 10 năm, đã có hơn 12 nghiên cứu tình huống chuyên sâu được thực hiện trong các ngành viễn thông, bán dẫn, hóa chất, dầu khí, ô tô và sản phẩm giải trí
- Quan sát, phỏng vấn người tham gia, tài liệu ghi chép và chỉ số định lượng đều được sử dụng
- Các mô hình để nắm bắt động lực của triển khai và cải tiến cũng được phát triển song song
- Lý do khiến phần lớn tổ chức không thu được trọn vẹn lợi ích của các đổi mới cải tiến hầu như không liên quan đến việc chọn công cụ cải tiến nào
- Các chương trình cải tiến mới vận hành tại nơi công cụ, thiết bị, người lao động, nhà quản lý và các cấu trúc vật lý, kinh tế, xã hội, tâm lý đan xen với nhau, nên nó trở thành một vấn đề mang tính hệ thống
Vật lý học cơ bản của cải tiến: thời gian và năng lực
- Hiệu suất thực tế của quy trình được quyết định bởi thời gian dành cho công việc (Time Spent Working) và năng lực quy trình (Capability) để thực hiện công việc đó
- Trong sản xuất, đầu ra sử dụng ròng được xác định bằng tích của số giờ lao động mỗi ngày và năng suất, tức lượng đầu ra khả dụng trên mỗi giờ lao động
- Hiệu suất có thể được nâng lên bằng cách làm nhiều hơn hoặc đầu tư nhiều hơn cho cải tiến, nhưng kết quả của hai cách này là khác nhau
- Nếu tăng giờ làm việc mỗi tuần thêm 20%, đầu ra có thể tăng 20% chừng nào việc làm thêm giờ còn được duy trì
- Cải thiện năng lực quy trình sẽ nâng đầu ra của mọi giờ làm việc được đưa vào sau đó
- Làm thêm giờ để sửa lại sản phẩm lỗi chỉ tăng đầu ra khi việc làm thêm giờ còn tiếp diễn, nhưng loại bỏ nguyên nhân gốc của lỗi sẽ liên tục giảm nhu cầu làm lại
- Năng lực được xem như một tài sản tích lũy (stock) tăng dần theo thời gian
- Thời gian dành cho cải tiến làm tăng đầu tư vào năng lực
- Vì cần thời gian để tìm nguyên nhân gốc, khám phá, thử nghiệm và triển khai giải pháp, nên tồn tại độ trễ giữa hoạt động cải tiến và thay đổi năng lực
- Năng lực không được duy trì thường xuyên sẽ suy giảm do máy móc hao mòn, quy trình lệch chuẩn, thiết kế lạc hậu và thủ tục lỗi thời
- Độ trễ của cải tiến thay đổi tùy theo mức độ phức tạp kỹ thuật và tổ chức của quy trình
- Với cải tiến quy trình tương đối đơn giản như năng suất máy trong job shop, độ trễ ở quy mô vài tháng
- Với các quy trình phức tạp như phát triển sản phẩm, độ trễ cải tiến có thể kéo dài vài năm hoặc hơn
- Ở các tổ chức có tốc độ thay đổi sản phẩm và nhân sự cao, tuổi thọ của năng lực đã được cải thiện cũng ngắn hơn
Sự căng thẳng giữa Work Harder và Work Smarter
- Ban lãnh đạo đặt các mục tiêu như nhu cầu khách hàng, số lượng hồ sơ bảo hiểm xử lý, hay số sản phẩm mới ra mắt theo quý làm Desired Performance
- Chênh lệch giữa hiệu suất thực tế và mục tiêu trở thành Performance Gap, và trong các tổ chức được nghiên cứu, rất hiếm khi tìm thấy một quy trình vượt kỳ vọng
- Ở những tổ chức ngại mở rộng nguồn lực hay tuyển thêm người, có hai lựa chọn cơ bản để thu hẹp khoảng cách hiệu suất
-
Vòng lặp Work Harder
- Khi có khoảng cách hiệu suất, nhà quản lý tăng áp lực công việc bằng cách đẩy nhanh tốc độ làm việc, tăng làm thêm giờ, đặt mục tiêu quyết liệt hơn hoặc áp dụng hình phạt khi không đạt chỉ tiêu
- Những cách tinh vi hơn như tăng tần suất đánh giá kết quả, mức độ chi tiết của đánh giá, hay cấp bậc của người đánh giá cũng thuộc về áp lực công việc
- Ở một công ty, một phó chủ tịch cấp cao xem xét hiệu suất của từng máy tại nhà máy, và điều này trở thành thông điệp rằng phải giữ máy chạy bằng mọi giá
- Một quản lý dự án khi thấy lịch của hệ thống con mình phụ trách bị chậm đã bị yêu cầu gọi báo cáo tình trạng mỗi giờ cho đến khi nguyên mẫu đáp ứng thông số kỹ thuật
-
Vòng lặp Work Smarter
- Nhà quản lý có thể cố nâng năng lực quy trình bằng cách khởi động chương trình cải tiến, khuyến khích thử nghiệm ý tưởng mới và đầu tư vào đào tạo
- Nếu thành công, theo thời gian năng lực được cải thiện, thông lượng tăng lên và khoảng cách hiệu suất giảm xuống
- Đầu tư cải tiến có thể tạo hiệu quả lớn hơn về dài hạn, nhưng phải mất đáng kể thời gian mới thấy tác dụng và luôn có rủi ro thất bại trong việc tìm ra nguyên nhân gốc hoặc áp dụng công cụ mới
- Trong các vấn đề khẩn cấp, Work Harder thường được chọn
- Nếu một dây chuyền sản xuất phục vụ khách hàng quan trọng bị dừng, nhà quản lý thường dễ chọn cách cho dây chuyền chạy lại và thúc ép làm thêm giờ đến khi giao xong hàng hơn là đào tạo cải thiện độ tin cậy
- Nếu sau khi xử lý tạm thời mà tổ chức không quay lại với hoạt động cải tiến, cách làm việc chăm hơn sẽ trở thành phương thức vận hành tiêu chuẩn
Vòng lặp tái đầu tư và bẫy năng lực
- Các tổ chức gần như không có nguồn lực dư thừa, nên khi áp lực công việc tăng, mọi người sẽ giảm các hoạt động không phải công việc như nghỉ ngơi và tăng làm thêm giờ
- Việc làm thêm giờ của lao động tri thức thường không được trả công, kéo dài sang buổi tối và cuối tuần, lấy đi thời gian dành cho gia đình và cộng đồng
- Khi thời gian không thể tăng thêm nữa, cách duy nhất để theo kịp khoảng cách hiệu suất ngày càng lớn là cắt giảm thời gian dành cho cải tiến
-
Vòng lặp Reinvestment
- Nếu đầu tư cải tiến thành công, hiệu suất tăng lên và khoảng cách hiệu suất giảm xuống, nhờ đó có thể dành nhiều thời gian hơn cho cải tiến, tạo ra một vòng tuần hoàn tích cực
- Ngược lại, nếu phản ứng với khoảng cách thông lượng bằng áp lực công việc, thời gian cải tiến sẽ giảm, năng lực suy thoái và khoảng cách hiệu suất còn tăng thêm, dẫn tới vòng xoáy tiêu cực với áp lực mạnh hơn và ít cải tiến hơn
- Trong các trường hợp cải tiến thành công, nguồn lực có được nhờ năng suất tăng được phân bổ lại một cách rõ ràng cho hoạt động cải tiến để củng cố quá trình tái đầu tư
- Ở nhiều tổ chức, áp lực về chi phí và tiến độ dẫn đến cắt giảm quy mô hoặc đặt mục tiêu hiệu suất cao hơn, lấy mất nguồn lực cải tiến và khiến năng lực chững lại hoặc đi xuống
-
Vòng lặp Shortcuts
- Những đường tắt như bỏ qua họp cải tiến, hoãn bảo trì phòng ngừa đã lên lịch, hay phớt lờ yêu cầu tài liệu hóa sẽ ngay lập tức làm tăng thời gian dành cho công việc
- Vì sự suy giảm năng lực không xuất hiện ngay, các đường tắt nhìn có vẻ hiệu quả và hấp dẫn trong ngắn hạn
- Một quản lý trì hoãn bảo trì phòng ngừa sẽ có được thời gian trì hoãn bằng cách tránh thời gian dừng máy đã lên kế hoạch và tiết kiệm chi phí bảo trì, nhưng về sau năng suất và thời gian hoạt động giảm xuống do thiết bị cũ đi và hao mòn
- Một kỹ sư phần mềm bỏ qua tài liệu hóa có thể hoàn thành dự án đúng hạn, nhưng sẽ phải trả giá vài tuần hoặc vài tháng sau khi sửa lỗi được phát hiện trong quá trình kiểm thử
-
Capability Trap
- Work Harder ban đầu làm tăng ngay tổng thông lượng, còn chi phí của việc giảm thời gian cải tiến chỉ bộc lộ muộn, nên tạo ra trạng thái better-before-worse
- Work Smarter làm giảm đầu ra trong ngắn hạn, nhưng theo thời gian mức tăng năng lực bù lại việc giảm nỗ lực lao động và nâng cao hiệu suất, tạo ra động lực worse-before-better
- Tương tác giữa Shortcuts và Reinvestment có thể nhốt tổ chức vào vòng xoáy suy giảm năng lực mang tên Capability Trap
2 bình luận
Ý kiến trên Hacker News
Tôi nhớ không thật rõ, nhưng có một ví dụ hay
Một tổ chức có quy trình xử lý đơn hàng quan trọng, nhưng lại ở trong tình huống không thể tin rằng mọi thông tin cần thiết sẽ luôn đến đầy đủ hoặc chính xác. Vì vậy họ đã tạo logic kiểm tra để làm sạch dữ liệu đầu vào và thay đổi cách xử lý, đồng thời lưu lại dưới dạng chỉ số xem những kiểm tra nào đã được kích hoạt trên từng đơn hàng. Khi thêm kiểm tra mới, họ cũng gắn kèm ngày tháng
Vì các chỉ số này được công khai và thỉnh thoảng được chia sẻ, nên khi ai đó hỏi “Nếu là XYZ thì sao?” có thể trả lời rằng “Chúng tôi đã xử lý rồi, và đã ngăn không cho #### đơn hàng bị chặn vì XYZ”
Điều đó cho thấy nhóm đã làm việc cẩn trọng, rằng kiểu công việc này là cần thiết để hệ thống tiếp tục vận hành tốt, và có thể dùng dữ liệu để chứng minh điều đó. Nhờ vậy, cuộc trò chuyện trong tổ chức chuyển từ “Sao lại không nghĩ ra?” sang “Giờ chúng ta nên làm gì?”, và sự công nhận đối với chất lượng mang tính phòng ngừa cũng được đẩy lên cấp trên
Hầu hết các nhóm có lẽ sẽ chỉ nhìn vào chỉ số như tỷ lệ thành công của đơn hàng rồi dừng lại, nhưng nếu lấy số lần xử lý dữ liệu xấu làm chỉ số thì có thể thoát khỏi cái bẫy những việc tốt dễ bị vô hình
Gần đây tôi đã gặp đúng chuyện như vậy ở chỗ làm
Với vai trò là tech lead/kiến trúc sư của tổ chức, tôi đã rà soát các dự án mới phát hành gần đây và tìm ra những điểm bắt buộc phải cải thiện do vấn đề nghiêm trọng về độ tin cậy/hiệu năng. Nhiều bản phát hành của một nhóm nằm ở đầu danh sách, nhưng PM, engineering manager của nhóm đó và những người ở phía trên đều phớt lờ mọi lo ngại với lý do phải ưu tiên cập nhật tính năng
Vài tháng sau, trong lúc tôi đang nghỉ phép, sự cố nổ ra, xảy ra leo thang sev 1, nhiều khách hàng nổi giận, và cả CEO/CTO cũng phải vào cuộc. Chính cái nhóm đã viết ra đoạn mã cẩu thả gây ra vấn đề và phớt lờ cảnh báo ấy đã làm việc ngày đêm để khôi phục dịch vụ, và giờ họ trở thành anh hùng. Đặc biệt, người quản lý đó còn được tiếng tốt trong công ty vì đã giao tiếp tích cực và thể hiện năng lực lãnh đạo trong lúc sự cố xảy ra
Việc sửa vấn đề do người khác tạo ra bao giờ cũng gây ấn tượng hơn. Tôi không muốn tung hô ai đó chỉ vì họ đã sửa sai lầm của chính mình, và bản thân tôi cũng không mong được khen chỉ vì đã tự sửa lỗi của mình. Ngay từ đầu tôi sẽ xin lỗi mọi người vì đã làm hỏng việc
Vấn đề trong tiêu đề khiến tôi cứ nghĩ về giá trị của bản thân
Nếu ai đó giúp giải quyết việc mà mọi người bị kẹt suốt 3 tháng chỉ trong 40 phút, giá trị của tôi sẽ rất rõ ràng với tất cả mọi người. Nhưng nếu tôi luôn làm việc cùng để không ai bị kẹt suốt 3 tháng ngay từ đầu, thì giá trị của tôi lại trở nên không rõ ràng. Tôi không biết phải xử lý nghịch lý này thế nào
Trong nhiều trường hợp, nếu bỏ thêm nỗ lực và thời gian thì phần thưởng lại tụt lại phía sau, trong khi người ta chỉ kỳ vọng bạn bỏ ra nhiều nỗ lực và thời gian hơn nữa. Giá trị và cơ hội gần với một quá trình hỗn loạn hơn là tỷ lệ với nỗ lực và thời gian
Cuối cùng, điều nên làm là cố giữ khối lượng công việc ở mức đầu óc vẫn đủ tỉnh táo để chớp lấy cơ hội khi nó xuất hiện. Những đồng nghiệp trung thực và cân bằng sẽ giúp ích, nhưng rốt cuộc đó vẫn là việc mỗi người phải tự làm
Dù sếp tôi có cố giải thích đi nữa, đến đợt sa thải tiếp theo thì cái đầu có thể rơi là đầu tôi
Họ có nói với các công ty khác rằng tôi giỏi việc này, nhưng rốt cuộc cũng không dẫn đến công việc nào. Đó là ngày đầu tiên và cũng là ngày cuối cùng tôi làm hợp đồng cho các công ty nhỏ
Nhờ vậy tinh thần của thành viên trong nhóm không bị suy sụp. Về mặt tâm lý, mỗi người đều cần được công nhận đóng góp cá nhân của mình
Những quản lý như vậy thường là người từng là individual contributor giỏi rồi mới trở thành team lead, và chính vì họ thành thạo kỹ năng đó nên họ ở vị trí tốt nhất để đánh giá những individual contributor mà họ quản lý
Phải mô tả thật sống động những thảm họa đã tránh được để mọi người có thể hình dung ra một bức tranh rõ ràng
Một biến thể khác là phân bổ quá nhiều nguồn lực để ngăn một vấn đề chỉ thực sự xảy ra đúng một lần, trong khi lại ít chú ý hơn đến những vấn đề nghiêm trọng hơn nhưng vẫn chưa xảy ra
Đây là vấn đề quản lý. Vì dù có hợp lý đến đâu khi làm những việc quan trọng hơn, chẳng ai muốn là người phải chịu trách nhiệm nếu cùng một sự cố lặp lại
Kiểu như một vết thương nhỏ bị thay thế bằng một tổ chức cứng nhắc và kém linh hoạt. Chỉ vì điều gì đó đã xảy ra một lần không có nghĩa là nhất thiết phải thay đổi để nó không bao giờ tái diễn nữa, và kiểu phản ứng thái quá đó có thể trở thành gánh nặng lớn trong tương lai
Chấp nhận tổn thất đó và thừa nhận rằng nó có thể xảy ra lần nữa đôi khi còn tốt hơn là phòng ngừa quá mức chỉ để chắc chắn ngăn chặn nó
Một chính sách không phân bổ nguồn lực phòng ngừa cho đến khi điều gì đó thực sự xảy ra, ở một mức độ nào đó, là hợp lý
Tôi đã có một năm khốn khổ chỉ để cố thuyết phục rằng họ đang phản ứng thái quá với sự cố và rằng vấn đề thực sự xảy ra có một cách giải quyết rất đơn giản. Nhưng nếu quản lý cấp cao thấy ghế của mình có nguy cơ vì tái diễn sự cố, họ sẽ chỉ đạo cả bộ phận rà soát và sửa mã cho các vấn đề tương tự. Và kỳ lạ là họ lại lắng nghe những tiếng nói lớn nhất đưa ra các giải pháp bị thiết kế quá mức một cách khủng khiếp
Có lần khác, hệ thống giao dịch bị sự cố vì hết hạn mật khẩu. Lượng công sức đổ vào một giải pháp thủ công buồn cười đến mức phi lý, chỉ để đảm bảo chuyện này “không bao giờ xảy ra nữa”, thật sự khó tin. Cuối cùng sau hơn một năm làm việc, tất cả bị vứt bỏ và thay bằng một giải pháp tập trung đơn giản hơn nhiều, vốn lẽ ra phải được làm ngay từ đầu
Điều này làm tôi nhớ đến chỗ làm cũ. Mỗi lần yêu cầu phản hồi, họ đều lặp lại rằng “ở đây, nếu không có PIR(post-incident response) thì không gì được ưu tiên cả”
Về sau, mỗi khi có ticket liên quan đến PIR được tạo, tôi sẽ đánh dấu nó là trùng với một ticket thực tế vốn đã có thể ngăn sự cố đó nhưng đang chết dần trong backlog. Việc hoàn toàn không có ảnh hưởng gì trong chuyện ngăn các vấn đề có thể dự đoán trước ở phạm vi mình phụ trách đã làm tinh thần cả đội sa sút nghiêm trọng
Hầu hết thành viên trong nhóm cuối cùng ngừng luôn việc đề xuất cải tiến. Vì tầng quản lý không cho phép chúng tôi tự kéo ticket vào làm
Đây là mô tả rất sát về việc Scrum kiểu doanh nghiệp đang biến thành địa ngục như thế nào
Agile vốn theo đúng nghĩa là làm việc nhanh và cải thiện năng lực theo các chu kỳ ngắn. Nhưng Scrum lại trở thành một phiên bản còn tệ hơn cả quy trình lập kế hoạch mà nó định thay thế
Cách Scrum chia nhỏ công việc thành các vấn đề ngay trước mắt lại càng làm vòng lặp này tệ hơn. Về dài hạn, nó trở thành một hệ thống ticket nơi đám cháy bị đẩy lên trên còn nợ kỹ thuật bị đẩy xuống dưới
Chưa kể nó còn nhả ra các con số hiệu suất dễ theo dõi nhưng vô nghĩa, rất thuận tiện cho consultant và executive chơi trò tối ưu hóa
Tôi nói thế cũng được. Trong số bạn thân của tôi cũng có scrum master
Tôi hiểu vì sao. Trong vô số việc có thể làm, phải có ai đó quyết định nên làm việc nào. Tính năng này có kiếm ra tiền không? Còn những việc không phải tính năng nhưng giúp giảm chi phí tài nguyên thì sao? Còn nợ kỹ thuật làm chậm tốc độ giao tính năng thì sao?
Tôi không phải quản lý cấp cao, nhưng cuối cùng ai đó ở phía trên vẫn có trách nhiệm bảo đảm công ty sống sót, kiếm ra tiền và trả lương cho chúng tôi. Họ cũng phải ra quyết định với lượng thông tin ít ỏi như chúng tôi có. Vì thế họ cần một cách để so sánh “cái này tốn bao nhiêu và có giá trị bao nhiêu” với “cái kia tốn bao nhiêu và có giá trị bao nhiêu”
Họ cần một cách để ước lượng điều đó, và khi ngành công nghệ quảng bá Agile như công cụ cho việc ấy thì họ mắc vào đó. Lỗi của ai đây?
Từ đó kéo theo việc ước lượng thường xuyên, theo dõi lịch trình và các nghi thức. Có người không tin những thứ đó nhất thiết phải đi kèm một cách tự nhiên, và tôi cũng đồng ý. Nhưng dù sao thì những nghi thức đó đã trở thành một phần của giáo phái
Chúng tôi đã bỏ Scrum, đồng thời bỏ luôn các buổi refinement, ước lượng story và story point. Giờ đây, mỗi tháng một lần chúng tôi mới gặp PM một cách chính thức để xem tình hình hiện tại ở cấp độ nhóm chỉ bằng ước lượng cỡ áo thun. Ngoài ra, chỉ cập nhật khi PM yêu cầu hoặc khi chúng tôi cảm thấy cần. Nhờ vậy quyền chủ động nằm ở phía chúng tôi, nhưng cũng phải có trách nhiệm và báo kịp thời nếu thấy tình hình có vẻ bất ổn. Vẫn phải “ước lượng” thôi. Suy cho cùng quản lý cấp cao vẫn phải ra quyết định. Nhưng nhìn chung nó khá nhẹ nhàng, và thật sự rất giải phóng
Mọi người đều cam kết với quy trình, và đội Scrum dành 20% công sức để ưu tiên xử lý nợ. Velocity của từng người cũng khá chính xác nên còn có thể cộng thêm 20% cho các việc theo mối quan tâm cá nhân, còn mức ưu tiên của stakeholder lấp đầy 60% còn lại
Ở vài sprint, nếu cần dồn lực để hoàn thành epic hay mục tiêu của đội, hoặc phải đổi ưu tiên vì tình huống khẩn cấp/lỗi, thì chúng tôi sẽ đổi hướng
Cứ thêm thật nhiều quy trình chỉ vì muốn thêm thì không tạo ra giá trị gì
Điều này làm tôi nhớ đến bức tranh biếm họa từng dán trong văn phòng: https://naksecurity.medium.com/the-detriments-of-hero-cultur...
Vì thế trong nhiều văn hóa doanh nghiệp, nếu vấn đề không thuộc phạm vi phụ trách trực tiếp của mình, thì dù biết cách sửa, việc không chủ động ngăn chặn lại có lợi hơn về mặt tưởng thưởng. Cứ để vấn đề lộ ra, để nó trở thành tình huống khẩn cấp của ai đó rồi sửa là được
Tất nhiên, về lâu dài thì một tổ chức như vậy không thể nào hoạt động tốt, nên cũng phải lên kế hoạch rời đi
Nhớ đến bài “Không ai được ghi nhận vì đã sửa một vấn đề chưa từng xảy ra” (2001) [pdf]
Mỗi khi thấy YouTuber hay mấy bài câu view trên mạng xã hội nói rằng lỗi Y2K chẳng có gì to tát, tôi lại nghĩ đến điều này
Lý do nó không thành chuyện lớn là vì vô số người kỳ cựu như tôi đã thức trắng nhiều đêm từ trước đó nhiều tháng để mọi thứ vận hành được
Tôi vẫn còn nhớ cảm giác căng thẳng lúc đếm ngược đến nửa đêm theo UTC. Rồi lại căng thẳng lần nữa khi đếm ngược theo giờ miền Đông, rồi thêm một lần nữa theo giờ địa phương. Chỉ đến khi giờ Thái Bình Dương bước sang năm 2000 thì tôi mới thật sự thở phào
Chắc đến năm 2038 thì sẽ biết
Nếu cùng thời kỳ đó thì Y2K cũng là một ví dụ rất hay. Hầu như không có chuyện gì nổi bật xảy ra, nhưng nếu mọi người cứ mặc kệ thì rất có thể đã có rất nhiều chuyện xảy ra
Không phải vì lương của tôi phụ thuộc vào việc đó. Dĩ nhiên tôi có rất nhiều cơ hội làm việc khác. Đây thực sự là một vấn đề có thể làm tê liệt ngành năng lượng và ảnh hưởng đến các công ty lớn cùng vô số tổ chức phụ thuộc vào họ. Từ trải nghiệm này, tôi cho rằng nhiều ngành khác như tài chính hay khai thác tài nguyên cũng sẽ chịu cú sốc tương tự, cả trực tiếp lẫn gián tiếp
Vì vậy đây là một ví dụ rất điển hình. Đến giờ tôi vẫn gặp những người nhớ Y2K như một cơn hoảng loạn vô nghĩa. Không phải vậy. Việc nó không trở thành vấn đề với bạn là vì rất nhiều người đã nỗ lực ngăn chặn
Những vấn đề đó không quá phức tạp, nhưng chúng lan rất rộng, rất quan trọng và đòi hỏi khối lượng công việc khổng lồ. Nó không giống một bài toán kỹ thuật tầm cỡ hạ cánh lên Mặt Trăng để đem ra khoe như kỳ tích của nhân loại, mà giống việc đi sửa vô số lỗi O-ring ngớ ngẩn kiểu Challenger trước khi mọi thứ phát nổ hơn
Vì vậy đến đúng ngày đó chỉ còn lại một ít lỗi tồn đọng nhỏ nhặt. Báo chí có vài câu đùa, nhưng nhìn chung công chúng cứ thế cho qua
Tôi làm trong lĩnh vực khí hậu và đã từng, hoặc vẫn đang, hy vọng điều tương tự sẽ xảy ra. Nhưng có vẻ sớm muộn gì nó cũng sẽ buộc mọi người phải chú ý
Nếu chuẩn bị tốt thì sẽ chẳng có gì thú vị xảy ra, cuộc sống tiếp diễn, và người ta chỉ nhớ là mình mở laptop lên rồi bấm vài nút
Nếu không chuẩn bị thì lưới điện Texas đóng băng, người ta chết, mất tiền tiết kiệm, và rồi thành ra “không ai có thể tưởng tượng nổi mọi thứ lại tệ đến thế”
Thú thật là tôi cũng từng tham gia công việc đó. Điều buồn cười là sau này tôi lại được gọi trở về khách hàng cũ để sửa một vấn đề theo đúng nghĩa đen do công việc trước đây của chính tôi tạo ra. Vừa nhìn thấy vấn đề là tôi sửa xong trong 20 phút. Rồi sau đó là kiểu “nhân tiện anh xem thêm cái này được không…” và chuyện đó kéo dài gần 2 năm, cho đến khi bộ phận đó bị đóng cửa và chuyển sang New York
Ít nhất thì nó vẫn được tính thành giờ có thể xuất hóa đơn
Vì bài này được viết ngay sau thời điểm đó nên lúc đầu tôi tưởng là đang nói về Y2K
Trong vài năm cuối thập niên 1990, tôi làm dự án Y2K và giúp hạ tầng trọng yếu của Anh không ngừng hoạt động vào thời khắc nửa đêm. Ví dụ, nếu không có nỗ lực của chúng tôi thì xứ Wales đã không có nước hoặc khí đốt
Nhưng sau đó tôi lại nghe những câu như “chẳng có gì xảy ra cả, vậy rõ ràng vốn đâu có vấn đề gì, sao lại tiêu nhiều tiền cho Y2K thế?” hoặc “Y2K là trò lừa do ngành IT dựng lên”
Chúng tôi đã thắng. Chúng tôi đã ngăn chặn thành công lỗi Y2K, đó là một công việc gian nan, và cho đến tận nửa đêm chúng tôi cũng không chắc mình đã xử lý hết chưa. Thế nhưng thay vì được chúc mừng, một số người lại xem đó là bằng chứng rằng chúng tôi đã chặt chém họ. Con người thật kỳ lạ
Điều bực bội là, với biến đổi khí hậu thì kịch bản tốt nhất cũng giống hệt như vậy. Nếu chúng ta thực sự thành công trong việc tránh được ngày tận thế, thì tất cả những kẻ “phủ nhận biến đổi khí hậu” sẽ cảm thấy rằng họ đã đúng
Ý kiến trên Hacker News
Nhìn tiêu đề làm tôi nhớ tới một điển tích Trung Hoa cổ khá thú vị. Cũng hơi mỉa mai khi Toyota gần đây lại vướng vào bê bối: https://www.bbc.com/news/articles/c1wwj1p2wdyo
Khi Văn Vương nước Ngụy hỏi Biển Thước: “Nếu cả ba anh em đều là thầy thuốc, ai là người giỏi nhất?”, Biển Thước đáp: “Anh cả là người giỏi nhất, anh hai đứng sau, còn tôi là kém nhất.”
Anh cả nhận ra bệnh khi nó còn chưa thành hình và âm thầm loại bỏ nó, nên chỉ nổi tiếng trong nhà; anh hai chữa trị khi bệnh vừa mới lộ ra, nên danh tiếng không vượt ra khỏi ngõ xóm; còn chính Biển Thước thì chích vào mạch máu, dùng thuốc mạnh, rạch da thịt, nên nhờ những hành động nhìn thấy được mà tiếng tăm lan truyền giữa các chư hầu
Tôi từng làm ở một công ty nơi “bộ phận vất vả” được khen ngợi và tăng ngân sách vào quý sau vì đã anh hùng xử lý đống vấn đề do chính họ tạo ra
Trong khi đó, bộ phận của tôi vốn vận hành êm đềm lại còn chật vật chỉ để giữ đèn sáng
Sự đứt gãy giữa ban quản lý không có nền tảng kỹ thuật chỉ hiểu ở mức nhấp đúp chuột và đội ngũ kỹ sư thực sự nâng đỡ công ty là một vấn đề nghiêm trọng trong ngành này. Tôi không nghĩ ra giải pháp nào tốt ngoài việc lãnh đạo phải xuất thân từ kỹ thuật
Có những vấn đề cần được gửi tín hiệu đau lên cấp trên trước khi sửa, để lãnh đạo có cơ hội học hỏi
Tuy vậy, thiết kế incentive là việc khó, và cấu trúc ở cấp điều hành cao nhất không được khiến cấp dưới hay các phòng ban không thể bộc lộ đau đớn và vấn đề. Người che giấu tín hiệu với ý tốt cũng rất phổ biến, nên trong tổ chức lớn có lẽ cần được huấn luyện rằng để một số vấn đề bộc lộ ra và đừng phản ứng quá mức lại hiệu quả hơn
Khi mọi người đều thiết kế dựa trên điều kiện bình thường và giả định vận hành hoàn hảo, cần có ai đó tìm cách làm hỏng thiết kế, dịch vụ, hạ tầng và ứng dụng
Một đồng nghiệp ở bộ phận IT lẽ ra đã có thể nhận hơn 2.000 euro một chút bằng cách thay chứng chỉ thương mại bằng Let’s Encrypt và bỏ yêu cầu EV, nhưng cuối cùng lại không được nhận. Lý do là những việc đó “vốn là công việc của anh ấy”
Trong khi đó, các đội thực sự làm ra dịch vụ chạy được thì ngân sách bị đóng băng, thậm chí còn bị cắt người
Khi đội khác gặp sự cố, đội chúng tôi có thể chỉ ra vì sao mình không gặp cùng vấn đề bằng danh sách các việc đã hoàn thành. Công việc đã được làm rồi, chỉ là được làm vào thời điểm tốt hơn để tránh downtime
Chuyện kiểu này xảy ra rất nhiều. Điều tôi thích là các giải pháp thanh nhã, nhìn lại sau này, thường có vẻ đơn giản
Bạn vật lộn rất lâu rồi tìm ra một lời giải thông minh, giải thích xong thì người ta đáp: “Ừ, hiển nhiên mà”
Trong khi đó, người ngồi cạnh đã làm vấn đề phức tạp quá mức lại được khen vì tạo ra thứ khó đến vậy
Các công ty lớn có thể vẫn đang tụt lại ở chỗ còn ngưỡng mộ sự phức tạp, nhưng khi bạn là người phải nhận đầu ra do AI tạo ra, trực tiếp hay gián tiếp, thì sự phức tạp không còn ấn tượng như trước nữa
Những ca cứu nguy kỳ diệu nhất lại thường đi kèm câu chuyện kiểu “đứa cháu tôi xử lý lỗi nhỏ này ngay lập tức”, như thể nhấn mạnh rằng tôi đã không làm được điều đó
Người phụ trách đã khuyên nên dùng cách phức tạp, vì như vậy mới được xuất bản. Không phải vì nó thông minh hơn, mà vì lời giải phải nghe phức tạp thì mới được công nhận
Điều này khớp hoàn toàn với thực tế là người ta ca ngợi quá trình phức tạp hơn là lời giải đẹp, và có lẽ quan liêu cũng sinh ra theo cách như vậy
Đoạn code đó bị quên mất sau 15 phút kể từ khi phát hành và không ai đọc lại nữa, nhưng nó vẫn được dùng suốt nhiều năm. Vì vậy tôi nghĩ AI có thể lấy đi việc làm nhanh hơn nhiều so với điều mọi người tưởng
Những thứ chúng ta dành nhiều thời gian nhất như code sạch, tách biệt mối quan tâm, khả năng bảo trì, thực tế lại không được đánh giá. Chỉ cần “đủ ổn” là quản lý đã hài lòng, còn khi có vấn đề thì AI có thể vá tiếp, kể cả theo kiểu spaghetti
Tôi từng gặp vấn đề tương tự ở chỗ làm cũ. Tôi đã dành gần như toàn bộ thời gian cho các công việc hành chính hậu trường như sắp lịch họp và đảm bảo mọi người có đủ thông tin cần thiết trước cuộc họp
Nhưng đến kỳ đánh giá hiệu suất, điều duy nhất tôi được nghe là vì tôi quá bận giữ cho mọi thứ không sụp đổ nên không hoàn thành được nhiều story point
Thế là tôi dừng toàn bộ việc hành chính và chỉ tập trung hoàn thành story point, rồi 1–2 tuần sau quản lý hỏi cả nhóm: “Tại sao mọi cuộc họp đều đang tan nát vậy? Vào họp mà chẳng ai biết chuyện gì đang diễn ra cả”
Sau khi làm cực nhiều việc về mạng, phần cứng và IT trong gần 2 năm để chuẩn bị cho Y2K, tôi bắt đầu chuyển sang marketing. Rốt cuộc, gần như công ty nào cũng cho rằng vì “chẳng có chuyện gì xảy ra” nên toàn bộ thời gian và tiền bạc đó là lãng phí
Thậm chí có một công ty còn đòi hoàn tiền toàn bộ, và khi tôi nói sẽ hoàn nếu có thể hoàn tác những gì tôi đã làm, họ đồng ý. Ngày hôm sau, toàn bộ hệ thống của công ty đó sụp đổ
Ngay cả công ty của bố tôi cũng nhất quyết không chịu trả phí hỗ trợ mạng của tôi, nên rất khó nhận làm. Sau khi hai người khác không giải quyết được vấn đề, tôi sửa xong trong 15 phút, và rồi họ lại càng không muốn trả tiền hơn vì cho rằng chỉ mất có 15 phút
Năng lực giữ cho mọi thứ không hỏng không được công nhận, chỉ có việc sửa sau khi đã hỏng mới được công nhận. Marketing trả lương tốt hơn, và mỗi ngày tôi đều có thể dùng những con số thực tế để biện minh cho mức lương của mình. Tôi thích nó ít hơn rất nhiều, nhưng lại được tôn trọng hơn bất kỳ công việc IT nào tôi từng làm
Những thứ được công nhận lại là mấy việc đơn giản như sửa máy in, sửa sự cố máy tính A/B/C, hay làm một ứng dụng Sudoku Android không quảng cáo cho bạn bè
Còn công việc cốt lõi mà tôi làm để lấy tiền thì lại không được công nhận. Có vẻ trong nhiều ngành, khi tiền bạc đã dính vào thì việc thực hiện đúng vai trò theo hợp đồng bị xem là điều hiển nhiên, nên sự biết ơn cũng giảm đi
Những người không biết về công nghệ thì nghĩ rằng lập trình viên làm việc tại nhà và mỗi ngày chỉ làm 30 phút, còn AI lại càng làm hình ảnh đó tệ hơn
Ian Rush nói rất đúng: “Tiền đạo là vị trí tuyệt nhất. Bỏ lỡ năm lần nhưng ghi bàn thắng quyết định thì thành anh hùng. Thủ môn có thể cứu thua xuất sắc cả trận, nhưng chỉ cần thủng lưới một bàn là thành tội đồ”
Mọi nơi tôi từng làm việc đều thưởng cho người chữa cháy hơn là người khiến đám cháy không bao giờ xảy ra. Tệ hơn nữa là ai cũng thấy cách tính đó là lộ liễu, trừ những người quyết định cơ chế khuyến khích
Nhưng cũng có mặt ngược lại. Có những người dành toàn bộ thời gian để lo về những thứ sẽ chẳng bao giờ xảy ra, nên đây không phải chuyện chỉ cần thưởng cho thái độ phòng thủ là xong
Ở nơi làm việc, thăng chức thường diễn ra theo kiểu đó. Làm hỏng thứ gì đó, bị escalated nên trở nên nổi bật, rồi email được gửi lên lãnh đạo. Sau đó chỉ cần “sửa” nó là mọi người đều cảm ơn và khen làm tốt
Một phiên bản khác là cố tình trì hoãn rất lâu việc vốn phải làm để tăng độ hiện diện. Lãnh đạo không nhìn thấy công việc của những người âm thầm chịu trách nhiệm và hoàn tất mọi thứ trước khi chúng thành vấn đề lớn
Thay vào đó, họ nhớ tên người đã làm hỏng thứ gì đó rồi “cứu” cả ngày hôm đó
Trong lúc đó họ nịnh cấp trên và nói kiểu “tốt hơn là đừng giao cho doublerabbit”, “có vẻ không phải người biết chơi cùng đội”. Dù toàn bộ đó đều là hạ tầng của tôi thì họ vẫn làm vậy
Đó là lý do người ta hỏi vì sao tôi ghét loài người
Tôi đã học điều này từ hồi lớp 1 tiểu học rồi. Những đứa trẻ ngồi yên trong giờ học và làm bài tập về nhà không chiếm nhiều thời gian và công sức của giáo viên
Chính những đứa trẻ cá biệt không chịu theo quy tắc và cần được khen liên tục mỗi khi bỏ ra dù chỉ một chút nỗ lực học hành mới chiếm lấy sự chú ý của giáo viên
Quãng thời gian làm IT của tôi cứ dao động giữa hai thái cực
“Mọi thứ xung quanh đều chạy tốt mà. Sao chúng ta phải trả tiền cho IT?”
“Mọi thứ hỏng hết rồi. Sao chúng ta phải trả tiền cho IT?”
Cá nhân tôi thì vẫn hướng tới vế đầu hơn vế sau. Tôi thường nói: “Nếu tôi làm việc đúng cách, mọi người thậm chí còn không biết tôi có ở đây.” Nhưng chính vì vậy mà tôi đã bị sa thải
Xét về mặt nghiệp báo thì tôi vẫn giữ liên lạc với người ở công ty cũ, và giờ ở đó là một mớ hỗn độn hoàn toàn. Điều đó ít nhiều cũng an ủi được tôi
Một khi bạn biết đến bẫy năng lực, bạn sẽ thấy nó ở khắp mọi nơi
Sterman, Repenning và các cộng sự khác đã viết thêm nhiều bài sau bài này, tất cả đều thú vị, nhưng hầu như bài nào cũng khiến người ta buồn
Đặc biệt là MIT Sloan, nơi động lực học hệ thống lần đầu trở thành một ngành học chính thức, lại ở ngay gần Harvard Business School, nơi động lực học hệ thống lần đầu bị phớt lờ