Một nhóm có thể có 150 người trên đó không? NHANH CHÓNG Agile Nói Có

Nhanh nhẹn NHANH CHÓNG là cách thực hành tổ chức thú vị nhất mà tôi đã học được trong một thời gian. Hôm nay tôi chia sẻ nhanh nhẹn NHANH CHÓNG là gì và khám phá xem liệu nó có đáng để thử nghiệm hay không. TL; DR? Khá hấp dẫn, nhưng vẫn còn thử nghiệm.

NHANH CHÓNG Agile là gì?

1. NHANH CHÓNG Agile là một biến thể phần mềm linh hoạt. FAST tập trung vào việc tự tổ chức trong các nhóm rất lớn. Những đội lớn này được gọi là Tập thể. Họ có thể là một vài người, cho đến 150 người [1].

Hai lần một tuần, Tập thể gặp nhau. Tại cuộc họp:

• Các thành viên trong nhóm thể hiện và cho biết họ đã đạt được tiến bộ gì .
• Người lãnh đạo sản phẩm nhắc lại tầm nhìn và định hướng . Họ đưa ra bối cảnh về các dự án hàng đầu. Họ giới thiệu các ưu tiên mới khi công việc hoàn thành hoặc các ưu tiên thay đổi. Và thông thường, họ hiển thị các ưu tiên theo cách trực quan, trên tường hoặc tương đương ảo.
• Mọi người trong Tập thể tự tổ chức và tự chọn thành các nhóm nhỏ hơn để thực hiện công việc ưu tiên hàng đầu.

Phần thú vị nhất của FAST Agile là các nhóm tự tổ chức này, vì vậy hãy mô tả chúng chi tiết hơn một chút.

Mỗi cuộc họp, mọi người tình nguyện lãnh đạo các đội và mọi người tình nguyện tham gia vào các đội đó. Khi ai đó tình nguyện quản lý một nhóm, họ bước tới và nói: “Tôi sẽ làm việc trên [một trong những dự án hàng đầu]”. Mọi người sau đó tham gia vào các nhóm đã được tạo ra và làm việc trong khu vực đó. Quy mô nhóm tối thiểu là hai người, vì vậy bạn cần mọi người “bỏ phiếu bằng chân” để thành lập nhóm.

Các đội được thành lập làm không phải xoay quanh các ưu tiên mà sản phẩm đã đặt ra. Ví dụ: một nhóm có thể hình thành xung quanh việc cải thiện quy trình triển khai hoặc cải thiện việc giám sát đối với một số dịch vụ không ổn định.

Ngoài giờ họp hàng tuần, mọi người dành phần lớn thời gian của họ trong các nhóm tự chọn, tự tổ chức của họ. Về mặt lý thuyết, bạn có thể thay đổi nhóm hai lần một tuần. Nhưng trong thực tế, mọi người sẽ tìm ra người mà họ muốn làm việc cùng và các nhóm có xu hướng ổn định sau tháng đầu tiên hoặc lâu hơn .

Chúng vẫn đủ linh hoạt để mọi người có thể di chuyển khi nhu cầu kinh doanh thay đổi hoặc cần những người có chuyên môn trong các lĩnh vực khác nhau. Di chuyển các nhóm là một thay đổi dự kiến, nỗ lực thấp. Vì vậy, điều này có nghĩa là trong các cuộc họp Tập thể, có một mô hình mọi người tái tạo nhóm của họ, nhưng thành phần có xu hướng không thay đổi nhiều như bạn tưởng tượng.

Có rất nhiều chi tiết khác như cách xử lý lỗi và cuộc gọi. Tôi sẽ đề cập đến một số chủ đề này sau. Nhưng cốt lõi cơ bản của nhanh nhẹn NHANH CHÓNG là các nhóm tự chọn này, làm việc trong một Tập thể lớn hơn, trong các dự án. Các cuộc họp tập thể được tổ chức và tập trung vào việc đưa ra bối cảnh về nhu cầu của doanh nghiệp và truyền đạt tiến độ so với những ưu tiên đó.

Tóm tắt sự khác biệt

FAST khác nhiều so với cách mà hầu hết các tổ chức phần mềm linh hoạt đang vận hành ngày nay. Dưới đây là những khác biệt khi tôi nhìn thấy chúng:

Như bạn có thể thấy, FAST là một cách tiếp cận rất khác so với những gì mà hầu hết các công ty đang làm hiện nay.

Vì vậy, sự cân bằng là gì?

Theo tôi thấy, đây là những đánh đổi của sự nhanh nhẹn NHANH CHÓNG:

• FAST có thể cung cấp khả năng mở rộng tổ chức tốt hơn
• FAST có thể được thử nghiệm dần dần
• NHANH CHÓNG sẽ dẫn đến ít reorg hơn
• NHANH CHÓNG giúp dễ dàng đáp ứng các ưu tiên thay đổi
• NHANH CHÓNG có thể tốt hơn cho động lực nội tại và khả năng duy trì

Nhưng…

• Nhiều môi trường không tương thích với FAST
• Bạn có thể phải quản lý tự quản lý
• NHANH đòi hỏi rất nhiều công việc
• Các tài liệu FAST đầy biệt ngữ

Chúng ta sẽ lần lượt thảo luận về từng vấn đề này.

FAST có thể cung cấp khả năng mở rộng tổ chức tốt hơn

Khi bạn mở rộng quy mô tổ chức, bạn thường làm như vậy bằng cách mở rộng quy mô “theo chiều ngang”. Bạn phát triển tổ chức một nhóm tại một thời điểm. Mỗi nhóm này sở hữu một phần sản phẩm và bạn thường có một tổ chức nền tảng giúp nhóm sản phẩm hoạt động hiệu quả hơn.

