Software Engineer

Không chỉ nhận task rồi code

Có những môi trường mà engineer nhận requirement, chia task, viết code, mở pull request rồi chuyển sang việc tiếp theo.

Cách làm ở Công Ty S được mô tả khá khác.

Engineer không chỉ là người biến một solution đã được quyết định thành code. Họ có thể tham gia khá sớm vào quá trình xác định vấn đề, trao đổi với product, design hoặc các team liên quan, cân nhắc hướng giải quyết và theo dõi xem thứ mình vừa ship có thực sự tạo ra tác động hay không.

Điều đó khiến role của engineer rộng hơn khá nhiều.

Bạn không chỉ cần biết “build thế nào?”

Mà còn phải hiểu:

“Mình đang build cái gì, cho ai và tại sao?”

Đây cũng là một trong những điểm tạo nên trải nghiệm khá đặc trưng ở Công Ty S.

Engineer có ownership khá sâu

Ở team được chia sẻ trong trải nghiệm này, engineer thường đóng vai trò DRI — người chịu trách nhiệm chính cho một vấn đề hoặc project.

Điều đó không có nghĩa engineer làm mọi thứ một mình.

Product vẫn có mặt.

Design vẫn có mặt.

Các team khác vẫn tham gia.

Nhưng engineer có thể là người đứng ở giữa để kéo các bên lại với nhau và biến một ý tưởng còn khá mơ hồ thành một thứ có thể ship được.

Một project có thể bắt đầu bằng một Project Brief:

• Vấn đề đang cần giải quyết là gì?
• Context hiện tại ra sao?
• Solution dự kiến là gì?
• Cần làm những gì?
• Đo hiệu quả bằng metric nào?

Việc viết những thứ này ra trước khi code có một tác dụng khá lớn.

Nó buộc người làm project phải hiểu vấn đề trước khi nhảy vào implementation.

Và quan trọng hơn, những người khác trong team có thể đọc, đặt câu hỏi hoặc phản biện từ khá sớm.

Thay vì đến lúc code gần xong mới phát hiện cả team đang hiểu vấn đề theo hai cách khác nhau, disagreement được đưa lên bàn từ đầu.

“Learning in public” không chỉ là một khẩu hiệu

Một điểm khá thú vị là việc chia sẻ suy nghĩ trong team được đưa vào chính workflow.

Khi engineer đang làm việc với product, design, legal hoặc những team khác, các câu hỏi và quyết định quan trọng được viết lại để những người còn lại có thể theo dõi.

Điều này tạo ra một kiểu transparency khá khác.

Bạn không cần phải tham gia mọi cuộc họp để biết project đang đi đến đâu.

Một phần context đã nằm trong document.

Bạn có thể đọc.

Đặt câu hỏi.

Góp ý.

Hoặc phát hiện một vấn đề mà người đang trực tiếp làm project chưa nhìn thấy.

Team cũng dành thời gian cho mentoring, pairing và teaching. Có những buổi meeting có phần chia sẻ kiến thức, những phiên pairing ngắn hoặc cùng nhau chỉnh sửa một document theo thời gian thực.

Nó tạo ra cảm giác rằng knowledge không chỉ nằm trong đầu của người đang làm task.

Một project được xem là “done” không chỉ khi code đã merge

Một chi tiết khá đặc biệt trong cách team vận hành là Shipped email.

Khi project hoàn thành, team gửi một email tóm tắt:

Vấn đề là gì.

Tại sao phải giải quyết.

Solution được triển khai như thế nào.

Impact ra sao.

Và tiếp theo còn gì cần làm.

Điều thú vị là đôi khi email này được viết ngay từ đầu project — chưa gửi, nhưng được dùng như một cách để xác định project thực sự đang cố đạt được điều gì.

Cách làm này khá thông minh ở một điểm:

Nó kéo team ra khỏi suy nghĩ “chúng ta cần build feature X”.

Thay vào đó là:

“Nếu project này thành công, chúng ta muốn thay đổi điều gì?”

Hai cách diễn đạt nghe gần giống nhau nhưng dẫn tới hai cách làm việc rất khác.

Customer feedback không nằm riêng ở team Product

Một trong những điểm nổi bật nhất là mức độ gần với người dùng.

Ở cấp độ công ty, customer có thể xuất hiện trực tiếp trong những buổi all-hands để chia sẻ trải nghiệm của họ.

Ở team, engineer và các thành viên khác được khuyến khích tham gia customer