Đội phẫu thuật của Fred Brooks có phải xử lý hiệu quả yếu tố xe buýt không?

Nhóm 4 nhà phát triển có kinh nghiệm của tôi làm việc trên một ứng dụng Windows mô-đun lớn (khoảng 200 KLoC). Tôi đã tập trung vào codebase cốt lõi từ khi bắt đầu dự án (3 năm trước) và dần dần chuyển sang vị trí nhà phát triển bán dẫn, mặc dù tôi không phải là người quản lý nhóm.

Lặp lại hiện tại của chúng tôi là một làm mới UI ưu tiên cao được yêu cầu bởi quản lý cấp trên, liên quan đến khoảng 15 thay đổi đối với cơ sở mã cơ sở. Khi được người quản lý hỏi, tôi ước tính rằng mỗi trong số 15 thay đổi sẽ mất ít hơn bốn giờ để tôi hoàn thành , tổng cộng chưa đến 7 ngày làm việc. Sau đó tôi tình nguyện thực hiện công việc. Thay vào đó, người quản lý quyết định chia đều tất cả 15 nhiệm vụ cho cả bốn nhà phát triển.

Trong ba ngày kể từ khi chúng tôi bắt đầu làm việc, tôi đã quan sát thấy hai điều:

1. Các thành viên khác trong nhóm thiếu kinh nghiệm đã hoàn thành khoảng 1 hoặc ít hơn mỗi nhiệm vụ.

2. Luật của Brook trong hành động: Tôi đã dành khoảng một nửa thời gian của mình để cung cấp hỗ trợ (cố gắng hướng dẫn họ sử dụng các thành phần). Kết quả là tôi chỉ tự mình hoàn thành 2 nhiệm vụ, thay vì 5 hoặc 6 dự kiến.

Tôi đã tiếp cận người quản lý của mình với sự lo lắng rằng chúng tôi đã chạy trễ và một lần nữa đề nghị tôi hoàn thành các nhiệm vụ còn lại. Yêu cầu của tôi đã bị từ chối và các lý do đã nêu để chia đều tải là gấp đôi:

1. Hạn chế yếu tố xe tải / xe buýt - tăng cường các nhà phát triển khác về các kỹ năng này ngay bây giờ, để trong tương lai, bất kỳ công việc nào cũng có thể được trao cho bất kỳ ai, không chỉ riêng tôi.
2. Để loại bỏ "nút cổ chai" (tôi) và hoàn thành công việc nhanh hơn.

Để rõ ràng, tôi không có vấn đề gì với: a) đầu tư thời gian giảng dạy, b) mọi người chạm vào mã của tôi hoặc c) bảo mật công việc. Trên thực tế, tôi thường xuyên đề xuất với trưởng nhóm rằng tôi đào tạo các nhà phát triển khác về các khía cạnh nhất định của cơ sở mã cơ bản để giảm rủi ro.

Trong lần lặp này, chúng tôi cũng có một bộ lớn các bản sửa lỗi ưu tiên cao được nhắm mục tiêu, vì vậy có vẻ như sẽ có nhiều tiến bộ hơn nếu khối lượng công việc được phân phối lại.

Trong Huyền thoại-Tháng đàn ông, Brooks 'gợi ý một " Nhóm phẫu thuật " trong đó mỗi đội bao gồm một người lãnh đạo + phụ (người quản lý và tôi) và một số vai trò nhỏ. Tôi cảm thấy như thể chúng tôi tự nhiên rơi vào tổ chức này, nhưng người quản lý của tôi đang làm việc chống lại nó. Tôi cảm thấy rằng yếu tố xe buýt đã được quan tâm (người quản lý thành thạo mã lõi) và nút cổ chai không thực sự tồn tại (liên quan đến nhiều nhà phát triển sẽ không khiến công việc diễn ra nhanh hơn). Tôi nghĩ rằng về vấn đề này, một đội phẫu thuật là một điều tốt.

Đây là những cảm xúc của tôi, nhưng tôi không phải là người quản lý có kinh nghiệm, chúng tôi cũng không phải đối phó với yếu tố xe buýt (gõ gỗ). Là Brooks phải không? Bạn đã từng làm việc trong một "Đội phẫu thuật" nơi yếu tố xe buýt xuất hiện chưa? Có kỹ thuật tốt hơn để quản lý phân phối chuyên môn?

Câu hỏi tương tự:

• Làm thế nào để tăng yếu tố xe buýt và chuyên cùng một lúc?
• /software/103718/always-keep-2-people-expert-on-any-one-chunk-of-code

Trên thực tế, tôi sẽ tranh luận rằng bạn đang theo mô hình "đội phẫu thuật". May mắn!

Một phần của mô hình nói trên là các thành viên nhóm thấp hơn có vai trò trợ lý. Khi nhóm nghiên cứu không phẫu thuật tim, thì việc di chuyển chậm hơn và cho họ cơ hội thực hành một số kỹ năng của họ hoặc rèn luyện trách nhiệm.

Công việc của bác sĩ phẫu thuật là kiểm tra và quản lý nhóm của họ bằng cách tìm kiếm những điểm yếu và giải quyết chúng, cũng như là nhà phát triển hàng đầu. Bạn không thể có một bác sĩ phẫu thuật (quản lý doanh nghiệp) làm điều này, bởi vì họ không hiểu các kỹ năng cần thiết, giống như một người học việc cho một nghệ nhân bậc thầy.

Vì vậy, người quản lý đang tận dụng cơ hội này để làm việc trên một trong những mục tiêu khác của mình. Nếu trong quá trình của nó, một số lỗ hổng được tiết lộ trong đội, anh ta có thể giải quyết nó trước khi nó trở thành một vấn đề. Nói, bằng cách thuê một nhà phát triển khác.

