Gần như đúng, nhưng tôi cho rằng nhân viên bán hàng hay tài chính cũng chẳng có nhiều quyền mua sắm như vậy. Vì thế mọi người đều dùng các công cụ được công ty cho phép hoặc gói miễn phí, và cuối cùng phải bán ý tưởng đó cho sếp
Phải thuyết phục theo kiểu nó tiết kiệm thời gian, khiến dự án minh bạch hơn, và giảm bớt tự do
Đây rất có thể cũng là lý do Excel được dùng rộng rãi như vậy. Excel cũng là công cụ mạnh nhất mà IT công ty cho phép
Cứ thử làm ở bộ phận bán hàng hoặc tài chính rồi xin phép cài WSL trên PC là sẽ hiểu. Lý do ứng dụng web phổ biến cũng là vì IT công ty phải biết thì mới chặn được
Một quản lý marketing có thể dùng thẻ của mình để trả tiền cho Basecamp, nhưng nếu muốn đưa vào một công cụ tự host thì chuyện sẽ to lên vì phải vượt qua chính sách IT kiểu “máy tính do chúng tôi quản lý, cách làm việc cũng do chúng tôi quyết định”
Lý do Excel được dùng rộng rãi là vì đúng nghĩa ai cũng dùng được. Không giống cơ sở dữ liệu, thứ bạn tạo ra hiện ra dưới dạng trực quan có thể nhìn thấy trực tiếp
Nó được bao gồm trong mọi giấy phép m365, và giấy phép vĩnh viễn trong thời gian dài cũng tương đối rẻ
Nói chuyện cho phép đội sales dùng WSL khiến tôi tự hỏi liệu người nói đã từng làm việc với nhân viên sales thực tế chưa. Ở 99% công ty, ngay cả nhân viên sales rành công nghệ cũng chỉ vừa đủ gửi file đính kèm email mà không cần trợ giúp, vậy họ định làm gì với WSL?
Nhìn chung là đúng. Công ty không phê duyệt mua lẻ một cuốn sách, nhưng lại phê duyệt đăng ký nền tảng học tập
Phê duyệt tất cả các khoản mua lặt vặt như vậy là quá nhiều việc, còn nếu không rà soát thì các gói đăng ký không dùng sẽ chất đống khắp nơi, hoặc sẽ mua nhiều thứ chẳng giúp ích gì mấy cho công ty
Theo kinh nghiệm của tôi, bộ phận sales có thể có công cụ tốt ở cấp phòng ban, nhưng quyền mua sắm thì không lớn lắm
Ngược lại phía marketing có vẻ có quyền mua khá lớn, có lẽ vì bản thân công việc liên quan đến việc mua đủ thứ
Ngay cả sếp cũng có thể thấy phiền vì muốn được duyệt mua công cụ thì phải bán ý tưởng lên cấp cao hơn. 80 đô la mỗi người dùng mỗi tháng thực ra gần như miễn phí so với chi phí nhân sự, nhưng lúc nào cũng trở thành rào cản
Việc mua ứng dụng tự host khó là vì IT phải chịu trách nhiệm cho chi phí máy chủ, mạng, lưu trữ, cài đặt, nâng cấp, vận hành, hỗ trợ, đăng nhập một lần dựa trên AD, email, Slack, sao lưu và khôi phục, xuất và di chuyển dữ liệu, cũng như cả an ninh mạng
Chỉ cần một ứng dụng bị xuyên thủng là toàn bộ IT của công ty có thể gặp rủi ro; ngay cả khi áp dụng cô lập hoặc zero trust thì bề mặt tấn công và chi phí bảo mật vẫn tăng
Trên thực tế, mua một ứng dụng tự host là phần dễ; phần khó là vận hành ổn định mỗi ngày trong suốt thời gian doanh nghiệp cần. Có trường hợp còn phải lưu giữ dữ liệu lâu dài theo luật
Ngay cả với công cụ do IT nghiệp vụ yêu cầu, họ có thể quản lý được một phần kỹ thuật, nhưng nhiều khi không làm được vì không có thời gian, hoặc chỉ là lập trình viên chứ không phải quản trị hệ thống/mạng
Cuối cùng phải dùng sandbox tách biệt với IT công ty, hoặc từ bỏ các tiện ích như sao lưu và AD, hoặc tự triển khai và duy trì như shadow IT
Vì vậy tôi nghĩ một trong những lý do SaaS và cloud tăng trưởng là nhờ ngoại hóa các chi phí này
Nếu phải đấu tranh để mua một cuốn sách 50 đô la thì có lẽ bạn đã chọn nhầm công ty
Tuy nhiên, có một số lập trình viên đã tạo tài khoản không chính thức bằng thẻ để thử nghiệm nội bộ Notion, rồi tạo các tài liệu tổng quan quan trọng trong đó và chia sẻ liên kết
Một nửa công ty muốn xem các tài liệu đó đã ngầm tạo tài khoản, và tháng sau CFO nhận được hóa đơn 10.000 đô la
Câu chuyện về việc không nên trao quyền mua sắm cho lập trình viên thường bắt đầu theo kiểu này
Đây chỉ là ví dụ về mô hình giá săn mồi và dark pattern
Có lý do khiến nhiều công ty SaaS không cung cấp tốt tùy chọn thanh toán trả trước hoặc trần chi phí cố định. Gần như là lừa đảo
Tôi không hiểu ai lại nghĩ một hệ thống có thể tính phí chỉ vì nhấp vào liên kết là ý hay. Nếu thẻ cũng không có hạn mức tháng hợp lý thì toàn bộ cấu hình đó quá vô lý
Khó mà tin đây là “khởi đầu của câu chuyện khiến lập trình viên không có quyền mua sắm”
Việc tự mua công cụ, dù là lập trình viên hay bất kỳ ai, thường có thể trở thành tối ưu cục bộ gây hại cho toàn tổ chức
Ví dụ công cụ bị phân mảnh khiến không thể tìm thông tin bằng một lần tìm kiếm, hoặc mỗi đội phải đăng nhập riêng vào các công cụ khác nhau
Nếu các đội tự quản lý những công cụ chứa tài sản trí tuệ của công ty theo cách riêng, đó sẽ là ác mộng tuân thủ khi nhắm tới SOC
Còn mua sách hoặc tài liệu học tập thì tôi nghĩ là tốt
Với tư cách người từng quyết định hơn 100 triệu đô la mỗi quý cho chi tiêu phần cứng, phần mềm và dịch vụ kỹ thuật, nếu bạn làm công cụ cho lập trình viên thì trước hết phải khiến các lập trình viên hiện tại thấy cực kỳ hữu ích và mạnh mẽ ủng hộ
Đừng đụng vào các hạng mục có quyền phủ quyết như hợp đồng thiếu minh bạch, lock-in, bảo mật dữ liệu/quyền riêng tư, đăng nhập một lần/tích hợp xác thực
Giá cũng phải hợp lý. Mức giá tỷ lệ tuyến tính theo biến số nào đó rất có thể sẽ vô lý trong bảng tính tài chính. Tính phí theo lập trình viên mỗi tháng thì dễ hiểu, giấy phép nổi toàn công ty thì tốt hơn, và trong một số trường hợp phí trọn gói không giới hạn toàn công ty lại phù hợp hơn
Ngay cả với cách cuối cùng, các chi phí tiêu hao như điện toán/lưu trữ cloud vẫn có thể chuyển nguyên sang khách hàng. Nếu có thể triển khai trực tiếp vào tài khoản cloud của khách hàng thì cũng giải quyết được vấn đề bảo mật dữ liệu/quyền riêng tư
Cần cung cấp kiểm soát chi phí như trần hóa đơn, trần sử dụng, hạn chế các thiết lập gây phí sử dụng đắt đỏ, và báo cáo mức sử dụng đầy đủ
Nếu làm tốt, cũng có thể ký hợp đồng nhiều năm với mức chi tiêu cam kết. Cần duy trì độ tin cậy của dịch vụ, và rà soát hằng quý với khách hàng lớn để nắm mức độ hài lòng cũng như các nhu cầu chưa được đáp ứng
Cũng có thể cung cấp và tính phí các dịch vụ chuyên nghiệp cao cấp như kỹ sư chuyên trách và hỗ trợ. Biên lợi nhuận cao, và đôi khi là then chốt để giành hoặc giữ một khách hàng cụ thể
Sản phẩm có thể gây tranh cãi trong nội bộ khách hàng, và người phản đối có thể khiến việc áp dụng sản phẩm thất bại; vì vậy nếu dịch vụ chuyên nghiệp đảm nhiệm tích hợp/triển khai ban đầu thì có thể giảm sự can thiệp của người gác cổng IT và tiếp cận người dùng thực sự
Tốt nhất đừng cố bán những sản phẩm mà khách hàng tin chắc họ có thể tự làm. Dù phán đoán đó sai, ban đầu bạn có thể thắng nhưng cuối cùng rất có thể sẽ thua
Điểm số 7 về tự làm hay mua thường không trắng đen như vậy. Trường hợp khó nhất là đã có sản phẩm nội bộ và bạn đang cố thay thế nó hoặc bổ sung tính năng mới
Vấn đề là khi nào đánh giá ROI của build vs buy
Mua một sản phẩm có chi phí tích hợp rất cao về thực chất cũng giống như tự làm. Việc tích hợp cần thời gian của lập trình viên, và thời gian đó lẽ ra có thể dùng cho việc khác hoặc cho chính sản phẩm
Sẽ tốt nếu điều này lộ ra trong quá trình tích hợp proof-of-concept, nhưng ngay cả ở giai đoạn đó cũng cần thời gian của lập trình viên để thực hiện
Tùy công ty. Công ty tôi từng làm trước đây có chính sách kiểu: “Sách, giấy phép, thậm chí cả phần cứng giúp công việc dễ dàng hơn, cần gì thì cứ mua. Chi phí quản lý dùng cho việc ra quyết định còn đắt hơn, nên mặc định là phê duyệt ngay.”
Các lập trình viên có đổ xô mua sắm không? Không; họ chỉ mua ở mức như trước khi có chính sách. Thực tế là cuộc sống tiện hơn.
Có thể xem sách, giấy phép và phần cứng như vật tư tiêu hao giống bút hay giấy. Điều này nhìn chung có thể phù hợp với các phần mềm cục bộ nhỏ như IDE.
Cần có tiền đề là tin tưởng trao quyền quản trị cho lập trình viên, hoặc bộ phận IT của công ty có thể cho phép cài đặt.
Có thể cấp một ngân sách nhỏ cho mọi người, hoặc quản lý theo đội/ phòng ban, nhưng ngay khi cần tích hợp với IT của công ty thì cách này không còn vận hành tốt nữa.
Tôi không nói cách đó là hay và cũng không nói là hoàn toàn không thể, nhưng mua sắm bùng nổ đột ngột không phải là kiểu thất bại duy nhất.
Nếu để 10, 20 năm thì nó có thể trông rất khác. Những mức tăng chi phí chậm và khó thấy sẽ tích tụ, và cũng có thể hình thành văn hóa trong đó những người tiêu ít hơn phải mua đồ để không khiến người khác trông như đang lãng phí.
Có nhiều cơ chế tinh vi thúc đẩy chi phí tăng, nên cần có thiết bị đẩy theo hướng ngược lại. Tôi xem đây là một vấn đề vẫn chưa được giải quyết.
Có thể đặt một hạn mức ngân sách rộng rãi nhưng nói rõ rằng không có nghĩa là phải dùng hết, và đặt quy tắc quyên góp một tỷ lệ nhất định của phần còn lại cuối năm cho một nơi tốt đẹp mà ai cũng có thể chấp nhận.
Kiểu như: “Bạn được phép mua sách. Nhưng hãy nhớ rằng vì cuốn sách đó mà khoản quyên góp cho ngựa con sẽ giảm 5 đô la.” Nếu đổi sang lợn biển thì có nguy cơ tôi sẽ phải làm việc bằng Chromebook.
Vấn đề nằm ở chỗ quản lý chen vào mọi quyết định. Mọi người nghĩ quản lý tồn tại để giúp đỡ, nhưng họ tạo ra nhiều vấn đề hơn là giải quyết.
Tốt lắm thì nhiều người trong số họ cũng chỉ là kém năng lực; giảm vài quản lý và dùng khoản lương đó làm ngân sách tùy nghi thì tốt hơn. Đôi bên cùng có lợi.
Công ty hiện tại của tôi có vài người phụ trách mang tính HR xử lý các khoản mua sắm kiểu này. Gửi email kèm liên kết phần cứng hoặc phần mềm cần mua là họ giao đến tận nhà.
Tôi không cần biết quy trình đặt hàng và giao hàng của công ty, nên đây là cách tốt nhất tôi từng thấy.
Tôi cũng có trải nghiệm tương tự. Họ phát thẻ công ty cho tất cả mọi người và khuyến khích sử dụng.
Khi còn là nhân viên, tôi từng gặp vấn đề này một lần. Tôi muốn ThinkPad nhưng ban lãnh đạo cứ khăng khăng chọn một chiếc Dell tệ hại, và cuối cùng tôi vẫn nhận được ThinkPad.
Ngoài chuyện đó ra, hễ xin sách hay công cụ là cứ được cấp, cả bàn phím tách rời đắt tiền cũng được.
Giờ khi đã tự làm chủ, tôi cần gì thì cứ mua. Thực ra cũng không cần nhiều lắm.
Không có nhiều “công cụ dành cho lập trình viên” hữu ích đến mức đáng bỏ tiền, và càng ít thứ đáng để tích hợp vào workflow của tôi. Theo thời gian, phần cuối này ngày càng quan trọng hơn.
Đời công sở là vậy.
Tôi được cấp một chiếc Dell tệ hại, nó hỏng, rồi lại được cấp một chiếc Dell tệ hại, rồi nó lại hỏng, rồi lại nhận một chiếc Dell nữa.
Họ nói: “Chúng tôi chỉ có hợp đồng với Dell”, nhưng khi hỏi chẳng phải ngay từ đầu đừng nên ký với Dell sao, thì im lặng bao trùm và lúc đó họ mới bắt đầu động não.
Bạn sẽ nhận ra khoảnh khắc Dell hỏng là những giây phút tuyệt vời nhất đời. Mất 5 ngày để đi qua các lớp lệnh mua hàng và chính trị đặt hàng trước khi họ gửi thiết bị mới, và trong 5 ngày đó bạn chẳng làm được gì vì chính sách bảo mật công ty quá hà khắc.
Thế là trong 5 ngày đó tôi ngủ, liên lạc với bạn bè, và trở lại làm người.
Tôi yêu Dell. Tôi không muốn ThinkPad.
Còn máy cá nhân thì tôi dùng MacBook.
Nếu phải đi hỏi, tức là bạn không có quyền.
Trước đây tôi làm ở một công ty con thiên về bán hàng của một công ty kỹ thuật.
Ban đầu, mời bữa trưa 100 đô la thì không vấn đề gì, nhưng tôi không thể mua một chiếc card 30 đô la cho máy tính của mình.
Ngược lại, ở công ty mẹ, mua thiết bị kiểm thử 5.000 đô la thì dễ, nhưng muốn đưa ai đó đi ăn fast food thì phải điền ba bản biểu mẫu.
Đến cuối nhiệm kỳ của tôi, ở cả hai nơi hầu như không thể làm gì nếu thiếu các biểu mẫu đó.
Nhiều công ty công cụ lập trình viên thành công kiếm tiền bằng cách marketing cho sếp, chứ không phải cho lập trình viên. Không chỉ trong công nghệ mà ở nhiều lĩnh vực khác cũng vậy.
Rất đồng cảm. Ở một trong các công ty công nghệ lớn, tôi cần một ổ cứng cho một việc nọ, nhưng mua một mảng ổ đĩa 5.000 đô la rồi tháo ổ ra còn dễ hơn là kê khai chi phí 200 đô la cho một HDD đơn lẻ.
Cố mua thứ nằm ngoài phạm vi của mình thì phức tạp đến vô lý.
Gần đây công ty nói “đã có thẻ công ty thì cứ dùng”, và các EVP phê duyệt chi phí liên quan đến sự kiện. Điều đó không phổ biến, nhưng thật ấn tượng khi họ hiểu rằng đôi khi cần cắt bỏ thủ tục quan liêu.
Lần tới khi làm một khoản hoàn phí bình thường, chắc tôi sẽ lại phải cãi nhau với phòng kế toán vì biên lai taxi 20 đô la không có điểm đi và điểm đến.
Tôi tự mua giấy phép phần mềm rồi đưa vào phần thuế. Đó là cách tránh kiểu tiết kiệm giả tạo.
Nhờ tự tìm và mua các công cụ phù hợp, rẻ tiền, tôi đã được trao giải ở nơi làm việc, trở nên không thể thay thế trong một dự án cụ thể, được tăng lương, và có thể chọn công việc mình muốn làm. Giấy phép Jetbrains của tôi là ví dụ tiêu biểu. Khó tưởng tượng việc refactor code mà không có nó.
Nếu việc cắt giảm chi phí của công ty dừng lại, tôi sẽ có nhiều đối thủ cạnh tranh hơn trong nội bộ.
Về lý thuyết, hệ thống thuế của Anh cũng cho phép làm vậy. Trong mẫu Self Assessment có mục để yêu cầu khấu trừ chi phí liên quan đến công việc mà chủ lao động không hoàn trả.
Chủ lao động cũ của tôi trả mức mileage thấp, nên tôi thường khai phần chênh lệch trong tờ khai thuế.
Với phần mềm thì tôi không rõ tiêu chí đánh giá chi phí được phép sẽ áp dụng như thế nào.
Tôi cũng đã làm theo cách đó nhiều năm rồi.
Vì hầu hết công ty không mua đúng phần mềm phù hợp cho công việc, tôi trở thành người làm việc hiệu quả nhất trong đội. Bởi vì khác với người khác, tôi có thể xử lý nhanh và hiệu quả.
Ở nhiều công ty, nếu làm vậy mà bị phát hiện thì sẽ gặp rắc rối lớn.
Tôi tò mò nhân viên W2 được miễn thuế ở Mỹ thì “đưa vào phần thuế” bằng cách nào.
Tôi tò mò còn ví dụ nào khác không.
Nếu có thể đưa lên Azure, AWS, Google Cloud thì câu chuyện sẽ khác
Dù không thể mua nổi một cây bút chì nếu chưa được phê duyệt, nhưng trên cloud của công ty thì có thể tiêu hàng nghìn đô la mà không ai hỏi
Đây là chỗ có phép màu của Amazon Marketplace. Bạn có thể mua cả các dịch vụ không phải của AWS, nhưng chúng vẫn xuất hiện trên hóa đơn AWS và vẫn được tính vào cam kết chi tiêu của công ty
Đúng vậy. Chúng tôi từng nhờ một lập trình viên thiết lập một máy chủ FTP. Anh ấy là một quản trị viên Linux khá ổn và đã làm việc này nhiều lần trên VPS giá 10 bảng
Nhưng lần đó anh ấy lại chọn một dịch vụ AWS hơn 1.000 bảng mỗi tháng. Khi nhận hóa đơn thẻ thì thành rắc rối lớn, và phí của tháng tiếp theo cũng đã phát sinh kha khá rồi
Sau đó chúng tôi buộc phải kiểm soát chặt hơn
Tôi cũng tương tự. Việc khiến đúng những người cần thiết xem xét localstack có lẽ sẽ là một cuộc chiến lớn và khó khăn
Nhưng nếu mua license doanh nghiệp thì chỉ riêng khoản tiết kiệm đã có thể hoàn vốn ngay, nên dù không phải công việc chính, tôi vẫn cảm thấy bị thúc ép phải thử
Công bằng mà nói, đó là vì đến giờ vẫn chưa ai tìm ra cách tích hợp terraform apply với luồng phê duyệt SAP
Mô hình kinh doanh trong đó kỹ sư là người ra quyết định hoàn toàn có thể tồn tại. Nhưng chỉ giới hạn ở những công cụ cho phép kỹ sư tối ưu cục bộ mà không gây ảnh hưởng trực tiếp ngoài phạm vi đó
IDE là ví dụ tốt nhất. Nếu công ty cho phép từng kỹ sư tự quyết định IDE cá nhân để tăng năng suất, tổng tác động ở cấp toàn cục của các quyết định đó vẫn có thể ổn. Jetbrains đã cho thấy điều này
Nhưng không phải công cụ nào cũng như vậy. Bài gốc bàn đến các ví dụ thuộc nhóm thứ hai như Redis, Terraform, AWS
Khác với IDE, khi các quyết định cá nhân về cơ sở dữ liệu, quản lý hạ tầng và hạ tầng cloud lan rộng thì sẽ phát sinh vấn đề. Công ty phải duy trì một stack không đồng nhất, còn nhà cung cấp thì không thể tạo ra một hợp đồng doanh nghiệp có ý nghĩa chỉ vì một nhóm nào đó đã chọn Redis
Vì vậy, đến một mức nào đó sẽ cần chuẩn hóa. Tại thời điểm đó, tác động của lựa chọn và quy mô license trở nên lớn hơn, nên không chỉ lead kỹ thuật mà cả tài chính cũng muốn có tiếng nói. Và họ có lý do chính đáng
Rồi ngay khi tài chính tham gia, bạn phải biện minh cho lựa chọn bằng một thứ ngôn ngữ khó đối với phần lớn kỹ sư
Quyền mua sắm của tôi kiểu như thế này. Tôi nói với sếp: “Nếu mua công cụ lập trình này, chúng ta có thể tiết kiệm X giờ thời gian của lập trình viên”
Miễn là X đủ lớn so với giá của công cụ. Cách này khá hiệu quả nên tôi dùng thường xuyên, đến mức giờ sếp cũng bắt đầu hoài nghi
Hoài nghi là đúng. Việc đánh giá quá cao lợi ích, dù là công cụ hay thiết kế lại, cũng phổ biến chẳng kém việc đánh giá quá thấp nỗ lực cần bỏ ra, và hai chuyện này có lẽ liên quan chặt chẽ với nhau
Không có nghĩa là không có công cụ đáng giá. Có, nhưng rất hiếm
Tôi tự hỏi sẽ mất bao lâu trước khi sếp nói: “Trong 3 tháng qua, cộng tất cả các công cụ mà anh nói lại thì anh bảo tiết kiệm được một năm công của lập trình viên, vậy tôi sẽ cắt 1 lập trình viên khỏi đội và giữ nguyên công việc lẫn lịch trình”
Có thể bạn sẽ nhận lại phản hồi kiểu: “Thời gian của lập trình viên không phải KPI, và dù làm 160 giờ, 180 giờ hay 200 giờ mỗi tháng thì lương vẫn như nhau”
1 bình luận
Các ý kiến trên Hacker News
Gần như đúng, nhưng tôi cho rằng nhân viên bán hàng hay tài chính cũng chẳng có nhiều quyền mua sắm như vậy. Vì thế mọi người đều dùng các công cụ được công ty cho phép hoặc gói miễn phí, và cuối cùng phải bán ý tưởng đó cho sếp
Phải thuyết phục theo kiểu nó tiết kiệm thời gian, khiến dự án minh bạch hơn, và giảm bớt tự do
Đây rất có thể cũng là lý do Excel được dùng rộng rãi như vậy. Excel cũng là công cụ mạnh nhất mà IT công ty cho phép
Cứ thử làm ở bộ phận bán hàng hoặc tài chính rồi xin phép cài WSL trên PC là sẽ hiểu. Lý do ứng dụng web phổ biến cũng là vì IT công ty phải biết thì mới chặn được
Một quản lý marketing có thể dùng thẻ của mình để trả tiền cho Basecamp, nhưng nếu muốn đưa vào một công cụ tự host thì chuyện sẽ to lên vì phải vượt qua chính sách IT kiểu “máy tính do chúng tôi quản lý, cách làm việc cũng do chúng tôi quyết định”
Nó được bao gồm trong mọi giấy phép m365, và giấy phép vĩnh viễn trong thời gian dài cũng tương đối rẻ
Nói chuyện cho phép đội sales dùng WSL khiến tôi tự hỏi liệu người nói đã từng làm việc với nhân viên sales thực tế chưa. Ở 99% công ty, ngay cả nhân viên sales rành công nghệ cũng chỉ vừa đủ gửi file đính kèm email mà không cần trợ giúp, vậy họ định làm gì với WSL?
Phê duyệt tất cả các khoản mua lặt vặt như vậy là quá nhiều việc, còn nếu không rà soát thì các gói đăng ký không dùng sẽ chất đống khắp nơi, hoặc sẽ mua nhiều thứ chẳng giúp ích gì mấy cho công ty
Ngược lại phía marketing có vẻ có quyền mua khá lớn, có lẽ vì bản thân công việc liên quan đến việc mua đủ thứ
Chỉ cần một ứng dụng bị xuyên thủng là toàn bộ IT của công ty có thể gặp rủi ro; ngay cả khi áp dụng cô lập hoặc zero trust thì bề mặt tấn công và chi phí bảo mật vẫn tăng
Trên thực tế, mua một ứng dụng tự host là phần dễ; phần khó là vận hành ổn định mỗi ngày trong suốt thời gian doanh nghiệp cần. Có trường hợp còn phải lưu giữ dữ liệu lâu dài theo luật
Ngay cả với công cụ do IT nghiệp vụ yêu cầu, họ có thể quản lý được một phần kỹ thuật, nhưng nhiều khi không làm được vì không có thời gian, hoặc chỉ là lập trình viên chứ không phải quản trị hệ thống/mạng
Cuối cùng phải dùng sandbox tách biệt với IT công ty, hoặc từ bỏ các tiện ích như sao lưu và AD, hoặc tự triển khai và duy trì như shadow IT
Vì vậy tôi nghĩ một trong những lý do SaaS và cloud tăng trưởng là nhờ ngoại hóa các chi phí này
Nếu phải đấu tranh để mua một cuốn sách 50 đô la thì có lẽ bạn đã chọn nhầm công ty
Tuy nhiên, có một số lập trình viên đã tạo tài khoản không chính thức bằng thẻ để thử nghiệm nội bộ Notion, rồi tạo các tài liệu tổng quan quan trọng trong đó và chia sẻ liên kết
Một nửa công ty muốn xem các tài liệu đó đã ngầm tạo tài khoản, và tháng sau CFO nhận được hóa đơn 10.000 đô la
Câu chuyện về việc không nên trao quyền mua sắm cho lập trình viên thường bắt đầu theo kiểu này
Có lý do khiến nhiều công ty SaaS không cung cấp tốt tùy chọn thanh toán trả trước hoặc trần chi phí cố định. Gần như là lừa đảo
Khó mà tin đây là “khởi đầu của câu chuyện khiến lập trình viên không có quyền mua sắm”
Ví dụ công cụ bị phân mảnh khiến không thể tìm thông tin bằng một lần tìm kiếm, hoặc mỗi đội phải đăng nhập riêng vào các công cụ khác nhau
Nếu các đội tự quản lý những công cụ chứa tài sản trí tuệ của công ty theo cách riêng, đó sẽ là ác mộng tuân thủ khi nhắm tới SOC
Còn mua sách hoặc tài liệu học tập thì tôi nghĩ là tốt
Với tư cách người từng quyết định hơn 100 triệu đô la mỗi quý cho chi tiêu phần cứng, phần mềm và dịch vụ kỹ thuật, nếu bạn làm công cụ cho lập trình viên thì trước hết phải khiến các lập trình viên hiện tại thấy cực kỳ hữu ích và mạnh mẽ ủng hộ
Đừng đụng vào các hạng mục có quyền phủ quyết như hợp đồng thiếu minh bạch, lock-in, bảo mật dữ liệu/quyền riêng tư, đăng nhập một lần/tích hợp xác thực
Giá cũng phải hợp lý. Mức giá tỷ lệ tuyến tính theo biến số nào đó rất có thể sẽ vô lý trong bảng tính tài chính. Tính phí theo lập trình viên mỗi tháng thì dễ hiểu, giấy phép nổi toàn công ty thì tốt hơn, và trong một số trường hợp phí trọn gói không giới hạn toàn công ty lại phù hợp hơn
Ngay cả với cách cuối cùng, các chi phí tiêu hao như điện toán/lưu trữ cloud vẫn có thể chuyển nguyên sang khách hàng. Nếu có thể triển khai trực tiếp vào tài khoản cloud của khách hàng thì cũng giải quyết được vấn đề bảo mật dữ liệu/quyền riêng tư
Cần cung cấp kiểm soát chi phí như trần hóa đơn, trần sử dụng, hạn chế các thiết lập gây phí sử dụng đắt đỏ, và báo cáo mức sử dụng đầy đủ
Nếu làm tốt, cũng có thể ký hợp đồng nhiều năm với mức chi tiêu cam kết. Cần duy trì độ tin cậy của dịch vụ, và rà soát hằng quý với khách hàng lớn để nắm mức độ hài lòng cũng như các nhu cầu chưa được đáp ứng
Cũng có thể cung cấp và tính phí các dịch vụ chuyên nghiệp cao cấp như kỹ sư chuyên trách và hỗ trợ. Biên lợi nhuận cao, và đôi khi là then chốt để giành hoặc giữ một khách hàng cụ thể
Sản phẩm có thể gây tranh cãi trong nội bộ khách hàng, và người phản đối có thể khiến việc áp dụng sản phẩm thất bại; vì vậy nếu dịch vụ chuyên nghiệp đảm nhiệm tích hợp/triển khai ban đầu thì có thể giảm sự can thiệp của người gác cổng IT và tiếp cận người dùng thực sự
Tốt nhất đừng cố bán những sản phẩm mà khách hàng tin chắc họ có thể tự làm. Dù phán đoán đó sai, ban đầu bạn có thể thắng nhưng cuối cùng rất có thể sẽ thua
Vấn đề là khi nào đánh giá ROI của build vs buy
Mua một sản phẩm có chi phí tích hợp rất cao về thực chất cũng giống như tự làm. Việc tích hợp cần thời gian của lập trình viên, và thời gian đó lẽ ra có thể dùng cho việc khác hoặc cho chính sản phẩm
Sẽ tốt nếu điều này lộ ra trong quá trình tích hợp proof-of-concept, nhưng ngay cả ở giai đoạn đó cũng cần thời gian của lập trình viên để thực hiện
Tùy công ty. Công ty tôi từng làm trước đây có chính sách kiểu: “Sách, giấy phép, thậm chí cả phần cứng giúp công việc dễ dàng hơn, cần gì thì cứ mua. Chi phí quản lý dùng cho việc ra quyết định còn đắt hơn, nên mặc định là phê duyệt ngay.”
Các lập trình viên có đổ xô mua sắm không? Không; họ chỉ mua ở mức như trước khi có chính sách. Thực tế là cuộc sống tiện hơn.
Cần có tiền đề là tin tưởng trao quyền quản trị cho lập trình viên, hoặc bộ phận IT của công ty có thể cho phép cài đặt.
Có thể cấp một ngân sách nhỏ cho mọi người, hoặc quản lý theo đội/ phòng ban, nhưng ngay khi cần tích hợp với IT của công ty thì cách này không còn vận hành tốt nữa.
Nếu để 10, 20 năm thì nó có thể trông rất khác. Những mức tăng chi phí chậm và khó thấy sẽ tích tụ, và cũng có thể hình thành văn hóa trong đó những người tiêu ít hơn phải mua đồ để không khiến người khác trông như đang lãng phí.
Có nhiều cơ chế tinh vi thúc đẩy chi phí tăng, nên cần có thiết bị đẩy theo hướng ngược lại. Tôi xem đây là một vấn đề vẫn chưa được giải quyết.
Có thể đặt một hạn mức ngân sách rộng rãi nhưng nói rõ rằng không có nghĩa là phải dùng hết, và đặt quy tắc quyên góp một tỷ lệ nhất định của phần còn lại cuối năm cho một nơi tốt đẹp mà ai cũng có thể chấp nhận.
Kiểu như: “Bạn được phép mua sách. Nhưng hãy nhớ rằng vì cuốn sách đó mà khoản quyên góp cho ngựa con sẽ giảm 5 đô la.” Nếu đổi sang lợn biển thì có nguy cơ tôi sẽ phải làm việc bằng Chromebook.
Tốt lắm thì nhiều người trong số họ cũng chỉ là kém năng lực; giảm vài quản lý và dùng khoản lương đó làm ngân sách tùy nghi thì tốt hơn. Đôi bên cùng có lợi.
Tôi không cần biết quy trình đặt hàng và giao hàng của công ty, nên đây là cách tốt nhất tôi từng thấy.
Khi còn là nhân viên, tôi từng gặp vấn đề này một lần. Tôi muốn ThinkPad nhưng ban lãnh đạo cứ khăng khăng chọn một chiếc Dell tệ hại, và cuối cùng tôi vẫn nhận được ThinkPad.
Ngoài chuyện đó ra, hễ xin sách hay công cụ là cứ được cấp, cả bàn phím tách rời đắt tiền cũng được.
Giờ khi đã tự làm chủ, tôi cần gì thì cứ mua. Thực ra cũng không cần nhiều lắm.
Không có nhiều “công cụ dành cho lập trình viên” hữu ích đến mức đáng bỏ tiền, và càng ít thứ đáng để tích hợp vào workflow của tôi. Theo thời gian, phần cuối này ngày càng quan trọng hơn.
Tôi được cấp một chiếc Dell tệ hại, nó hỏng, rồi lại được cấp một chiếc Dell tệ hại, rồi nó lại hỏng, rồi lại nhận một chiếc Dell nữa.
Họ nói: “Chúng tôi chỉ có hợp đồng với Dell”, nhưng khi hỏi chẳng phải ngay từ đầu đừng nên ký với Dell sao, thì im lặng bao trùm và lúc đó họ mới bắt đầu động não.
Bạn sẽ nhận ra khoảnh khắc Dell hỏng là những giây phút tuyệt vời nhất đời. Mất 5 ngày để đi qua các lớp lệnh mua hàng và chính trị đặt hàng trước khi họ gửi thiết bị mới, và trong 5 ngày đó bạn chẳng làm được gì vì chính sách bảo mật công ty quá hà khắc.
Thế là trong 5 ngày đó tôi ngủ, liên lạc với bạn bè, và trở lại làm người.
Tôi yêu Dell. Tôi không muốn ThinkPad.
Còn máy cá nhân thì tôi dùng MacBook.
Trước đây tôi làm ở một công ty con thiên về bán hàng của một công ty kỹ thuật.
Ban đầu, mời bữa trưa 100 đô la thì không vấn đề gì, nhưng tôi không thể mua một chiếc card 30 đô la cho máy tính của mình.
Ngược lại, ở công ty mẹ, mua thiết bị kiểm thử 5.000 đô la thì dễ, nhưng muốn đưa ai đó đi ăn fast food thì phải điền ba bản biểu mẫu.
Đến cuối nhiệm kỳ của tôi, ở cả hai nơi hầu như không thể làm gì nếu thiếu các biểu mẫu đó.
Nhiều công ty công cụ lập trình viên thành công kiếm tiền bằng cách marketing cho sếp, chứ không phải cho lập trình viên. Không chỉ trong công nghệ mà ở nhiều lĩnh vực khác cũng vậy.
Cố mua thứ nằm ngoài phạm vi của mình thì phức tạp đến vô lý.
Gần đây công ty nói “đã có thẻ công ty thì cứ dùng”, và các EVP phê duyệt chi phí liên quan đến sự kiện. Điều đó không phổ biến, nhưng thật ấn tượng khi họ hiểu rằng đôi khi cần cắt bỏ thủ tục quan liêu.
Lần tới khi làm một khoản hoàn phí bình thường, chắc tôi sẽ lại phải cãi nhau với phòng kế toán vì biên lai taxi 20 đô la không có điểm đi và điểm đến.
Tôi tự mua giấy phép phần mềm rồi đưa vào phần thuế. Đó là cách tránh kiểu tiết kiệm giả tạo.
Nhờ tự tìm và mua các công cụ phù hợp, rẻ tiền, tôi đã được trao giải ở nơi làm việc, trở nên không thể thay thế trong một dự án cụ thể, được tăng lương, và có thể chọn công việc mình muốn làm.
Giấy phép Jetbrains của tôi là ví dụ tiêu biểu. Khó tưởng tượng việc refactor code mà không có nó.
Nếu việc cắt giảm chi phí của công ty dừng lại, tôi sẽ có nhiều đối thủ cạnh tranh hơn trong nội bộ.
Chủ lao động cũ của tôi trả mức mileage thấp, nên tôi thường khai phần chênh lệch trong tờ khai thuế.
Với phần mềm thì tôi không rõ tiêu chí đánh giá chi phí được phép sẽ áp dụng như thế nào.
Vì hầu hết công ty không mua đúng phần mềm phù hợp cho công việc, tôi trở thành người làm việc hiệu quả nhất trong đội. Bởi vì khác với người khác, tôi có thể xử lý nhanh và hiệu quả.
Nếu có thể đưa lên Azure, AWS, Google Cloud thì câu chuyện sẽ khác
Dù không thể mua nổi một cây bút chì nếu chưa được phê duyệt, nhưng trên cloud của công ty thì có thể tiêu hàng nghìn đô la mà không ai hỏi
Nhưng lần đó anh ấy lại chọn một dịch vụ AWS hơn 1.000 bảng mỗi tháng. Khi nhận hóa đơn thẻ thì thành rắc rối lớn, và phí của tháng tiếp theo cũng đã phát sinh kha khá rồi
Sau đó chúng tôi buộc phải kiểm soát chặt hơn
Nhưng nếu mua license doanh nghiệp thì chỉ riêng khoản tiết kiệm đã có thể hoàn vốn ngay, nên dù không phải công việc chính, tôi vẫn cảm thấy bị thúc ép phải thử
terraform applyvới luồng phê duyệt SAPMô hình kinh doanh trong đó kỹ sư là người ra quyết định hoàn toàn có thể tồn tại. Nhưng chỉ giới hạn ở những công cụ cho phép kỹ sư tối ưu cục bộ mà không gây ảnh hưởng trực tiếp ngoài phạm vi đó
IDE là ví dụ tốt nhất. Nếu công ty cho phép từng kỹ sư tự quyết định IDE cá nhân để tăng năng suất, tổng tác động ở cấp toàn cục của các quyết định đó vẫn có thể ổn. Jetbrains đã cho thấy điều này
Nhưng không phải công cụ nào cũng như vậy. Bài gốc bàn đến các ví dụ thuộc nhóm thứ hai như Redis, Terraform, AWS
Khác với IDE, khi các quyết định cá nhân về cơ sở dữ liệu, quản lý hạ tầng và hạ tầng cloud lan rộng thì sẽ phát sinh vấn đề. Công ty phải duy trì một stack không đồng nhất, còn nhà cung cấp thì không thể tạo ra một hợp đồng doanh nghiệp có ý nghĩa chỉ vì một nhóm nào đó đã chọn Redis
Vì vậy, đến một mức nào đó sẽ cần chuẩn hóa. Tại thời điểm đó, tác động của lựa chọn và quy mô license trở nên lớn hơn, nên không chỉ lead kỹ thuật mà cả tài chính cũng muốn có tiếng nói. Và họ có lý do chính đáng
Rồi ngay khi tài chính tham gia, bạn phải biện minh cho lựa chọn bằng một thứ ngôn ngữ khó đối với phần lớn kỹ sư
Quyền mua sắm của tôi kiểu như thế này. Tôi nói với sếp: “Nếu mua công cụ lập trình này, chúng ta có thể tiết kiệm X giờ thời gian của lập trình viên”
Miễn là X đủ lớn so với giá của công cụ. Cách này khá hiệu quả nên tôi dùng thường xuyên, đến mức giờ sếp cũng bắt đầu hoài nghi
Không có nghĩa là không có công cụ đáng giá. Có, nhưng rất hiếm