Xử lý nợ hệ thống

Pre-amble / tl; dr: Gần đây tôi đã xuất bản Nguyên tắc về sự nhanh nhẹn của Lloyd Braun chủ yếu là một nhận xét ngớ ngẩn nhưng đúng đắn về cách dòng Seinfeld cổ điển "Thanh thản bây giờ, điên rồ sau" liên quan trở lại với Agile. Tôi đã kết thúc bài đăng đó bằng một tuyên bố về cách chúng ta cần chuẩn bị tốt hơn cho "Sự điên rồ" xảy ra sau đó. Với ý nghĩ đó, tôi đang giới thiệu cách tiếp cận của mình để xây dựng các nhóm làm việc hiệu quả. Đó là về việc thanh toán Nợ Hệ thống của bạn.

Đội ngũ công nghệ hiện đại đã bị phá vỡ. Chúng ta phụ thuộc quá nhiều vào Người cao niên và không tận dụng Người cao tuổi.

Tôi đã suy nghĩ về vấn đề này rất nhiều trong năm qua, vì tôi đã điều chỉnh nhiều đội theo "trạng thái bình thường mới" của chúng tôi. Nhiều tháng trước, tôi đã bắt đầu một bài báo ủng hộ trường hợp rằng người quản lý tuyển dụng nên thuê đàn em. Để lập luận hiệu quả, tôi biết mình phải giải quyết một mối quan tâm chung: "Đầu tiên tôi cần tiền bối để đào tạo đàn em ..." Bài báo nhanh chóng phát triển và lớn mạnh.

Nếu bạn chưa quen với quản lý, đây là "chuyên luận" của tôi về Quản lý. Đó là về cách xây dựng các nhóm hiệu quả và năng suất cao và dựa trên hơn một thập kỷ quản lý thành công nhiều nhóm lớn.

Những gì sau đây là một bài đọc dài - vì vậy tl; dr là:

Chúng ta nói nhiều về #TechnicalDebt, nhưng Nợ kỹ thuật là dấu hiệu của một vấn đề lớn hơn mà tôi đang đặt tên là Nợ Hệ thống.

Công thức rất đơn giản:

1) Giao nhiệm vụ cho Người cao niên của bạn để thanh toán Khoản nợ Hệ thống của bạn, và làm cho công việc dễ dàng hơn.

2) HIỀN. ĐÀN EM.

3) Ngừng chống tiêu hao. Thanh thiếu niên sẽ ở lại trung bình 18-24 tháng. Họ muốn có những trải nghiệm đa dạng. Họ sẽ tìm kiếm công việc khác. Là một cộng đồng công nghệ, chúng tôi MUỐN Người cao niên có thêm kinh nghiệm trên con đường trở thành Người có thâm niên. Nó làm cho họ tốt hơn và nó làm cho chúng ta tốt hơn. Vì vậy, chúng ta hãy nắm lấy sự tiêu hao. Hãy bắt đầu tập trung vào việc giúp họ tận dụng tối đa 18 tháng đó và sau đó hỗ trợ họ trên các bước tiếp theo.

Bất kỳ đội giao hàng tốt nào cũng nhấn mạnh đến khả năng sử dụng. Các nguyên tắc thúc đẩy khả năng sử dụng xuất hiện dưới nhiều hình thức khác nhau: Nguyên tắc Pareto , Phép thử bà nội , Nguyên tắc Đủ tốt , và hơn thế nữa. Và tất cả họ đều đạt được điều gì đó rất con người: Điều này có khó hơn mức cần thiết không?

Chúng tôi luôn thấy điều đó : Các thiết kế tối giản ưu tiên tính dễ sử dụng và siêu tập trung vào tầm nhìn rõ ràng. Mọi thứ khác là một sự phân tâm, nó cồng kềnh.

Có rất nhiều người nói về lãnh đạo, quản lý, cân bằng công việc / cuộc sống và làm việc từ xa / trực tiếp. Mọi thứ đang được đánh giá lại - và câu hỏi đọng lại trong tâm trí tôi hàng tháng nay chỉ đơn giản là: Có phải làm việc chăm chỉ hơn mức cần thiết không? Đó hoàn toàn không phải là một câu hỏi mới, nhưng đó là một sợi chỉ dệt nên phần lớn sự nghiệp của tôi. Tôi thích viết mã và xây dựng sản phẩm, nhưng một cái nhìn tổng thể có thể tiết lộ rằng nhiều mã hơn không phải lúc nào cũng là câu trả lời. Nhiều mã hơn có nghĩa là chi phí đào tạo và bảo trì nhiều hơn.

Nếu bạn là một người quản lý mới, hãy ghi nhớ câu hỏi này có thể rất có giá trị. Người quản lý chịu trách nhiệm về rất nhiều việc: bạn đang giúp đỡ từng cá nhân - hoàn thành công việc và mục tiêu cá nhân của họ. Bạn chịu trách nhiệm về sự gắn kết và định hướng của nhóm. Bạn thường chịu trách nhiệm thiết lập các quy trình và chính sách. Sau đó là phân bổ nguồn lực và lập kế hoạch, cũng như làm việc theo lịch trình của PTO. Nhưng ánh sáng dẫn đường cho tất cả những điều này là cùng một câu hỏi: Điều này có khó hơn nó phải không?

Lần cuối cùng bạn đánh giá cơ chế nội bộ của mình là khi nào? Nghĩ về nhóm giao hàng của bạn như một sản phẩm, người tiêu dùng của bạn (nhóm kinh doanh / vận hành) dễ dàng đạt được mục tiêu của họ như thế nào? Và nghĩ về toàn bộ doanh nghiệp của bạn như một sản phẩm, làm thế nào để khách hàng dễ dàng đạt được sản phẩm của họ?

Tập trung vào con người, các câu hỏi tương tự cũng được áp dụng: Nhóm của bạn khó thực hiện công việc của họ như thế nào? Những cấu trúc, khuôn khổ, quy trình có sẵn và hệ thống phân cấp nào tồn tại có thể khiến bà của bạn lắc đầu trước mức độ phức tạp của bạn?

Một cơ hội nợ

Trên thực tế, toàn bộ suy nghĩ này về việc đánh giá các quy trình nội bộ của bạn là một phần của triết lý Agile thường bị bỏ qua. Các nhóm cho rằng họ hoàn toàn Agile, hoặc "Agile-hybrid" nhưng xem xét kỹ hơn, bạn nhận ra ý của họ là họ chỉ đơn giản là cắt các góc không thuận tiện để cung cấp các sản phẩm cẩu thả nhanh hơn. Khi nói đến phần mềm, bất kỳ nhà phát triển dày dạn kinh nghiệm nào cũng sẽ biết chính xác điều này trở thành công thức cho món nợ kỹ thuật ngày càng gia tăng. Trò đùa đang diễn ra của các lập trình viên là người cuối cùng đã làm sai, và nếu bạn muốn nó đúng , bạn sẽ cần phải xây dựng lại nó. Đây không phải là do lười biếng hay thiếu khả năng. Công việc của Greenfield dễ dàng hơn bởi vì nó đã loại bỏ tất cả các khoản nợ kỹ thuật - nhưng, vẫn để lại những quy trình tồi tệ tương tự, nó sẽ chỉ phát triển thêm một lần nữa.

Nợ kỹ thuật là một triệu chứng, và ngay cả khi bạn chủ động thanh toán xong - bạn vẫn chỉ đang điều trị triệu chứng này. Triệu chứng này xuất phát từ sai lầm khi nghĩ Agile chỉ là phân phối phần mềm.