Sự phức tạp của tổ chức bùng nổ khi số lượng người tăng lên. Nếu bạn có mười người trong ngành kỹ thuật, tất cả họ đều có thể giao tiếp với nhau. Một trăm người trong ngành kỹ thuật không thể nói chuyện với nhau. Và cơ sở mã sẽ không vừa với đầu của bất kỳ cá nhân nào. Vì vậy, bạn phân chia sự phức tạp này thành các nhóm và mỗi nhóm có một lĩnh vực mà họ có thể tập trung vào.

FAST rất thú vị vì nó là một nỗ lực để mở rộng quy mô tổ chức “theo chiều dọc”. Thay vì thêm nhiều nhóm hơn, FAST cố gắng tạo các nhóm lớn hơn , được gọi là Tập thể. Tập thể vẫn sở hữu mã, nhưng các nhóm tự tổ chức trong Tập thể đó thì không. Và bạn vẫn phải phân đoạn giao tiếp. Nhưng các đội năng động hơn và liên tục phát triển. Thay vì định hình lại các nhóm thông qua các tổ chức lại, đó là một phần liên tục, được mong đợi trong cách bạn vận hành.

Quy mô nhóm là một chủ đề quen thuộc đối với nhiều trưởng bộ phận kỹ thuật. Các nhóm nên lớn như thế nào? Hãy đi sâu vào chủ đề này một chút vì nó giúp chúng ta hiểu cách FAST tuyên bố mở rộng quy mô tốt hơn.

Các nhóm nên lớn như thế nào?

Khi bạn dành thời gian cho những người thuộc Phó Giám đốc Kỹ thuật, đôi khi chủ đề về quy mô nhóm kỹ thuật sẽ xuất hiện. Bạn sẽ nghe thấy các tranh luận cho các nhóm nhỏ và các tranh luận cho các nhóm lớn. Cả hai bên đều có công.

Ưu điểm của đội nhỏ

• Ít phối hợp và chi phí liên lạc trong nhóm.
• Kết quả là có thể di chuyển nhanh chóng.
• Ít luồng công việc hơn nên dễ tập trung hơn và tạo ra kết quả.
• Dễ quản lý hơn.

Ưu điểm của đội lớn

• Tổ chức phẳng hơn. Một tổ chức kỹ thuật với 150 kỹ sư trong đó sẽ có 3-4 giám đốc với các nhóm mười người. Nó sẽ có 6-8 giám đốc và 1-2 VP với các nhóm năm người. Sự nhầm lẫn trong một tổ chức đến từ đâu? Có lẽ là lãnh đạo, nên các đội lớn có thể giảm bớt sự nhầm lẫn.
• Khả năng phục hồi cao hơn. Ai đó có thể đi nghỉ và nhóm có thể tiếp tục tốt.

Vì vậy, các nhóm nhỏ là tuyệt vời trong nhóm của họ, nhưng ít lý tưởng hơn vì có quá nhiều người trong số họ, điều đó làm tăng sự phức tạp của tổ chức. Các nhóm lớn hơn tốt hơn cho sự phức tạp tổng thể của tổ chức, nhưng ít lý tưởng hơn cho hiệu suất trong mỗi nhóm.

Cách tiếp cận mà nhiều nhà lãnh đạo áp dụng là thành lập các nhóm lớn tập trung vào ít luồng công việc hơn. Điều này làm giảm độ phức tạp của nhóm nội bộ và cũng làm giảm độ phức tạp của tổ chức.

Bạn có thể xem NHANH CHÓNG như một cách tiếp cận cố gắng đạt được sự đơn giản hơn nữa về mặt tổ chức thông qua các nhóm lớn một cách lố bịch. Và nó cũng cố gắng đạt được những lợi ích của việc có các nhóm nhỏ tự lắp ráp.

Mở rộng quy mô tổ chức là công việc đầy thách thức

Phần lớn công việc tư vấn của tôi là giúp các tổ chức đối phó với quy mô. Có một số giai đoạn mở rộng quy mô thách thức mà các tổ chức gặp phải.

Rào cản đầu tiên thường ở mốc kỹ sư 15-25. Đây là lúc amip của bạn đã trở nên quá lớn và cần phải tách ra. Bạn thấy những loại vấn đề này:

• Các kênh truyền thông trở nên kém hiệu quả.
• Kỹ thuật bắt đầu gặp vấn đề về giao hàng và/hoặc chất lượng.
• Các nhà quản lý hoặc lãnh đạo cảm thấy choáng ngợp. Thêm người sẽ làm cho nó tồi tệ hơn, không tốt hơn.

Và rào cản thứ hai là khoảng 60 kỹ sư. Tại thời điểm này, bạn bắt đầu thấy nhiều vấn đề về phối hợp hơn:

• Các dự án giữa các nhóm hiếm khi thành công.
• Công việc sản phẩm lấn át các nhóm nền tảng hoặc ngược lại.
• Không có khả năng hoàn thành các sáng kiến lớn.

Tôi đã chứng kiến những người xuất sắc thất bại hết lần này đến lần khác trong việc điều hướng những thay đổi theo trình tự các bước này trong sự phức tạp của tổ chức. Linh cảm của tôi là các bước này tăng độ phức tạp tương ứng với khi bạn thêm một lớp quản lý bổ sung.

Phát triển các tổ chức kỹ thuật là một kỹ năng thực sự. Nó đòi hỏi sự hiểu biết sâu sắc về cách thức hoạt động của các tổ chức và con người. Bạn tìm hiểu về những thứ như:

• Các mô hình phối hợp để khiến các nhóm người làm việc cùng nhau.
• Các nhóm được sắp xếp theo luồng so với các nhóm được thiết kế theo chức năng.
• Cách thực hiện tổ chức lại, nơi bạn thay đổi người và viết mã khi các ưu tiên kinh doanh thay đổi.
• Làm thế nào để phân chia sản phẩm thành các lĩnh vực trách nhiệm kỹ thuật chồng chéo với đầu tư sản phẩm.
• Thiết lập các kênh liên lạc xung quanh các nhóm.
• Thiết lập các chương trình về cuộc gọi và độ tin cậy để hỗ trợ sản phẩm của bạn một cách hiệu quả.
• Thiết lập các tổ chức nền tảng và sáng kiến kinh nghiệm của nhà phát triển để chống lại sự phức tạp.
• Vân vân.

