- Công việc hằng ngày và quỹ đạo sự nghiệp của kỹ sư phụ thuộc nhiều vào việc lương được chi từ ngân sách nào trong ba loại: bán hàng/marketing, nghiên cứu & phát triển, hay bảo trì
- Kỹ thuật thuộc ngân sách bán hàng/marketing gần với tiền và dễ đo lường hiệu quả, nhưng có thể dẫn đến stack ranking và văn hóa cạnh tranh nội bộ
- Ngân sách nghiên cứu & phát triển tuyển dụng nhiều kỹ sư nhất dưới tổ chức sản phẩm, coi trọng giá trị dài hạn và việc biến thành tài sản trong từ một quý trở lên hơn là các thử nghiệm ngắn hạn
- Ngân sách bảo trì bị xem là đối tượng tối ưu hóa chi phí; sysadmin, vận hành hệ thống cũ, một phần platform engineering và công việc công cụ nội bộ có thể rơi vào nhóm này
- Biết công việc của mình thuộc ngân sách nào giúp phản ánh vào quyết định sự nghiệp: những thay đổi thường xuyên của công việc tăng trưởng, đầu tư dài hạn của nghiên cứu & phát triển, và mức ưu tiên thấp của bảo trì
Ba loại ngân sách phân chia công việc kỹ thuật
- Lương kỹ sư phần mềm nhìn chung được chi trả từ một trong ba ngân sách
- Bán hàng/marketing
- Nghiên cứu & phát triển
- Bảo trì
- Bản chất của ngân sách ảnh hưởng đến cách làm việc hằng ngày và hướng đi sự nghiệp của kỹ sư
- Cách phân loại này có thể hữu ích khi nghĩ về tầm nhìn nghề nghiệp hoặc định vị bản thân
Ngân sách bán hàng/marketing: kết quả tức thì có thể đo lường
- Kỹ thuật thuộc tổ chức tăng trưởng dễ định lượng kết quả
- Cấu trúc “làm việc gì thì chỉ số tăng” tương đối rõ ràng
- Nhóm này bao gồm các vai trò như growth engineer, sales engineer, devrel
- Giúp sản phẩm hiện có bán chạy hơn
- Giúp mọi người biết đến các tính năng
- Hỗ trợ người mua đưa công cụ vào quy trình làm việc của họ
- Điều công ty kỳ vọng là tác động tức thì
- Ưu điểm là dễ nắm được lợi tức đầu tư, và công việc gắn trực tiếp với doanh thu
- Càng dễ đo lường thì càng dễ so sánh giữa con người với nhau
- Có thể xuất hiện stack ranking giữa nhân viên
- Văn hóa cạnh tranh nội bộ có thể mạnh hơn văn hóa cùng nhau giải quyết vấn đề
- Nhịp công việc nhìn chung thiên về ngắn hạn
- Thử nghiệm tiếp theo
- Khách hàng tiếp theo
- Xu hướng marketing tiếp theo
- Công ty nhìn giá trị theo hệ số nhân mà số tiền đưa vào ngân sách này tạo ra, và trong quá trình theo đuổi tối ưu hóa có thể xuất hiện hiệu ứng cửa xoay
Ngân sách nghiên cứu & phát triển: tài sản tích lũy theo thời gian
- Nghiên cứu & phát triển, tức R&D, là lĩnh vực tuyển dụng nhiều kỹ sư nhất
- Thường nằm dưới tổ chức sản phẩm
- Ở các công ty lớn hơn có thể có tổ chức nghiên cứu hoặc tổ chức khoa học thực sự
- Nhóm này bao gồm các vai trò như product engineer, researcher, architect
- Xây dựng thứ công ty đang bán
- Hoặc khám phá những thứ công ty có thể bán nếu chúng vận hành tốt
- Điều công ty kỳ vọng là tăng trưởng theo thời gian
- Môi trường tương đối điềm tĩnh hơn
- Cân bằng giữa việc giữ chân người dùng hiện tại và các tính năng thu hút người dùng mới
- Có thể nghiêng về phía tăng trưởng bằng cách xây dựng tính năng cải thiện việc kích hoạt, từ đăng ký sang sử dụng thực tế
- Cũng có khi nghiêng về phía nghiên cứu bằng cách khám phá các dòng sản phẩm mới
- Ở những công ty có bộ phận nghiên cứu đúng nghĩa, cũng có những người làm các ý tưởng sẽ chưa được sản phẩm hóa trong nhiều năm
- Nghiên cứu & phát triển thực chất là hai ngân sách khác nhau được gộp vào một nhóm
- Phát triển và nghiên cứu là khác nhau
- Nhưng điểm chung là đều tập trung vào kết quả dài hạn
- Khoảng thời gian ngắn nhất được quan tâm là theo quý
- Công việc của kỹ sư được thiết kế để trở thành tài sản và mang lại giá trị trong nhiều năm tới
- Các thử nghiệm ngắn hơn là những bước đệm trong quá trình đó
- Đo lường hiệu quả là khó, nhưng công ty xem công việc này là đầu tư
- Với giả định rằng sản phẩm càng tốt thì bán hàng và tỷ lệ giữ chân cũng càng tốt
Ngân sách bảo trì: chi phí muốn cắt giảm
- Bảo trì nhìn chung đã được hấp thụ vào công việc phát triển
- Điều ngân sách này mong muốn là tối ưu hóa chi phí
- Sysadmin, những người tiếp tục vận hành hệ thống cũ, và đôi khi platform engineer thuộc nhóm này
- Công ty xem công việc này là chi phí thuần túy và cố gắng giảm thiểu
- Ở nhiều công ty, vai trò bảo trì lan tỏa trong phát triển sản phẩm
- Đó là công việc không được đánh giá cao
- Nhưng khi ai đó thấy đủ bất tiện thì cuối cùng cũng sẽ được xử lý
- Công ty đôi khi đóng gói việc cho kỹ sư thời gian xử lý NFR, tức yêu cầu phi chức năng, như một đặc quyền đặc biệt
- Chẳng hạn tình huống cho 2 ngày mỗi sprint để xử lý các việc phiền phức
- Xây dựng công cụ nội bộ cũng có thể thuộc nhóm này
- Có dashboard quản trị giúp công ty vận hành
- Nhưng không phải lúc nào cũng nhận được mức ưu tiên đầy đủ
Vị trí ngân sách đưa ra tín hiệu gì cho quyết định sự nghiệp
- Công việc thuộc ngân sách nào sẽ quyết định trải nghiệm hằng ngày của kỹ sư
- Công việc tăng trưởng có thể đo lường và thay đổi thường xuyên
- Công việc nghiên cứu điềm tĩnh hơn nhưng kết quả mơ hồ
- Công việc phát triển được xem là có giá trị và tích lũy theo thời gian
- Công việc bảo trì bị coi là thứ có thể bị cắt bất cứ lúc nào
1 bình luận
Các ý kiến trên Hacker News
Không chỉ cần biết lương của bạn đến từ hạng mục ngân sách nào, mà còn phải hiểu tổ chức đánh giá phát triển phần mềm ra sao, vì điều đó ảnh hưởng rất lớn đến sự nghiệp
Nếu công ty là hãng tư vấn bán thời gian phát triển, năng lực được đánh giá sẽ là khả năng quan hệ với khách hàng và khả năng nhanh chóng tạo ra phần mềm đủ dùng; nếu là công ty sản phẩm bán sản phẩm phần mềm, năng lực được đánh giá sẽ là khả năng xây dựng và vận hành phần mềm
Nếu đó là một mảng kinh doanh khác có một phần phần mềm hoặc được phần mềm hỗ trợ, năng lực được đánh giá sẽ là khả năng bàn giao trong phạm vi ngân sách, nhưng khó trở thành nhân vật chính trên sân khấu
Điều thú vị là cách phân loại này khớp khá tốt với ba nhóm mà tác giả nói đến: tư vấn tương ứng với bán hàng/marketing, sản phẩm tương ứng với nghiên cứu & phát triển, còn phần còn lại tương ứng với bảo trì
Khi là kỹ sư cấp cao ở một startup phần mềm, tôi được đối xử như ngôi sao, có quyền chọn cổ phiếu và một văn hóa văn phòng đúng như mong đợi; còn khi là tư vấn viên cấp cao ở một công ty tư vấn IT, tôi gần như phải là một nhân viên bán hàng biết làm PowerPoint đẹp
Tôi phải tối đa hóa số giờ có thể tính phí, và không được kết thúc dự án quá nhanh hay bằng lượng code tối thiểu
Chắc bạn cũng đoán được đại khái hiện giờ tôi đang ở đâu
Đây không phải thứ có thể mua như một sản phẩm đóng hộp; thường là nhiều hệ thống được tùy biến nặng nề rồi ép nối với nhau, và nhiều khi ban đầu chúng không được thiết kế để hoạt động cùng nhau
Mỗi công ty cũng có cách làm khác nhau
Tôi thích công việc này và có thế mạnh trong việc suy nghĩ về toàn bộ hệ thống trải dài qua nhiều phòng ban
Để vượt qua vấn đề, cũng cần hiểu biết về chính trị nội bộ, và chính ở điểm đó giá trị của tôi xuất hiện
Là một lập trình viên thì tôi cũng ổn, nhưng không đạt đến mức chuyên môn của những người lấy lập trình làm sự nghiệp
Trong hai trường hợp còn lại, bạn trở thành một chi phí cần được giảm thiểu hoặc loại bỏ
Chỉ khi bạn tạo ra sản phẩm cốt lõi của công ty thì bạn mới trở thành tài sản mang lại doanh thu
Tôi cũng từng mắc sai lầm đó, bị gọi vào họp và được hỏi “Tình hình thế nào rồi”, rồi ngay sau đó bị nói “Đừng nói chi tiết”
Làm việc ở nhóm số 3 nghĩa là tạo ra những giải pháp nhàm chán và dễ bị lãng quên, và bạn có thể tạo ra một giải pháp tuy hợp lý về mặt kỹ thuật nhưng lại là hành động tự sát về mặt chính trị
Ví dụ, nếu làm ở nhà sản xuất phần cứng, bạn không những không phải nhân vật chính mà còn khó được tôn trọng
Nhân sự phần mềm bị xem là chi phí, và là khoản chi phí mà nếu có thể thì họ không muốn trả
Dù bàn giao đúng hạn và thấp hơn ngân sách, bạn cũng không nổi bật lên mà ngược lại còn biến mất khỏi sự chú ý
Khó hiểu khi trong văn hóa công nghệ hiện đại, người ta nói bảo trì luôn nằm cuối danh sách, bị cắt ngân sách và không nhận được ngân sách đúng mức
Suốt 20 năm qua, qua nhiều công ty, tôi vẫn nghe điều đó nhưng hầu như chưa bao giờ đồng ý
Công ty đúng là muốn các tính năng mới để đưa ra thị trường, nhưng đồng thời cũng muốn dịch vụ hoạt động đúng
Ngay cả khi sa thải hoặc đóng băng tuyển dụng, tôi cũng thấy các tổ chức mang tính SRE trụ vững hơn các tổ chức nghiên cứu phát triển
Tuy vậy, ở một công ty, văn hóa đã chuyển sang liên tục tạo ra cái mới và không tưởng thưởng cho việc duy trì cái cũ, kéo theo việc liên tục di chuyển công cụ nội bộ, liên tục khai tử, và các đợt migration dang dở
Khi những người tạo ra sản phẩm được thăng chức rồi rời sang hạng mục công việc tiếp theo trong portfolio, những thứ từng mới mẻ và bóng bẩy cũng sớm bị bỏ mặc, rồi một đội mới lại tạo ra thứ thay thế
Trong 6 năm, một công cụ nội bộ đã bị thay thế bằng công cụ nội bộ mới tới bốn lần, và người dùng bị phân tán trên cả bốn công cụ
Có thể gọi đó đơn giản là thất bại trong thực thi, nhưng một văn hóa nói rằng doanh nghiệp không coi bảo trì là có giá trị thì rất độc hại và dẫn đến tự hủy
Giả sử mỗi lần lập trình viên thêm tính năng mới, họ dùng 1.000 đô la dung lượng đĩa và tạo ra 10.000 đô la doanh thu mới
Quản trị viên hệ thống mua một file server lớn, và giả sử một server mới có giá 500.000 đô la
Trong một tổ chức quan liêu, quản trị viên hệ thống sẽ tính phí nội bộ dung lượng đĩa cho lập trình viên, và khi cần file server mới thì tiền đã sẵn sàng
Trong một tổ chức vận hành tốt và ít quan liêu hơn, ban lãnh đạo hiểu rằng hóa đơn 500.000 đô la giúp thực hiện các dự án mang về 5 triệu đô la, nên sẵn lòng chi
Trong một tổ chức vận hành kém, ban lãnh đạo khó chịu vì 500.000 đô la là đắt và không gắn với một dự án cụ thể; quản trị viên hệ thống lần sau bảo người cần 1.000 đô la dung lượng đĩa phải trả 500.000 đô la, và người kia từ chối
Cuối cùng quản trị viên hệ thống phải từ chối yêu cầu và thuyết phục lập trình viên giảm thời gian lưu log từ 7 ngày xuống 3 ngày, rồi chẳng mấy chốc ban lãnh đạo nghe được phản hồi xấu về quản trị viên hệ thống
Môi trường bạn mô tả lại trông giống thực tế nơi doanh nghiệp không coi bảo trì là có giá trị
Câu “bảo trì nằm cuối danh sách” gần với việc mô tả những gì đang xảy ra hơn là một khuyến nghị nên làm vậy
Người viết không phân tích vì sao lại như thế, hay cách tiếp cận khác có tốt hơn cho doanh nghiệp không, nhưng nếu coi việc hệ thống hoạt động đúng và chất lượng cao là có giá trị thì đương nhiên ta sẽ mong kết quả khác
Tuy nhiên, nếu chỉ rất ít công ty hành động như vậy, có khả năng tồn tại lý do liên quan đến việc căn chỉnh lợi ích
Vì bạn không thể bán bảo trì cho khách hàng; thứ có thể bán là tính năng
Từ góc nhìn lập trình viên, bảo trì cũng là việc muốn tránh
Khó đưa bảo trì vào CV như một mục nổi bật, và ai cũng muốn thấy thành tích, dự án đã ra mắt, cùng công nghệ hiện đại
Việc tiếp tục vận hành dịch vụ ở mức khách hàng yêu cầu là ưu tiên cao với mọi người
Không công ty nào muốn cắt SRE đến mức khách hàng rời đi vì sự cố
Nhưng SRE gần với vận hành trong các công ty truyền thống hơn, tức một chức năng không thể tránh nếu muốn cung cấp dịch vụ, và khác với loại bảo trì có thể trì hoãn càng lâu càng tốt
Từ góc nhìn này, bảo trì là những việc như giảm nợ kỹ thuật, cải thiện công cụ nội bộ, rút ngắn vòng lặp thử nghiệm, và tôi nghĩ các việc này thường bị đánh giá thấp so với tác động của chúng lên sản phẩm
Bài viết nói về vế sau, và nói rằng rơi vào nhóm số 3 là tự sát sự nghiệp
Nếu bạn không thuộc kiểu người “thăng chức hoặc bị đào thải”, cũng có thể cân nhắc dành thời gian ở nhóm số 3
Tất nhiên, phần mềm trở nên cũ ngay khi được sử dụng, nên ngay cả những người nghĩ mình ở nhóm số 2 thực ra có thể đang dành phần lớn thời gian ở nhóm số 3 và chỉ một phần rất nhỏ cho nhóm số 2
Dù vậy, ngân sách được phân bổ mỗi năm một lần, nhiều lắm là vài lần, nên nếu vào thời điểm đó bạn ở nơi được xếp vào nhóm số 2 thì bạn vẫn ở vị thế tốt hơn
“Bán hàng/marketing” và “nghiên cứu phát triển” là các phân loại có thể thấy trong báo cáo thường niên của công ty, nhưng bảo trì thì không xuất hiện theo cách đó
Nên đọc thử báo cáo tài chính của công ty
Bạn sẽ thấy các khoản như “giá vốn hàng bán” hay COGS, “chi phí quản lý chung”, các chi phí một lần như M&A; mỗi khoản có động lực khác nhau và cũng vận hành khác nhau tùy công ty
Hiểu cấu trúc kinh doanh của ngành mình cũng rất quan trọng
Ngay trong luồng thảo luận này cũng có nhiều trường hợp đánh giá rằng một công ty “không coi trọng” kỹ nghệ phần mềm, nhưng thật ngây thơ khi so sánh một công ty mạng xã hội có biên lợi nhuận gộp 70% với công ty ô tô hoặc hàng không ở mức 15–20%
Việc một ngành có thể tuyển nhiều kỹ sư hơn, trả lương cao hơn, cung cấp nhiều quà tặng và phúc lợi hơn là điều hiển nhiên
Ngay trong cùng một công ty, một số dòng sản phẩm và chức năng nhận được đầu tư dài hạn, còn một số dòng sản phẩm có biên lợi nhuận cao hơn những dòng khác
Số tiền có thể chi cho sản phẩm phần mềm khác nhau rất lớn tùy theo ngân sách
Kỹ sư khi nghĩ về công việc của mình cũng cần nhìn vào tài chính của công ty
Công ty không phải tổ chức từ thiện hay nhà thờ, mà là một doanh nghiệp phải cân bằng dòng tiền, doanh thu, chiến lược dài hạn và chi phí phát triển sản phẩm
Bài này cũng hay, nhưng bài của patio11 cũng phân tích rất tốt theo trung tâm chi phí và trung tâm lợi nhuận
Bài đó giải thích thuyết phục vì sao bạn nên gắn mình với trung tâm lợi nhuận, và nếu chưa đọc thì còn nhiều nội dung hay khác
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
Quy tắc số 2 là trong trung tâm lợi nhuận đó, đảm nhận vai trò có liên hệ đáng tin cậy với khả năng sinh lời bền vững
Không nhất thiết phải trực tiếp kiếm tiền, nhưng phải rõ rằng nếu tôi ngừng làm việc thì tiền bạc sẽ bị ảnh hưởng trực tiếp
Hơi lạc đề một chút, nhưng tôi đã đọc Serverless Handbook mà Swizec viết vài năm trước và thấy rất hữu ích, đồng thời từ lâu vẫn thích newsletter email sâu sắc và giàu suy nghĩ của anh ấy
Anh ấy đứng vững trong trường phái “học bằng cách làm / học công khai”, và rất giỏi chia sẻ quá trình học của mình
Rất khuyến nghị theo dõi hoặc đăng ký
Về mặt lịch sử, kỹ thuật phần mềm từng là một phần của chức năng IT, và IT bắt nguồn từ kế toán
Trước khi máy móc làm việc đó, “computer” đúng nghĩa là công việc của một người nào đó
Ngay cả ngày nay, trong nhiều doanh nghiệp, kế toán vẫn là động lực chính và nguồn ngân sách chủ yếu cho phần mềm
Trên thực tế có bốn nhóm ngân sách
Nhóm 1 là nghiên cứu và phát triển, thường được áp dụng cách xử lý thuế đặc biệt và tín dụng thuế
Nhóm 2 là bán hàng/marketing, bao gồm các kỹ sư presales và đôi khi cả công việc triển khai
Nhóm 3 là bảo trì, tức các lập trình viên sửa lỗi và làm những việc liên quan đến mã không thuộc nghiên cứu và phát triển, thường không được xử lý thuế đặc biệt hay khấu trừ
Nhóm 4 là vận hành trong các dịch vụ hosting, PaaS, SaaS, thường cũng bao gồm một phần lương kỹ sư phần mềm
Việc hiểu tác động về thuế tùy theo tiền đến từ ngân sách nào và bạn làm công việc gì là rất quan trọng, và càng mở rộng quy mô thì càng phức tạp hơn nhiều
Tôi cho rằng mô hình trung tâm lợi nhuận so với trung tâm chi phí tốt hơn
Lý tưởng nhất là mọi bộ phận đều chịu trách nhiệm cả về doanh thu lẫn chi phí
Nếu không đo lường được thì đó là vấn đề của KPI
KPI có thể bị đặt lệch theo hướng tập trung vào chi phí, nhưng điều đó không có nghĩa bản thân bộ phận đó trở thành trung tâm chi phí
Tuy nhiên tôi thích việc bổ sung phân biệt nghiên cứu và phát triển
Tôi cho rằng các đội thiên về bảo trì cũng phải làm nghiên cứu và phát triển để giảm chi phí bảo trì, giống như một đội sales giỏi làm nghiên cứu và phát triển để tăng lợi nhuận bán hàng
Chúng mang lại những góc nhìn khác nhau và có thể bổ sung cho nhau
Trong các công ty tôi từng làm, chưa nơi nào mà lương kỹ sư tăng trưởng được lấy từ ngân sách marketing
Cũng không có thứ gọi riêng là “ngân sách bảo trì”; tất cả đơn giản đều là nghiên cứu và phát triển/kỹ thuật
Kỳ vọng có thể rất khác nhau tùy theo đội hoặc vai trò, nhưng đó không phải là vấn đề ngân sách mà phụ thuộc vào cách công ty theo dõi mục tiêu
Hoặc là đang kiếm tiền ngay lúc này, hoặc tạo ra giá trị dài hạn, hoặc đang từ từ chìm xuống trong sản phẩm hiện có; một trong ba trường hợp đó