#9 Tại sao mình luôn ưu tiên fix bug cho team khác trước cả việc của mình?

Là một developer, công việc của mình hàng ngày chính là tiếp nhận, xử lý các yêu cầu, tính năng, lỗi mà bên trên yêu cầu hoặc được cảnh báo bởi Team khác.

Suy nghĩ của mình luôn là: việc của dev có thể chậm trễ một chút, nhưng việc gỡ lỗi, sửa lỗi cho team khác, để họ không bị block quá lâu, giúp tăng trải nghiệm khách hàng nên làm nhanh nhất có thể, ưu tiên lên hàng đầu.

Tại sao lại vậy

Bản thân mình khi đóng vai trò là khách hàng cũng vậy.

Hiện tại, mình là khách hàng của một công ti bảo hiểm nhà ở, mình gọi điện lên để yêu cầu giấy chứng nhận cho hợp đồng bảo hiểm vì hệ thống đang lỗi, nhưng mấy ngày sau họ mới gửi cho mình trong khi mình đang cần gấp, làm mình điên không chịu được, chỉ muốn đổi công ti bảo hiểm khác vì trải nghiệm quá tệ hại.

Nhưng nếu họ gửi cho mình thứ mà mình muốn ngay lập tức, mình sẽ rất hài lòng và không ngại đề xuất cho bạn bè của mình một khi họ có nhu cầu mua bảo hiểm nhà.

Theo mình nghĩ, team dev trong công ti đóng vai trò support nhiều hơn là trực tiếp tạo ra lợi nhuận.

Nhìn vào lịch sử của con người, khi chưa có công nghệ, họ vẫn buôn bán, trao đổi hàng hoá, vẫn có những đế chế ngàn tỷ đấy thôi. Không nên tự thần thánh hoá bản thân, nghĩ mình quan trọng, thay vì đó, làm việc, kết hợp với team khác cùng nhau tạo ra giá trị thì tốt hơn.

Rõ ràng với mình, những người cần được support tốt nhất phải là những người tìm kiếm khách hàng và tiếp xúc với khách hàng, hoặc liên quan tới khách hàng (như làm báo giá) mang lại trực tiếp lợi nhuận cho tổ chức.

Hệ thống đã ổn định, bạn đang dev một tính năng mới chưa từng có, có một yêu cầu lỗi từ team khác, bạn không thể nói:

Ê, nhà bao việc, không rảnh nhé, nào làm xong thì nhắn 🙃

Theo mình, nên gác lại những thứ không ưu tiên, xem xét độ ưu tiên của các vấn đề hiện tại, nếu thực sự ảnh hưởng tới trải nghiệm của khách hàng hoặc ảnh hưởng tới lợi nhuận của công ti thì nên ưu tiên trước.

Rõ ràng nếu khách hàng hài lòng, trải nghiệm tuyệt vời, mang lại tiền và danh tiếng cho tổ chức, cả hệ thống đều có lợi, kể cả bản thân mình.

Có người nói:

Không thể làm nhiều việc cùng một lúc được, người chứ có phải cái máy đâu 🥺

Không hề nhé, việc đó chỉ xảy ra khi bạn cùng lúc làm nhiều dự án lớn cùng 1 lúc, còn khi hệ thống đã ổn định, thì đó chỉ là những bản vá, sửa lỗi nhỏ mà thôi.

Còn nếu impact lớn, thì nên gác lại việc của bạn để tập trung vào gỡ lỗi, nếu không thiệt hại tài chính cho công ti là không hề nhỏ.

Lợi thế của bạn

Bạn có muôn vàn lợi thế khi là một developer, so với các anh em khác trong lĩnh vực IT như: Devops, Architectes, SREs.

Tất nhiên mỗi cái đều có cái hay nhưng với mình thì developer là có vai trò thú vị nhất. Khi mình là developer:

• Mình có thể làm việc với tất cả các Team khác, gần như mỗi yêu cầu đều phải qua Team dev hết, haha. Dev vừa đóng vai trò trung tâm, vừa như là trạm chung chuyển các yêu cầu kỹ thuật hoặc nghiệp vụ.

• Vừa nắm được nghiệp vụ (business) của toàn bộ tổ chức, vừa nắm được hệ thống IT cho cái nghiệp vụ đó như thế nào, gần như bạn biết hết từ A đến Z mọi thứ. Khi có vấn đề, dev có thể chủ động debug trước khi truyền tải thông tin cho các team khác.

• Việc switch vai trò trở nên dễ dàng hơn rất nhiều. Chán làm developer, mình có thể tìm hiểu thêm các kiến thức Devops, SA, Architectes, SREs một cách dễ dàng, vì khi đã có kiến thức nền tảng, việc học thêm một kiến thức mới không còn là đáng ngại.

  Ngược lại, nếu từ các vai trò khác mà muốn qua làm dev thì hơi vất vả xíu (không gì là không thể) nhưng mình cá là thời gian để một người đổi vai trò sang dev có thể làm việc được sẽ lâu và tốn thời gian, công sức hơn so với chiều ngược lại.

Những thứ mình làm và tư duy

• Cố gắng hiểu business càng nhiều càng tốt. Hiểu qua hỏi người khác, khi dev tính năng mới, khi fix một lỗi nào đó, dần dần hiểu biết về business sẽ nhiều lên.

  Khi mình biết business, cách mình nhìn nhận một vấn đề, cách mình làm việc xử lý vấn đề sẽ tốt hơn rất nhiều.

  Mình không cần đi hỏi thêm người khác mất thời gian vì mình biết rõ, và khi làm chủ business, mình có thể fix lỗi mà không cần lo sợ có gây ra impact ở nơi khác không, mọi thứ trong tầm kiểm soát.

• Không sợ nhiều việc, biết cách tổ chức, đánh giá khối lượng và mức độ ưu tiên của công việc.

  Làm càng nhiều thì mình biết càng nhiều, chỉ có không làm thì mới không có lỗi. Khi làm việc, chắc chắn mình sẽ nhận được một giá trị nào đó.

  Việc càng khó thì giá trị thu được sau khi xong task càng nhiều, năng lực tiến bộ càng nhanh.

• Chia sẻ kinh nghiệm nghiệp vụ hiểu biết của mình cho người khác. Đây là một cách vô cùng hiệu quả, vì mỗi lần mình làm như vậy, mình như được đọc, ghi nhớ thêm một lần nữa, rồi phải tìm cách giải thích cho người khác hiểu và cũng là giảm bớt khối lượng công việc để tập trung vào task khó hơn.

  Nhiều khi mình giải thích cho đồng nghiệp, chính mình lại nhận ra những thứ mình còn thiếu sót trong cách hiểu vấn đề.

• Không sợ thử, không sợ sai (tất nhiên sai nhỏ thôi nhé). Mỗi lần như vậy sẽ làm mình nhớ hơn những thứ mà mình làm một lần là thành công ngay.

Kết

Phát triển bản thân không phải là chuyện một sớm một chiều, chỉ có tích luỹ dần dần, học hỏi với tinh thần cầu tiến, làm việc chăm chỉ thì mới không bị bỏ lại phía sau.

Chưa chắc những gì mình suy nghĩ đều đúng nhưng nhờ nó mình thấy tiến bộ, thế là đủ rồi .

Bài viết này cũng được mình dịch sang tiếng Anh trên blog substack của mình.

Mình viết lại những điều này như một cách để ghi nhớ hành trình làm nghề của mình. Nếu bạn cũng đang làm backend, devops hoặc cloud, hy vọng những chia sẻ này có thể giúp bạn một chút gì đó. Còn nếu có chỗ nào mình hiểu chưa đúng, mình vẫn luôn sẵn sàng học thêm.