Có phải các nhóm của tôi vượt quá tầm kiểm soát?

Tôi là trưởng nhóm phát triển phần mềm (gần đây tôi đã nắm quyền kiểm soát một nhóm mới) và cuối cùng chịu trách nhiệm duy trì năng suất cao, chất lượng tốt và các ưu tiên có tổ chức.

Tôi có 6 nhà phát triển cao cấp trong nhóm của mình, nhưng mọi thứ cảm thấy như một mớ hỗn độn ở đây. Tình huống là tôi phải giải quyết các yêu cầu của JIRA từ khoảng 10 điểm liên lạc khác nhau trong công ty của chúng tôi và tất cả chúng đều đại diện cho các đơn vị kinh doanh hoặc khách hàng khác nhau.

Vấn đề tôi gặp phải là công việc của tôi chủ yếu bao gồm dập lửa cả ngày và đảm bảo rằng mọi vấn đề của mọi người đang được giải quyết. Thật không may, văn hóa trong công ty của chúng tôi có năng suất cao (phát hành nhanh) nhưng chất lượng thấp (lỗi sản xuất) và khách hàng của chúng tôi sẽ không chấp nhận sự chậm trễ đột ngột trong kết quả.

Một số cách tốt để xử lý này là gì? Tôi có vô số lý thuyết, nhưng tôi đang tìm kiếm câu trả lời từ một người thực sự có kinh nghiệm làm việc trong một tình huống như của tôi.

Đây là một danh sách nhỏ về cách mọi thứ hoạt động:

• Mỗi nhà phát triển chịu trách nhiệm cho một ứng dụng và dịch vụ cụ thể tương tác với nó;
• Các bản phát hành thường được khách hàng kiểm tra trong một máy chủ sản xuất mô phỏng và sau đó được triển khai đến máy chủ trực tiếp;
• Mỗi ứng dụng được sử dụng bởi trung bình 50-80 người, với tổng số 8 ứng dụng.

Cảm ơn

khách hàng của chúng tôi sẽ không chấp nhận sự chậm trễ đột ngột trong kết quả

Chà, sau đó họ phải chấp nhận chất lượng kém mà họ đang nhận được.

Những gì bạn phải làm để thay đổi điều này là khiến khách hàng của bạn chấp nhận thực tế phát triển phần mềm (hoặc bất kỳ sản xuất nào khác!): Rằng những thứ vội vã ảnh hưởng đến chất lượng.

Tạo một danh sách lớn những điều đang sai - về những điều bị phá vỡ, những lần họ đã gây ra để phàn nàn. Giải thích cho họ lý do cho những vấn đề này và cho họ biết bạn muốn làm gì để thay đổi điều đó. Hãy chắc chắn rằng bạn giải thích cho họ phần trăm thời gian mà nhóm của bạn dành để hỗ trợ và sửa chữa các ứng dụng trực tiếp. Nếu bạn không thu thập dữ liệu về điều đó, bây giờ là thời gian để bắt đầu (và thu thập dữ liệu trong một tháng trước khi bạn trình bày thông tin cho khách hàng).

Nhận các bên liên quan chính trong một phòng và nói: "bạn muốn X cố định hay bạn muốn Y được giao? Chúng tôi chỉ có thời gian cho một trong hai." Làm cho họ có trách nhiệm thiết lập các ưu tiên, và rõ ràng rằng bạn có năng lực hạn chế. Nếu họ yêu cầu một cái gì đó mới, hãy hỏi họ những gì họ sẵn sàng hy sinh từ lộ trình hiện tại của họ để đạt được nó.

Hỏi nhóm của bạn thời gian và tài nguyên họ cần để "đặt mọi thứ đúng" (cả về cách sửa các lỗi cơ bản và về cách khắc phục các vấn đề lớn hơn về chất lượng / kiến ​​trúc / v.v.). Bao gồm những mục đó trong danh sách những điều mà các bên liên quan của bạn phải ưu tiên.