Ngay cả khi bạn có những người có chuyên môn này, nó đòi hỏi rất nhiều nỗ lực từ đội ngũ quản lý của bạn để đối phó với việc mở rộng quy mô. Vì vậy, nếu FAST có thể mở rộng quy mô tốt hơn, thì bạn sẽ mở ra nhiều tiềm năng cho nhóm quản lý của mình để tập trung vào thứ khác. Và vì các thay đổi theo thứ tự bước của bạn xảy ra ít thường xuyên hơn nên bạn có khả năng làm cho tổ chức của mình dễ quản lý hơn nhiều.

Một thử nghiệm suy nghĩ xung quanh nhanh nhẹn NHANH CHÓNG

Vì vậy, hãy tưởng tượng bạn có thể mở rộng quy mô nhóm. Thay vì các nhóm gồm năm hoặc mười người, điều gì sẽ xảy ra nếu bạn có thể có các nhóm hai mươi người hiệu quả? Hay đội sáu mươi người?

Thoạt nhìn, đây là một đề xuất lố bịch. Các nhóm lớn không hiệu quả. Ngay cả các đội mười hai người cũng là một khoảng thời gian dài. Đôi khi tôi thấy sơ yếu lý lịch của những người đã có hai mươi hoặc ba mươi người báo cáo cho họ. Phản ứng ngay lập tức của tôi là nghĩ rằng họ đã làm việc tại một công ty tồi tệ. Có nhiều báo cáo trực tiếp như vậy là một “mùi của tổ chức”.

Tiền đề trung tâm của nhanh nhẹn NHANH CHÓNG là nếu bạn thêm các nhóm tự tổ chức và tự chọn trong Tập thể lớn hơn này, thì bạn có thể mở rộng quy mô các nhóm của mình theo chiều ngang hơn . Mỗi đội (FAST gọi họ là Tập thể) có thể lớn hơn nhiều. Và sau đó, các nhóm mà mọi người làm việc hàng ngày sẽ tự tập hợp lại trong các Tập thể đó.

Nếu các Tập thể lớn hơn hoạt động hiệu quả, chúng sẽ giảm đáng kể độ phức tạp của tổ chức. Việc khởi động phần mềm điển hình có thể kéo dài nhiều năm trước khi phải phân chia thành các lĩnh vực chịu trách nhiệm. Cơ sở mã sẽ không cần phải được phân chia nghiêm ngặt thành các khu vực mà mỗi nhóm sở hữu. Điều này sẽ giải phóng đáng kể thời gian quản lý mà người quản lý có thể sử dụng để tập trung vào sản phẩm và nhóm.

Vì vậy, đây là điều trọng tâm mà chúng ta cần kiểm tra: liệu việc tự lắp ráp và tự tổ chức có cung cấp một cách thức hoạt động hiệu quả như các nhóm được thiết kế nhỏ hơn không?

Nếu đúng như vậy, thì nó sẽ đưa ra một cách để mở rộng quy mô các tổ chức có khả năng tốt hơn ở mức độ lớn hơn trong việc mở rộng quy mô các tổ chức. Tại sao nhiều như vậy? Hãy so sánh một tổ chức đang phát triển với các nhóm có quy mô sáu người so với một tổ chức mở rộng quy mô với “nhóm/Tập thể” có quy mô sáu mươi người.

Có rất nhiều giả định được xây dựng trong lập luận này và bạn có thể chọc thủng một số lỗ hổng trong đó. Nhưng ngay cả khi bạn làm như vậy, FAST về cơ bản cho phép một đơn vị tổ chức lớn hơn sở hữu một khu vực của sản phẩm và cơ sở mã.

FAST còn mới, vì vậy hiện tại không có nhiều bằng chứng về việc liệu các nhóm FAST có hoạt động hiệu quả như các nhóm nhanh nhẹn thông thường hay không. Nhưng tôi nghi ngờ câu trả lời cho câu hỏi đó là có. Tôi có một vài lý do để tin điều đó. Đầu tiên, trải nghiệm ban đầu của Jim Shore với nó khá tích cực và anh ấy là người mà tôi tin tưởng.

Lý do thứ hai khiến tôi lạc quan về FAST là tôi đã có một số kinh nghiệm với các nhóm lớn những người tự tổ chức. Và tôi đã rất ngạc nhiên về hiệu quả của nó.

Tất nhiên, trong các công ty nhỏ, bạn sẽ thấy rất nhiều hoạt động tự tổ chức. Nhưng khi các công ty phát triển, bạn tiêu chuẩn hóa mọi thứ và loại bỏ tính tự tổ chức ngoại trừ trong các nhóm. Tuy nhiên, một trong những thử nghiệm thú vị nhất mà tôi từng tham gia là một sự kiện tự tổ chức quy mô lớn tại New Relic. Chúng tôi đã thiết kế lại tất cả các nhóm của mình và yêu cầu mọi người trong 50 nhóm phần mềm chọn nhóm mà họ muốn tham gia. Chúng tôi có những hạn chế về kỹ năng cần thiết cho mỗi đội và đã xác định những gì mọi người cần sở hữu. Nó đã kết thúc thành công hơn bất kỳ ai mong đợi, ngay cả những người tổ chức chúng tôi.

Vì vậy, mặc dù ban giám khảo không đồng tình với điều này, linh cảm của tôi là phương pháp này có rất nhiều tiềm năng trong bối cảnh phù hợp.

FAST có thể được thử nghiệm dần dần

Điều này không được đề cập trong các tài liệu của FAST, nhưng có một điều khiến tôi thấy thú vị về FAST là bạn có thể thử nghiệm nó dần dần.

Bạn có thể triển khai FAST Agile trên một nhóm dưới dạng thử nghiệm, sau đó sử dụng phương pháp tiếp cận blob trong đó bạn nuốt chửng các nhóm bổ sung theo thời gian. Nếu suôn sẻ, tiếp tục nuốt các đội bổ sung. Nếu không, hủy bỏ thử nghiệm.

