Thất bại của việc hàng hóa hóa công việc kỹ thuật
(ludic.mataroa.blog)- Kỳ vọng của giới quản lý và vendor vào việc chuẩn hóa công việc kỹ thuật như một nhà máy để biến nó thành đầu ra có thể tái tạo là rất lớn, nhưng nhiều nơi làm việc vẫn chưa thể được hàng hóa hóa một cách ổn định theo cách đó
- Kiểu vận hành của McDonald's gần với một kỷ luật nhằm khiến các địa điểm và nhân sự khác nhau tạo ra cùng một kết quả hơn là bản thân chất lượng, và nhiều sách quản trị cũng nhìn vận hành IT theo dòng sản xuất như vậy
- Việc bán phần mềm doanh nghiệp gần với một lời hứa rằng có thể thay thế công việc SQL, dữ liệu và phát triển bằng kéo-thả cùng giao diện nhất quán để khiến nhân lực trở nên có thể thay thế cho nhau
- Trong các tổ chức thực tế, giấy phép phần mềm tệ và các lớp trừu tượng hóa sai lầm không giải quyết được vấn đề kỹ thuật, và cuối cùng những kỹ sư xuất sắc thường vẫn phải trực tiếp sửa các mô hình dữ liệu tệ và các quyết định kỹ thuật sai
- Những công việc cần đến sáng tạo, gu thẩm mỹ, chuyên môn và sự kết nối giữa con người không thể bị quy về hoàn toàn thành bảng Jira hay điểm Agile, và ngay cả trong hạ tầng sản xuất quy mô lớn, từng cá nhân vẫn là người khiến hệ thống vận hành
Độ khó của tiêu chuẩn hóa mà McDonald's cho thấy
- Người quản lý đầu tiên của tác giả, một kỹ sư dữ liệu xuất sắc, là người rất đam mê nấu ăn và nhiều lần đánh giá rất cao độ phức tạp trong vận hành của McDonald's
- Giá trị của McDonald's không nằm ở chất lượng đầu ra tự thân, mà ở sự tối ưu hóa và kỷ luật để những nhân viên có trình độ đào tạo và xuất thân vùng miền khác nhau có thể làm ra cùng một chiếc burger
- Việc khiến lực lượng lao động chưa có tay nghề ở nhiều địa điểm khác nhau tạo ra kết quả nhất quán không hề đơn giản, và ví dụ này dẫn tới bàn luận về việc hàng hóa hóa công việc kỹ thuật
Sách quản trị đối xử với IT như một nhà máy
- The Phoenix Project đặt vận hành IT như một bài toán tương tự công việc của nhà máy sản xuất, lấy việc quản lý luồng công việc và giao tiếp trong tổ chức làm trung tâm
- Những cuốn sách mang tinh thần tương tự gồm The Unicorn Project, Investments Unlimited, The Goal
- The Goal là câu chuyện về việc thay đổi vận hành của một nhà máy thực sự, và được xem là tác phẩm đã truyền cảm hứng cho các cuốn sách còn lại
- High Output Management cũng dùng cách công việc vận hành trong nhà hàng làm ví dụ, giải thích luồng công việc theo kiểu nếu luộc trứng sai thời điểm thì khi đến tay khách, bánh mì nướng sẽ nguội
- Trong lối tư duy này, các chủ đề như lợi thế kinh tế theo quy mô, thông lượng và luồng công việc lặp đi lặp lại
Cốt lõi của màn chào hàng từ vendor là khả năng thay thế, không phải công nghệ
- Nhiều màn giới thiệu sản phẩm tại một hội nghị vendor tập trung vào lời hứa có thể cung cấp một cách lặp lại đầu ra công việc đủ tốt hơn là vào chi tiết kỹ thuật
- Một sản phẩm cụ thể quảng bá rằng có thể thiết lập phụ thuộc bằng trình biên tập kéo-thả mà không cần tự viết SQL
- Trên thực tế, vì ứng dụng kết nối với Postgres nên SQL không hề biến mất; thay vào đó, một lớp trừu tượng có giấy phép sẽ viết SQL thay người dùng
- Với ban lãnh đạo, kiểu chào hàng này có thể được nghe như một thông điệp rằng có thể thay “SQL chậm chạp và đầy vấn đề” bằng một giao diện nhất quán cùng các chuyên gia công cụ trên thị trường, từ đó làm mượt việc chuyển giao dữ liệu trong tổ chức
- Cách Agile được triển khai trong các tổ chức rối loạn chức năng ở mức trung bình cũng bộc lộ vấn đề tương tự
- Đó là cách đếm kỹ sư như máy móc, đầu ra như linh kiện, story point như đơn vị sản xuất rồi kiểm tra tỷ lệ hoàn thành mục tiêu tuần sau
Vì sao nhiều công việc kỹ thuật vẫn chưa được hàng hóa hóa
- McDonald's thường có thể cung cấp khoai tây chiên với chất lượng ổn định trong vòng 5 phút, nhưng nhiều tổ chức kỹ thuật lại mua các giấy phép phần mềm tệ trong khi vẫn không thể triển khai thứ gì có giá trị
- Con đường giải quyết vấn đề kỹ thuật và các mô hình dữ liệu tệ bằng tiền gần với việc tuyển được những kỹ sư xuất sắc chỉ tập trung vào giải quyết vấn đề hơn
- Có nhiều lĩnh vực trông có vẻ có thể hàng hóa hóa, nhưng trên thực tế thường là sự kết hợp giữa các công ty bán sản phẩm không hoạt động và những người ra quyết định thiếu hiểu biết đi mua chúng
- Một số người ra quyết định cũng có thể chọn cách dùng hỗ trợ qua điện thoại ở khu vực lương thấp với danh nghĩa đáp ứng tuân thủ pháp lý, mà không quan tâm tới những khách hàng muốn hủy dịch vụ
- Bài viết cũng chia sẻ kinh nghiệm rằng khi cần liên hệ nhân viên hỗ trợ, trước tiên nên gọi vào đường dây bán hàng để thử được nối nhanh tới người phụ trách tại địa phương có thẩm quyền
Trong công việc kỹ thuật mang tính sáng tạo, yếu tố con người vẫn còn đó
- Hammock Driven Development của Rich Hickey nói về một quy trình làm việc kiểu đưa việc nghiên cứu vào tiềm thức, thiền, ngủ và rồi tìm ra lời giải thiết kế
- Lập trình viên thường trải nghiệm hiện tượng nảy ra câu trả lời khi tách khỏi vấn đề, và điều này khác với kiểu công việc chỉ nhằm sản xuất widget nhanh hơn
- Xã hội có rất nhiều loại công việc sản xuất nhanh hơn, nhưng nhiều đầu ra có giá trị lại xuất hiện ở điểm gặp nhau giữa sự sáng tạo khó định nghĩa và thực tế của sản xuất
- Ngay cả trong các ví dụ như sách, đồ ăn hay vận hành nhà hàng, người ta có thể tinh chỉnh sản xuất hàng loạt hoặc hệ thống phân phối, nhưng để tạo ra kết quả đẹp vẫn cần gu thẩm mỹ và sự chăm chút
- Dù có cố rút gọn việc phát triển tính năng thành bảng Jira và những câu chuyện Agile, nếu không gắn với con người thì rất khó tạo ra kết quả có giá trị
- Như trường hợp một người quen thiết kế chip cho iPhone, dù có hạ tầng kiểm thử và sản xuất hàng loạt, từng cá nhân vẫn giữ vai trò quan trọng đến mức nếu một người cụ thể bị ốm thì bản phát hành tiếp theo có thể bị trì hoãn
- Dù xã hội vận hành trên thực tế hàng hóa hóa, chỉ riêng sự hàng hóa hóa thuần túy mà bỏ qua hiểu biết về một nghề thủ công cụ thể cũng như sự phức tạp, nhu cầu và tính dễ tổn thương của con người thì không thể dùng để vận hành công việc kỹ thuật
1 bình luận
Các ý kiến trên Hacker News
Có vẻ tác giả đã bỏ sót rằng một phần đáng kể những thứ từng được gọi là công việc kỹ thuật nay đã được hàng hóa hóa thành sản phẩm phổ dụng
Trước đây, mail merge thực sự là in ra hàng loạt nhãn địa chỉ rồi dán thủ công lên thư và phong bì; khoảng Word 2.0 đã giải quyết vấn đề đó vào thập niên 1990, và MailChimp đã thương mại hóa nó trong thế kỷ 21
Kế toán kép từng là công việc kỹ thuật do người được đào tạo chuyên sâu thực hiện, nhưng giờ chủ cửa hàng chỉ cần quét mã vạch và khách hàng thanh toán bằng cách chạm thẻ/thiết bị
Vẫn chưa có giao diện kéo-thả nào dùng được cho những thứ phức tạp hơn Scratch, nhưng phần khó không phải là công việc kỹ thuật nối các thư viện lại với nhau mà là thu thập yêu cầu
Việc đưa vào thư viện mã hóa chất lượng cao, nhúng bản đồ tương tác vào website, hay chỉnh sửa website theo kiểu WYSIWYG đã dễ hơn bao giờ hết
Tác giả đúng ở chỗ không thể đặt một thanh niên 18 tuổi đang chán trước IDE rồi bảo tạo ERP, nhưng rất nhiều việc lặt vặt trong IT giờ rõ ràng đã trở thành sản phẩm hàng hóa
Tôi cho rằng việc lặt vặt trong ngành công nghệ đang tăng chứ không giảm: hiện có lượng việc lặt vặt là X, công nghệ mới Z xuất hiện và giảm X xuống còn 0,1X, nhưng đồng thời Z mở ra những cách làm việc mới và kéo theo các việc lặt vặt khác như sản phẩm phụ. Khi đó lượng việc lặt vặt hiện tại trở thành Y, và Y xấp xỉ X
Nếu tiến bộ công nghệ dừng lại vào thập niên 2000, những việc lặt vặt bắt nguồn từ thập niên 90 đến nay gần như đã về 0, nhưng công nghệ mới mang đến cả tự động hóa lẫn việc lặt vặt
Ví dụ gần đây là các công cụ AI. Có các công cụ tạo âm thanh, hình ảnh, video, văn bản, nhưng để tạo ra sản phẩm hay trải nghiệm khác biệt thì cần công việc lặt vặt là kết hợp các công cụ như ChatGPT, Stable Diffusion
Càng hàng hóa hóa thêm, vấn đề càng leo lên tầng trừu tượng cao hơn, và các kỹ sư chuyên môn được tuyển cũng dịch chuyển lên phía trên của stack
Trong các sản phẩm startup được SaaS hóa gần đây, có vẻ tỷ lệ sản phẩm chưa thực sự làm được việc người ta muốn vẫn khá cao. Kiểu thu tiền để khách dùng dịch vụ, rồi thu thập các use case của khách làm mục tiêu triển khai và hàng hóa hóa cho khách khác, khiến lead time dài hơn và tài sản trí tuệ cũng bị rò rỉ
Template hóa SQL là thứ ban lãnh đạo luôn hiểu sai. SQL đã tồn tại lâu đáng kinh ngạc trong ngành và thực ra làm khá tốt. 99% các wrapper hay DSL đặt lên trên nó khiến mọi thứ tệ hơn nhiều, và hễ có việc chỉ hơi không tầm thường thì cuối cùng vẫn phải đi xuống SQL. Thay vì tuyển chuyên gia SQL, bạn lại rơi vào tình huống phải đào tạo chuyên gia về một wrapper DSL SQL kiểu SaaS X thậm chí không hề tồn tại
Vấn đề gốc rễ có thể nằm ở chỗ các sản phẩm kiểu này được thiết kế để trông như đồ gia dụng “mua về cắm vào là giải quyết vấn đề” trong mắt người mua không làm việc trong lĩnh vực đó
Nhiều sản phẩm thực ra không giải quyết được vấn đề, chỉ trông như có giải quyết vì người khác cũng mua. Và bạn phải nói dối rằng việc triển khai đã thành công thì mới được thăng chức. Những thứ như mail merge thật sự là vấn đề đã được giải quyết như ấm đun nước rồi, và các vấn đề như vậy có thể tự thử và giải quyết
Vấn đề lớn hơn là chủ lao động của tôi đã mua Workday vì tin rằng nó giống như một cái ấm đun nước, nhưng không thể sửa được sự thật rằng cấu trúc tổ chức của chúng tôi quá kinh khủng đến mức bản thân việc mô hình hóa cũng không làm nổi
Năm nay lần đầu tiên tôi nhận ra rằng trong doanh nghiệp lớn, cấu trúc tổ chức đủ tệ cũng là một dạng nợ kỹ thuật. Bạn phải làm đủ chuyện kỳ quặc để tìm xem ai làm việc dưới quyền ai, người dùng này được xem gì trong cơ sở dữ liệu này
So với năm 1994 hay 2004, hiện nay việc vận hành doanh nghiệp, tạo website, lên kế hoạch du lịch, thanh toán hóa đơn đã đơn giản hơn bao nhiêu?
Đôi khi có cảm giác các thế hệ trước sống với nhịp độ chậm hơn và vì thế có cuộc sống trọn vẹn hơn. Bây giờ thời gian trôi quá nhanh và mức căng thẳng cũng cao
Gần đây ở ngân hàng, tôi thấy ít nhất ba người trên 60 tuổi loay hoay không xử lý được những việc đơn giản và phải nhờ nhân viên giúp. Đáng lẽ đó là việc có thể làm dễ dàng bằng ngân hàng trực tuyến, nhưng vì tình huống ngoại lệ nên hệ thống không hỗ trợ; rốt cuộc họ phải đặt lịch hẹn, và lịch sớm nhất là 3–4 tháng sau
Một trong số họ cần rút tiền từ tài khoản bị chặn để mua củi sưởi nhà, nhưng nhân viên ngân hàng chỉ bảo đợi 3 tháng
Hai năm trước, bố tôi không tìm được cách gọi một cuộc điện thoại đơn giản từ Sicily về nhà. Nếu là thập niên 1970, chỉ cần vào quán bar gần đó và bỏ vài đồng xu là xong
Trước đây, người bình thường có thể tự sửa những thứ như đèn, ô tô, hệ thống sưởi, hay loại cửa không phải cửa tự động, nhưng giờ phải gọi chuyên gia
Nỗ lực hàng hóa hóa hoàn toàn công việc kỹ thuật là một ý tưởng tồi, và hy vọng sau này nó vẫn sẽ thất bại
Tuy vậy, dù tôi đã đọc The Phoenix Project hai lần và ghét phần lớn Scrum, tôi không cho rằng cuốn sách đó chủ trương điều như vậy
Điều cốt lõi tôi rút ra là: có một hệ thống rõ ràng để thực hiện và quản lý các công việc có thể lặp lại, tự động hóa ở những nơi có thể; giảm lượng công việc đang làm để mọi người không bị trói vào vô số tác vụ; chia sẻ thông tin rộng rãi và cho phép nhiều thành viên trong nhóm làm cùng một việc; kiểm tra xem liệu mình có đang làm những việc doanh nghiệp thực sự cần hay không; giảm nhiễu và các việc ngoài kế hoạch để nhân viên có thể làm những công việc giá trị cao mà họ thích, thay vì lội trong một đầm lầy hỗn loạn
Ý chính của The Phoenix Project không phải là biến con người thành những con rối tự động có thể thay thế, mà là xây dựng một hệ thống cho họ dư địa và thời gian để làm những việc thật sự có giá trị, vốn không thể tự động hóa hay hệ thống hóa
Vì từng vận hành nhà máy và cũng từng làm lập trình viên nên tôi nhìn thấy cả hai phía: biến lập trình viên thành công nhân dây chuyền sản xuất là vô lý, nhưng những công việc trông giống việc nhà máy, như các tác vụ đã biết và các bước có thể lặp lại, thì nên được xử lý theo cách tương tự
s/manufacturing/IT/g, sau đó cập nhật bằng các tham chiếu hiện đạiKhông có nghĩa là tôi ghét cuốn sách. Tôi đã đọc khoảng một nửa, và từng cố bắt các nhóm đọc nó để chuyển tư duy sang hướng lấy hệ thống làm trung tâm. Chỉ là tôi không thể nói nó sâu sắc hay có nhiều insight hơn The Goal nhiều
Dù tôi có châm chọc văn phong, nó thực sự đáng đọc. Không thể đổ lỗi cho kiểu tư duy Phoenix Project về nhiều điều mà mọi người làm sai trong các tác vụ đã biết hay các bước có thể lặp lại
Tuy nhiên trong lập trình, rất hiếm khi có chuyện thực hiện một công việc đã biết theo các bước lặp lại. Nếu chuyện đó xảy ra, thường là do đã mắc sai lầm chiến thuật trong quản lý các bên liên quan, khiến không còn thời gian để tự động hóa
Đọc một cách có suy nghĩ sẽ dẫn tới kết luận như đoạn cuối, nhưng tôi biết chắc rằng phần lớn quản lý tôi gặp không hiểu sự khác biệt giữa sản xuất widget và thiết kế hệ thống
Học tập liên tục, tự động hóa và đo lường là các công cụ giúp hiện thực hóa các điểm 1–5 ở trên
Tôi không nhận được thông điệp “hãy làm việc chăm chỉ hơn để làm nhiều việc hơn, nhanh hơn” từ The Phoenix Project
https://scrumguides.org/scrum-guide.html
Điều thường kinh khủng là đủ thứ linh tinh mà người ta chất thêm lên trên rồi gọi là Scrum. Cách tốt nhất để chống lại Scrum dởm không phải là chiến đấu, mà là giả vờ trung thành một cách thuần túy với giáo lý gốc. Như vậy trông ít phản nghịch hơn và cũng dễ tạo ảnh hưởng hơn
Tiêu đề làm tôi bối rối. “commodify” chẳng phải có nghĩa là “làm cho có thể bán được”, tức thương mại hóa sao? Công nghệ chẳng phải đã kiếm được hàng chục tỷ đô la rồi sao?
Điều tác giả nói có vẻ là commoditization, tức biến công việc kỹ thuật thành công việc phổ thông mà bất kỳ nhân viên có thể thay thế nào cũng làm được
Theo https://en.wikipedia.org/wiki/Commoditization, có thể tóm tắt rằng commoditization là việc một thứ độc quyền trở thành hàng hóa phổ thông, còn commodification là việc một thứ trước đây không thể bán được trở nên có thể bán được
Tôi có đang bắt bẻ quá mức không? Tôi từng nghĩ hai từ này có nghĩa khác nhau
Sửa: Xem Wiktionary thì https://en.wiktionary.org/wiki/commodification nói rằng chúng đôi khi cũng được dùng thay thế cho nhau. Có vẻ chỉ là một sự nhầm lẫn phổ biến
https://www.merriam-webster.com/dictionary/commodify
Nó có nghĩa là “biến một thứ như giá trị nội tại hay tác phẩm nghệ thuật thành hàng hóa”, nên commodify gần với ý nói về commoditization hơn
Dầu mỏ là hàng hóa vì có nhiều nhà sản xuất và tất cả đều tạo ra cùng một thứ, nên mua từ bên nào cũng không quan trọng
Trong phép ví von với McDonald’s, lập trình viên không phải là thiếu niên đứng làm việc trước máy, mà là kỹ sư đã thiết kế ra cỗ máy. Trong phép ví von đó, máy tính mới là thiếu niên
Lập trình không phải là công việc, mà là siêu công việc. Một khi đã tạo ra một danh sách lệnh, máy tính sẽ tiếp tục thực hiện việc đó 24 giờ mỗi ngày, còn tôi đi viết danh sách lệnh mới cho việc khác
Nếu viết cùng một danh sách lệnh hai lần thì về cơ bản là đang làm sai. Vì thế ta luôn làm việc mới, và vì không làm cùng một việc hai lần nên rất khó biết sẽ mất bao lâu
IT không phải là nhà máy, mà là việc tạo ra nhà máy
Tôi cho rằng nhiều xung đột giữa lập trình viên và nhà quản lý xuất phát từ việc từ “nhà quản lý” bị gom quá rộng. Nhà quản lý ở McDonald’s giám sát xem nhân viên có tuân theo quy trình để làm ra sản phẩm hay không. Việc có không tuân theo quy trình hay không là rõ ràng, quy trình được giả định là có hiệu lực, và việc có tạo ra đầu ra hay không cũng rõ ràng
Ngược lại, lập trình viên được thuê để phát triển quy trình cho máy móc tuân theo. Người quản lý nhân viên này cũng có thể có một quy trình để lập trình viên tuân theo, và việc họ có tuân theo hay không có thể rõ ràng, nhưng liệu quy trình đó có hiệu lực hay không, liệu một hành động cụ thể có dẫn tới kết quả đã định hay không, và bản thân kết quả có rõ ràng hay không thì đều bất định
Vậy mà cả hai vai trò đều được gọi là “nhà quản lý”
Trong phép ví von cỗ máy này, lập trình viên không quản lý con người mà là một kiểu nhà quản lý khác, chỉ huy máy móc. Chỉ có điều những cỗ máy đó được thả ra thế giới, và lập trình viên không liên tục giám sát chúng
Tất nhiên, như các bình luận khác nói, cũng có khả năng khái niệm này hoàn toàn nhảm nhí. Nhưng nếu vài năm nữa tôi nhận ra đây là một ý nghĩ ngốc nghếch, thì ít nhất việc có ai đó cùng xấu hổ vẫn đỡ hơn là xấu hổ một mình
Khoảng 10 năm trước, vài người bạn là kỹ sư cơ khí của tôi đã ngạc nhiên khi biết tôi học phát triển phần mềm
Họ nói những câu như “Vẫn còn nhiều việc để làm à? Những gì cần thiết chẳng phải hệ thống hiện có đã làm được hết rồi sao?”
Sự hiểu lầm nằm ở ý nghĩ rằng việc tạo ra các hệ thống giải quyết vấn đề mới là dễ dàng và đã được hàng hóa hóa, nên không còn cần viết code nữa
Thực tế, hiếm khi việc xây dựng phần mềm dễ như cấu hình UI. Ta cần văn bản để biểu đạt các quy tắc logic và luồng, cần quản lý phiên bản để theo dõi và rollback các thay đổi hệ thống, và cuối cùng vẫn cần lập trình viên
Coding không biến mất, chỉ có mức độ trừu tượng tăng lên
Tôi cho rằng ngành công nghệ từ lâu đã cố hàng hóa hóa lập trình viên, và COBOL hay Java cũng nằm trong dòng chảy đó
Nhưng dù trừu tượng hóa thứ gì, vẫn có những đặc tính cốt lõi sẽ lại lộ ra. Ngay cả khi yêu cầu trông có vẻ đơn giản và có framework cấp cao, phần lớn phần mềm của chúng ta vẫn không hoạt động đúng
Như tác giả nói, giải pháp thật sự là những lập trình viên có năng lực và biết quan tâm. Có thể xây dựng sự nghiệp từ điều đó
Nếu làm lâu trong cùng một lĩnh vực, các pattern lặp lại khá giống nhau, nhưng yêu cầu kinh doanh của mỗi bên lại khác nhau một chút. Ở mỗi tầng của stack, sự khác biệt này lớn dần lên, và nhìn tổng thể thì có vô số việc phi hàng hóa, mang tính tùy chỉnh
Vì vậy hai sản phẩm không bao giờ giống hệt nhau, và cũng không chỉ tồn tại một công ty toàn cầu khổng lồ sản xuất mọi thứ
Tôi đã thấy vô số lần lập trình viên phấn khích khi có cơ hội tự hàng hóa hóa theo kiểu chia nhỏ chính mình theo chủ nghĩa Taylor
Ngành y là phản ví dụ tôi thường nêu khi có thảo luận về tự động hàng hóa hóa. Về mặt cảm xúc, nó có hai sức hấp dẫn. Bệnh nhân ghét việc bị chuyển qua chuyển lại giữa các bác sĩ. Họ hiểu rằng hàng hóa hóa đi kèm một mức độ chuyên môn hóa tăng lên, và mỗi lần bàn giao thêm lại là thêm một điểm có thể thất bại
Thứ hai là có thể tô điểm địa vị và cách làm việc sao cho trông giống địa vị cao hơn. Nếu đặt điều thứ nhất lên trước và để điều thứ hai được đọc như ẩn ý thì thường rất hiệu quả. Người lao động duy trì các năng lực tổng quát hơn, và dựa vào việc tham vấn lẫn nhau thay vì bàn giao
Dây chuyền lắp ráp là chuyên môn hóa theo trình tự định sẵn; cứ nhìn các lỗi bàn giao liên quan đến giờ làm việc của bác sĩ nội trú thì thấy
Vận hành, đổi mới, bảo trì. Cứ chọn bất kỳ ba trong ba cái đó
Sẽ tốt hơn nếu cùng một đội làm, hoặc các đội rất gần nhau làm
Lý tưởng nhất là mỗi người trong đội đều thực hiện cả ba chức năng này ở các mức độ khác nhau. Vì cảm hứng cải tiến đến từ đó
Cũng có thể chia ba chức năng này thành ba nhóm và ba tầng quản lý, nhưng kết quả thường tầm thường và mọi người trở nên khổ sở. Đặc biệt, những người bị kẹt trong đội bảo trì làm công việc cốt lõi nhưng không được ghi nhận
Cũng có thể giao cho một đội chịu trách nhiệm cả ba chức năng, nhưng người ta lại thường tuyển quản lý quá khớp với một chức năng cụ thể. Trùng hợp thay, chức năng đó lại là chức năng dẫn tới đãi ngộ tốt hơn trong quý tới
Trong cùng một văn hóa, rất khó đồng thời ủng hộ xuất sắc trong vận hành, bảo trì tận tâm và thời gian để suy nghĩ sâu. Khó là đúng thôi
Nhìn vào vai trò business intelligence/nhà phân tích, có thể thấy ngành này đang cố thay thế người dùng SQL bằng người dùng các công cụ như Tableau.
Kiểu như “chỉ cần kết nối với bất kỳ kho dữ liệu nào là nhân sự phi kỹ thuật có thể kéo thả để làm được”.
Vấn đề có vài điểm. Thứ nhất, họ quên rằng vì đầu ra chỉ tăng tuyến tính nên phải tuyển thêm nhiều nhân sự lương thấp. Tất cả đều là công việc dựa trên UI, nên con người vẫn phải quay tay từng vòng.
Thứ hai, mã chuyển đổi logic nghiệp vụ rất phức tạp và lộn xộn vẫn sẽ xuất hiện, chỉ là giờ bị chôn trong UI. Người biết logic đó là gì chỉ còn PM hoặc đội ngũ nghiệp vụ.
Tổ chức engineering cung cấp các tập dữ liệu chất lượng cao, đã được kiểm thử, khá thô sơ để trả lời các câu hỏi nghiệp vụ. Phần khó là giải quyết bài toán lấy kết quả nghiệp vụ từ dữ liệu nguồn theo những cách kỳ quặc.
Giờ lời giải đó được lưu trong workbook Tableau và không thể dùng làm đầu vào khác. Phải sao chép rồi dán trong UI sang workbook Tableau mới.
Vì đã mua dịch vụ đám mây Tableau, đội BI có thể làm cho các phần trích xuất SQL nghiêm ngặt hơn và duy trì chúng. Tableau trông như đang muốn lấy một phần mảng kinh doanh của Databricks, nhưng giờ việc đó lại do một đội không phải engineering làm. Không biết có ổn không.
Ví dụ có câu hỏi điển hình: “Người dùng của chúng ta đến từ quốc gia nào?” Quốc gia ghi trong form đăng ký, quốc gia hiện đang truy cập dịch vụ, quốc gia của phương thức thanh toán, quốc gia nơi sinh, quốc gia có quốc tịch, quốc gia đang cư trú, địa chỉ giao hàng hay địa chỉ thanh toán — tất cả đều khác nhau.
Nếu tập dữ liệu đủ lớn, mỗi cách sẽ cho một câu trả lời khác. Trong lĩnh vực “fintech toàn cầu”, những trường hợp kỳ quặc như vậy sẽ trở thành bình thường.
Người dùng Tableau lương thấp điển hình nhiều khả năng sẽ tìm mã quốc gia thấy được, chạy count rồi tuyên bố đó là sự thật.
Người dùng Tableau thông minh hơn một chút sẽ nhờ kỹ sư viết SQL giúp.
Phải có người hiểu tập dữ liệu và hệ thống nguồn thì mới có thể hỏi ngược lại phía nghiệp vụ, buộc họ đặt câu hỏi đúng và đưa ra đúng ngữ cảnh.
Các công cụ kiểu Tableau rất tốt để thay thế những “công việc kỹ thuật” kiểu mỗi ngày dán cùng một truy vấn SQL vào pgAdmin rồi gửi CSV qua email, nhưng chúng không khiến những người lao động kỹ năng thấp, làm việc xoay quanh UI, suy nghĩ tốt hơn.
Mở rộng tuyến tính đầu ra theo chi phí có thể được mô hình hóa bằng spreadsheet, và có thể chuyển chi phí đó sang khách hàng hoặc tính phí cho họ. Mọi người ở tầng kinh doanh đều thấy thoải mái với động lực này.
Ngược lại, tình huống một chuyên gia chuyên trách có thể tạo ra đầu ra gấp 1000 lần với ít công sức, nhưng không chắc mất một ngày hay một tuần, khiến mọi người rơi vào bất định và làm lãnh đạo bất an. Nếu ai cũng muốn sự tầm thường dễ chịu, thì rất khó bán ý tưởng đó.
Điểm 2 trớ trêu thay lại đòi hỏi nhiều chuyên gia hơn, chỉ là một loại chuyên gia khác, vì phải duy trì toàn bộ logic đó.
Cuối cùng nó sẽ vận hành như một chương trình tạo việc làm và trở nên đắt đỏ hơn, nhưng sẽ phân bổ giá trị tương ứng với các lãnh địa có ảnh hưởng chính trị, nên nó sẽ thành công.
Trước hết sa thải hết người backend vì cho rằng họ không hiểu kinh doanh, rồi lấy Tableau làm backend mới. Sự thật rằng người backend đã hấp thụ và tinh chỉnh các yêu cầu nghiệp vụ bị phớt lờ.
Sau đó, khi người làm nghiệp vụ mắc kẹt trong mớ mạng nhện hỗn loạn do chính họ tạo ra, họ gọi tư vấn Tableau đến; những người này hút tiền mà chẳng tạo ra thứ gì có giá trị.
Tôi xuất thân từ kỹ thuật kết cấu, và thấy phần mềm giống quy hoạch đô thị hơn là các ngành kỹ thuật khác.
Nó quá rộng lớn. Theo thời gian, việc xuất hiện ngày càng nhiều chức danh mô tả các loại công việc cụ thể như backend, frontend, firmware, kỹ sư machine learning, data scientist, nhà phân tích bảo mật, lập trình viên kernel cũng không có gì đáng ngạc nhiên.
Khi các tiêu chuẩn phát triển, tôi nghĩ đến một lúc nào đó làm việc ở những vị trí này có thể cần các chứng chỉ rất cụ thể. Có thể nó sẽ biến thành hình thức khác, nhưng hiệu ứng kết tinh là thấy rõ.
Nghĩ về phần mềm như một nhà máy cũng có thể đúng và hữu ích. Nhưng không phải mọi thứ đều khớp với phép ví von đó. Chẳng hạn khi xét đến tích hợp sản phẩm, hoặc khi thứ được tạo ra là dịch vụ chứ không phải ứng dụng.
Nhà máy hàm ý rằng có một thứ gì đó được sản xuất ra, nhưng trong nhiều trường hợp phần mềm không phải kết quả cuối cùng, mà bản thân nó là phương tiện tạo khả năng.
Trong phần mềm, phần lớn công việc đã được tự động hóa tiệm cận. Vì vậy ta quên mất rằng việc đó từng là lao động.
Cứ nghĩ đến thao tác sao chép file đơn giản. Có thể nói đó là “người chép thuê tự động”.
Việc sao chép đã được tự động hóa đến mức khối lượng sao chép khổng lồ mà hệ thống của chúng ta thực hiện trở nên vô hình, và nó cũng biến mất với tư cách là điểm khác biệt kinh tế.
Hơn nữa, ở tầng meta nó cũng hữu ích. Bản thân chương trình sao chép cũng dễ dàng được sao chép bằng cùng thuật toán.
Ý chính là việc viết phần mềm, giống như toán học, luôn dành thời gian ở ranh giới giữa cái đã biết và cái chưa biết. Bởi mọi lĩnh vực đã hoàn toàn được biết và đặc tả đều sẽ được tự động hóa theo cách vừa giải quyết vấn đề cho mọi người, vừa đốt sạch nền đất kinh tế của hoạt động đó.
Công việc phần mềm ở bất kỳ lĩnh vực nào cũng luôn chứa yếu tố thám hiểm, tức nghiên cứu: đi vào vùng chưa biết để tìm kiếm của cải. Dù vùng đất mới đó huy hoàng hay bi kịch tầm thường thì cũng vậy.
Những lĩnh vực mà một nhà quản lý không có chuyên môn phần mềm có thể tự động làm được giống như cây ăn quả đã được thuần hóa để dễ hái quả. Nhưng trên những cây đó không còn quả nữa.
Nếu định nghĩa vấn đề của nhà quản lý đó không vươn trở lại lên những vùng khó tự động hóa, nơi đòi hỏi sự sáng tạo và chuyên môn phiền phức, thì họ không còn làm công việc khác biệt hay có giá trị nữa.