Điều tốt nhất tôi từng làm trong công việc hiện tại của mình là đưa 8 bên liên quan hàng đầu vào một phòng cùng lúc và đưa ra một đống 16 thẻ chỉ số đại diện cho các tính năng mới đã được yêu cầu. Tôi lùi lại khỏi bàn và nói: "chúng ta có thể giao một trong những thứ này cùng một lúc. Bạn muốn chúng theo thứ tự nào?" Hãy để họ tranh luận eachother qua ưu tiên kinh doanh thay vì bạn bị mắc kẹt ở giữa.

Ngừng thả và cuộn. Hỏa hoạn cần nhiên liệu và thường nó ở dạng hoảng loạn. Dành thời gian để quản lý bản thân và nhóm theo thứ tự. Đánh giá các nhà phát triển của bạn và xem liệu bạn có bất kỳ ai không đủ kỹ năng và / hoặc không làm việc chăm chỉ để tạo ra kết quả bạn muốn. Quyết định ai ở lại (và nỗ lực để giữ họ), ai cần một chút thúc đẩy, phần còn lại phải đi. Đánh giá sự hỗ trợ và các công cụ mà các lập trình viên của bạn đang nhận để đảm bảo rằng họ có thể thực hiện công việc của mình. Đảm bảo kiểm tra âm thanh, xem xét, kiểm soát nguồn và tài liệu được theo dõi. Những người giỏi với các công cụ tốt cần có trách nhiệm để làm tốt công việc.

Phải có một hệ thống để biết nhóm của bạn cần làm gì, hiện đang làm việc và khi nào họ dự kiến ​​sẽ hoàn thành. Rất nhiều phương pháp, lý thuyết, phần mềm, bảng xóa khô và ghi chú dán, tài liệu và email để thực hiện điều này. Làm cho một cái gì đó hoạt động bằng cách làm cho tất cả mọi người dính vào nó. Nếu mọi người đều có một số đầu vào vào hệ thống, sẽ có nhiều động lực hơn để theo dõi nó.

Hiểu rõ hơn về những gì khách hàng mong đợi. Đây có thể không phải là một phần của công việc của bạn. Có thể có những cá nhân khác giả vờ tóc họ đang bốc cháy, khách hàng của họ không vui và bầu trời sụp đổ. Đó là những gì họ làm và một số thực sự giỏi về nó. Nếu tất cả mọi thứ là một trường hợp khẩn cấp, thì không có gì là khẩn cấp vì tất cả sẽ không được thực hiện. Đề nghị ngồi vào thảo luận với khách hàng thỉnh thoảng. Bạn sẽ thấy rằng nhiều người 'tốt bụng để biến thành' người giải quyết thỏa thuận 'theo thời gian họ đến đội nhà phát triển. Hãy là người liên lạc kỹ thuật hoặc một số lý do khác để giúp đỡ. Thực hiện những lời hứa mà bạn không thể giữ còn tệ hơn là nói với họ những gì họ không muốn nghe ở nơi đầu tiên. Chúng tôi muốn làm một công việc tốt vì vậy chúng tôi cần 8 tuần chứ không phải 5. Họ sẽ hạnh phúc hơn về lâu dài.

Cuối cùng, bạn cần giáo dục khách hàng của mình về phát triển phần mềm và liên quan đến họ trong quá trình này càng nhiều càng tốt. Những gì họ đang thấy bây giờ là cung cấp nhanh chóng các tính năng mới nhưng cũng có lỗi trong phần mềm. Trong khi họ sẽ hạnh phúc với người trước, họ sẽ không (hoặc không nên) hạnh phúc với người sau.

Bạn cần giải thích với họ rằng với các quy trình tốt hơn trong khi việc phân phối phần mềm mới sẽ bị trì hoãn bởi một lượng ngắn, sẽ có ít lỗi hơn (sẽ không bao giờ có số không). Nếu bạn có thể đồng ý rằng đây là con đường phía trước, bạn sẽ có thể bắt đầu giới thiệu các quy trình bạn cần để lấy lại quyền kiểm soát sự phát triển của mình.

