The Effective Engineer: một phép chia để FDE chọn việc khi danh sách ở chỗ khách quá dài

Phần giới thiệu sách trên Goodreads đưa ra một lời hứa táo bạo: kỹ sư giỏi nhất có thể tạo ra tác động gấp 10 lần người khác mà không làm gấp 10 số giờ. Nếu tuần này bạn có 12 yêu cầu từ khách và chỉ đủ giờ cho 4, câu hỏi đáng giá nhất là cái gì tạo ra khoảng cách ấy.

Câu trả lời của Edmond Lau trong The Effective Engineer, phát hành tháng 3/2015, gói trong một từ: đòn bẩy. Trang chính thức của sách định nghĩa đó là giá trị tạo ra trên mỗi đơn vị thời gian đầu tư, và cuốn sách dài khoảng 250 trang được dựng quanh khung ấy.

Sách viết cho kỹ sư phần mềm nói chung, nên bạn phải tự chuyển nó sang công việc FDE. Thử đặt nó vào một tuần ở chỗ khách: người gửi yêu cầu ngồi ngay cạnh bạn, ai cũng nói việc của mình gấp, và quyết định làm gì trước nằm ở bạn.

Vì sao một phép chia lại đáng cả cuốn sách?

Lau nói về ý này rất nhất quán. Trong cuộc phỏng vấn với Glitch năm 2015, ông khuyên ưu tiên những việc tạo ra tác động lớn so với lượng thời gian bỏ ra. Hai năm sau, trên podcast của Intercom, ông vẫn định nghĩa đòn bẩy theo cách đó: bạn tạo ra bao nhiêu tác động với thời gian mình bỏ vào.

Thử hình dung bạn đang ở tuần 3 của một engagement 12 tuần, triển khai hệ thống xử lý hồ sơ cho một khách hàng. Mỗi ngày có 300 hồ sơ, 30% phải sửa tay, tức 90 hồ sơ. Ba việc đang chờ, và các con số dưới đây là ước lượng giả định theo cùng một đơn vị: số giờ tiết kiệm được đến hết engagement.

Việc	Giờ bỏ ra	Giờ tiết kiệm	Đòn bẩy
A. Đổi format báo cáo cho trưởng phòng	3	0	0
B. Script kiểm tra file đầu vào hỏng hằng tuần	8	4 giờ × 9 tuần = 36	4,5
C. Sửa lỗi khiến một nửa số hồ sơ sửa tay xuất hiện	16	3 giờ × 45 ngày = 135	khoảng 8,4

Dòng C dựa trên giả định 45 hồ sơ ít đi mỗi ngày, mỗi hồ sơ mất 4 phút. Cả B lẫn C đều được tính như thể bản sửa có hiệu lực ngay từ ngày bắt đầu. Việc tốn nhiều giờ nhất lại có đòn bẩy cao nhất, trong khi việc dễ nhận lời cảm ơn nhất đứng cuối.

Con số không cần chính xác, vì nó chỉ dùng để xếp thứ tự. Nhưng hãy thử làm nó sai đi: nếu số giờ tiết kiệm của C chỉ bằng một nửa ước tính, đòn bẩy còn khoảng 4,2, thấp hơn 4,5 của B. A thì vẫn đứng cuối dù bạn ước lượng giờ bỏ ra thế nào, vì nó không tiết kiệm được giờ nào.

Thứ tự giữa B và C vì thế phụ thuộc vào giả định 45 hồ sơ và 4 phút. Trước khi cam kết 16 giờ, hãy đếm xem trong 90 hồ sơ sửa tay hôm nay có bao nhiêu ca do đúng lỗi đó gây ra, và bấm giờ vài ca.

Đòn bẩy ở chỗ khách có hạn sử dụng

Áp phép chia của Lau vào một engagement có ngày kết thúc, bạn sẽ thấy thêm một điều. Vẫn việc B đó, nếu bắt đầu ở tuần 11 thì chỉ còn 1 tuần để thu hoạch: 4 giờ tiết kiệm cho 8 giờ bỏ ra, đòn bẩy rơi xuống 0,5.

Việc C cũng tụt còn khoảng 0,9: 3 giờ × 5 ngày = 15 giờ tiết kiệm cho 16 giờ bỏ ra. Thực tế còn thấp hơn, vì 8 đến 16 giờ xây dựng ăn mất một phần chính tuần thu hoạch ấy. Cuối engagement, việc đáng làm có thể không còn là sửa lỗi mà là viết tài liệu bàn giao để đội của khách tự xử lý.

