- Các đội ngũ kỹ sư thường chịu áp lực phải "phát hành nhiều tính năng hơn và nhanh hơn"
- Nhưng nếu triển khai quá nhiều việc cùng lúc thì năng suất lại giảm đi
- "Bí quyết để phát hành nhiều hơn thực ra là làm ít hơn" -
Less is More
Nguyên tắc cốt lõi
- Trực quan hóa mọi công việc
- Định nghĩa công việc thành các đơn vị nhỏ
- Giới hạn công việc đang thực hiện
- Phân bổ nguồn lực theo đúng năng lực chứa tải
- Thêm nữa: chừa khoảng trống dự phòng cho những điều có thể phát sinh
# Trực quan hóa mọi công việc
- Khi trực quan hóa công việc, bạn sẽ nhìn thẳng vào thực tế
- Khi mọi việc đều hiện rõ trong tầm mắt, sẽ có các lợi ích sau
- Có thể thiết lập ưu tiên rõ ràng
- Có thể dừng hoặc tạm hoãn những việc không cần thiết
- Giúp đội ngũ tập trung hoàn thành những gì đã bắt đầu
- Mục tiêu không phải là theo dõi mọi công việc mãi mãi → mà là để nắm rõ thực trạng và đưa ra quyết định tốt hơn
# Định nghĩa công việc thành các đơn vị nhỏ
- Nếu công việc quá lớn, năng lượng của cả đội sẽ bị bào mòn và tiến độ cũng không rõ ràng
- Giới hạn mỗi đơn vị công việc trong khoảng 1~2 tuần
- Lập trình viên duy trì động lực nhờ các kết quả ngắn hạn
- Có thể nhận phản hồi và điều chỉnh nhanh chóng
- Lợi ích của đơn vị công việc nhỏ
- Code review trở nên dễ hơn
- Chia sẻ kiến thức diễn ra tự nhiên hơn
- Tăng cường hợp tác giữa các thành viên
- Giảm rủi ro khi triển khai
- Giảm kích thước đơn vị công việc sẽ giúp tăng tốc → có thể giữ được đà tiến mà không bị choáng ngợp bởi các tính năng phức tạp
# Giới hạn công việc đang thực hiện
- Xử lý nhiều tính năng cùng lúc thực ra làm giảm năng suất
- Phát sinh chi phí chuyển đổi ngữ cảnh → có thể mất tới 23 phút để thích nghi với một công việc mới
- Càng có nhiều việc đang dở dang thì càng dễ phát sinh các vấn đề sau
- Chất lượng suy giảm
- Lỗi tăng lên
- Tinh thần của đội ngũ đi xuống
- Dấu hiệu quá tải ở cấp độ đội nhóm
- Mỗi lập trình viên đang xử lý hơn 4 đầu việc
- Thời gian hoàn thành kéo dài hơn dự kiến
- Số tính năng đang làm nhiều hơn số tính năng đã hoàn thành
- Dấu hiệu quá tải ở cấp độ cá nhân
- Khả năng tập trung giảm
- Thời gian phản hồi code review tăng
- Khó giải thích mức độ ưu tiên trong các cuộc họp cập nhật trạng thái
# Phân bổ nguồn lực theo đúng năng lực chứa tải
- Cách tiếp cận kiểu "một lập trình viên phụ trách một tính năng" là không hiệu quả
- Tập trung nguồn lực của cả đội vào những việc quan trọng nhất
- Tăng cường hợp tác → giải quyết vấn đề nhanh hơn
- Cải thiện chất lượng mã nguồn → thúc đẩy peer review theo thời gian thực
- Tăng tốc độ hoàn thành công việc
- Các lập trình viên có thể hiểu vấn đề sâu hơn thông qua hợp tác
- Cần khuyến khích thành quả ở cấp độ đội nhóm → tập trung vào kết quả của cả đội thay vì thành tích cá nhân
# Chừa khoảng trống dự phòng
- Vận hành ở mức công suất 100% lại có thể làm hiệu suất giảm đi
- Những việc phát sinh ngoài dự kiến là điều không thể tránh khỏi → chỉ là không biết khi nào chúng sẽ xảy ra
- Những vấn đề dễ xảy ra nếu không có khoảng trống dự phòng
- Đội ngũ phải làm việc theo kiểu phản ứng bị động
- Chất lượng suy giảm
- Đổi mới sáng tạo giảm
- Nợ kỹ thuật tăng lên
- Khi có khoảng trống dự phòng, sẽ có các lợi ích sau
- Có thể phản ứng linh hoạt trước các vấn đề bất ngờ
- Có thể giải quyết vấn đề một cách sáng tạo
- Duy trì chất lượng cao
- Duy trì nhịp độ làm việc bền vững
- Mức khoảng trống dự phòng hợp lý là khoảng 20% → có thể điều chỉnh tùy theo đặc thù của đội ngũ
Tóm tắt chiến lược cốt lõi
- Trực quan hóa công việc → để nhìn thẳng vào thực tế
- Định nghĩa công việc thành các đơn vị nhỏ → duy trì đà tiến
- Giới hạn công việc đang thực hiện → tăng khả năng tập trung
- Phân bổ nguồn lực theo đúng năng lực chứa tải → tập trung theo mức độ ưu tiên
- Chừa khoảng trống dự phòng → tăng tính linh hoạt
Kết luận
- Muốn làm được nhiều việc hơn thì cần một chiến lược làm ít hơn
- Thành quả của đội ngũ không được đo bằng việc xử lý bao nhiêu tính năng cùng lúc, mà bằng mức độ cung cấp giá trị cho khách hàng một cách hiệu quả đến đâu
- Vai trò của người lãnh đạo không phải là chất thêm việc cho đội ngũ, mà là loại bỏ bớt những việc không cần thiết
12 bình luận
Trong cuốn The Phoenix Project, từng được nhắc đến nhiều lần trên GeekNews, cũng có câu chuyện tương tự. Rằng khi tiến gần tới mức 100% công suất, thời gian phản hồi sẽ tăng theo cấp số nhân.
Ồ. Câu chuyện đó cũng có trong cuốn sách Goal!
Vì bản thân The Phoenix Project vốn là một cuốn sách được viết như phiên bản IT của The Goal.
Ôi trời........ cảm ơn bạn!!
Mình cũng cố gắng giữ 80% khối lượng công việc và chừa 20% khoảng trống, nhưng lúc nào cũng băn khoăn không biết nên lấy tiêu chí nào.. Có khi lại nghĩ hay là tính đơn giản theo thời gian nhỉ.
Vì thế nên tôi hẳn luôn dành riêng chiều thứ Sáu làm thời gian phát triển cá nhân!
Khi bị chia nhỏ thành những tác vụ như vậy, người lãnh đạo nắm bức tranh lớn sẽ có quyền hạn rất lớn. Ngược lại, các kỹ sư làm cùng lại dễ mất động lực và rơi vào cảm giác “rốt cuộc chúng ta đang đi về đâu vậy”. Đây là một nhược điểm điển hình của agile dựa trên sprint.
Có vẻ bài viết này được viết quá nhiều từ góc nhìn của người lãnh đạo, đúng như tiêu đề.
Động lực của kỹ sư cũng chịu ảnh hưởng rất lớn bởi việc người lãnh đạo đang giương ngọn cờ theo hướng nào. Có lẽ cũng cần suy nghĩ thêm về cách trình bày giá trị muốn mang đến cho khách hàng là gì, cũng như output của từng sprint và outcome của việc bàn giao là gì. Tất nhiên đây là một soft skill khó, nên cũng hiếm thấy lãnh đạo làm tốt và cũng không có nhiều bài viết hay về chủ đề này.
Tôi thực sự rất đồng cảm với bình luận này. Đã có nguy cơ xảy ra việc micromanage đối với các khía cạnh kỹ thuật. Thật sự không hề dễ dàng.
Chẳng phải là chia sẻ bức tranh lớn, rồi khi mọi người đều đã hiểu thì chia nhỏ công việc thành các tác vụ nhỏ sao??
Nếu chia thành 1-2 tuần thì có vẻ tự nhiên chỉ những người rất hạn chế mới biết được bức tranh về một tính năng. Giống như sự khác nhau giữa process và thread vậy. Vì là giới hạn phạm vi quan tâm để nâng cao năng suất mà.
Ngay cả khi có chia sẻ bức tranh đó, thì đây cũng là tiền đề rằng người ta sẽ đặt câu hỏi về bức tranh ấy; nhưng tôi cũng có vẻ đã tự nhiên mặc định rằng theo định hướng thay đổi chút ít ở mỗi lần sprint planning, người ta sẽ không thể khớp được cách đang theo dõi bức tranh lớn.
Tôi hoàn toàn đồng ý với những gì bài viết này nêu ra, đồng thời cũng đồng ý với vấn đề mà bạn đã nói đến.
Thực tế đây cũng là điểm mà tôi đang suy nghĩ.
Tuy có khác nhau ở từng squad, nhưng nếu tích cực để các thành viên trong nhóm tham gia vào sprint planning thì vấn đề bạn nói đến đã không xảy ra. Trong khi chia sẻ bối cảnh của dự án và tình hình thay đổi qua từng sprint để mọi người có thể nhận thức đầy đủ về những công việc thay đổi, tôi cũng yêu cầu thử chia nhỏ công việc một cách rất chi tiết.
Đúng như bạn nói, xét ở góc độ quản lý như theo dõi tiến độ, đo tốc độ làm việc, ứng phó với tình huống ngoài dự kiến, và chi phí cơ hội khi nội dung công việc không diễn ra như mong muốn, thì cuối cùng vẫn thấy rằng phải chia nhỏ ra thì công việc mới tiến triển tốt.
Những bài kiểu này cứ lặp đi lặp lại, nhưng lòng tham của con người là vô tận và chúng ta lại tiếp tục mắc cùng một sai lầm
Mức tải CPU 100% của máy tính không phải là trạng thái bình thường,
nhưng với khối lượng công việc của con người ở mức 100% thì lại đi đến kết luận rằng phải làm chăm chỉ hơn nữa..