Sử dụng quy trình Agile có thể giúp ích ở đây khi họ đề xuất (và trong một số nhiệm vụ triển khai) rằng khách hàng được đưa vào như một phần của nhóm. Nếu bạn liên quan đến khách hàng rất chặt chẽ, họ sẽ thấy những gì đang hoạt động và những gì bạn có thể sản xuất đầu tiên.

Ý kiến ​​(kinh nghiệm hạn chế) của tôi: Tôi nghĩ có hai vấn đề cần giải quyết. Đầu tiên, quy trình chất lượng. Bạn có sử dụng scrum / thác nước / cái gì đó ở giữa không? Trong scrum, bạn có thể thêm các tác vụ bổ sung cho mỗi câu chuyện: 1 để đưa ra một kịch bản / kế hoạch thử nghiệm, một kịch bản khác để chạy nó, một nhiệm vụ khác để đánh giá mã, v.v. Trong thác nước, bạn có thể chỉ cần thêm các bước này vào không?

Vấn đề khác là vấn đề chính lớn tồn tại ở mọi nơi trong phần mềm. Quản lý kỳ vọng. Tức là tăng thời gian từ ai đó hét lên rằng họ cần một nút để thực hiện X để giao nó.

Nếu bạn có thể thêm các bước bổ sung vào quy trình và đưa ra thông báo phô trương lớn về nó [chúng tôi hiện đang thực hiện quy trình chất lượng này: điều đó có nghĩa là sẽ sửa lỗi ít thời gian hơn! và kết quả chất lượng tốt hơn! email / cuộc họp lớn, v.v. để cho họ biết] và cung cấp kết quả thường xuyên (ala scrum), ý tưởng là những người bạn đang gửi sẽ tìm hiểu và xem giá trị trong các bước của quy trình bổ sung và họ sẽ mua nó. Sửa lỗi ít thời gian hơn = nhiều thời gian thực hiện và kiểm tra các tính năng.

Khách hàng sẽ không chấp nhận sự chậm trễ đột ngột trong kết quả? Họ khá nhiều phải. Rõ ràng là nó không thể tiếp tục như vậy. Có lẽ bạn có thể thêm các bước QA bổ sung và sau đó nếu cần thêm thành viên nhóm? Nhưng các bước chất lượng là hoàn toàn cần thiết.

Một lần nữa nếu bạn sử dụng scrum hoặc tương tự, bạn có thể nhắm đến một cuộc chạy nước rút một tuần để có kết quả giao hàng thường xuyên. Điều đó sẽ xoa dịu mọi người cũng như quay vòng nhanh.

Hy vọng điều đó sẽ giúp ở một mức độ nào đó ... hy vọng tôi đã không bỏ lỡ vấn đề.

Những gì bạn mô tả nghe có vẻ rất bình thường và không thực sự đáng báo động.

• Khách hàng thường có suy nghĩ khác về những gì quan trọng hơn các kỹ sư. Chúng tôi thích mọi thứ là đúng, nhưng khách hàng phải đối mặt với một thực tế rằng thưởng đúng giờ hơn độ tinh khiết. Họ cần giải quyết vấn đề của họ một cách nhanh chóng để có thể cạnh tranh và đó chính xác là những gì họ đang trả tiền cho bạn.
• Đặt mức độ ưu tiên quá lớn và nhiều lông cho một người để quản lý một mình, tồn đọng các vấn đề quan trọng (vì vậy bạn đang sử dụng JIRA), với các trung úy quản lý từng lĩnh vực quan tâm là lựa chọn tốt nhất chúng tôi có để giữ công việc bất lực ở phía trước thời khóa biểu.

Không có gì phải lo lắng. Điều đó nói rằng, bạn có thể tiết kiệm cho mình rất nhiều nỗi đau bằng cách chuyển càng nhiều nhiệm vụ quản lý càng tốt cho khách hàng trả tiền, bằng cách đưa họ vào quá trình phát triển đặt ưu tiên và xuống công nghệ, tự động hóa càng nhiều thói quen như khả thi.