NHANH CHÓNG sẽ dẫn đến ít reorg hơn

Thay đổi xảy ra trong các tổ chức. Ưu tiên thay đổi, mọi người rời đi, các khu vực của sản phẩm có sự tăng trưởng bất ngờ. Các quyết định kỹ thuật trước đây cắn bạn và bạn phải làm thêm công việc. Cơ hội mới phát sinh đòi hỏi phải đầu tư.

Tất cả những điều này có tác động đến cấu trúc tổ chức của bạn. Bạn có một tập hợp các nhóm, mỗi nhóm có khu vực sở hữu riêng. Khi thay đổi này xảy ra, bạn sẽ cấu trúc lại tổ chức của mình theo thời gian để thực hiện tốt nhất có thể. Những tái cấu trúc này là “tổ chức lại” và trong các tổ chức đang phát triển, chúng có thể xảy ra thường xuyên!

Việc tổ chức lại sẽ ít thường xuyên hơn rất nhiều với FAST. Đơn vị tổ chức lại lớn đến mức bạn không cần phải thực hiện nó thường xuyên.

Một nhược điểm tiềm ẩn của điều này là bạn không có các nhóm với các lĩnh vực trách nhiệm được xác định. Vì vậy, bạn có thể có sự phân tán trách nhiệm và có một mã chung được bảo trì kém. (Chúng ta sẽ nói về điều này một chút sau)

NHANH CHÓNG giúp dễ dàng đáp ứng các ưu tiên thay đổi

Khi các ưu tiên thay đổi trong các nhóm có cấu trúc thông thường, bạn có các nhóm được thiết lập để thực hiện công việc. Nếu cấu trúc nhóm đó không hỗ trợ các ưu tiên mới, bạn phải cấu trúc lại tổ chức của mình.

Đối với NHANH CHÓNG, các thay đổi về mức độ ưu tiên linh hoạt và liên tục hơn. Chừng nào trách nhiệm còn thuộc về Tập thể, các nhóm chỉ tự tổ chức xung quanh công việc và mọi việc sẽ như một ngày khác.

Cấu trúc cuộc họp tập thể cũng làm cho việc thay đổi các ưu tiên ít kịch tính hơn. Về cơ bản, bạn có chương trình Chung tay tích hợp hai lần một tuần. Tại các cuộc họp Tập thể, bạn có thể liên tục truyền đạt bối cảnh và giáo dục nhóm của mình về khách hàng và thị trường. Điều này sẽ giúp giữ cho nhóm của bạn liên kết tốt hơn.

Khi tôi đối chiếu cách tiếp cận đó với một số thứ như OKR hàng quý, nó có vẻ trôi chảy hơn và có vẻ như nó sẽ thực hiện tốt hơn việc sắp xếp mọi người. Nó đòi hỏi một nỗ lực cam kết từ nhà lãnh đạo sản phẩm để liên tục chia sẻ bối cảnh và các ưu tiên. Nhưng một số nhóm tốt nhất mà tôi từng tham gia có một nhà lãnh đạo sản phẩm hành động theo kiểu này, vì vậy tôi nghi ngờ rằng đây là thời gian hợp lý.

NHANH CHÓNG có thể tốt hơn cho động lực nội tại và khả năng duy trì

Nhiều nhóm có thể cảm thấy như quy trình của họ được thiết kế như một công cụ để kiểm soát mọi người. Và nó có thể giống như làm việc trên một dây chuyền lắp ráp.

FAST coi khả năng tự tổ chức là một thành phần cơ bản trong thiết kế của mình. Nó rất cơ bản, nó sẽ không hoạt động nếu không có sự tự tổ chức. Nó yêu cầu một bộ công cụ hoàn toàn khác để quản lý và hầu hết (mặc dù không hoàn toàn) không tương thích với các phương pháp tiếp cận theo cấp bậc từ trên xuống.

Daniel Pink đã vạch ra ba khía cạnh nổi tiếng của động lực nội tại :

• Quyền tự chủ – Mong muốn được tự định hướng, điều này làm tăng sự tham gia hơn là tuân thủ.
• Mastery - Sự thôi thúc để có được kỹ năng tốt hơn.
• Mục đích – Mong muốn làm điều gì đó có ý nghĩa và quan trọng. Các doanh nghiệp chỉ tập trung vào lợi nhuận mà không coi trọng mục đích sẽ có dịch vụ khách hàng kém và nhân viên không hài lòng.

Với FAST, bạn có thể tự định hướng công việc của mình, giúp bạn cảm thấy tự chủ. Bạn có thể chọn tập trung vào công việc giúp cải thiện kỹ năng của mình, đạt được cảm giác làm chủ. Và bạn liên tục được nhắc nhở về cách công việc của bạn được kết nối với những gì quan trọng đối với doanh nghiệp, giúp bạn cảm thấy có mục đích. Vì vậy, mặc dù điều đó không được đảm bảo, nhưng tôi thấy các tổ chức triển khai FAST có tiềm năng đạt được tỷ lệ duy trì cao.

Tự tổ chức cũng cung cấp một số tín hiệu hữu ích có thể giữ cho một cộng đồng mọi người làm việc cùng nhau tốt hơn. Kiểu người “quản lý giật gân” nhận được tín hiệu rằng hành vi của họ không được hoan nghênh. Làm sao? Họ bước tới để lãnh đạo một đội, và nói công việc họ muốn làm. Nếu không có ai tham gia nhóm của họ, công việc sẽ không diễn ra và nhóm không thành lập (các nhóm có ít nhất hai hoặc ba người tham gia, hoặc họ không xảy ra).