Theo hướng ngược lại, script B dùng lại được ở khách hàng kế tiếp thì mẫu số giữ nguyên còn tử số lớn thêm. Vì thế, trước khi viết một thứ gì, hãy hỏi nó sống được bao lâu sau ngày bạn rời đi.

Ba ý đáng giữ lại

Ý đầu tiên là tìm điểm khuếch đại thay vì làm nhiều hơn. Lau mô tả kỹ sư hiệu quả là người đi tìm những điểm có thể khuếch đại nỗ lực họ bỏ vào. Ở chỗ khách, trước khi nhận yêu cầu, hãy hỏi còn cách nào đạt cùng kết quả với một phần giờ không.

Ý thứ hai là một metric chung để nói “chưa”. Trên podcast của Intercom, Lau khuyên gắn ưu tiên với sứ mệnh của đội và một metric chung, để ai cũng nhắm vào cùng một con số, dù làm chuyên môn gì.

Trong ví dụ trên, metric có thể là tỷ lệ hồ sơ không cần sửa tay: việc C đưa nó từ 70% lên 85%, việc A không làm nó nhúc nhích.

Chốt metric này với khách ngay tuần đầu, vì khi đó từ chối không còn là ý kiến riêng của bạn. Tuy vậy, đừng máy móc: nếu trưởng phòng kia có tiếng nói trong ngày go-live, 3 giờ cho việc A vẫn đáng bỏ ra. Hãy xem đó là chi phí giữ quan hệ, giới hạn đúng 3 giờ, và đừng nhầm nó với việc có đòn bẩy.

Ý thứ ba là đặt việc khó vào giờ tốt nhất. Lau khuyên dành khung giờ nhiều năng lượng nhất cho những việc đòn bẩy cao mà bạn hay trì hoãn.

Việc C chính là loại đó: 16 giờ tập trung, không ai cảm ơn ngay, nên rất dễ bị những cuộc họp và tin nhắn ăn mất; hãy giữ các buổi sáng cho nó và đẩy họp với khách sang buổi chiều.

Ai nên đọc, và đọc theo thứ tự nào?

Cuốn sách hợp nhất với người bận rộn cả ngày mà đến tối vẫn không nói được mình đã thay đổi điều gì. Kỹ sư sắp chuyển từ SWE sang FDE cũng nên đọc để tập tự sắp xếp việc trước ngày đến chỗ khách.

Trang chính thức gọi đây là tài liệu bắt buộc của nhiều đội và hứa giúp sự nghiệp của bạn đi nhanh hơn, nhưng phép thử đáng tin hơn nằm ở danh sách việc của bạn.

Theo một bản tóm tắt của độc giả, phần đầu sách bàn về cách ưu tiên công việc và dự án: hãy đọc phần đó trước, chấm điểm các yêu cầu đang mở, rồi mới đi tiếp.

Mỗi chương kết bằng phần tóm tắt những thói quen làm được ngay. Hãy dùng những trang đó làm checklist đầu mỗi engagement, và mỗi lần chỉ chọn một thói quen.

Cũng đừng kỳ vọng phép chia làm hết phần việc. Nó xếp hạng được các việc bạn đã biết, còn việc xác định đúng vấn đề của khách vẫn phải đến từ discovery.

Biến nó thành câu chuyện khi đi xin việc

Tên một cuốn sách trong CV không cho thấy bạn biết chọn việc; một quyết định có số liệu thì có. Vì vậy, đừng ghi tên sách vào CV; hãy viết một dòng có đủ ba phần: việc bạn đã chọn làm, việc bạn đã gác lại, và metric đã thay đổi.

Khi đọc mô tả công việc, hãy để ý những cụm như “ambiguous priorities” hay “multiple stakeholders”, rồi chuẩn bị đúng một ví dụ theo cấu trúc bảng trên. Nếu chưa làm FDE, bạn vẫn luyện được ngay trên backlog của đội hiện tại.

Lần tới có người bên khách nhắn “việc này nhanh thôi”, bạn sẽ có một câu hỏi tốt hơn “khi nào cần”: nó tạo ra gì, trong bao nhiêu tuần còn lại?