Một định nghĩa đúng đắn về Nợ kỹ thuật là 'tích lũy công việc cần tái cấu trúc.' Như đã đề cập, nó phát sinh từ việc đi tắt khi tập trung vào giao hàng. Trừ khi bạn đang tích cực trả nó xuống, nó sẽ phát triển nhanh chóng. Kết quả của quá nhiều nợ kỹ thuật là tính giòn và không ổn định.

Ở mức tốt nhất, Nợ kỹ thuật là một quyết định có chủ đích: đó là đặt một khoản tín dụng nào đó với ý định trả sau. Trong những trường hợp như vậy, Nợ kỹ thuật không phải là xấu - miễn là bạn phải siêng năng thanh toán khoản nợ đó. Sự hiện thân bất chính hơn của Nợ kỹ thuật là khi bạn vô tình thêm vào khoản nợ, hoặc tệ hơn - bạn không biết rằng bạn đã thêm vào nó.

Nợ kỹ thuật đề cập đến công nghệ, nhưng có một khái niệm tương tự về Nợ quá trình - các quy trình kế thừa đã phát triển cũ kỹ, hoạt động kém, tạo ra xích mích, tác động đến động lực giữa các nhóm hoặc có thể không còn áp dụng khi các vai trò đã thay đổi. Quy trình Nợ bao gồm các khiếm khuyết hoạt động phi kỹ thuật của chúng tôi.

Vẫn còn các hình thức nợ khác ảnh hưởng đến việc phân phối: Nợ thiết kế, Nợ kiến trúc.

Tất nhiên, nợ vốn dĩ không phải là xấu xa. Cũng giống như bạn có thể gánh một khoản nợ tài chính lành mạnh về mặt chiến lược, việc chấp nhận bất kỳ hình thức nợ nào trong số này là một quyết định chiến lược. Thay vì trả 20.000 đô la cho một chiếc ô tô cùng một lúc, bạn vay một khoản vay mua ô tô và chia đều các khoản thanh toán trong 10 năm. Tương tự như vậy - hệ thống công nghệ bạn sử dụng, cách bạn cấu trúc bộ kỹ năng của nhóm, thâm niên của những vai trò đó và các quy trình thúc đẩy doanh nghiệp của bạn phải gánh chịu một hình thức nợ được trả dần trong một khoảng thời gian.

Chỉ - đôi khi chúng tôi không trả nó xuống. Hoặc tệ hơn: chúng tôi nghĩ rằng chúng tôi đang trả bớt nợ nhưng chúng tôi thực sự đang tích lũy nhiều hơn.

Giới thiệu: Nợ hệ thống

Tôi muốn giới thiệu một khái niệm mà tôi sẽ gọi là Nợ Hệ thống (Hệ thống như trong Lý thuyết Hệ thống; để biết thêm về Lý thuyết Hệ thống, hãy đọc Tư duy tuyệt vời trong Hệ thống của Donnella Meadow ).

Hệ thống Nợ là nguyên nhân bao trùm và gốc rễ của các dạng nợ cuối cùng cản trở hoặc tác động tiêu cực đến việc phân phối - cho dù thông qua các quyết định từ doanh nghiệp, hay các quyết định về kỹ thuật, kiến trúc hoặc quy trình. Nó là sản phẩm của việc sử dụng những con đường tắt có tính toán trong kinh doanh, đặt công việc lên hàng đầu. Hệ thống Nợ cản trở một hệ thống hoạt động thông qua thiết kế cấu trúc của nó.

Trong Tư duy trong Hệ thống, Meadows cung cấp một ví dụ đơn giản về một hệ thống: bồn tắm. Đầu vào của hệ thống là vòi, đầu ra là cống. Meadows giải thích các yếu tố khác nhau có thể khiến lồng giặt không bao giờ đầy, không bằng phẳng hoặc tràn. Một hệ thống tối ưu là mức nước còn lại - với đầu vào (vòi) và đầu ra (cống) chảy với tốc độ như nhau. Nợ hệ thống sẽ là hậu quả của việc sử dụng các phím tắt khi soạn thảo hệ thống. Để kéo dài sự tương tự bồn tắm, có thể vòi được lắp đặt kém và cuối cùng nước bị rò rỉ. Có thể vị trí của ống thoát nước dẫn đến nước tích tụ ở một số khu vực nhất định nên bồn tắm không bao giờ có thể thoát nước hoàn toàn. Có thể nước của chúng ta cần làm mềm và làm cho vôi tích tụ.

Trong những trường hợp này, không có tác động ngay lập tức và vẫn có thể tạo ra một hệ thống tối ưu - nhưng điều ẩn giấu là sự tích tụ nợ đang làm căng thẳng hệ thống: vòi phải chảy nhanh hơn để bù đắp cho những chỗ rò rỉ, hoặc vòi chảy chậm hơn và bồn tắm mất nhiều thời gian hơn để làm đầy.

Nếu bạn đã quen thuộc với cuốn sách của Meadows - nhiều ví dụ của cô ấy bắt nguồn từ thực tế với các mô hình thường cung cấp một tầm nhìn tĩnh; hệ thống không thay đổi theo thời gian. Nó hoàn hảo cho các mục đích của cô ấy, nhưng khi nói đến cá nhân, nhóm, hoạt động và doanh nghiệp, chúng ta là ai của ngày hôm nay không phải là chúng ta sẽ là ngày mai.

Để xác định Nợ Hệ thống theo một cách hơi khác:

Nợ hệ thống = Lý thuyết hệ thống + Mô hình đáo hạn

Với nhóm Phần mềm, bạn thấy bảng kê khai Nợ hệ thống theo một số cách:

• Cùng với thời gian, nếu không được quản lý, các đội phát triển ngày càng nhiều "kiến thức bộ lạc". Những điều này thể hiện những thói quen, lối tắt và cách giải quyết có chủ đích. Bởi vì chúng tạo ra hiệu quả ngắn hạn, chúng dẫn đến những thiếu sót dài hạn bị bỏ qua. Nếu nó không được trả xuống, có một nguy cơ rõ ràng là mất kiến thức thông qua việc tiêu hao thường xuyên. Điều này dẫn đến tổn thất năng suất khi các nhóm phải xoay vòng và tăng tốc. ("Joe biết điều này, nhưng bây giờ anh ấy đã rời đi - chúng ta sẽ phải dành thời gian để tìm ra nó.") Hoặc một khoản nợ kỹ thuật tích lũy do không quen thuộc. ("Chúng tôi không thể cập nhật thành phần đó. Sally đã xây dựng nó và bất cứ khi nào chúng tôi chạm vào nó, nó sẽ bị hỏng ...")
• Các đội sẽ dựa trên các mẫu thiết kế tùy chỉnh, các quy tắc phát triển không chính thức hoặc các thỏa thuận nhằm tối đa hóa dòng chảy địa phương, nhưng những mẫu đó rất dễ thay đổi. Điều này cản trở việc phân phối khi có thứ gì đó không phù hợp với khuôn mẫu đã thiết lập, khiến nhóm kinh doanh làm con tin cho các quyết định kỹ thuật. ("Chúng tôi không thể tạo ra một phiên bản tùy chỉnh - chúng tôi chưa bao giờ thiết kế nó theo cách đó.")
• Các nhóm phát triển tự mãn đặt quyền ưu tiên vào việc duy trì hiện trạng hơn là các cuộc hồi tưởng gây rối. Họ có thể vẫn giữ quan điểm hồi tưởng, nhưng nếu họ đã mất niềm tin vào khả năng giải quyết các vấn đề thực sự, họ sẽ chỉ tập trung vào việc sửa chữa những điều nhỏ nhặt. ("Chúng tôi đang trở nên quá tải với các yêu cầu sự cố, nhưng bất cứ điều gì - chúng tôi chỉ cần tiếp tục giải quyết chúng, tôi đoán ...")
• Tình trạng bất ổn hoặc thờ ơ đi kèm với việc đạt được tốc độ bền vững bất chấp ma sát có thể giải quyết được. Tốc độ bền vững tạo ra cảm giác sai lầm về hiệu quả. ("Chúng ta có thực sự cần thay đổi quy trình không? Chúng ta đã đạt được bước tiến của mình - tại sao lại làm gián đoạn nó?")