Tự tổ chức cũng cho phép mọi người đối phó với những khía cạnh đau đớn của công việc mà có thể không được chú ý ở các công ty khác. Ví dụ: nếu bộ thử nghiệm quá tệ, ai đó có thể đứng ra lãnh đạo nhóm khắc phục sự cố đó. Hoàn toàn hợp lý khi làm công việc rõ ràng không phải là ưu tiên kinh doanh. Nhưng đó là công khai và những người khác phải tham gia để nó xảy ra. Điều này có thể giúp tránh cảm giác như bạn đang ở trong một xưởng sản xuất tính năng .

Cuối cùng, bạn có thể chọn những người mà bạn làm việc cùng hàng ngày. Trước đây, khi tôi thấy các nhóm tự tổ chức, đây là một lợi ích bất ngờ: mọi người chọn làm việc với những người mà họ muốn làm việc cùng. Và những đội đó mạnh hơn nhiều so với tôi mong đợi.

Điều mà tất cả những điều này sẽ được cân bằng là bất kỳ nỗi đau mới nào mà mọi người sẽ trải qua với NHANH CHÓNG. Một thách thức có thể là với động lực quyền lực không chính thức, hoặc chính trị tiềm năng.

Nhiều môi trường không tương thích với FAST

Bởi vì FAST còn quá mới nên việc triển khai sẽ gặp nhiều rủi ro hơn. NHANH CHÓNG sẽ không có ý nghĩa trong mọi tình huống. Và còn nhiều ẩn số nữa. Tốt nhất hãy nghĩ về nó như một cách tiếp cận thử nghiệm.

Môi trường nào thuận lợi nhất để thử NHANH CHÓNG? Và bạn nên tránh NHANH CHÓNG ở đâu?

Công ty của bạn càng có nhiều phẩm chất từ danh sách này thì càng phù hợp với FAST:

• Quan tâm đến đổi mới quản lý và thử nghiệm.
• Niềm tin cao, môi trường sợ hãi thấp. Hoặc ít nhất là mong muốn tránh mệnh lệnh và kiểm soát trong lãnh đạo.
• Một hướng dẫn tốt hoặc người hỗ trợ của quá trình. Một người có thể điều hành một cuộc họp tập thể hiệu quả, thiết lập quy trình, đánh giá và quản lý nó một cách tích cực. Một người hiểu động lực của tổ chức và cách mọi người trong nhóm làm việc cùng nhau. (Bạn có thể thuê tôi cho việc này).
• Tỷ lệ thay đổi ưu tiên từ trung bình đến cao. NHANH CHÓNG sẽ ít hữu ích hơn nếu các ưu tiên không thay đổi.
• Một nhóm hợp tác, tự định hướng, có hiệu suất cao và không ngừng học hỏi.
• Một nhóm lãnh đạo có thể tìm ra các ưu tiên của nó.
• Bạn có một nhà lãnh đạo sản phẩm có thể nói về các ưu tiên và bối cảnh kinh doanh tại mỗi cuộc họp Tập thể. Và họ có thể giao tiếp hiệu quả.

Những đặc điểm này càng ít đúng thì bạn càng gặp nhiều trở ngại với FAST. Tôi không nghĩ rằng bạn cần phải ở trong một môi trường hoàn hảo cho nó. Theo một số cách, tôi nghĩ muốn trở thành những thứ này quan trọng hơn là thực sự trở thành những thứ này. Vì vậy, có lẽ yếu tố thành công quan trọng nhất là khả năng lãnh đạo đồng hành với việc tạo không gian cho nó.

Bạn có thể phải quản lý tự quản lý

Các hệ thống tự tổ chức có thể hoạt động hiệu quả. Nhưng chúng không miễn phí. Họ giống như quản lý một cộng đồng.

Bạn sẽ cần tạo ra các ràng buộc và phương tiện để khuyến khích hành vi đúng đắn. Và bạn sẽ cần theo dõi và quản lý cẩn thận để đảm bảo mọi thứ không đi chệch hướng.

Bất kỳ tổ chức nào cũng có thể có những kẻ xấu hoặc những người không phù hợp với lợi ích của cộng đồng đó. Tôi nhớ có lần nói chuyện với một kỹ sư, người này đã nói với tôi (tôi không đùa với bạn đâu) rằng họ không nghĩ rằng họ có nghĩa vụ tạo ra giá trị cho chủ nhân của họ. Một số kỹ sư có thể muốn tập trung vào những thứ phát triển kỹ năng của họ hoặc khiến họ trở thành một nhân viên có giá trị hơn, thay vì những thứ tốt cho công ty tuyển dụng họ.

Với FAST, bạn đang đăng ký quản lý một cộng đồng người.

Trong các tình huống thông thường, hệ thống phân cấp làm rõ ai chịu trách nhiệm về việc này. Trong FAST, tôi cho rằng sẽ rất dễ dàng để tránh xung đột và “hãy để các thành viên tự tìm hiểu”. Điều này có thể dẫn đến việc các mạng lưới điện không chính thức chiếm ưu thế trong một kiểu chuyên chế phi cấu trúc . Nếu bạn sử dụng NHANH CHÓNG, đây là điều tôi sẽ đề phòng.

Một thái cực khác là không để nhóm tìm ra vấn đề và để ban quản lý xử lý hoàn toàn. Điều này cũng có thể có hại.

Vì vậy NHANH CHÓNG sẽ yêu cầu hỗ trợ tốt, quan sát cẩn thận và thỉnh thoảng can thiệp.

NHANH đòi hỏi rất nhiều công việc

Lý do lớn nhất mà bạn có thể không muốn thử nghiệm với FAST là có rất nhiều công việc ẩn với FAST. Nó đòi hỏi rất nhiều thay đổi trong tổ chức của bạn, đối với một cách điều hành không quen thuộc.

Bạn có thể so sánh NHANH CHÓNG với việc làm việc trong một ngôn ngữ lập trình máy tính mới. Ngôn ngữ mới có vẻ đầy hứa hẹn vì nó có rất nhiều tính năng công thái học mới có vẻ tốt hơn nhiều so với bất kỳ ngôn ngữ nào bạn từng thấy trước đây. Tuy nhiên, bạn không có khung và thư viện được viết bằng ngôn ngữ mới này. Vì vậy, bạn sẽ phải tự mình xây dựng rất nhiều thứ.

