Pragmatic Programmer – Topic 49: Pragmatic Teams — Team nhỏ
Có lần mình ngồi trong một buổi họp retro mà cả team im thin thít. Không ai phản đối gì, cũng không ai đồng ý gì. Ba tháng sau, dự án chậm deadline, scope phình gấp đôi, giao diện lệch hẳn so với bản thiết kế ban đầu. Không ai làm sai một cú lớn nào cả. Chỉ là mười mấy con người ngồi cạnh nhau, mỗi người giữ một mối lo riêng, và không ai nói ra.
Ảnh: Yan Krukau — Pexels
Mở đầu
Topic 49 của The Pragmatic Programmer bàn đúng chỗ này: kỹ thuật cá nhân giỏi chưa chắc thành team giỏi. Sách mở bằng chuyện một nhóm sáu lập trình viên cứng, và tác giả so việc quản lý họ với việc lùa mèo. Hình ảnh đó cũ, nhưng vẫn đúng đến mức người ta nhắc mãi, vì lập trình viên đúng là giống mèo: thông minh, ý chí mạnh, thích tự quyết.
Câu hỏi đặt ra rất thẳng: những kỹ thuật giúp một người thành lập trình viên tốt hơn liệu có dùng được cho cả team không? Tác giả trả lời "có", và lợi ích sẽ nhân lên nhiều lần nếu cả tập thể cùng hành xử theo kiểu pragmatic.
Điểm mình thích nhất là định nghĩa team. Năm mươi người không phải team, đó là một bầy. Những nhóm mà thành viên liên tục bị kéo sang việc khác, người nọ không biết người kia, cũng không phải team — chỉ là mấy người xa lạ tạm trú chung một trạm xe buýt dưới mưa. Team thật thì nhỏ, tầm dưới 10–12 người, ít thay đổi nhân sự, ai cũng hiểu tính nhau và dựa vào nhau được.
Cửa sổ vỡ và con ếch luộc
Hai chương trước để lại hai khái niệm, và khi nhìn ở góc độ tập thể chúng nghiêm trọng hơn hẳn.
Cửa sổ vỡ. Người kỹ tính nhất đặt vào một team không quan tâm chất lượng sẽ rất khó giữ lửa. Tệ hơn, nếu team còn chủ động ngăn người đó dành thời gian sửa lỗi nhỏ, thì cái mầm hư hỏng đã nằm trong cấu trúc rồi. Sách nói thẳng: chất lượng là việc của cả team, và mô hình giao hẳn trách nhiệm này cho một "quality officer" là vô nghĩa. Chất lượng được xây từ bên trong bằng đóng góp cá nhân, không phải gắn thêm vào bên ngoài.
Con ếch luộc. Một cá nhân thiếu để ý có thể bị luộc từ lúc nào không hay, cả team thì càng dễ. Người ta mặc định "chắc có ai đó đang lo rồi", hoặc "chắc lead duyệt thay đổi này rồi". Thế là scope tăng, deadline co lại, thêm tính năng, thêm môi trường mới — toàn bộ thứ không nằm trong thỏa thuận ban đầu — mà không ai chặn. Cách chống không phải từ chối thay đổi, mà là theo dõi và ý thức được nó. Sách gợi ý giữ số liệu về các yêu cầu phát sinh, để biết mình đang bị chuyển sang nồi nước nào.
Xếp lịch cho việc học, đừng để "khi nào rảnh"
Phần này là chỗ mình tâm đắc nhất. Nếu để ở dạng "khi nào có thời gian trống thì làm", chắc chắn sẽ không bao giờ làm. Bốn nhóm việc cần đưa vào lịch, ngang hàng với phát triển tính năng:
- Bảo trì hệ thống cũ — team thường gom việc này vào góc tối. Nếu team được giao thì phải làm thật, có thời gian thật.
- Soi lại và cải tiến quy trình — cải tiến liên tục chỉ xảy ra khi có người dừng lại nhìn quanh. Nhiều team bận tát nước đến mức không có thời gian bịt chỗ rò. Xếp lịch, rồi sửa.
- Thử công nghệ mới — đừng chọn framework chỉ vì "ai cũng xài" hay vì nghe ở hội nghị. Làm prototype, phân tích kết quả rồi mới quyết.
- Học và nâng kỹ năng — học cá nhân là khởi đầu tốt, nhưng nhiều kỹ năng chỉ phát huy khi lan ra cả team. Brown-bag lunch cũng được, miễn là có kế hoạch.
Mình để ý các team tách backlog thành hai đường — một cho feature, một cho việc "không phải feature" — thường ít nợ kỹ thuật hơn hẳn. Không phải vì họ giỏi hơn, mà vì công việc đó có chỗ đứng chính thức trong lịch.
Team cũng phải biết nói chuyện
Nội bộ team nói chuyện với nhau là đương nhiên. Cái dễ quên là team, với tư cách một thực thể, cũng có hiện diện trước phần còn lại của tổ chức và cần nói chuyện rõ ràng.
Team tệ thì cau có, im lặng, họp không cấu trúc, tài liệu mỗi người một kiểu. Team giỏi có cá tính riêng: người khác mong được họp với họ, tài liệu gọn gàng nhất quán, cả team nói bằng một giọng.
Cách làm trong sách nghe hơi lạ nhưng thực dụng: đặt tên cho dự án, càng kỳ quặc càng tốt, rồi dành nửa tiếng vẽ một cái logo. Dùng cái tên đó khi nói chuyện với người khác. Nghe có vẻ trẻ con, nhưng nó cho team một bản sắc để bám vào và cho tổ chức một cái mốc để nhớ.
Ảnh: Christina Morillo — Pexels
Chỗ khó khi áp dụng
Khó nhất là tính bền vững của team. Giữ một nhóm dưới 12 người, ít thay đổi nhân sự, trên thực tế thường xuyên đụng vào kế hoạch nhân sự của công ty. Team nhỏ thì hay bị rút người đi cứu việc khác, người giỏi bị kéo sang dự án mới. Chưa kể khi phải grow gấp để kịp deadline, ranh giới 12 người vỡ cái một.
Phần đặt tên và logo cũng rất dễ phản tác dụng nếu làm như một nghi thức rỗng. Đặt tên mà tài liệu vẫn mỗi người một phách, họp vẫn không có cấu trúc thì cái tên chẳng cứu được gì. Bản sắc đến từ cách làm việc nhất quán, không phải từ cái tên dễ thương.
Bài học rút ra
- Team thật là đơn vị nhỏ, ổn định, dưới 10–12 người, ai cũng biết và tin nhau. Vượt ngưỡng đó là bầy, không phải team.
- Chất lượng là trách nhiệm chung. Không giao chất lượng cho một người hay một chức danh nào.
- Giữ số liệu về yêu cầu, thay đổi scope và deadline. Không chặn thay đổi, chỉ cần biết chúng đang xảy ra.
- Việc học, bảo trì, thử công nghệ và cải tiến quy trình phải nằm trong lịch. Không xếp lịch thì không bao giờ xảy ra.
- Team cần một giọng nói thống nhất với bên ngoài: tài liệu nhất quán, họp có cấu trúc, có bản sắc riêng.
Đọc xong topic này mình nghĩ lại buổi retro im lặng kia. Vấn đề không nằm ở kỹ năng từng người, mà ở chỗ tập thể đó chưa bao giờ được xem là một thực thể có tiếng nói riêng. Vậy team của bạn hiện tại đang là một team, hay chỉ là mấy người tình cờ đứng chung một trạm xe buýt?
📋 Phụ lục thuật ngữ
- Pragmatic team — nhóm nhỏ, ổn định, các thành viên tin và phụ thuộc lẫn nhau, cùng áp dụng nguyên tắc pragmatic.
- No broken windows — không bỏ qua lỗi nhỏ, vì lỗi nhỏ không sửa sẽ kéo chất lượng đi xuống dần.
- Boiled frog — không nhận ra thay đổi dần dần của môi trường cho đến khi quá muộn.
- Knowledge portfolio — coi kiến thức như danh mục đầu tư, cần đầu tư đều và có kế hoạch.
- Brown-bag lunch — buổi chia sẻ kiến thức nội bộ không chính thức, thường vào giờ ăn trưa.
- Scope creep — phạm vi dự án phình ra ngoài thỏa thuận ban đầu mà không được theo dõi.