Với nhóm Sản phẩm & Vận hành, bạn thấy Nợ hệ thống theo những cách tương tự:

• Lối tắt "mỗi cuộc gọi của khách hàng là một lần báo cháy" , đang thu hút sự tham gia của nhóm phát triển để nhanh chóng khắc phục các vấn đề nhỏ về việc phát hành chậm trễ, giảm tốc độ, v.v. ("Tôi cần nhóm xem xét một vấn đề do một khách hàng giận dữ nêu ra, nó sẽ chỉ mất 20 phút ... ")
• Sự hỗn loạn giữa người cuối cùng-tôi-nói-là-tôi-ưu tiên cao nhất buộc nhóm phải liên tục chuyển đổi bối cảnh và không thể tập trung vào một vấn đề cho đến khi hoàn thành.
• Khi ưu tiên là một lối tắt thông qua việc sử dụng các số liệu gây hiểu lầm. Ví dụ: khách hàng có nhiều đô la không còn phù hợp với mục tiêu kinh doanh. Chúng có ý nghĩa trong những ngày đầu Khởi nghiệp của bạn, nhưng khi doanh nghiệp đã trưởng thành, chính khách hàng đó đã trở nên có vấn đề hơn. ("Chúng tôi không biết liệu chúng tôi có muốn giữ chân khách hàng này hay không, nhưng họ trả cho chúng tôi rất nhiều nên chúng tôi cần phải làm điều đó ...")

Nhắc lại: Tất cả các hình thức nợ là khi chúng ta chọn đi đường tắt ngay bây giờ với ý định sửa chữa nó sau này. Nợ kỹ thuật là khi chúng tôi làm điều này với mã. Quy trình Nợ là khi chúng tôi thực hiện điều này với các quy trình chính thức của mình. Nợ Hệ thống là khi chúng ta làm điều này ở cấp độ tổ chức. Tôi thích xem nó là 'Nợ hệ thống' thay vì 'Nợ tổ chức' vì nghĩ về tổ chức như một hệ thống, có nghĩa là Nợ về kỹ thuật, quy trình, thiết kế đều do Nợ hệ thống trực tiếp gây ra. Các yếu tố dẫn đến việc chúng tôi chấp nhận Nợ kỹ thuật cuối cùng liên quan đến Nợ hệ thống. ("Bạn chỉ có thể cứu rất nhiều người khỏi chết đuối trên sông trước khi bạn bắt đầu nhìn ngược dòng để xác định lý do tại sao họ tiếp tục rơi xuống.")

Ví dụ: Nhóm phát triển đang phát hành một tính năng mới đã được lên kế hoạch và chi phí hợp lý. Nhóm đã đi đúng hướng nhưng trong giai đoạn cuối cùng gặp phải một vấn đề buộc phải đặt ra một câu hỏi đáng sợ: Trì hoãn việc phát hành bằng cách giải quyết vấn đề đúng cách hay thực hiện bản sửa lỗi tối thiểu và sau đó giải quyết nó đúng cách trong lần lặp tiếp theo? Họ quyết định tiếp nhận Nợ kỹ thuật: "Chúng tôi sẽ xử lý nó trong lần lặp lại tiếp theo."

Đây là lúc Nợ Hệ thống bắt đầu đi vào phương trình. Nhóm nghiên cứu sẽ thực sự có thể giải quyết nó? Nhóm có đủ kỹ năng để tái cấu trúc không? Liệu doanh nghiệp có trả lời rằng "nó đủ tốt, chúng ta cần phải tiếp tục"? Liệu chi phí trong tương lai có tiết lộ rằng bây giờ nó trở nên quá đắt để làm đúng cách không? Liệu sự thay đổi các ưu tiên hoặc sự gia tăng các vấn đề khẩn cấp có đột ngột trì hoãn việc sửa chữa bằng một lần lặp lại khác không? Sau đó, lặp lại khác, sau đó khác ...

Ngoài ra, nhìn ngược lại: tại sao lại mất nhiều thời gian để gặp phải vấn đề này? Những giả định tồi tệ nào đã được thực hiện? Họ có phải là những giả định xấu không? Luôn luôn có vấn đề bạn không thể xác định cho đến cuối trò chơi - nhưng sau đó tại sao nó lại trở thành một câu hỏi về việc trì hoãn việc phát hành? Lời hứa có được thực hiện quá sớm không? Nên có một bộ đệm lớn hơn? Liệu điều này có được giải quyết nếu Người A (nhân viên kinh doanh thượng nguồn) nói chuyện nhiều hơn với Người F (nhà phát triển hạ nguồn) theo chuỗi ngắn nhất ?

Một ví dụ quá quen thuộc khác về cơ sở hạ tầng, kiến trúc và mô hình lưu trữ mà chúng tôi tự khóa mình vào từ rất sớm, dựa trên các giả định về cách doanh nghiệp sẽ mở rộng quy mô trong 3-5 năm nữa. Một nhóm nhỏ có thể chọn nhận nợ cơ sở hạ tầng và kiến trúc sớm để có lợi cho việc phân phối nhanh hơn là tuân thủ các nguyên tắc DevOps tốt nhất.

Tất nhiên, thật dễ dàng để vẽ ra các tình huống như thế này mà không có chi tiết cụ thể - nhưng bất kể chi tiết cụ thể và lý do cho những chi tiết cụ thể đó là gì: Nợ Hệ thống sẽ tích lũy. Nó không thể tránh khỏi. Điều đó không sao - nó chỉ cần sự chú ý liên tục và tập trung vào việc trả nó xuống mức có thể duy trì được.

Phím tắt bù

Chúng tôi coi nợ - Hệ thống hay cách khác - như một con đường tắt. Trước khi tìm hiểu sâu hơn về Nợ Hệ thống và cách trả nợ, trước tiên chúng ta hãy lùi lại một bước và hỏi tại sao chúng ta lại đi tắt? Các phím tắt, giống như Nợ, vốn dĩ không xấu - nhưng chúng nên được phân tích kỹ lưỡng.

Nghĩ về các phím tắt vật lý là một cách tuyệt vời để bắt đầu. Nếu bạn đã từng là người đi bộ hoặc đi xe đạp, chắc chắn bạn đã nhận thấy cách mọi thứ được thiết kế cho phương tiện đi lại trước tiên, người đi bộ thứ hai. Khi bạn đi bộ, bạn sẽ đi theo nhiều “lối tắt” và không đi theo đường - nhưng tất nhiên, đây không phải là những lối đi tắt. Những lối tắt này là những con đường tối ưu nhanh như bay dành cho người đi bộ có thể đi đến những nơi ô tô không thể đi được. Trên thực tế, việc xây dựng các tuyến đường của chúng tôi chủ yếu dành cho ô tô ở những khu vực đông người đi bộ là [một dạng khác] (một dạng khác) của Nợ hệ thống.