Vì vậy, nhược điểm lớn nhất của FAST là nó không phải là một phương pháp được thiết lập tốt. Bạn sẽ cần phải tạo ra nhiều thứ để giải quyết sự không tương thích giữa cách thức hoạt động của FAST và các thông lệ thông thường. Dưới đây là một số ví dụ:

Quản lý hiệu suất hoạt động như thế nào?

Trong các nhóm thông thường, bạn có một người quản lý giám sát công việc và huấn luyện các cá nhân. Bạn có đánh giá hiệu suất và nếu ai đó không phù hợp, người quản lý có thể can thiệp. Mặc dù có vấn đề với đánh giá hiệu suất, nhưng hầu hết mọi người đều hiểu cách họ làm việc và họ phục vụ một mục đích nào đó trong tổ chức.

Trong các nhóm NHANH CHÓNG, thực sự không có một cách rõ ràng nào để đánh giá hiệu suất. Người quản lý của người đó có biết họ đang làm gì hoặc họ đang làm việc như thế nào không? Bạn thậm chí không thể đánh giá “các nhóm”, bởi vì chúng là nhất thời.

Vì vậy, toàn bộ khái niệm về quản lý hiệu suất cần phải được phát minh lại. Mặc dù dù sao đó cũng có thể là một ý tưởng hay, nhưng đó là điều cần phải suy nghĩ và phát minh.

Vai trò của các nhà quản lý kỹ thuật trong FAST là gì?

Có rất nhiều cách để cấu trúc vai trò của người quản lý kỹ thuật. Tôi thường khuyên người quản lý kỹ thuật chịu trách nhiệm quản lý dự án vì điều đó giúp họ làm việc sát cánh với nhóm của mình mà không đặt họ vào khu vực mà sự chênh lệch công suất gây ra sự cố. Có rất nhiều cách hợp lệ để xác định vai trò của người quản lý kỹ thuật, nhưng đó là cách mà tôi có xu hướng bị thu hút.

Trong FAST, vai trò của người quản lý kỹ thuật ít rõ ràng hơn. Bạn không có các nhóm tồn tại lâu dài, do đó, người quản lý kỹ thuật sẽ khó làm việc cùng với các báo cáo trực tiếp của họ hơn.

Bạn có thể nhờ các nhà quản lý kỹ thuật lãnh đạo các nhóm tự lắp ráp. Hoặc bạn có thể để họ trở thành những người quản lý thuần túy. Hoặc bạn có thể để họ làm cầu thủ-huấn luyện viên.

Tất cả những điều này đều có sự đánh đổi và một số nhược điểm khá lớn. NHANH CHÓNG dường như làm giảm nhu cầu quản lý kỹ thuật càng nhiều. Bạn vẫn cần người để thuê, quản lý hiệu suất và giám sát quy trình. Nhưng có lẽ không nhiều như trong một tổ chức thông thường?

Tôi đã chứng kiến nhiều tổ chức gặp khó khăn vì họ không coi quản lý là một nguyên tắc. Nhưng tôi đoán rằng các tổ chức FAST cần ít sự quản lý hơn.

Tôi thực sự tò mò muốn biết liệu điều này có diễn ra hay không và muốn nghe ý kiến từ các tổ chức thử nghiệm FAST. Bạn làm gì với quản lý?

Làm thế nào bạn sẽ đảm bảo chất lượng mã mà không có khu vực sở hữu?

Quyền sở hữu mã cung cấp các ưu đãi tự nhiên để giữ chất lượng mã cao. Đó là vì lợi ích cá nhân của bạn, bởi vì bản thân tương lai của bạn phải hoạt động trong mã hiện tại của bạn.

Trong trường hợp quyền sở hữu mã được chia sẻ, bạn phải nỗ lực nhiều hơn để đảm bảo chất lượng mã. Đề xuất của tôi sẽ là ghép nối hoặc di chuyển như một thông lệ bắt buộc.

Bạn cũng sẽ cần các tiêu chuẩn mạnh hơn cho các mẫu mã. Bạn sẽ cần mã linting. Và bạn sẽ cần một số kiểu ra quyết định về kiến trúc. Bạn không muốn có 20 mẫu về cách mã giao diện người dùng của bạn xử lý trạng thái. Đây là những vấn đề bạn sẽ gặp phải trong hầu hết các tổ chức phần mềm, nhưng chúng sẽ cấp bách hơn nhiều trong một tổ chức sử dụng FAST.

Một điều mà nhiều tổ chức chưa đầu tư là đào tạo và truyền thông xung quanh các mẫu thiết kế phần mềm hiệu quả. Và các cuộc trò chuyện để đảm bảo mọi người đều thống nhất về cách tiếp cận và thời điểm sử dụng. Những điều này có lẽ còn quan trọng hơn trong một tổ chức NHANH CHÓNG.

Quyền sở hữu mã được chia sẻ là một thông lệ đã có tiền lệ. Sẽ rất đáng để dành thời gian tìm hiểu làm thế nào để thành công với nó nếu bạn tiến hành NHANH CHÓNG.

Điều gì xảy ra với nhiều Tập thể và vượt qua ranh giới Tập thể?

Công việc vượt qua ranh giới Tập thể về cơ bản là không được xác định trong FAST. Và các sáng kiến lớn đòi hỏi mức độ phối hợp cao cũng được FAST chỉ định dưới mức. Vì vậy, bạn phải phát minh ra giải pháp cho những tình huống này.

Bất kỳ tổ chức nào đủ lớn để có nhiều Tập thể sử dụng FAST sẽ tham gia vào các dự án Tập thể chéo. Các mô hình để giải quyết những điều này sẽ giống hoặc tương tự như cách bạn giải quyết nó ở quy mô nhỏ hơn. Nhưng đây phần lớn là lãnh thổ chưa được khám phá, theo như tôi biết. Vì vậy, bạn sẽ cần sử dụng một số mô hình phối hợp để giải quyết những vấn đề này khi chúng phát sinh. Nó sẽ là một hành động của phát minh.

