Code được chạy thường xuyên hơn là được đọc
(olano.dev)- Nguyên tắc “code được đọc thường xuyên hơn là được viết” bắt đầu từ ý rằng cần ưu tiên người bảo trì hơn người viết, rồi được mở rộng thành một mô hình ra quyết định có tính đến cả người dùng, vận hành và kinh doanh
- Giá trị của code không nằm ở độ tinh xảo tự thân mà ở việc nó có đáp ứng mục đích của người dùng hay không; vì vậy, điều quan trọng là đưa sản phẩm đến trước người dùng sớm và thường xuyên, rồi phản ánh lại những gì học được từ phản hồi
- “Chạy” code trong môi trường production không chỉ là triển khai chương trình, mà còn bao gồm triển khai, nâng cấp, quan sát, kiểm toán, giám sát, sửa chữa và loại bỏ; chi phí vận hành dài hạn có thể lớn hơn rất nhiều so với những bất tiện trong lúc phát triển
- KISS không chỉ dừng ở việc đơn giản hóa code, mà còn được mở rộng thành một nguyên tắc vận hành: giảm bớt các bộ phận chuyển động và hiểu rõ các chế độ lỗi để hệ thống vẫn hoạt động ngay cả khi xảy ra sự cố
- Ngân sách, marketing, deadline, các bên liên quan, nhà đầu tư và lợi ích chính trị đều can thiệp vào việc ra quyết định, nên cần thừa nhận rằng làm người dùng hài lòng và tạo ra doanh thu không phải lúc nào cũng trùng khớp
Mở rộng mô hình ưu tiên
- Câu “code được đọc thường xuyên hơn là được viết” có nghĩa là người viết code ban đầu không nên phớt lờ chi phí mà người sẽ đọc và sửa đổi nó trong tương lai phải gánh chịu
- Nguyên tắc này là cơ sở để đầu tư vào khả năng bảo trì như tính đơn giản, kiểm thử và tài liệu hóa
- Tóm gọn lại, có thể xem đây là mô hình
maintainer > author
Người dùng đứng trước nhà phát triển
- Code là phương tiện để đạt mục đích, và phần mềm phải phục vụ một nhóm người dùng nào đó
- Dù code có được viết tốt đến đâu hay công nghệ có tinh vi đến mức nào, nếu không đáp ứng được mục đích và không mang lại trải nghiệm người dùng tốt thì giá trị của nó sẽ giảm đi
- Thứ tự ưu tiên được mở rộng thành
user > maintainer > author, và nếu không phân biệt các vai trò của nhà phát triển thì thànhuser > dev - Thay vì chỉ đoán người dùng muốn gì hoặc chỉ hỏi họ, tốt hơn là đưa chương trình ra trước người dùng sớm và thường xuyên, rồi phản ánh lại những gì học được từ phản hồi
Chạy bao gồm cả vận hành production
- “Chạy” không chỉ là hành vi bật chương trình lên, mà bao gồm toàn bộ quá trình vận hành trong production
- Triển khai
- Nâng cấp
- Quan sát
- Kiểm toán
- Giám sát
- Sửa chữa
- Loại bỏ
- Dan McKinley trong Choose Boring Technology cho rằng chi phí dài hạn để giữ cho hệ thống tiếp tục hoạt động ổn định gần như luôn lớn hơn rất nhiều so với những bất tiện trong lúc xây dựng
- Khi đưa góc nhìn này vào, mô hình trở thành
user > ops > dev - Nhiều phần mềm không bao giờ đạt đến production ở quy mô có ý nghĩa, và được xây dựng trên những giả định chưa được kiểm chứng
- Khi vận hành code trong production, KISS vượt ra ngoài phạm vi code để trở thành bài toán giảm bớt các bộ phận chuyển động và hiểu rõ các chế độ lỗi
- Điều quan trọng là triển khai được thứ gì đó và đảm bảo nó vẫn hoạt động ngay cả khi thất bại xảy ra
Kinh doanh là một trục riêng biệt
- Phát triển với suy nghĩ về người dùng có thể đưa bạn đi rất xa, nhưng giả định rằng “phần mềm có giá trị với người dùng cũng có giá trị với tổ chức” là một dạng trừu tượng hóa quá đơn giản
- Từ góc nhìn của nhà phát triển, thật dễ để tách bạch rằng mình làm ra phần mềm tốt còn doanh nghiệp sẽ biến nó thành tiền, nhưng cuối cùng sẽ có lúc cần đưa góc nhìn kinh doanh vào quá trình làm việc
- Sự phân biệt này nhìn chung hoạt động trong cả phần mềm tiêu dùng và phần mềm doanh nghiệp
- Mô hình được mở rộng thành
biz > user > ops > dev - Ngân sách là ví dụ rõ ràng nhất, vì tài nguyên để đáp ứng nhu cầu người dùng không phải là vô hạn nên phải đo lường chi phí và lợi ích
- Marketing, deadline, các bên liên quan, nhà đầu tư, lợi ích cá nhân và chính trị cũng ảnh hưởng đến quyết định
- Một quyết định đúng nếu chỉ nhìn vào phần mềm, đội ngũ và người dùng có thể lại không đúng khi xét đến toàn bộ tổ chức
- Đôi khi phải làm việc tạo ra doanh thu thay vì việc làm người dùng hài lòng
Những “mùi” của tổ chức phát triển nhìn qua mô hình
-
Code không thể bảo trì:
author > maintainer- Code khôn lỏi nhưng lười biếng biến thành spaghetti và “rừng ma”
- Bao gồm các vấn đề như tối ưu hóa quá sớm, hoặc các module chỉ một vài người cụ thể mới có thể động vào
-
Phần mềm không dùng được:
dev > user- Xuất hiện ở những đội ngũ không học từ người dùng hoặc ưu tiên công nghệ hơn
- Ví dụ là các chương trình được thiết kế quá mức, những đợt “hiện đại hóa” làm trải nghiệm người dùng tệ đi, hay các web app phá hỏng chức năng của trình duyệt
-
“Máy tôi chạy được mà”:
dev > ops- Đây là phần mềm không được thiết kế với việc vận hành trong đầu
- Bao gồm sự phức tạp quá mức như dùng cơ sở dữ liệu hào nhoáng cho tải dữ liệu nhỏ, hoặc một đội nhỏ lại vận hành cả hệ sinh thái microservice
- Những phần mềm mà người bị đánh thức lúc nửa đêm khi có sự cố không phải là người đã thiết kế nó cũng thuộc nhóm này
-
“Điều đúng đắn”:
dev > biz- Là khi code bị đối xử như thể nó là mục đích tự thân
- Ví dụ gồm những người thợ thủ công kiểu phô trương, các nhạc công trên tàu Titanic, và Lisp Hackers
-
Phát triển theo định hướng CV:
dev > *- Là loại phần mềm được tạo ra khi không có gì bị đặt cược và nhà phát triển có thể làm bất cứ điều gì mình muốn
-
Phần mềm trong tưởng tượng:
biz > user > ops > dev- Là phần mềm đã được làm ra nhưng gần như hoặc hoàn toàn không bao giờ vào production
- Charity Majors gọi điều này là living a lie
- Phần mềm không có người dùng cũng thuộc nhóm này, tức là không giải quyết vấn đề nào, giải quyết sai vấn đề, hoặc giải quyết một vấn đề mà chưa từng có ai gặp phải
- Cũng bao gồm trường hợp cầm một công nghệ bị thổi phồng rồi gõ vào mọi thứ cho đến khi thứ gì đó trông giống một use case mơ hồ xuất hiện
-
“Chủ nghĩa tư bản hậu kỳ”
- Là khi phần mềm dựa trên đầu tư mạo hiểm không có mô hình kinh doanh, hoặc có mô hình kinh doanh là phát triển tới mức độc quyền rồi khai thác người dùng
Căng thẳng giữa người dùng và kinh doanh
biz > userkéo theo những hệ quả khó chấp nhận- Cách nhiều người học về phần mềm là giải quyết vấn đề của người dùng cuối, và một trong những lời khuyên cuối cùng của The Pragmatic Programmer được tóm lại thành mục tiêu không chỉ giao code mà còn phải làm người dùng hài lòng
- Khi phần mềm trở nên phổ biến khắp nơi, việc giữ vững giả định này ngày càng khó hơn
- Rất nhiều phần mềm không quan tâm đến người dùng, thao túng họ, hoặc biến họ thành sản phẩm
- Vấn đề này không chỉ giới hạn ở mạng xã hội
- Popup cố giành lấy sự chú ý của người dùng xuất hiện cả khi đặt phòng, gọi món ăn, hay bấm nút Start của Windows
- Google Search bị mô tả là trả về những kết quả như một đống rác
- Sự lệch pha giữa niềm tin rằng mình đang làm điều tốt và thứ mà một phần đáng kể của ngành xem là có lợi nhuận giải thích cho sự khó chịu của nhiều chuyên gia phần mềm
- Không thể quay lại quá khứ khi phớt lờ thực tế kinh tế, nhưng cần một lập trường đạo đức mạnh mẽ hơn để không gây hại cho người dùng
- Người dùng không phải lúc nào cũng có thể đứng trước kinh doanh, nhưng kinh doanh cũng không thể luôn luôn đứng trước
user > ops > devbiz > ops > devbiz ≹ user
1 bình luận
Ý kiến trên Hacker News
Có những trường hợp người dùng không dùng một hệ thống vì họ thích nó, mà vì công ty đã mua nó
Trong tình huống đó, theo định nghĩa thì lợi ích kinh doanh được ưu tiên hơn người dùng, và nhà phát triển sẽ phải đáp ứng yêu cầu của quản lý cấp trung bên khách hàng hơn là của người dùng thực tế. Nếu không làm vậy thì sẽ không giành được hợp đồng. Kết quả là người dùng bị mắc kẹt với bộ tính năng làm qua loa, trong khi đội phát triển bận làm các tính năng mới mà quản lý cấp trung thích
Hơi mang tính hoài nghi, nhưng với tư cách kỹ sư, biết rằng về bản chất mình đang ở trong kiểu công ty như vậy cũng là điều hữu ích. Ví dụ, các nhà bán lẻ trực tuyến rất nhạy với người dùng, đến mức họ có thể làm các phiên bản website khác nhau theo từng quốc gia chỉ vì người Đức thích X còn người Mỹ thích Y. Chỉ một thay đổi nhỏ cũng có thể tạo ra khác biệt lớn về doanh thu
Ngược lại, có những công ty hầu như không nhạy cảm với tính khả dụng vì người mua sản phẩm không phải là người dùng thực tế
Để chốt được hợp đồng, chúng tôi phải đáp ứng checklist của khách hàng, nhưng cũng vẫn quan tâm đến trải nghiệm người dùng. Trải nghiệm người dùng tốt hiếm khi là một yêu cầu khắt khe từ phía khách hàng
Phần mềm của đối thủ cực kỳ đau khổ khi sử dụng, nên chúng tôi muốn khác biệt ở điểm đó; nhờ vậy việc đào tạo dễ hơn, người dùng hài lòng hơn, và khi có thể họ còn đề xuất với quản lý của mình mua thêm sản phẩm của chúng tôi
Cuối cùng, 80% việc này đến từ niềm tự hào rằng “phần mềm của chúng tôi không tệ” và từ sự đồng cảm, nhưng về lâu dài đó cũng là lợi ích của chúng tôi vì nó bồi đắp thương hiệu
Chúng tôi chọn chiến lược tăng trưởng dựa trên sản phẩm, không có nhân viên bán hàng, và đội sản phẩm hoàn toàn tập trung vào trải nghiệm người dùng. Vấn đề là chúng tôi không bán cho người dùng. Những người mua phần mềm là những người khác trong tổ chức của người dùng, và họ thậm chí chưa từng trực tiếp dùng thử sản phẩm
Đó là một cách tiếp cận tất yếu sẽ thất bại. Chúng tôi cần nhân viên bán hàng có thể hiểu cách nghĩ của người mua, giải thích lợi ích cho họ, và hướng dẫn người dùng giải thích các lợi ích đó cho những người khác trong tổ chức. Cần phải lấp đầy khoảng cách giữa người dùng và người mua
Vì vậy đây trở thành vấn đề ưu tiên nhóm người dùng nào, và phải tìm sự cân bằng giữa việc ưu tiên trải nghiệm của thiểu số có ảnh hưởng lên tầng quản lý, với việc duy trì sản phẩm để phần còn lại của người dùng có thể dùng đủ nhiều nhằm cung cấp dữ liệu có ý nghĩa cho cấp quản lý
Điều quan trọng chỉ là ý kiến của thị trưởng, quản lý thị trấn và hội đồng thành phố. Nếu báo cáo trông ổn và giá phù hợp thì họ gia hạn
Tôi vẫn nhớ cảnh trong các cuộc họp tại hiện trường, những người dùng hằng ngày nói thẳng vào mặt chúng tôi rằng nó khủng khiếp đến mức nào. Vậy mà không ngoại lệ, khách hàng đó vẫn gia hạn chỉ với lời hứa sửa vài lỗi cụ thể và mức tăng giá tối thiểu
Hôm nay tôi mới biết ký hiệu ≹. Nó được mô tả là “biểu thị mối quan hệ mà trong đó không đối tượng nào trong hai đối tượng được so sánh là lớn hơn hay nhỏ hơn đối tượng kia, nhưng cũng không nhất thiết có thể nói là bằng nhau. Đây là một khác biệt tinh tế quan trọng trong những lĩnh vực có cách so sánh không hoàn toàn mang tính số học” (https://www.mathematics-monster.com/symbols/Neither-Greater-...)
Có vẻ viết |z_1| = |z_2|, tức hai số phức có cùng độ lớn tuyệt đối, sẽ rõ ràng hơn
Bài đó còn viết rằng “tóm lại, ký hiệu ≹ đóng vai trò quan trọng trong việc cung cấp một vùng trung gian giữa các toán tử quan hệ truyền thống”, nhưng với tư cách nghiên cứu sinh tiến sĩ toán, tôi chưa từng thấy nó lần nào. Khó mà tin nó có “vai trò quan trọng”
Game là siêu tập của số siêu thực, còn số siêu thực là siêu tập của số thực; về cơ bản người ta đã nới lỏng định nghĩa của số siêu thực để làm mất tính toàn thứ tự
Vì thế xuất hiện những “con số” kỳ lạ có thể “bị nhầm lẫn với” hoặc “mơ hồ” so với các số khác. Ví dụ đơn giản nhất là * (star), không lớn hơn cũng không nhỏ hơn 0 nên bị nhầm với 0. Nó giống như một đám mây mơ hồ quanh 0 và được ký hiệu là 0║*
Những game phức tạp hơn như switch có thể bị nhầm với những khoảng số lớn hơn và được xem là “nóng”. Tạo số từ switch có thể cho ra những game nóng thú vị hơn nữa
Các sự kiện được tạo trên một thiết bị đơn lẻ luôn có thứ tự toàn phần. Nhưng nếu sự kiện được tạo trên hai thiết bị đang offline thì không thể nói cái nào xảy ra trước, và giữa hai sự kiện xuất hiện quan hệ ≹. Nói cách khác, có thể xem hai sự kiện là đồng thời
Vì thế có thể có các thứ tự “d > b > a” và “d > c > a”, nhưng “c ≹ b”
Một phần lớn bài toán mà CRDT giải quyết là định nghĩa cách xử lý hòa một cách tất định trong những trường hợp như vậy
Sao chuyện đó có thể xảy ra được?
Với khá nhiều người trong chúng ta, chi phí để chạy mã 1 tỷ lần có thể còn rẻ hơn vài phút thời gian của lập trình viên
Trên AWS, nếu chi 200 USD tiền máy chủ mỗi tháng thì có thể chạy phần lớn mã web API của tôi tới 100 tỷ lần
Vì vậy, tối ưu cho người đọc là lựa chọn tốt hơn trong hầu hết trường hợp, và chỉ nên làm các kiểu tối ưu khác khi đã chứng minh được rằng nó chậm đến mức khó chấp nhận về mặt kinh tế
Bài viết kết lại theo kiểu này:
user > ops > dev
biz > ops > dev
biz ≹ user
Kết luận có vẻ gần với ý rằng mã tồn tại vì người dùng cuối và doanh nghiệp. Ký hiệu cuối cùng, ≹, diễn đạt gọn rằng nhu cầu của người dùng cuối và doanh nghiệp không hoàn toàn giống nhau, nhưng cả hai đều quan trọng ngang nhau đối với lý do tồn tại của mã
Người dùng phải trả theo những cách ít rõ ràng hơn như hóa đơn điện cao hơn, tuổi thọ bị rút ngắn[0], cơ hội bị đánh mất, sự bực bội lớn hơn, hay phải nâng cấp phần cứng thường xuyên hơn
Hơn nữa, đa số người dùng không có mức lương hay chất lượng cuộc sống như lập trình viên, nên thiệt hại tác động lên họ lớn gấp nhiều lần
[0] Lãng phí thời gian của người khác là làm giảm QALY
Nó bao gồm cả việc vận hành trong production, tức triển khai, nâng cấp, quan sát, kiểm toán, giám sát, sửa chữa và khai tử
Nếu nói ngược lại kết luận từ tiêu đề để trả về cho tác giả, thì thay vì “mã được đọc nhiều hơn được viết”, có lẽ đúng hơn là mã không thể đọc sẽ không chạy được lâu
Dĩ nhiên, tôi là một quản trị viên hệ thống giàu kinh nghiệm đang muốn rẽ sang làm phát triển, nên xét theo nghĩa đó thì vẫn là người mới hoàn toàn
Nói chính xác hơn thì có lẽ phải là “mã không thể đọc sẽ không thể được sửa đổi lâu dài”
Trừ khi đang nói đến việc cố ý làm rối mã, còn lại đa số mã đều có thể đọc được với người sẵn sàng bỏ công, và nếu cần thì còn có formatter mã
Có một hệ quả nữa có thể thêm vào đây. Giữa mỗi tầng sau đây, số lần sử dụng tăng theo cấp số nhân
Trong nhiều ngôn ngữ, tỷ lệ giữa mỗi tầng đại khái ở mức 1000 lần, nên với mỗi 1 nhà thiết kế ngôn ngữ có thể có 1000 người thiết kế và phát hành mô-đun, 1 triệu lập trình viên, và 1 tỷ người dùng. Tùy hoàn cảnh cụ thể mà các con số có thể khác rất nhiều, nhưng với thảo luận định tính thì quy mô xấp xỉ như vậy là hợp lý
Điểm mấu chốt là chỉ một chút lười biếng ở tầng một hoặc hai cũng bị nhân lên rất mạnh ở hạ nguồn. Một trò vá víu bẩn thỉu được tạo ra để tiết kiệm 1 phút “cho tiện mình” ở tầng 1 có thể theo nghĩa đen làm lãng phí hàng triệu giờ quý giá trong đời người khác. Vì nó bắt họ phải chờ phần mềm chậm, chịu bực bội vì crash, hoặc chờ lâu hơn do việc phát triển tính năng ở tầng 2 và 3 bị chậm lại
Để giữ được mức chất lượng cần thiết ở hai tầng đầu đòi hỏi kỷ luật tự thân rất lớn và đạo đức nghề nghiệp ở cấp cá nhân. Ngược lại, mỗi lần nghe ai đó bảo vệ một lập trường không thể biện minh liên quan đến thiết kế ngôn ngữ lõi hay thư viện chuẩn, tôi lại thấy rất buồn
Tôi thường nghe những câu kiểu như “chỉ cần biết toàn bộ lịch sử vì sao góc cạnh này xuất hiện thì sẽ ổn thôi! Chỉ cần cảnh giác mãi mãi thì không sao cả. Nó không phải là thứ không an toàn, rủi ro bảo mật, chậm hay có vấn đề, miễn là đừng dùng sai”, và tôi biết những thứ như thế sẽ khiến các lập trình viên vấp ngã trong nhiều thập kỷ tới, đồng thời làm chậm phần mềm của hàng triệu, hàng tỷ người
Có vẻ tác giả đang lấy một quy tắc kinh nghiệm khá ổn rồi cố biến nó thành thuyết vạn vật
Nghe thì gọn gàng và khôn ngoan, nhưng nếu bỏ cách diễn đạt gượng ép đi thì nó gần như chỉ là nhai lại những điều hiển nhiên vốn đã ai cũng biết
Vì thế diễn đạt có thể trở nên hơi vụng
Và ngay cả khi đó là “điều hiển nhiên ai cũng biết”, bài này vẫn hữu ích như một tài liệu tham khảo vì nó kết nối các ý đó theo một cách đặc biệt nhất quán
Với ai đó thì mọi thứ đều mới, và ngay cả khi với tôi nó chỉ xác nhận thiên kiến sẵn có, đây vẫn là một góc nhìn thú vị
Cách tác giả đóng khung vấn đề có thể bị hiểu sai theo quá nhiều cách, nên khó trở thành một cách viết tắt hữu ích. Không thể có một thứ hạng tuyệt đối giữa các nhóm này
Trước hết, ở đây “dev” không phải là một cá nhân mà là một tập hợp những người có chuyên môn và thâm niên đa dạng, trải rộng across các tổ chức sản phẩm, kỹ thuật và thiết kế trong nhiều tổ chức
“ops” cũng không phải chỉ là một thứ và cũng không chỉ có nghĩa là vận hành kỹ thuật. Nó còn có thể bao gồm vận hành kinh doanh, hỗ trợ khách hàng, v.v.
“biz” cũng vậy, không phải là một khối duy nhất. Có xây dựng thương hiệu, marketing, bán hàng, pháp lý, ban điều hành, hội đồng quản trị, cơ quan quản lý, bên cho vay và nhà đầu tư
Tất cả những người này đều ảnh hưởng đến việc mã nào được viết ra, được viết như thế nào, và khi nào, bằng cách nào nó được triển khai tới người dùng. Tất cả đều phải giải cùng một vấn đề
Nhiều người trong tổ chức tồn tại chủ yếu để giúp mọi người cùng hiểu và nhìn thấy một vấn đề, đồng thời cùng làm việc hướng tới một mục tiêu chung
Nhưng sự hiểu biết đó liên tục tiến hóa, và có độ trễ khi lan truyền ra toàn tổ chức. Vì vậy, ngay cả khi mọi người đều đang hướng tới cùng một mục tiêu, vẫn có độ trễ, trong khi chính mục tiêu đó cũng đang thay đổi
Cuối cùng, “user” cũng không phải là một khối duy nhất, và cũng không có nhóm người dùng nào là tĩnh. Có nhiều nhóm người dùng khác nhau, và hành vi của họ có thể không ổn định trong dài hạn
Vì vậy, sẽ hữu ích hơn nếu hiểu và thừa nhận mọi biến số xung quanh thay đổi như thế nào, rồi trong bối cảnh đó diễn giải một thế giới không hoàn hảo và đầy trục trặc. Nếu không, rất dễ rơi vào kiểu suy nghĩ rằng những người khác đều tệ, mọi thứ đều hỏng, nên muốn làm lại toàn bộ từ đầu
Rất mừng khi thấy có thảo luận về những điều gần với đạo đức
Ở đoạn bài viết nói rằng “tôi nghĩ có một sự lệch pha giữa điều chúng ta tưởng là việc tốt và điều mà phần lớn ngành này coi là có lợi nhuận, và đó là lý do khiến sự khó chịu của nhiều chuyên gia phần mềm ngày càng tăng”, từ khó chịu là một cách nói khá nhẹ. Còn rất nhiều điều chưa được nói ra
Tôi muốn bổ sung vài câu hỏi. Điều gì xảy ra khi người dùng không phải là khách hàng, tức là người trả tiền? Doanh nghiệp có nghĩa vụ đạo đức với mọi người dùng, kể cả người dùng không trả tiền, hay không? Nếu một khách hàng trả tiền muốn sử dụng doanh nghiệp của bạn theo cách tạo ra tác động tiêu cực hạ nguồn lên người dùng thì sao?
Ví dụ, nếu một nền tảng khiến việc lừa đảo trở nên dễ hơn so với các lựa chọn thay thế trước đó, hoặc khiến việc phát tán thông tin sai lệch dễ hơn, hoặc khiến việc định hình ý kiến của người dùng theo những cách về lâu dài là phá hoại nhưng lại hấp dẫn và dễ gây nghiện trở nên dễ hơn thì sao? Tất cả những điều này đều đã được chứng minh là mô hình kinh doanh thành công trong một khoảng thời gian nhất định
Nếu những động lực này là thực tế, doanh nghiệp có nên theo đuổi những mô hình mang tính bóc lột đó không? Nếu có, liệu có thể làm một cách có trách nhiệm hơn không? Một phiên bản doanh nghiệp có đạo đức hơn có thể làm giảm bớt những xu hướng tệ nhất của đối thủ cạnh tranh không, hay cuối cùng vẫn trở thành một phần của vấn đề?
Kết luận cốt lõi thì rõ ràng. Có những loại vấn đề lớn hơn và quan trọng hơn mô hình kinh doanh. Có những vấn đề có thể được diễn đạt là “cần những chuẩn mực và quy tắc nào để buộc các công ty hoạt động trong một phạm vi hợp lý của lẽ thường”
Cuối cùng tôi muốn làm rõ. Doanh nghiệp về bản chất luôn truyền tải một tập hợp giá trị, và điều này là không thể tránh khỏi. Ngay cả việc chỉ chọn lập trường “cái gì phổ biến thì thắng” cũng tự nó là một lựa chọn mang hàm ý sâu sắc về giá trị. Các nhà khoa học chính trị và sử học đã biết từ lâu về vấn đề bạo quyền của số đông. Dù triết học chính trị của bạn là gì, đây vẫn là điều đáng suy ngẫm
Tôi không biết hệ thống đạo đức nào là “tốt nhất”, nhưng tôi biết rằng có những hệ đạo đức tốt hơn những hệ khác. Và tôi hy vọng chúng ta sẽ tiếp tục mài giũa đạo đức của mình thay vì để nó không được xem xét
Bạn có thể chọn vấn đề và lĩnh vực nào phù hợp với đạo đức của mình. Bài viết này nói về cách xây dựng hệ thống và cách đặt thứ tự ưu tiên cho công việc
Doanh nghiệp thực ra không tồn tại; đó là một cấu trúc tưởng tượng mà chúng ta tạo ra để tổ chức nguồn lực và cùng nhau làm việc
Doanh nghiệp không phải là thứ quan trọng hơn tất cả. Có nhiều người dùng, và đôi khi lợi ích của họ xung đột với nhau. Bạn không thể hiện diện ở mọi nơi và cũng không thể là mọi thứ, nên phải đặt ra ưu tiên. Việc theo đuổi những người dùng mang lại nhiều lợi nhuận hơn hoặc phù hợp với chiến lược dài hạn có thể trông như là “tốt cho doanh nghiệp”, nhưng thực ra mục tiêu vẫn là phục vụ người dùng. Chỉ là phải đi qua thêm vài bước mà thôi
Khi chính trị nội bộ trở nên rối rắm đến mức các quyết định chỉ còn được đưa ra vì lợi ích của doanh nghiệp mà không còn xét xem chúng dẫn tới hạnh phúc của người dùng như thế nào, thì tổ chức đó đã trở nên độc hại. Nó không nên tiếp tục tồn tại nữa. Nó có thể lảo đảo trong trạng thái zombie thêm một thời gian, nhưng đang trên đà đi xuống, và những người giỏi rồi sẽ rời đi hết
Có thể nói cảm xúc cũng chỉ là một cấu trúc được tạo ra để mô tả phản ứng trước hoàn cảnh, nhưng không phải vì nó không được tạo thành từ nguyên tử mà nó không “có thật”
Doanh nghiệp tồn tại theo nghĩa nó là yếu tố chủ đạo quyết định cuộc sống của phần lớn mọi người. Nó định hình thành phố, truyền thông, luật pháp, chính trị, chính sách đối ngoại và ảnh hưởng rất lớn đến gần như mọi thứ quan trọng. Dù có “thực” hay không, nó vẫn tạo ra tác động thực chất xung quanh chúng ta
Bên ngoài thế giới mã nguồn mở, điều khá rõ ràng là bên trả tiền sẽ quyết định cách mọi thứ được tạo ra. Điều đó vẫn đúng ngay cả khi quyết định ấy tệ cho chính chủ thể đó, tệ cho người dùng, và tệ cho công chúng nói chung hoặc môi trường. Dĩ nhiên vẫn có quy định của ngành và của chính phủ, nhưng nhìn chung công ty mới là bên có quyền quyết định
Đáng buồn thay, doanh nghiệp tồn tại để phục vụ chủ sở hữu. Trong đa số trường hợp, đặc biệt là ở các công ty lớn chứ không phải những cơ sở siêu nhỏ dưới 5 người, chủ sở hữu muốn có tiền, nên mọi người trong công ty đều tồn tại để kiếm thêm tiền cho chủ sở hữu. Hạnh phúc của người khác, kể cả hạnh phúc của người dùng, hoàn toàn không liên quan trừ khi nó có tương quan với doanh thu
Một động lực phổ biến khác trong công ty là sự tự bảo toàn. Vì vậy, ngoài việc kiếm tiền, những người ra quyết định còn cân nhắc cả sự an toàn của vị trí công việc của chính mình
Nhân viên không rời đi. Công ty khiến họ đủ hài lòng. Trả lương tốt và khiến họ cảm thấy mình là một phần của “cộng đồng”; thật đáng kinh ngạc là việc giữ con người tiếp tục làm việc cho một tổ chức xấu xa hoặc vô diện lại dễ đến thế. Chỉ cần nhìn các văn phòng FAANG là có thể thấy một danh sách chi tiết những chiêu trò nhân sự kiểu này
Tôi đồng ý rằng những công ty như vậy là độc hại và không nên tồn tại, nhưng thực tế là công ty vận hành theo cách này. Đây không phải dấu hiệu suy tàn, mà là hình ảnh của một doanh nghiệp trưởng thành và khỏe mạnh có thể kéo dài hàng chục năm. Ban điều hành, sản phẩm và chủ sở hữu có thể thay đổi, nhưng doanh nghiệp vẫn còn đó
Nhưng mức độ quan trọng là chủ quan. Nếu đó là đoạn code cá nhân để tự vui thì doanh nghiệp chẳng quan trọng. Nếu bạn muốn biến nó thành nguồn thu nhập chính thì doanh nghiệp là điều quan trọng nhất. Vì nếu phần mềm không thể phục vụ ai, thì dù người dùng có thích đến đâu nó cũng không chuyển hóa thành doanh thu thực tế được
Không có mô hình kinh doanh, thì ngay cả phần mềm tuyệt vời được người dùng yêu thích, có thể triển khai và dễ bảo trì cũng có thể dần lụi tàn
Ban đầu tôi hoài nghi, nhưng tôi thích mô hình tư duy này
Tất nhiên không nên mù quáng làm theo. Vẫn có những ngoại lệ dev > biz, vụ OpenAI là một ví dụ, và cũng có ngoại lệ dev > ops. Ở các startup giai đoạn đầu, cần di chuyển thật nhanh, nên đặc biệt vì lý do kinh doanh mà đôi khi dev > ops