Trong thế giới kinh doanh, chúng ta đi đường tắt để bù đắp - thiếu thời gian, thiếu ngân sách, thiếu nguồn lực, thiếu trách nhiệm giải trình hoặc thiếu tầm nhìn rộng hơn. Thời gian, Ngân sách và Nguồn lực đều được chú ý - nhưng trách nhiệm giải trình và quan điểm rộng lớn chính xác là trọng tâm của câu hỏi mở đầu của tôi: Điều này có khó hơn mức cần thiết không? Khi bạn đang cứu người khỏi chết đuối trên sông, đó là hãy nhìn ngược dòng (góc nhìn rộng) và chỉ vào người (trách nhiệm giải trình) tiếp tục thúc đẩy mọi người vào cuộc.

Nói cách khác: Nếu bạn sắp có một cuộc trò chuyện nghiêm túc về Nợ Hệ thống, thì mọi người cần phải là một phần của cuộc trò chuyện. Các nỗ lực bản địa hóa chỉ đạt được cho đến nay.

Vì vậy, làm thế nào để bạn trả nợ Hệ thống?

Hãy quay lại câu hỏi trước đó: Nhóm giao hàng của bạn giao hàng dễ dàng như thế nào? Nếu bạn chưa bao giờ xem xét câu hỏi này, đã đến lúc lấy một số số liệu! Những chỉ số này không nhất thiết phải cung cấp cho bạn câu trả lời nhưng chúng là điểm khởi đầu quan trọng. Khi nói đến KPI, lời khuyên tốt nhất mà tôi từng nhận được là KPI cá nhân không xấu cũng không tốt. Về mặt khách quan nó chỉ là một con số, một giá trị. Đó là công việc kinh doanh của bạn như thường lệ - và để bạn quyết định xem bạn có muốn điều chỉnh con số đó lên hay xuống hay không. Nếu bạn là người yêu thích hệ thống OKR hoặc các mục tiêu SMART, thì điều này thật tuyệt vời vì biết KPI của bạn cho phép bạn tạo ra các OKR tốt hơn và dễ dàng định lượng.

Vì vậy, hãy bắt đầu với một số điều cơ bản và tìm hiểu cỏ dại. Những gì sau đây không phải là một danh sách đầy đủ và có thể có những câu hỏi phù hợp hơn cho nhóm của bạn. Hãy coi danh sách này như một điểm khởi đầu để đặt những câu hỏi hay hơn.

Vận chuyển:

• Thời gian dẫn đầu và chu kỳ của bạn cho các mặt hàng có mức độ ưu tiên cao / khẩn cấp là bao nhiêu?
• Thời gian dẫn đầu và chu kỳ của bạn cho các mặt hàng có mức độ ưu tiên thấp là bao nhiêu?
• Bạn đã phân bổ bao nhiêu để trả nợ?
• Nợ của bạn đang tăng lên bao nhiêu?

Những câu hỏi này có vẻ quen thuộc với bất kỳ ai theo dõi hoạt động của nhóm - nhưng hãy nhớ hỏi những câu hỏi này ở cấp tổ chức. Thời gian dẫn đầu của nhà phát triển có thể bắt đầu từ khi tấm vé được tạo - nhưng nó đã tồn tại trong đầu ai đó bao lâu?

Nguồn lực:

• Cơ cấu đội hiện tại của bạn (tiền bối và hậu bối) là gì?
• Nguy cơ hao mòn của bạn đối với tiền bối và hậu bối là gì?
• Cái giá phải trả của việc mất đi một người cao cấp là gì?
• Cái giá phải trả của việc mất đi một người đàn em là gì?
• Chi phí và thời gian thuê là bao nhiêu?
• Thời lượng phỏng vấn / lên máy bay của bạn là bao lâu?
• Thời gian đào tạo / tăng cường của bạn là bao nhiêu (và những nguồn lực nào cần tham gia và do đó làm giảm năng suất?)

Công việc kinh doanh tồn đọng:

• Giả sử Khung chiến lược của Giám đốc sản phẩm được xác định, có bao nhiêu ngoại lệ được thực hiện?
• Có bao nhiêu Sử thi / Tính năng không bắt nguồn từ các trường hợp kinh doanh được xác định một cách khách quan gắn liền với cả tài chính và khung thời gian?
• Cuối cùng thì đường dẫn Nhà phát triển bán hàng / kinh doanh cung cấp cho phần mềm tồn đọng của bạn như thế nào và thời gian Lead & chu kỳ cho những thứ đó là bao nhiêu?
• Các mục tiêu kinh doanh cấp cao thay đổi thường xuyên như thế nào và sự hỗn loạn đó ảnh hưởng đến những nỗ lực hạ nguồn như thế nào?
• Các mục tiêu tăng trưởng dài hạn của doanh nghiệp là gì và làm thế nào để bộ kỹ năng và kế hoạch nguồn lực của nhóm phù hợp?

Hoạt động tồn đọng

• Có bao nhiêu vấn đề của khách hàng được nêu ra hàng ngày?
• Có bao nhiêu vấn đề khách hàng cần đến bộ phận hỗ trợ Cấp 1, 2, 3?
• Thời gian trung bình để giải quyết là gì?
• Thời gian dẫn đầu cho một vấn đề của khách hàng và thời gian từ cuộc gọi ban đầu đến khi vé phát triển được tạo là bao nhiêu?

Hiểu đơn giản về thời gian mất bao lâu để một thứ gì đó đi từ khi thành lập đến khi có sẵn có thể rất thú vị - đặc biệt khi đó là vấn đề của khách hàng.

Có một số tài nguyên giúp cải thiện các chỉ số ở trên - nhưng triết lý quan trọng đằng sau tất cả những điều này là: 1) Đo lường, 2) Phân tích, 3) Giải quyết, 4) Lặp lại. Càng nhiều vấn đề Cấp 3 có thể giảm tải xuống Cấp 2, càng có nhiều Cấp 2 đến Cấp 1 và càng nhiều Cấp 1 có thể cho phép Khách hàng giải quyết độc lập thì mọi người càng trở nên năng suất hơn.

Nhà phát triển:

• Mất bao lâu để họ lấy nguồn và xây dựng?
• Bạn cung cấp thông tin đăng nhập cho các nhà phát triển mới nhanh chóng như thế nào?
• Làm thế nào họ có thể đứng dậy và tương tác với một môi trường làm việc thấp hơn một cách nhanh chóng?
• Mất bao lâu để một nhà phát triển phát hành mã để sản xuất (tính từ ngày thuê của họ)?
• Mất bao lâu để tăng cường SDLC và các quy trình của bạn?
• Nếu họ bắt đầu giữa Sprint, họ ngồi bên lề bao lâu?
• Nhìn chung, đường cong học tập hiện tại của bạn là gì?

Để so sánh: Etsy là một ví dụ tuyệt vời về hiệu quả và tạo ra một chuẩn mực tuyệt vời. Etsy đảm bảo các nhà phát triển triển khai sản xuất vào ngày đầu tiên của họ .

Nhìn toàn diện:

• Hành trình giao hàng từ khi bắt đầu đến khi có hàng là gì? Vạch ra quy trình làm việc - nó có thể được tối ưu hóa không?
• Hành trình của khách hàng từ bán hàng đến doanh thu (và hơn thế nữa) là gì?
• RPO và RTO là gì?
• Hiệu suất kinh doanh so với những người có hiệu suất phân phối cao như được mô tả trong Accelerate: The Science of Lean Software và DevOps như thế nào?
• 10 kịch bản thảm họa ác mộng hàng đầu là gì? Đây là điều mà FedEx đã làm để cải thiện hoạt động của họ và xây dựng một 'Playbook' nội bộ để biến họ trở thành công ty như ngày nay.