Làm thế nào để FAST đối phó với cuộc gọi?

On-call không được đề cập cụ thể trong hướng dẫn NHANH CHÓNG . Vì vậy, bạn sẽ cần phải phát minh ra một kế hoạch để đối phó với nó.

Trong các nhóm thông thường, lời khuyên tiêu chuẩn cho cuộc gọi là để mỗi nhóm chịu trách nhiệm về các hoạt động của riêng mình. Và để có tất cả mọi người trong đội theo yêu cầu. Điều này ngụ ý rằng bạn nên có các nhóm ít nhất bốn người để gánh nặng không quá tệ. Suy nghĩ là việc có các nhóm theo yêu cầu cho sản phẩm công việc của họ sẽ khuyến khích họ nâng cao độ tin cậy. Điều này giúp họ đảm bảo rằng họ có một lịch trình theo yêu cầu phù hợp.

Với FAST, bạn có thể tạo vòng quay theo yêu cầu có các bậc (hãy làm theo sổ tay hướng dẫn này và chuyển cấp nếu điều đó không khắc phục được). Và bạn sẽ cần phải giữ một bản đồ rõ ràng về những người có thể hỗ trợ những gì. Điều này sẽ không ánh xạ tới các nhóm của bạn.

Điều này không quá khó thực hiện, nhưng nó ít phổ biến hơn so với các phương pháp theo yêu cầu thông thường và sẽ cần sự chú ý của ban quản lý.

Điều gì về sửa lỗi và leo thang hỗ trợ?

FAST có một vai trò tùy chọn được gọi là “Người quản lý tính năng”. Họ là một chuyên gia về một tính năng cụ thể và là đầu mối liên hệ xung quanh tính năng đó cho các bên liên quan. Họ không bắt buộc phải làm việc liên tục trên tính năng đó, nhưng bắt buộc phải có sự hiểu biết liên tục về nó.

Giống như khi gọi điện, bạn sẽ cần ánh xạ các tính năng tới những người có chuyên môn về các tính năng đó. Điều này sẽ rất quan trọng đối với cả lỗi và leo thang hỗ trợ. Và bạn cũng có thể kết hợp nó với cuộc gọi. Bạn sẽ cần một số cách để phân loại vấn đề cho đúng người.

Bạn cũng cần đảm bảo rằng bạn có một cơ chế để lấp đầy khoảng trống kiến thức khi chuyên môn bị cô lập bởi một hoặc hai người.

Một điều bạn sẽ phải quyết định là chính sách sửa lỗi của bạn. Bạn có muốn chúng luôn cố định, làm chậm hoạt động của các tính năng khác không? Người đã giới thiệu chúng đã sửa lỗi hay bạn muốn một số kế hoạch khác? Và làm thế nào bạn sẽ xác định ai chịu trách nhiệm phân loại lỗi? Có lẽ là một vòng quay của một số loại?

Leo thang hỗ trợ cũng sẽ đòi hỏi một số nỗ lực. Đầu mối liên hệ là Feature Steward cho một khu vực. Nhưng nếu Feature Steward đang trong kỳ nghỉ thì sao? Bạn có thể muốn có nhiều hơn một người hiểu biết về từng lĩnh vực. Và nếu câu hỏi hỗ trợ kết thúc yêu cầu công việc thì sao? Bạn chỉ làm công việc hay đưa nó vào các ưu tiên trung tâm?

Không có vấn đề nào trong số này là khó giải quyết, nhưng chúng là công việc quản lý. Và mọi thứ bạn làm sẽ có sự đánh đổi giữa sự tập trung và khả năng đáp ứng.

Điều gì về sự cố độ tin cậy và hồi cứu sự cố?

FAST không xác định cách xử lý sự cố. Các mẫu cuộc gọi của bạn sẽ quyết định phần lớn cách xử lý các sự cố và có khả năng sẽ liên quan đến việc bất kỳ ai biết cách khắc phục tình huống được kéo vào để khắc phục.

FAST không mô tả cách xử lý hồi cứu sự cố. Tôi khuyên bạn nên làm điều gì đó như sau: lên lịch trình hồi cứu sự cố xảy ra trước cuộc họp Tập thể tiếp theo. Một trong những mục tiêu của quá trình hồi tưởng là xác định một số công việc có thể được thực hiện để làm giảm khả năng xảy ra hoặc mức độ nghiêm trọng của bất kỳ nguyên nhân nào gây ra sự cố. Một cách khác là học tất cả những gì bạn có thể từ vụ việc.

Tại cuộc họp Tập thể ngay sau khi sự cố xảy ra, tôi sẽ chia sẻ những gì chúng tôi đã học được, đồng thời đặt ưu tiên tự động cho chu kỳ tiếp theo là thực hiện một số công việc được xác định trong quá trình hồi cứu.

Tại New Relic, chúng tôi không sử dụng FAST, nhưng chúng tôi có chính sách tương tự. Chúng tôi gọi nó là “Không lặp lại sự cố” (DRI). Đó là một trong những điều tốt nhất chúng tôi từng làm để đảm bảo độ tin cậy. Quy tắc là công việc DRI tự động quan trọng hơn các ưu tiên khác. Do đó, một sự cố luôn dẫn đến phạm vi ít hơn hoặc thời hạn bị đẩy lùi.

Làm thế nào để các nhà thiết kế làm việc NHANH CHÓNG?

Một thách thức mà nhiều nhà thiết kế gặp phải là tập trung làm việc với nhóm kỹ thuật hoặc làm việc trước nhóm kỹ thuật. Hoặc có họ hoạt động theo cả hai cách. Bạn sẽ nghe thấy những lập luận mạnh mẽ cho cả hai cách làm việc.

