Chuyện Team Mobile Ở SupremeTechNhững “Nguyên Tắc Ngầm” Giữ Chúng Tôi Gắn Bó

Mình không viết bài này để khoe thành tích hay nói SupremeTech “hoàn hảo”. Mình chỉ muốn kể lại những điều rất đời thường: cách team đối xử với nhau mỗi ngày, và vì sao chính những điều đó giúp tụi mình đi đường dài trong một ngành luôn đổi thay.

Hình 1. Văn hoá tạo ra hành vi, hành vi tạo ra kết quả.

Vì sao tụi mình đặt văn hoá song song cùng với công nghệ

Người ta hay nói “Muốn đi nhanh hãy đi một mình, muốn đi xa hãy đi cùng nhau”. Nhưng trong nghề Mobile, nơi công nghệ thay đổi từng giờ và deadline thì lúc nào cũng dí sát, để đi cùng nhau một chặng dài thật sự không dễ. Tụi mình nhận ra: clean code là quan trọng, nhưng clean code không giữ được con người ở lại. Thứ giữ tụi mình gắn bó là cảm giác tin tưởng, an toàn khi trao đổi, và một tiêu chuẩn chung về chất lượng.

Dưới đây là 5 “nguyên tắc ngầm” mà team Mobile ở SupremeTech luôn tâm niệm. Nghe có thể giống quy tắc, nhưng thực ra nó là thói quen – cứ lặp lại mỗi ngày, rồi thành văn hoá.

1) Không “blame”, chỉ làm rõ vấn đề (No Blame Culture)

Bug là thứ không thể tránh khỏi. Khi sự cố xảy ra – đặc biệt trên Production – câu hỏi đầu tiên của tụi mình không bao giờ là “Ai làm phần này?” mà là “Vì sao hệ thống hoặc quy trình lại để lỗi lọt qua?”. Đổ lỗi chỉ tạo ra tâm lý phòng thủ và khiến người ta ngại nói thật. Còn khi cả team cùng nhìn vào dữ liệu, cùng dựng lại timeline, và cùng tìm nguyên nhân gốc rễ, mọi thứ trở nên bình tĩnh hơn rất nhiều.

Hình 2. Cách team xử lý sự cố: ưu tiên ổn định, rồi mới tối ưu quy trình để không lặp lại.

Sau khi mọi thứ ổn định, tụi mình thường chốt lại bằng vài thứ rất cụ thể: một checklist mới cho review, một test case bị thiếu, hoặc một cảnh báo (alert) cần bổ sung. Mục tiêu là lần sau không ai phải “đứng hình” vì đúng một lỗi cũ, chỉ khác bối cảnh.

2) Thẳng thắn nhưng tôn trọng (Radical Candor)

Những buổi code review hay họp kỹ thuật ở SupremeTech đôi khi khá “nóng”. Có lúc tụi mình nói thẳng: “Logic này chưa ổn”, “Thiết kế này sẽ khó mở rộng”, hoặc “Case này chạm UX”. Nhưng điểm quan trọng là: sự thẳng thắn đó chỉ nhắm vào vấn đề kỹ thuật, không nhắm vào con người. Team coi phản biện là một cách tôn trọng – tôn trọng sản phẩm, tôn trọng người dùng, và tôn trọng công sức của nhau bằng việc không để một quyết định ‘tạm được’ thành nợ phải trả sau này.

3) Làm việc có trách nhiệm (Extreme Ownership)

Trong team Mobile, một tính năng không được gọi là Done chỉ vì đã merge. Nó chỉ thật sự xong khi chạy ổn định trên tay người dùng, không tạo crash/lag, và không kéo theo một loạt bug vặt. Tụi mình tránh tư duy “lỗi bên Backend” hay “QA chưa test kỹ”. Nếu trải nghiệm trên app không tốt, đó là vấn đề của cả team Mobile – vì người dùng không quan tâm lỗi nằm ở đâu, họ chỉ thấy app ‘khó chịu’.

Hình 3. Extreme Ownership: ôm trọn vòng đời tính năng, đặc biệt là sau khi release.

4) Không giấu nghề – chia sẻ là sức mạnh

Tụi mình quan tâm tới “bus factor” – rủi ro khi một người nắm kiến thức quan trọng rồi nghỉ hoặc bận là cả team chậm lại. Vì vậy, trong team có một thói quen rất tự nhiên: biết gì mới thì chia sẻ, giải xong bug khó thì viết lại ngắn gọn, tối ưu được gì thì demo 10-15 phút cho mọi người cùng học. Chia sẻ không làm ai “mất vị thế”; ngược lại, nó giúp cả team cùng lên trình, và giúp mỗi người bớt cảm giác phải tự bơi một mình.

5) Ưu tiên chất lượng và trải nghiệm người dùng (User-Centric)

Tụi mình là Developer nhưng cố gắng tư duy như User: animation giật, nút khó bấm, loading thêm nửa giây – đều là thứ người dùng cảm thấy ngay. Có những lúc deadline rất gấp, nhưng team vẫn cân nhắc refactor hoặc làm lại một phần, vì trải nghiệm tệ sẽ ‘ăn’ niềm tin của người dùng nhanh hơn bất kỳ bug nào. Chất lượng ở đây không chỉ là “không crash”, mà còn là mượt, rõ ràng, và nhất quán.

Hình 4. Bộ lọc ra quyết định: UX và độ ổn định luôn là câu hỏi đi trước.

Một khoảnh khắc mình thấy “văn hoá” hiện ra rõ nhất

Có một lần team làm presentation để thống nhất cách tiếp cận một phần quan trọng của app. Mình chuẩn bị khá kỹ và cũng hơi hồi hộp, vì presentation là lúc mọi điểm yếu lộ ra rất rõ. Trong lúc mình trình bày, mọi người hỏi thẳng: “Nếu mạng yếu thì sao?”, “Nếu user thao tác nhanh liên tục thì state có lệch không?”, và “Phần này có làm UX bị khựng không?”. Không ai nói kiểu “cái này sai rồi”, cũng không ai truy “ai thiết kế”. Cả team chỉ chăm chăm làm rõ rủi ro và chốt hành động: bổ sung retry/backoff, làm rõ trạng thái loading, thêm test case và cập nhật checklist review.

Kết thúc buổi đó, điều mình nhớ không phải slide đẹp hay không, mà là cảm giác: thẳng thắn vẫn có thể tử tế, và văn hoá tốt khiến cả team tự kéo chất lượng lên mà không cần ai “gồng” làm người xấu.

Lời kết

Team Mobile tại SupremeTech chắc chắn chưa hoàn hảo – tụi mình vẫn có bug, vẫn có lúc tranh luận căng, và vẫn có những đêm Slack sáng đèn vì sự cố Production. Nhưng chính những nguyên tắc ngầm này giúp tụi mình giữ được niềm tin với nhau và giữ được tiêu chuẩn về chất lượng. Với tụi mình, văn hoá không phải thứ treo trên tường; nó nằm trong từng buổi review, từng cách phản ứng khi có vấn đề, và từng quyết định ‘làm thêm một chút’ để người dùng bớt khó chịu.

Văn hoá tạo ra đội ngũ. Đội ngũ tạo ra sản phẩm tốt. Và khi những người đủ tin tưởng nhau cùng nhìn về một hướng, sản phẩm tốt sẽ là kết quả tất yếu.