Với tất cả các con số và chỉ số ở trên, tôi sẽ nhắc lại rằng bất kỳ con số nào trong số này đều đại diện cho doanh nghiệp của bạn như bình thường. Mặc dù về bản chất chúng không phải là xấu hay tốt, Nợ hệ thống khiến việc duy trì những con số này lâu dài trở nên khó khăn hơn. Một số con số có thể gây ngạc nhiên và tiết lộ các lĩnh vực mà khoản nợ đó có thể đã có tác động.

Bước tiếp theo là xem xét cách các chỉ số này thay đổi theo thời gian - khi bạn đã trưởng thành và tiếp tục trưởng thành. Ví dụ: các kỹ sư xây dựng sản phẩm cốt lõi đã khóa bạn vào một kiến trúc gần đạt đến giới hạn về khả năng mở rộng của nó. Trong những trường hợp này, các nhóm tìm cách trả nợ Kỹ thuật - nhưng còn Nợ hệ thống thì sao? Với nguồn lực hạn chế, nguy cơ tiêu hao ngày càng tăng và doanh nghiệp đang trưởng thành - làm cách nào để bạn duy trì KPI phân phối trong khi thanh toán Nợ kỹ thuật?

'Giết em yêu của bạn,' Bắn các ngôi sao nhạc Rock của bạn, 'Phá hủy' Nhà máy ẩn 'của bạn, Đừng có ích nữa

Đó là một loạt các tuyên bố táo bạo trong một tiêu đề. Điểm mấu chốt của tất cả là: Việc "hữu ích" để làm tắt một quy trình có thể nguy hiểm. Nếu chúng ta đăng ký với ý tưởng rằng "những gì được đo lường, sẽ được thực hiện", vấn đề trở nên hữu ích là nó thường không được đo lường .

Hãy tưởng tượng một khách hàng đang gọi điện vì họ vô tình xóa một bản ghi trong cổng thông tin của họ khi di chuyển quá nhanh. Chúng có thời gian ngắn - và không thể thực hiện quá trình khôi phục hồ sơ. Họ gọi đến và nhân viên Hỗ trợ khách hàng của bạn, muốn hữu ích, ngay lập tức báo cáo với kỹ sư cơ sở dữ liệu, người muốn được hữu ích, ngay lập tức khôi phục hồ sơ. Khách hàng vui mừng, điểm NPS tăng lên. Mọi thứ đều tuyệt vời, phải không?

Bỏ qua những rủi ro rõ ràng của việc ai đó cập nhật cơ sở dữ liệu sản xuất trong chốc lát, có rất nhiều thông tin hữu ích bị mất đi:

• Tại sao thực hiện một hành động kịch tính lại dễ dàng như vậy mà khách hàng đã phạm sai lầm ngay từ đầu?
• Tại sao việc hoàn tác hành động kịch tính lại khó đến mức họ phải gọi đến?
• Tại sao bộ phận Hỗ trợ khách hàng không xử lý được?
• Tác động năng suất nào là kết quả của việc hữu ích và chuyển đổi ngữ cảnh ? (Một nhiệm vụ 20 phút có vẻ đơn giản nhưng lại trở thành hơn 35 phút vì mất thời gian để trở lại với quy trình làm việc hiệu quả.)

Hãy rõ ràng: tiêu đề của tôi được in đậm. Tuy nhiên, tôi không ủng hộ việc hỗ trợ khách hàng - tuy nhiên, tôi nghĩ rằng những hành động như vậy nên được tuân theo với một số phân tích nguyên nhân gốc rễ. Không có gì quá trang trọng - nhưng là một cái gì đó để tránh một vấn đề tương tự trong tương lai.

Trong một tổ chức, tôi đã cải thiện 50% năng suất của nhóm phát triển chỉ bằng cách triển khai Playbook. Một khách hàng gọi đến và họ sẽ được chào đón một cách nhã nhặn bởi đại diện Hỗ trợ khách hàng, người tuân theo quy trình giải quyết công việc rõ ràng. Nếu họ không thể giải quyết nó, thì chúng tôi có một vòng phản hồi để họ chỉ báo cáo vấn đề một lần. Kết quả là một nhóm Hỗ trợ khách hàng có năng lực và kỹ năng tốt hơn, một nhóm phát triển ít bị gián đoạn hơn, giảm căng thẳng về tổng thể - và quan trọng là khách hàng hài lòng.

Vấn đề là khi công việc hữu ích xảy ra trong bóng tối, bạn không thể khắc phục nguyên nhân gốc rễ.

Chúng tôi cũng thấy vấn đề tương tự với nhà phát triển Ngôi sao nhạc rock, người đảm nhận quá nhiều công việc và trách nhiệm để bù đắp cho một đội có kỹ năng thấp hơn - chỉ khiến họ trở nên thất vọng, kiệt sức và rời đi (một chi phí có thể gây thiệt hại). Cuốn sách tuyệt vời của Will Larson - Một câu đố thanh lịch - thực hiện rất tốt cách xử lý các "Ngôi sao nhạc rock" của bạn.

Sức mạnh của Juniors ...

Những người cao niên rất quan trọng đối với sự thành công của một tổ chức và sản phẩm - nhưng họ cũng là một trong những rủi ro lớn nhất.

Ví dụ: một Nhà phát triển cấp cao sẽ biết cơ sở mã thông qua và thông qua. Họ biết những gì được ghi lại và những gì không. Họ sẽ biết nó có quy mô tốt ở đâu và nó rơi vỡ ở đâu. Họ sẽ biết nơi chôn cất những bộ xương. Chúng tôi thường xuyên tìm đến họ - dựa vào họ để xây dựng và thiết kế các tính năng, giải pháp kiến trúc và giúp giải quyết các lỗi khó nhất. Họ là những chuyên gia kiến thức có thể trả lời bất kỳ câu hỏi nào. Họ đào tạo và cố vấn cho các nhân viên cấp dưới và được tư vấn khi phát triển các giải pháp.

Chỉ cần nói rằng, rất nhiều nhân viên cấp cao được hỏi. Đó là một tuyên bố hiển nhiên, dựa trên kinh nghiệm của họ và có lẽ quan tâm đến sự thành công của tổ chức. Tuy nhiên, tôi muốn nói rằng đây là nơi chúng tôi gánh nhiều Nợ Hệ thống nhất.

Bất kỳ nhân viên cấp cao nào tiến hành một công việc có thể giao được là một lối tắt để tích lũy Nợ Hệ thống.

Tôi sẽ nhắc lại vì rất dễ hiểu sai. Bạn có thể yêu cầu một thành viên nhóm Cấp cao làm việc trên một sản phẩm có thể giao được, nhưng bạn phải có kế hoạch thanh toán khoản nợ sẽ tích lũy khi làm như vậy.

Việc dựa vào Người cao tuổi để giao đồ là một mô hình đã hỏng - đặc biệt là trong thế giới ngày nay, nơi có nhiều ứng viên Cấp độ đầu vào có tay nghề và Người cao tuổi, và rủi ro hao mòn từ Trung cấp đến Cao cấp vừa cao vừa tốn kém .

Lực lượng lao động ảo từ xa đã làm cho bất kỳ tổ chức nào trở nên quan trọng hơn trong việc nâng cao đội ngũ cấp dưới / cấp trung gian trong khi giảm tác động của sự hao mòn của nhân viên Cấp cao. Điều này không có nghĩa là giảm bớt nhân sự Cấp cao, nhưng nó có nghĩa là sự khác biệt về cơ cấu trong cách tiếp cận.