FAST không chỉ định cách thức hoạt động của tính năng này, vì vậy bạn cần tự quyết định. Các nhà thiết kế có đăng ký cho các nhóm làm việc không? Hay họ là một tổ chức dịch vụ, làm việc trước mọi thứ và đóng vai trò là nhà tư vấn khi mọi người cần thứ gì đó từ họ? Bạn sẽ cần phải quyết định. Tôi có thể yêu cầu các nhà thiết kế đăng ký và trở thành một phần của nhóm, nhưng một lần nữa, đây là một ví dụ về loại quyết định mà bạn sẽ cần đưa ra khi áp dụng FAST.

Làm thế nào để các nhà quản lý sản phẩm làm việc trong FAST?

Vai trò của sản phẩm trong FAST chủ yếu là ưu tiên và truyền đạt các ưu tiên. Có rất nhiều điều không thực sự được mô tả trong sách hướng dẫn FAST về công việc bên ngoài đó.

Giả định trong sách hướng dẫn FAST dường như là người quản lý sản phẩm truyền cảm hứng và giao tiếp, sau đó các kỹ sư làm việc trên các tính năng.

Ở mức độ mà bạn có thể, tôi sẽ nhờ các kỹ sư nói chuyện với khách hàng và để họ có được kiến thức chuyên môn trong lĩnh vực sản phẩm mà họ đang làm việc. Lý tưởng nhất là họ sẽ thực hiện công việc, demo cho khách hàng và nhận phản hồi về công việc đó từ họ . Nhờ các nhà quản lý sản phẩm hỗ trợ điều đó và nâng cao khả năng của các kỹ sư để thực hiện điều đó một cách hiệu quả, có thể là một phần có giá trị trong công việc của họ.

Có rất nhiều tính linh hoạt trong mô hình này. Bạn có thể thực hiện chuyển giao sản phẩm điển hình cho kỹ thuật hoặc bạn có thể yêu cầu họ khám phá và giải quyết vấn đề cùng với khách hàng.

Vì vậy, như bạn có thể thấy, có rất nhiều lỗ hổng trong FAST. Bạn sẽ cần phải giải quyết vấn đề còn lại.

Các tài liệu FAST đầy biệt ngữ

Bạn có thể thấy trang web FAST và hướng dẫn sử dụng khó hiểu. Bạn sẽ phải điều hướng rất nhiều biệt ngữ và thuật ngữ khó chịu để có được vàng của Agile NHANH CHÓNG. Ví dụ: đây là định nghĩa khủng khiếp về Nhanh nhẹn Nhanh nhẹn cố gắng xác định thực tiễn trong phiên bản 2.12 của Hướng dẫn NHANH CHÓNG :

“Công nghệ mở rộng quy mô chất lỏng là gì? Công nghệ mở rộng quy mô linh hoạt kết hợp Công nghệ không gian mở và phân bổ mở để tạo ra một phương pháp gọn nhẹ, dễ hiểu và đơn giản để thành thạo để tổ chức mọi người xung quanh công việc - quy mô đó. FAST là từ viết tắt của Công nghệ mở rộng quy mô chất lỏng. Công nghệ mở rộng quy mô linh hoạt cho Agile là Agile NHANH CHÓNG.”

Vì thế. Xấu. Và điều này rất tiêu biểu. Bạn sẽ thấy rất nhiều tài liệu tham khảo về Tập thể, Chu kỳ giá trị, Công nghệ mở, Biến đổi màu xanh ngọc, Lý thuyết Y, v.v. Tất cả những điều này được trình bày mà không có lời giải thích nào, và thực sự ngay cả khi được giải thích thì nó cũng không hữu ích. Họ đang nói chuyện với một nhóm khán giả thích hợp gồm các nhà lý thuyết nhanh nhẹn và tập trung vào sự quy kết hơn là tính hữu dụng.

Phần kết luận

Vậy điều đó để lại cho chúng ta ở đâu? FAST linh hoạt có đáng để thử nghiệm không?

Tôi tin rằng câu trả lời là có, nhưng cần thận trọng và trong bối cảnh phù hợp. Bạn có thể chơi với nó trong các nhóm riêng lẻ. Và nếu bạn có sự hỗ trợ của lãnh đạo, hãy thử nghiệm nó dần dần trong các tổ chức lớn hơn.

Hãy chia sẻ với tôi nếu bạn thử nghiệm với nó. Và nếu bạn muốn trợ giúp triển khai nó trong tổ chức của mình, hãy liên hệ với tôi. Tôi sẽ giúp bạn trực tiếp hoặc kết nối bạn với những người khác có thể trợ giúp.

Cảm ơn

Các phiên bản đầu tiên của bài đăng này… thực sự tồi tệ. Tôi muốn cảm ơn Seth Falcon và Davy Stevenson vì bài phê bình của họ. Cả hai đều chỉ ra một số vấn đề lớn với bài đăng khiến tôi phải sao lưu và suy nghĩ lại về cách tiếp cận của mình. Và họ đã đưa ra một số điểm xuất sắc mà tôi đã đưa vào các phần riêng của họ trong bài đăng. Cuối cùng, tôi đã viết lại hầu hết bài đăng và tôi rất vui với kết quả này. Cảm ơn! Seth có một bản tin về khả năng lãnh đạo kỹ thuật đáng xem, còn Davy (giống tôi) tư vấn và huấn luyện khởi nghiệp .

Jim Shore đã giới thiệu tôi với NHANH CHÓNG nhanh nhẹn. Anh ấy có một số cuộc nói chuyện tuyệt vời về kinh nghiệm của mình với nó. Và chúng tôi đã gặp nhau một vài lần và thảo luận về ý nghĩa và việc triển khai NHANH CHÓNG. Jim là tác giả của Nghệ thuật phát triển linh hoạt .

Hình ảnh được cung cấp bởi Kanenori từ Pixabay

chú thích

1. Tôi tin rằng 150 người có lẽ là khó sử dụng đối với một Tập thể. Tôi nghi ngờ sáu mươi người là kích thước tối đa tốt hơn.