Hoặc, các đàn em có thể phạm sai lầm. Đây là thời điểm hoàn hảo để họ làm như vậy, vì họ có ai đó dõi theo trên vai họ. Oscar Wilde nói

Kinh nghiệm chỉ đơn giản là cái tên chúng ta đưa ra những sai lầm của mình.

Nếu những hậu bối không bao giờ có cơ hội để phạm sai lầm, sau đó họ sẽ không bao giờ được cải thiện. Nó sẽ không cướp đi đội ngũ các nhà phát triển có kinh nghiệm trong tương lai của bạn, nhưng theo một nghĩa nào đó, sẽ cướp đi cơ hội mà họ nên có.

Công ty chúng tôi đã từng làm việc như bạn đang đề xuất. Chúng tôi chỉ có hai người hiểu một phần quan trọng của mã. Bất cứ khi nào một nhiệm vụ xuất hiện trong phần mã đó, thay vì mất vài tuần để giúp người khác tăng tốc, nhiệm vụ sẽ được giao cho họ vì họ có thể hoàn thành nó trong vài ngày. Điều này thực sự làm việc khá tốt trong một thời gian.

Điều xảy ra cuối cùng là đĩa của họ trở nên đầy đến mức mặc dù họ có thể hoàn thành một nhiệm vụ trong 2 ngày, nhưng sẽ mất vài tuần để chuyển lên đầu danh sách của họ. Các nhà quản lý sẽ có những trận chiến bằng lời nói khốc liệt về nhiệm vụ cấp bách hơn. Nhiệm vụ phụ thuộc khẩn cấp sẽ nằm hoàn tác.

Cuối cùng, các nhà quản lý đã phát ốm vì chờ đợi và bắt đầu đào tạo đội ngũ của riêng họ. Vâng, nó đã chậm hơn rất nhiều trong một thời gian, nhưng bây giờ thông lượng của chúng tôi tốt hơn nhiều.

Bây giờ bạn có thể đang ở giai đoạn đầu tiên, nơi bạn có thể xử lý công việc, nhưng bạn không có cách nào để dự đoán khi nào bạn sẽ chuyển sang giai đoạn thứ hai. Đây là một gợi ý: nó luôn xảy ra vào thời điểm bất tiện nhất có thể. Người quản lý của bạn có quyền thực hiện cú đánh khi bạn vẫn còn một số phòng thở.

Vâng, thật bực bội khi chứng kiến ​​ai đó đấu tranh với thứ gì đó bạn có thể làm nhanh hơn và dễ dàng hơn cho chính mình. Hãy thử làm cha mẹ một đứa trẻ hai tuổi. Bạn làm điều đó bởi vì nó giúp cả nhóm cải thiện. Đó là công việc của người quản lý của bạn để lo lắng về lịch trình. Nếu bạn lo lắng về các lỗi ưu tiên cao chưa hoàn tác, hãy thử thách bản thân xem bạn có thể sửa chúng nhanh như thế nào.

Bạn có thể không phải là một nút cổ chai bây giờ, nhưng cuối cùng bạn sẽ làm được nếu bạn tiếp tục tự mình làm tất cả công việc. Người quản lý của bạn nhận ra rằng điều đó đủ quan trọng để bạn học cách ủy thác để mạo hiểm rằng dự án của bạn bị trễ - hãy tin tưởng anh ta. Một khi bạn học cách buông tay, đàn em của bạn sẽ bắt đầu học và sản xuất nhiều hơn nữa dưới sự hướng dẫn của bạn.

Bạn đang áp dụng một ràng buộc có thể không có mặt hoặc có ý nghĩa đối với mức độ bạn nghĩ nó là. Cụ thể, bạn lo lắng về thời gian cho đến khi hoàn thành. Mặt khác, người quản lý của bạn không tỏ ra lo ngại bởi những hạn chế về thời gian.

Nếu bạn dành thời gian giao hàng cho câu hỏi của mình, bạn sẽ nhanh chóng bắt đầu tự hỏi tại sao bạn lại đặt câu hỏi ngay từ đầu.

Điều đó không có nghĩa là thời gian luôn có sẵn và bạn đã nói rằng đây là một yêu cầu ưu tiên cao từ quản lý cấp trên. Nhưng bạn không bí mật với tất cả các cuộc trò chuyện mà sếp của bạn đã có với họ. Anh ta có thể đã thương lượng thêm thời gian để bạn dành thời gian đó để đào tạo các thành viên khác trong đội.

Và trong khi bạn cảm thấy yếu tố xe buýt đã được giải quyết, sếp của bạn có thể đang tìm kiếm yêu cầu tiếp theo trong dòng không thể dễ dàng phù hợp với 7 ngày làm việc của một trong những nhà phát triển ngôi sao của anh ấy. An toàn hơn nhiều khi đào tạo đội ngũ trên một vòng lặp nhỏ hơn trong đó mức độ rủi ro khách quan nhỏ hơn nhiều.

Tôi đã là một nút cổ chai quan trọng trước đây; và thành thật mà nói, nó không phải là một nơi dễ chịu. Trong trường hợp của tôi, VP của CNTT và tôi đã nói chuyện và chúng tôi đã đưa ra một kế hoạch để khắc phục vấn đề này vĩnh viễn. Nó đau, nhưng nó đau ít hơn nhiều so với việc tôi bị xe tải chở đi.

Thật dễ dàng để đi vào suy nghĩ của tất cả mọi thứ cần phải bị loại ra càng nhanh càng tốt. Một nhà quản lý giỏi phát hiện ra những cơ hội hiếm có trong đó một chút chậm trễ (đối với đào tạo chéo / giáo dục) có thể trả cổ tức đáng kể sau này.