Sử dụng khái quát hóa, các nhóm Cấp cao ngày nay chịu trách nhiệm phần lớn về sự phức tạp đằng sau các hệ thống: kinh nghiệm và chuyên môn của họ tạo ra các hệ thống trưởng thành và các thành phần dựa trên nhiệm vụ nhỏ hơn được thực hiện bởi nhiều thành viên nhóm cấp dưới hơn.

Đây chính xác là mô hình chứng tỏ có vấn đề khi một thành viên Cấp cao rời đi, và cũng là cấu trúc tích lũy Nợ hệ thống. Trong tình huống này, Cấp cao chịu trách nhiệm về sự phức tạp và có thể hỗ trợ khi nhóm cấp dưới không thể phân phối (ví dụ như nhà phát triển "Rock Star").

Vấn đề này càng trở nên trầm trọng hơn do tỷ lệ tiêu hao nhân viên hiện tại: ví dụ, các nhà phát triển Junior trên toàn quốc sẽ giữ một vai trò trong 18-24 tháng (lâu hơn ở các công ty lớn hơn). Nói cách khác, khi một Thiếu niên đạt đến thời điểm mà họ có thể bắt đầu có những đóng góp quan trọng hơn, họ đang trên đường ra đi.

Các tổ chức sẽ đấu tranh để giữ lại nhân viên Cấp cao, đấu tranh (phần nào) để giữ lại nhân viên Cấp dưới - và liên tục bị cạn kiệt kiến thức. Cuối cùng, đây là một trận chiến thua - ngay cả khi nhân viên được giữ lại, hoặc các thành viên mới trong nhóm tham gia, họ hiện đang ở trong tình thế phải trả một số lượng lớn Nợ Hệ thống.

Làm cho công việc tốt trở nên dễ dàng hơn và nâng cao sự bất khả kháng

Hãy tưởng tượng một nhà hàng nhỏ được trao sao Michelin. Đầu bếp trưởng tham gia rất nhiều vào việc sản xuất các món ăn, với các món ăn quá phức tạp để phân phối cho một nhóm đầu bếp. Đầu bếp là nhà hàng trong trường hợp này.

Ngược lại điều này với các nhà hàng nhượng quyền thương mại rộng lớn hơn. Bạn có một bếp trưởng trở lại Công ty, người có trách nhiệm không sản xuất các món ăn cho khách hàng tiêu dùng. Thay vào đó, mục tiêu của họ là sản xuất các món ăn có thể tái sản xuất. Các món ăn có thể dễ dàng tái tạo (trong khi vẫn ngon). Các món ăn được tối ưu hóa sao cho đường cong học tập là tối thiểu - những người mới nấu ăn có thể dễ dàng được đào tạo để sản xuất các món ăn và việc mất đi sự ra đi cuối cùng của họ sẽ ít ảnh hưởng hơn. Các bếp trưởng cũng hợp tác với các chuyên gia về hiệu quả để xem xét cách thức tối ưu hóa nhà bếp của bên nhận quyền để giao hàng.

Đây là mô hình chúng ta nên sử dụng khi chúng ta nghĩ về đội bóng hiện đại. Trách nhiệm của nhóm Cấp cao không nên là sự phức tạp của sản phẩm. Nó nên tập trung hoàn toàn vào việc đơn giản hóa phân phối: đơn giản hóa đào tạo và tăng cường, thiết lập thời gian, xây dựng thời gian, hợp lý hóa thời gian dẫn đầu và chu kỳ (trên toàn diện, từ Bán hàng / Giải quyết sản phẩm, đến Lập kế hoạch lặp lại, đến Phát hành).

Bạn sẽ cấu trúc mọi thứ như thế nào nếu bạn biết rằng bạn chỉ có thể giữ chân mọi người trong 18 tháng? Trên thực tế, bạn sẽ cấu trúc mọi thứ như thế nào nếu bạn đặt chúng vào một hợp đồng 18 tháng, với một thời hạn cuối cùng? Bạn muốn đoạn đường tăng nhanh và ngắn nhất có thể. Bạn muốn nhóm chuyên gia của mình đảm bảo rằng các nhân viên mới của bạn có thể được tăng lên trong vài tuần để họ có thể tối đa hóa tác động. Bạn muốn đảm bảo nhóm chuyên gia của mình có thể giữ một cánh cửa xoay vòng tối đa hóa hiệu quả và không bao giờ can thiệp vào việc hỗ trợ (đối với rủi ro xây dựng Nợ).

Trong việc xây dựng một hệ thống có thể thích ứng hơn, có thể nắm bắt và thúc đẩy việc làm trong thời gian ngắn, sau đó, bạn sẽ giảm tác động nếu bạn mất một thành viên Cấp cao vì kiến thức trở nên bất tử trong quá trình chứ không phải trong con người.

Tag, bạn là nó

Ai đã dạy bạn cách chơi thẻ? Bất kể bạn ở đâu trên thế giới, bạn có thể đã học cách chơi trò chơi này từ những đứa trẻ khác. Người lớn không cần dạy bọn trẻ chơi thẻ.

Chúng ta nghĩ meme là những hình ảnh vui nhộn, nhưng định nghĩa ban đầu của meme là một yếu tố của văn hóa hoặc hệ thống hành vi được truyền từ cá nhân này sang cá nhân khác bằng cách bắt chước hoặc các phương tiện từ tính khác.

Tag là một meme. Không ai sở hữu các quy tắc. Không ai chịu trách nhiệm cải thiện trò chơi. Trên thực tế, các quy tắc rất đơn giản trong khi vẫn hỗ trợ các biến thể như Freeze Tag. Hơn nữa, nó có thể thích nghi với các môi trường khác nhau. Nó được thiết kế cho một cánh cửa quay vòng của những đứa trẻ cuối cùng chuyển thành thanh thiếu niên quá tuyệt.

Có rất ít Nợ Hệ thống đối với một trò chơi như Tag. So sánh Tag với các trò chơi sân chơi khác yêu cầu nhiều người chơi hơn hoặc nhiều thiết bị hơn ... Bulldog Anh, Dodgeball, Duck Duck Goose, Cops 'n Robbers, Red Rover. Có thể bạn đã chơi những trò chơi này, có thể bạn chưa. Những trò chơi này có Nợ Hệ thống nhiều hơn một chút. Nhiều luật lệ hơn, nhiều thiết bị hơn hoặc nhiều người chơi hơn có nghĩa là cần nhiều người hỗ trợ hơn.

Vậy làm thế nào chúng ta có thể hoạt động như Tag?

1. Đòn bẩy người cao niên để hạ thấp thanh . Người cao tuổi không ở đó để chơi Tag hoặc cung cấp thông số kỹ thuật. Mục tiêu của họ là hạ thấp tiêu chuẩn: làm thế nào để mọi người có thể đào tạo nhanh hơn và mang lại giá trị nhanh hơn? Làm cách nào để có thể phát hành thường xuyên, tăng dần và thường xuyên với rủi ro tác động thấp? (* khụ khụ * DevOps, Nhanh nhẹn)
2. Lập bản đồ các quy trình, vạch ra các luồng và xác định các điểm tắc nghẽn: Có thể vấn đề không phải do nhóm phần mềm. Có lẽ nó không phải là thiếu một đội kiểm tra chuyên dụng. Có thể vấn đề nằm ở phía ngược dòng: doanh nghiệp đang làm quá tải đường ống giao hàng với các ưu tiên xung đột?
3. Người lái xe cho người ta nghỉ làm gì? Hoàn toàn không có gì sai khi nghỉ ngơi - nhưng chúng thường là những gợi ý đáng kinh ngạc về sự thất vọng tràn ngập. Theo dõi khi nào và tại sao ai đó bỏ đi có thể rất nhiều thông tin: Có thể họ đã bỏ đi vì mã mất một lúc để biên dịch và triển khai. Có thể họ đã bỏ đi vì họ cần suy nghĩ sâu sắc hơn về một thách thức mà họ đang phải đối mặt. (Đây không phải là một điều xấu, nhưng vấn đề có thể đã được chia nhỏ để giảm bớt sự phức tạp?) Có thể họ đã bỏ qua vì nhu cầu của khách hàng đang làm họ nản lòng. Có thể họ cần phải công bố vì một tính năng mới đang buộc phải thiết kế lại hoặc tiết lộ một giả định xấu.
4. Quan sát việc thiếu thời gian nghỉ giải lao: Một điều tương tự là khi ai đó quá cúi đầu. Họ không thể bước đi - sự chú ý của họ là bắt buộc. Điều này có nghĩa là có sự phụ thuộc quá lớn vào ai đó hoặc công việc và phạm vi đã được xác định quá rộng, hoặc hệ thống cơ bản phức tạp hơn nhiều so với mức cần thiết.
5. Xây dựng văn hóa đơn giản hóa. Đó là, Người quản lý của bạn, Người cao niên của bạn, Người trung gian của bạn - mọi người nên được trao quyền để nói: "Việc này phức tạp hơn mức cần thiết - làm thế nào chúng ta có thể làm cho việc này dễ dàng hơn?" Thu thập thông tin phản hồi - đặc biệt là từ các hậu bối. Đàn em không đủ giá trị. Đừng sai lầm khi nghĩ rằng họ thiếu kinh nghiệm có nghĩa là họ còn ngây thơ. Các thanh thiếu niên có thể không phải lúc nào cũng biết có nhiều cách tốt hơn, nhưng họ rất thẳng thắn về nơi họ sử dụng (và lãng phí) năng lượng của mình.
6. Bất cứ khi nào Cấp cao đóng góp vào việc phân phối, hãy tìm hiểu lý do. Mọi. Thời gian. Một lỗi P0 trong sản phẩm yêu cầu một bản sửa lỗi nóng khẩn cấp. Mã cấp thấp được yêu cầu thay đổi. Một khách hàng cần một cuộc thảo luận. Giám đốc điều hành cần một bản trình bày cho một bản cập nhật.

Nước lên thang máy tất cả các tàu thuyền. Những người cao niên nên là thủy triều, không phải là những con thuyền.

Bằng chứng là trong pudding

Nguyên tắc chỉ đạo xuyên suốt sự nghiệp của tôi là hiểu được vấn đề ảnh hưởng như thế nào đến năng suất. Nó không phải là để tạo ra các nhóm hiệu quả hơn mà là các nhóm có tác động hơn. Người quản lý sản phẩm có câu thần chú đo lường Kết quả, không phải Đầu ra. Hiệu quả quan trọng khi bạn biết mình đang làm gì và bạn chỉ cần làm nhanh hơn. Tác động là một mục tiêu di động vô định hình, kém xác định. Nó đòi hỏi sự thích nghi. Đó là lý do tại sao các nguyên tắc Agile, OKRs, Lean và Kanban có thể trở nên mạnh mẽ khi được sử dụng đúng cách.

Tập trung vào kết quả của toàn hệ thống và thanh toán Nợ Hệ thống đã cho tôi cơ hội để trở nên có tác động theo nhiều cách khác nhau.

• Đối với một doanh nghiệp SaaS, vạch ra quy trình từ súp đến các loại hạt từ giai đoạn đầu trước khi bán hàng cho đến triển khai mã vào sản xuất. Đo lường thời gian Chì và Chu kỳ từ quan điểm của từng giai đoạn để xác định các nút thắt cổ chai. Khi xem nó như một hệ thống, sau đó chúng tôi có thể xác định làm thế nào để đủ điều kiện tốt hơn, loại tốt hơn cũng như cách thức và thời điểm tái cấu trúc quy trình bán hàng và triển khai dựa trên loại khách hàng. Việc áp dụng phương pháp tiếp cận Kanban là kéo công việc thay vì đẩy, thiết lập các giới hạn WIP nghiêm ngặt (trong khi vẫn tính đến độ trễ - xem phép tương tự Drum-Buffer-Rope của Goldratt ) và chính thức hóa Định nghĩa Hoàn thành đã cho phép chúng tôi liên tục cải thiện quy trình làm việc. Cuối cùng, một nguyên tắc bổ sung, trong trường hợp này, là không cho phép quá trình cản trở năng suất . Trong việc tạo một lộ trình tăng tốc, mọi thứ có thể tiến triển nhanh hơn nếu có thể (tức là "các phím tắt") nhưng nó luôn đi kèm với phân tích về vị trí mà quy trình cơ sở không thành công (tức là thanh toán Nợ hệ thống.) Việc triển khai hợp lý này từ 6 tuần trở lên xuống còn 2 và trở thành một hệ thống tự quản lý.
• Nhân sự với Triết lý đầu tiên của Juniors cho phép tôi tăng gấp bốn lần quy mô nhóm của chúng tôi trong vòng 6 tháng. Bằng cách giảm thời gian tăng tốc và tập trung nhóm Cấp cao vào năng suất của Người nhỏ tuổi, có nghĩa là chúng tôi có thể nắm bắt được mức tiêu hao không thể tránh khỏi và dự đoán . Cách tiếp cận này khiến bất kỳ Junior nào đạt được mốc 2 năm với hai lựa chọn hấp dẫn: tốt nghiệp vào một vai trò trung gian hơn, nơi trọng tâm của họ chuyển sang tạo điều kiện cho Juniors khi họ tiếp tục phát triển bộ kỹ năng của mình hoặc làm việc với nhóm trên một lối thoát thân thiện. Sự minh bạch này đã giúp chống lại sự ngứa ngáy trong 2 năm mà Juniors mắc phải khi đối mặt với sự bấp bênh trong sự nghiệp.
• Đưa các nhóm Vận hành và Phát triển dưới một ô quy trình. Điều này đã liên kết các nhóm để thay vì các dòng công việc song song, nó là vòng tròn: Đầu ra của nhóm Vận hành là đầu vào của nhóm Phát triển. Đầu ra của nhóm Phát triển trở thành đầu vào của nhóm Vận hành. Bằng cách thực hiện một cuốn sách "sống" , với các vòng phản hồi chiến lược, các nhóm ngày càng trở nên tự chủ hơn. Điều này giúp nhóm cấp cao không phải tham gia vào các hoạt động và giảm thời gian dẫn đầu từ hơn 7 tháng xuống còn 3 tuần.
• Xoay vòng quan điểm của nhóm phát triển SaaS từ các giai đoạn phát triển phần mềm (xác định, triển khai, xác thực, phát hành) sang tập trung vào khách hàng với trọng tâm là tác động trong khi vẫn ưu tiên công việc gần hoàn thành nhất. Điều này cho phép các nhóm phân phối có ý thức tốt hơn về tác động và các ưu tiên, đồng thời cho phép doanh nghiệp nhận thức rõ hơn và quan trọng hơn về công việc / khách hàng có tác động thấp.
• Đầu tư vào việc hợp lý hóa quy trình phát triển lặp đi lặp lại bằng cách cắt giảm thời gian xây dựng và triển khai. Đây là một trong những khoảnh khắc "Quan sát những khoảng thời gian nghỉ" mà nhóm sẽ thường xuyên bỏ bước do sự bất lực của một quá trình xây dựng / triển khai kéo dài. Quan trọng là, bản sửa lỗi không hoàn toàn là kỹ thuật - mà là một quy trình. Bằng cách thiết lập một quy trình mới, các nhóm giao hàng đã trở nên năng suất hơn 200%.
• Không xây dựng phần mềm cho sự kém hiệu quả của quy trình. Tôi rất thích viết mã để giải quyết các vấn đề thú vị, thì mã mới nên là phương sách cuối cùng. Ngay cả khi mã không có phím tắt và không có Nợ kỹ thuật riêng, mã cần được duy trì. Bạn đã giới thiệu thêm Nợ hệ thống - và không giải quyết được gốc rễ của vấn đề. Những trường hợp này tràn lan và dễ bị bỏ qua - nhưng chúng tương đương với việc giải quyết tình trạng dột mái bằng cách đặt một cái xô trên sàn. Loại bỏ các bản sửa lỗi này bằng cách giải quyết vấn đề gốc rễ sẽ tạo ra hiệu quả không thể đo lường được và cho phép nhóm làm việc trên những gì quan trọng.

Nhưng tôi chỉ là người quản lý cấp trung, làm cách nào tôi có thể thực hiện thay đổi trên toàn tổ chức?

Tôi đã viết trước đó rằng những nỗ lực bản địa hóa chỉ đạt được cho đến nay và tôi vẫn giữ vững điều đó. Khi toàn bộ tổ chức xem xét kỹ lưỡng về cách làm thế nào để hiệu quả hơn, đó là nơi bạn thấy được sự cải thiện thực sự. Những nỗ lực mang tính bản địa hóa mới chỉ đi được đến nay - nhưng chúng đã tiến xa, và khi chúng làm được, chúng sẽ mang theo vốn ảnh hưởng.

Mang đi

Tôi sẽ kết thúc với những nguyên tắc cuối cùng sau:

1. Nợ Hệ thống tích lũy cho bất kỳ lối tắt kinh doanh nào (phần mềm, thiết kế, quy trình hoặc cách khác). Điều đó, tự nó, là OK.
2. Nợ quá nhiều là một điều xấu và đòi hỏi bạn phải trả liên tục và có chủ đích.
3. Việc thanh toán này nên được thực hiện bởi nhóm Cấp cao. Nhóm Cấp cao cũng nên tập trung vào cách giảm thiểu rủi ro đối với các khoản nợ trong tương lai (bằng cách tìm kiếm sự kém hiệu quả của địa phương trước tiên, sau đó là sự kém hiệu quả trên toàn hệ thống). Những người cao niên không nên làm việc với những công việc được giao, nhưng khi họ làm việc đó thì nên làm một lần. Thiết lập các vòng phản hồi hỏi "Tại sao điều này lại cần thiết và làm thế nào chúng ta có thể ngăn chặn nó trong tương lai?"
4. Một thước đo tốt về tình trạng Nợ của Hệ thống là xem xét tình hình hoạt động của đội ngũ cấp dưới của bạn. Lập kế hoạch cho nhóm Junior của bạn rời đi sau 18 tháng. Vậy là được rồi. Cho phép nhóm Cấp cao làm cho họ hoạt động hiệu quả càng sớm càng tốt.
5. Khuyến khích tiếng nói của nhóm Junior để xác định các vấn đề. Ngay cả những vấn đề ngây thơ cũng là dấu hiệu của một vấn đề nghiêm trọng hơn ("Khi nào tôi nhận được địa chỉ email của mình?"; "Làm cách nào để lấy dữ liệu kiểm tra?"; "Nhóm của chúng tôi làm gì?"; "Tôi chỉ lấy mã nguồn và Tôi đang gặp lỗi bản dựng. ")
6. Lập kế hoạch cho bất kỳ người nào ở bất kỳ vai trò nào sẽ rời đi sau 18 tháng. Điều này cũng OK. Nhóm Cấp cao nên ở đó để làm việc xây dựng các quy trình và đường ống cho phép phân phối liên tục bất chấp sự gián đoạn . Họ nên xây dựng các quy trình tự cung tự cấp, các nhóm tự quản lý & tự tổ chức. Nhóm Junior cuối cùng sẽ cảm thấy nhàm chán với công việc, bởi vì nó trở nên lặp đi lặp lại. Các thành viên trong nhóm nên liên tục và tích cực làm cho mình trở nên thừa thãi và không cần thiết.
7. Lập kế hoạch cho những người sẽ ở lại trên 18 tháng. Mặc dù làm việc để khiến bản thân trở nên thừa thãi, bạn sẽ không bao giờ hết việc để thúc đẩy hiệu quả. Xác định Khung nghề nghiệp nâng cao Người chưa thành niên lên Người trung gian, Người trung gian lên Người cao niên phù hợp với hiệu quả tập trung vào kết quả.
8. Hãy đối xử với ngày đầu tiên như thể đó là ngày cuối cùng: Ngày đầu tiên làm việc, nhân viên có góc nhìn tốt nhất về những gì cần làm. Họ nên nghĩ: Nếu có người khác tham gia sau khi tôi rời đi, thì điều này có thể được cải thiện như thế nào?
9. Thường xuyên tổ chức các câu hỏi ngu ngốc Chỉ các cuộc họp. Cho phép mọi người gửi (ẩn danh) những câu hỏi ngu ngốc nhất của họ. Bạn sẽ tìm thấy những lỗ hổng kiến thức lớn nhất (và các vấn đề) theo cách này. Những điều này nên được giải quyết.
10. Lên lịch các cuộc họp 'Giảm tiền' thường xuyên: Tập hợp Nhóm Cấp cao lại với nhau và tìm kiếm những điểm không hiệu quả. Tốn tác động của chúng. Chi phí giải quyết của họ. (Danh sách này là lý do tại sao Nhóm Cấp cao của bạn sẽ không bao giờ hết việc.)
11. Phần quan trọng nhất của Agile là khả năng thích ứng của nó. Điều chỉnh thường xuyên. Có vòng lặp phản hồi. Những thứ đã hoạt động trước đây không phải lúc nào cũng hoạt động. Đó không phải là một vấn đề - đó là tiêu chuẩn. Bất cứ ai chống lại sự thay đổi liên tục và thử nghiệm là một phần lớn của vấn đề hơn họ nhận ra.
12. Cuối cùng, và có lẽ là quan trọng nhất: Đây không phải là một bài tập 'đồng đội'. Đây sẽ là một bài tập cho toàn công ty. Mặc dù bạn có thể thúc đẩy hiệu quả địa phương trong nhóm của mình, nhưng họ sẽ chỉ tiến xa. Điều đó đang được nói, nếu bạn không ở vị trí để ảnh hưởng đến cách tiếp cận trên toàn tổ chức, hãy thu hút sự quan tâm của người quản lý của bạn và sau đó tạo các biểu đồ xung quanh nhóm của bạn để cách ly nhóm của bạn khỏi các yếu tố bên ngoài. Làm việc với người quản lý của bạn để xác định phạm vi của hệ thống nhỏ hơn của bạn, các đầu vào và đầu ra của nó, đồng thời giúp họ xác nhận cách bạn dự định đánh giá, phát triển và thanh toán Nợ Hệ thống của mình.

Đó là tất cả! (Anh ấy đã viết, thừa nhận hoàn toàn trớ trêu khi đã viết bài báo dài nhất của mình.)