Hầu như mọi lỗi được báo cáo là một lỗi ưu tiên cao [đã đóng]

Tôi đã nhận thấy một mô hình trong khi làm việc trên một số dự án phần mềm: phần lớn các lỗi được báo cáo có mức độ ưu tiên cao / rất cao. Tôi đã hỏi một số đồng nghiệp về lý do tại sao điều này có thể xảy ra và họ đã đề cập rằng nếu một lỗi không có mức độ ưu tiên đó thì rất hiếm khi Bug được nhà phát triển chú ý, điều này thực sự có ý nghĩa.

Vì vậy, tôi muốn biết liệu vấn đề này là phổ biến hay tôi chỉ gặp xui xẻo. Tôi đã thực hiện một tìm kiếm nhanh trên Google và tôi thấy rằng một số nhóm thực hiện các nguyên tắc Báo cáo lỗi hoặc có một nhóm "Xử lý lỗi" riêng biệt. Nếu bạn đã đối mặt và giải quyết vấn đề này, phương pháp nào hiệu quả với bạn?

Câu hỏi này đặc biệt về vấn đề "Lạm phát ưu tiên": Nếu bạn phải đối mặt với kịch bản và kết quả của bệnh sởi có hiệu quả đối với vấn đề này.

Tôi đã hỏi một số đồng nghiệp về những gì điều này có thể xảy ra và họ đã đề cập rằng nếu một lỗi không có mức độ ưu tiên đó thì rất hiếm khi Bug được nhà phát triển chú ý, điều này thực sự có ý nghĩa

Trên thực tế, nếu bạn hỏi tôi thì không. Càng nhiều mức độ ưu tiên (được sử dụng), bạn càng có nhiều thông tin. Nếu bạn thực sự chỉ có một ưu tiên, thì đó cũng giống như không có ưu tiên nào cả.

Và vì bạn vẫn có cùng một số lỗi cần khắc phục, và cùng một số lượng lỗi để làm điều đó, nên theo sau đó một số heuristic khác sẽ được sử dụng, có thể là một lỗi - "đến trước được phục vụ trước". Và vì vậy, bây giờ bạn có một số liệu ưu tiên lỗi, ngoại trừ đó là thời gian đến và không còn nằm trong tầm kiểm soát của bạn.

Nó có thể là một triệu chứng của việc không đủ tài nguyên được phân bổ cho việc sửa lỗi (có một số chính sách như " Không có tính năng mới cho đến khi sửa lỗi " có thể giúp đỡ ở đó. Joel chấp thuận ; hiểu giới hạn và hậu quả là quyết định kinh doanh ).

Trong một dự án tôi đã làm việc, các lỗi đến được tích lũy trong "bộ đệm không ưu tiên" và mỗi thứ Hai chúng tôi sẽ xem xét danh sách lỗi, ước tính độ khó (ước tính rất sơ bộ; thường xuyên hơn là chúng tôi không đưa vào, "Trung bình") và sắp xếp chúng theo thời gian có sẵn. Điều này đã có xu hướng giảm xuống danh sách các lỗi nhàm chán, không thú vị hoặc suy nghĩ là khó khăn; để bù đắp cho điều đó, các giám sát viên và tiếp thị có một số tín dụng nhất định mỗi tuần mà họ có thể chi tiêu để vượt qua mức độ ưu tiên của các lỗi yêu thích và được hoàn trả cho các lỗi chưa được giải quyết (điều này đặt ra giới hạn về mức độ lỗi của nhà phát triển có thể bị trì hoãn) .

Cũng có thể hợp nhất, hủy bỏ và phân tách lỗi; Tôi nhớ một mô-đun rất thiếu sót đến nỗi chúng tôi đã gửi một số hai mươi hoặc ba mươi báo cáo lỗi thành một "viết lại điều này từ đầu", sau đó được chia thành "nêu rõ các đầu vào và đầu ra của điều tồi tệ", "viết thử nghiệm để đảm bảo đầu vào và đầu ra khớp với thông số kỹ thuật ", v.v. Mục cuối cùng là "in mã cũ trên giấy tái chế, mang nó ra bãi cỏ và đốt lửa" (chúng tôi cũng đã làm như vậy. Tôi nhớ nó cảm thấy tốt như thế nào. Chúng tôi thay phiên bản eulogy; nó khá vui nhộn ).

Sau một số mặc cả, chúng tôi đã có danh sách việc cần làm trong tuần, được chia thành "sẽ làm", "có thể làm" và "không thể làm" được đưa vào tuần tới. Đây là nơi mà một số mặc cả khác xuất hiện: chúng tôi đã nói rằng năm mươi giờ để phân bổ cho các lỗi và chúng tôi đã chắc chắn 95% để sửa hai mươi đầu. Ban quản lý rất muốn sửa lỗi thứ hai mươi mốt và không còn tín dụng; sau đó chúng tôi sẽ đề nghị trao đổi lỗi đó với một trong danh sách "Sẽ làm" hoặc ai đó sẽ nói "Hãy đưa tôi ra khỏi phụ đề FooBazFeature trong một vài ngày và tôi sẽ làm điều đó", hoặc chúng tôi sẽ nói "Chúng tôi cần nhiều hơn nhân lực ".

Hệ thống làm hài lòng không ai, thực sự, nhưng điều này được tin rằng (ít nhất là trong số các nhà phát triển) là một dấu hiệu tốt.

Một số mô hình tiêu cực bổ sung xuất hiện là "Suy nghĩ mong muốn" về phía người quản lý ("Bạn đã nêu lỗi 57212 cần tám giờ. Điều đó không thể chấp nhận được. Làm cho bốn") và "Gỡ lỗi bởi Fiat" ("Làm bất cứ điều gì bạn muốn nhưng bốn mươi lỗi này phải được sửa trước bản demo lớn vào tuần tới. Bạn không thể có nhiều thời gian hơn, bạn không thể có nhiều người hơn "). Ngoài ra Hội chứng Boxer ("Tôi sẽ làm việc chăm chỉ hơn"), có xu hướng hoạt động rất tốt trong một thời gian ngắn , nhưng thường dẫn đến một nhà phát triển hoảng sợ hoặc rời khỏi đồng cỏ xanh hơn.

Nếu bạn gặp vấn đề này khi người dùng đang gán các lỗi ưu tiên cao hơn bao giờ hết thì giải pháp thực tế duy nhất là cơ chế xử lý. Tất cả các lỗi được báo cáo với bất kỳ mức độ ưu tiên nào chúng thích, nhưng một số người quản lý kém sẽ phải trải qua mọi lỗi mới được báo cáo và đặt lại mức độ ưu tiên của nó về mức hợp lý.

Sau một thời gian, người dùng của bạn sẽ nhận được thông báo hoặc bạn có thể thay đổi hệ thống báo cáo để mọi lỗi đều có mức độ ưu tiên mặc định. Nếu họ muốn nó leo thang, họ sẽ phải liên hệ với ai đó để nâng nó lên, điều này sẽ đòi hỏi một số biện minh. Chỉ riêng thực tế này sẽ khiến 99% tất cả các lỗi không được người dùng nâng cấp.

Rõ ràng là bạn có nhiều lỗi hơn mức bạn có thể xử lý, vì vậy có lẽ bạn cần phải bắt tay vào một bản sửa lỗi để xóa phần tồn đọng. Điều này sẽ cho người dùng thấy rằng các lỗi của họ sẽ được sửa mà không cần phải được đánh dấu là siêu siêu dooper-thực sự-không-trung thực-lần này quan trọng.

TUYÊN BỐ TỪ CHỐI: Tôi chưa có kinh nghiệm với các shenanigans ưu tiên lỗi do người dùng báo cáo. Tôi biết câu hỏi yêu cầu điều này, nhưng nó có thể giúp có quan điểm của người ngoài cuộc.

Vấn đề của bạn không phải là bạn có quá nhiều lỗi ưu tiên cao. Vấn đề của bạn là bạn có quá nhiều người có quyền kiểm soát trực tiếp ưu tiên lỗi. Nếu mọi người dùng có thể trực tiếp gán mức độ ưu tiên cho lỗi của họ, họ sẽ gần như tự động báo cáo vấn đề của họ là mức độ ưu tiên cao.

Bạn có thể làm cho nó trở thành ưu tiên lỗi phải được cấu hình bởi người quản lý hoặc máy bay trợ giúp, nhưng điều này có thể dẫn đến sự thiên vị và kỹ thuật xã hội, nơi khách hàng được ưu tiên cao hơn một cách giả tạo vì trạng thái của họ hoặc vì họ biết cách tạo ra thông điệp của họ làm cho chúng có vẻ quan trọng hơn Nó cũng tốn nhiều công sức hơn.

Có một nền tảng trung gian, nơi người dùng của bạn có một số quyền kiểm soát ưu tiên, nhưng theo cách khiến việc khai thác hệ thống khó khăn hơn. Về cơ bản, bạn buộc người dùng của mình sử dụng một mẫu để báo cáo lỗi. Đầu tiên họ chọn một danh mục:

1. Chương trình trở nên không sử dụng được hoặc gặp sự cố khi tôi làm gì đó.
2. Chương trình có một khiếm khuyết đồ họa ảnh hưởng đến chức năng.
3. Chương trình không cho phép tôi làm điều gì đó tôi có thể làm.
   Chương trình cho phép tôi làm điều gì đó mà tôi không thể làm.
4. Chương trình cho kết quả sai khi tôi làm một cái gì đó.
5. Chương trình mất quá nhiều thời gian để làm một cái gì đó.
6. Chương trình có một khiếm khuyết đồ họa không ảnh hưởng đến chức năng.
7. Chương trình có một khiếm khuyết không phù hợp với một trong các loại trên.

Để đưa ra ví dụ:

1. IPhone của tôi gặp sự cố khi tôi nhận được một tin nhắn có chứa các ký hiệu tiếng Do Thái.
2. Màn hình khóa Android của tôi được xoay theo cách mà một nửa màn hình rơi xuống.
3. Điện thoại Android của tôi đôi khi không chấp nhận mã màn hình khóa của tôi, mặc dù tôi đã nhập đúng mã.
4. Khi tôi cố điều hướng đến PhoneHub.net, điện thoại của tôi chuyển hướng tôi đến một trang web người lớn.
5. Khi tôi mở ứng dụng Facebook, phải mất một phút để mở, ngay cả trên các kết nối nhanh và không có ứng dụng nào khác đang chạy.
6. Ứng dụng của bạn có lỗi chính tả.
7. Tôi tìm thấy một lỗi bảo mật trong chương trình của bạn và muốn báo cáo nó.

Như bạn có thể thấy, mỗi lỗi này có một mức độ nghiêm trọng khác nhau và các loại được sắp xếp theo thứ tự dựa trên mức độ nghiêm trọng này. Sau đó, bạn có thể chỉ định mỗi lỗi một mức độ ưu tiên dựa trên danh mục, người báo cáo và từ khóa xuất hiện trong mô tả. Lỗi trong loại 7 sẽ được ưu tiên chỉ định bằng tay.

Lưu ý rằng điều này có thể xảy ra hoàn toàn tự động, và bạn nên để điều này tự động xảy ra; trong thực tế tự động hóa là chìa khóa ở đây. Người dùng có xu hướng đánh giá quá cao tầm quan trọng của chính họ đối với doanh nghiệp, vì vậy họ không thấy vấn đề trong việc báo cáo lỗi của họ là ưu tiên cao hơn mức họ nên làm. họ ít có xu hướng cố tình đặt lỗi của họ vào một danh mục khác, bởi vì điều đó đòi hỏi họ phải nói dối về lỗi này.

Người dùng vẫn có thể nhập lỗi của họ trong danh mục sai tất nhiên. Điều đầu tiên bạn nên làm là, từ phiên bản 1.0, hiển thị một thông báo thân thiện khuyến khích người dùng cung cấp thông tin chính xác về lỗi để giúp các nhà phát triển tìm và sửa nó nhanh hơn. Hầu hết người dùng sẽ hiểu và ngừng báo cáo sai. Một số người dùng vẫn có thể tiếp tục cung cấp thông tin sai. Khi điều đó xảy ra, hãy gửi cho những người dùng đó một lời nhắc nhở nhẹ nhàng qua thư rằng thông tin chính xác là quan trọng và vui lòng không lạm dụng hệ thống. Nếu họ tiếp tục làm sai lệch hồ sơ, bạn đưa ra cảnh báo rằng họ cố tình lạm dụng hệ thống và tiếp tục lạm dụng sẽ dẫn đến lỗi của họ tự động được chỉ định loại thấp hơn. Nếu họ kiên trì, bạn có thể điều chỉnh hệ số nhân lỗi của họ.

Bạn có thể thấy các bộ phận của hệ thống này thay thế trong các tình huống hỗ trợ thông lượng cao: các công ty công nghệ khổng lồ như Microsoft, Facebook, Google, các công ty trò chơi có nhiều người dùng như Valve và Blizzard, một số chính phủ nhất định, ... Trong khi tôi không chắc chắn về các hoạt động đằng sau hiện trường, bạn nhận thấy rằng hệ thống hỗ trợ người dùng của họ có giao diện tương tự như những gì tôi đề xuất ở đây, với một hệ thống danh mục nghiêm ngặt.

Như mọi người đã nói, đây là lý do tại sao những người báo cáo lỗi không được chỉ định mức độ ưu tiên. Nhóm nhà phát triển của bạn nên kiểm soát việc phân công nhiệm vụ của riêng họ (trong phạm vi được đặt bởi quản lý cao hơn). Vì vậy, có người tiếp tục lên nói "làm việc trên này ứng dụng, sửa chữa này tính năng, làm cho nó tốt hơn ở làm này ", và nhóm nghiên cứu được để quyết định làm thế nào để đi về điều đó, bởi vì họ là những người có chuyên môn kỹ thuật cần thiết để đánh giá mức độ tốt nhất để đạt được những gì quản lý muốn.

Những người báo cáo các lỗi nên được chỉ định mức độ ảnh hưởng hoặc mức độ nghiêm trọng , có phạm vi được xác định. Bạn có thể dễ dàng gọi mọi người ra vì không tuân theo các mức độ nghiêm trọng đã thỏa thuận, bởi vì bạn có bằng chứng vật chất cho các cấp độ đó. Ví dụ:

1. Mất hoàn toàn chức năng
2. Mất một phần chức năng
3. Giảm hiệu quả rộng rãi
4. Giảm hiệu quả cục bộ
5. Khó chịu hoặc cản trở (giải pháp tồn tại)
6. Mỹ phẩm
7. Không ai thực sự nhận thấy, đã được tìm thấy trong thử nghiệm thăm dò tối nghĩa

Để bắt đầu, bạn có thể sử dụng các cấp độ này như một công cụ cùn để chỉ ra rằng việc căn chỉnh một số văn bản tiêu đề không phải là lỗi Cấp 1 vì nó không khiến toàn bộ ứng dụng không thể sử dụng được. Khi họ có ý tưởng, bạn có thể làm cho nó trở nên chi tiết hơn và bắt đầu tranh luận xem liệu trục trặc trong việc cập nhật hộp văn bản này có phải là Cấp 5 hay không bởi vì bạn có thể khắc phục bằng cách nhấp chuột phải vào hộp văn bản một vài lần hoặc Cấp 4 bởi vì nó làm chậm mọi người trong Kế toán nên họ nhận được ít biểu mẫu hơn mỗi giờ.

Khi bạn đã có thông tin hữu ích, có thể đo lường được về mức độ nghiêm trọng của lỗi đối với tổ chức của bạn , việc gán mức độ ưu tiên trở nên rõ ràng. Bất cứ điều gì hiện đang gây ra vấn đề lớn nhất cho tổ chức - lợi nhuận bị mất, thiệt hại cho hình ảnh công cộng, sự bất hạnh của nhân viên, bất cứ điều gì - sẽ là Ưu tiên cao và bạn sẽ làm việc từ đó.

Nó đi một chút như thế này:

Mẹ: bạn đang làm gì vậy? Dev: nhiệm vụ ưu tiên thấp này Mgr: bạn có nên làm việc với các nhiệm vụ ưu tiên cao không?

Khách hàng: khi nào thì lỗi của tôi sẽ được sửa? Dev: đó là mức độ ưu tiên thấp, chúng tôi có các nhiệm vụ ưu tiên cao. Khách hàng: oh, sau đó đặt trạng thái lỗi của tôi thành ưu tiên cao.

Điều này sẽ dẫn đến mức độ ưu tiên leo thang. Tôi thấy bạn đã vượt quá mức ưu tiên cao đến mức ưu tiên rất cao. Điều gì sẽ tiếp theo là:

1. Ưu tiên siêu cao
2. Ưu tiên cực cao
3. Ưu tiên siêu siêu cao.
4. Ưu tiên cực cao siêu siêu Mega.

Vân vân.

Vâng, đây là một quá trình bình thường. Miễn là không có chi phí liên quan đến việc gán mức độ ưu tiên và người gọi có ảnh hưởng, tất nhiên họ sẽ cố gắng giải quyết vấn đề của mình theo cách nhanh nhất và đặt mức độ ưu tiên cao nhất.

Về cơ bản có 2 cách để chống lại điều này:

1. Hãy kiểm soát khách hàng về mức độ ưu tiên.
2. Liên kết một chi phí cho khách hàng cho các mức độ ưu tiên cao.

Người ta có thể thêm các mức độ ưu tiên cao hơn và cao hơn cho hệ thống, đặc biệt nếu đó là Jira. Đưa ra các ưu tiên cao mới ngày càng ngớ ngẩn nhưng những cái tên tàn khốc có thể làm tăng hiệu ứng Hawthorne trong chất lượng của các lựa chọn ưu tiên được thực hiện bởi tất cả các bên. Nếu ưu tiên cao nhất có một tên thực sự kỳ quặc, hiệu quả có thể là vĩnh viễn. Cuối cùng, khi ai đó chọn ưu tiên, họ phải cân nhắc các hậu quả xã hội của việc chọn ưu tiên "lỗi chết" so với việc nhận được sự quan tâm đúng mức. Vì vậy, ưu tiên cao nhất là trên thực tế dành riêng cho điều gì đó đã xảy ra với CTO tại nhà trước mặt khách của mình hoặc các sự cố khác có tầm nhìn tương đương.

Giới thiệu một chi phí để hỗ trợ các yêu cầu. Bạn chỉ có thể cho phép người dùng báo cáo X số mục ưu tiên cao trong một khoảng thời gian nhất định, số Y của các mục ưu tiên trung bình và Z ưu tiên thấp.

Tất nhiên, điều đó cũng có nghĩa là nhóm phát triển và quản lý sẽ phải đảm bảo rằng một số trong số này thực tế sẽ được sửa chữa - tất cả các mục ưu tiên cao, hầu hết các mục ưu tiên trung bình và (có thể) một số mục ưu tiên thấp trong một khung thời gian nhất định.

Nhưng nếu điều này sẽ làm việc, quản lý thực sự sẽ phải mua nó, nếu không toàn bộ bài tập là một sự lãng phí thời gian.

Tuy nhiên, vào cuối ngày, tình huống cụ thể của bạn dường như là một triệu chứng của vấn đề mà quản lý của bạn không phân bổ đủ nguồn lực để xử lý các vấn đề hỗ trợ. Nếu các vấn đề được giải quyết kịp thời, thì tôi không nghĩ điều này sẽ xảy ra.

Một cái gì đó như thế này đã được thực hiện trong công ty đầu tiên tôi làm việc vì quy trình hỗ trợ không ổn định và dẫn đến tình huống nếu mọi thứ đều khẩn cấp thì không có gì. Trong trường hợp của chúng tôi, sau khi kiểm soát được tình hình nội bộ, người quản lý phát triển phần mềm mới đặt giới hạn cứng cho số vấn đề ưu tiên cao mà khách hàng có thể đưa ra tùy thuộc vào số tiền họ đã trả trong các hợp đồng hỗ trợ. Nếu họ đi quá giới hạn, họ sẽ ho nhiều tiền hơn hoặc vấn đề hỗ trợ được ưu tiên hạ xuống.

Điều này xảy ra cực kỳ thường xuyên trong các tập đoàn lớn nơi CNTT được coi là phụ trợ và / hoặc được thuê ngoài. Người kinh doanh không hiểu phần mềm và không quan tâm, tất cả những gì họ quan tâm là lỗi "của họ" đã được sửa vào ngày hôm qua, bất kể nó không quan trọng đến mức nào. Họ không nhận ra, hoặc quan tâm, rằng có hàng trăm người dùng khác cũng đang sửa lỗi và một nhóm có thể có 5 nhà phát triển có sẵn để sửa chữa mọi thứ.

Điều này trở nên trầm trọng hơn bởi quản lý kém, đặc biệt là các nhà quản lý không thuộc CNTT, những người không thể nói "không" hoặc đơn giản là để người kinh doanh đặt ưu tiên lỗi. (Trong cả hai trường hợp, người quản lý cho biết không thực hiện công việc của mình.) Hầu hết các nhà quản lý sẽ ưu tiên lỗi mà họ đã liên hệ lần cuối vì "điều đó là khẩn cấp"; kết quả cuối cùng là các nhà phát triển cuối cùng nhảy từ lỗi này sang lỗi khác, do đó việc sửa một lỗi duy nhất mất nhiều thời gian hơn (chuyển ngữ cảnh) và vào cuối ngày mọi người đều không hài lòng. "Khi mọi lỗi là một lỗi ưu tiên cao, không có lỗi nào là ưu tiên cao".

Tôi đã ở trong tình huống này, và nói chung cách duy nhất để thoát khỏi nó là thoát ra. Nguyên tắc báo cáo lỗi luôn bị bỏ qua vì người dùng không cung cấp dưới dạng ** t. Cố gắng giới thiệu bộ xử lý lỗi sẽ bị chống lại hoặc nó sẽ được thực hiện và sau đó bỏ qua lần sau khi người dùng gọi cho người quản lý của bạn để phàn nàn về lỗi "của họ".

Về cơ bản, nếu các nhà phát triển không kiểm soát mức độ ưu tiên , bạn đã mất.

Là công ty, bạn muốn giải quyết các vấn đề với tỷ lệ quan trọng / chi phí cao nhất. Người dùng quyết định tầm quan trọng, Kỹ thuật quyết định chi phí. Nếu người dùng gán tầm quan trọng như nhau cho tất cả các lỗi, thì chi phí một mình là vấn đề.

Thực tế, điều này có nghĩa là bạn xác định mức độ ưu tiên là mức độ quan trọng / chi phí và không cho phép người dùng hoặc nhà phát triển đặt mức độ ưu tiên đó trực tiếp. Không bên nào có hình ảnh đầy đủ.

Nếu người dùng quyết định xếp hạng tất cả các vấn đề quan trọng như nhau, điều đó không sao - nhưng điều đó có nghĩa là kỹ thuật (chi phí) quyết định những gì đã làm. Giải thích cho họ rằng tầm quan trọng là cách duy nhất mà họ có thể ảnh hưởng (nhưng không quyết định) mức độ ưu tiên.

Một vài yếu tố ...

• Thường thì người báo cáo lỗi không biết bức tranh lớn hơn và không thể quyết định mức độ nghiêm trọng của lỗi.
• Thông thường các lỗi có mức độ ưu tiên thấp không bao giờ được xử lý hoặc xem xét, do đó, tốt hơn là đưa ra mức độ ưu tiên quá cao và để người thực hiện việc phân loại hạ thấp nó.
• Khi tôi phát triển, tôi thường xem báo cáo lỗi và thấy rằng có một vấn đề ưu tiên rất cao đằng sau lỗi, nhưng người quản lý sản phẩm thực hiện việc xử lý không quan tâm đến lỗi.

Vì vậy, tôi nghĩ rằng tất cả các báo cáo lỗi cần được xem xét NHANH CHÓNG bởi một đến hai nhà phát triển có kinh nghiệm, thêm suy nghĩ của họ vào báo cáo lỗi, sau đó lỗi cần phải được xử lý. Mong đợi người tìm thấy lỗi có thể đặt ưu tiên hữu ích tại thời điểm họ tìm thấy, chỉ là yêu cầu quá nhiều.

Hoàn toàn có thể là tất cả các lỗi được đề cập là ưu tiên cao. Tôi đã tham gia vào các dự án vừa bị thiếu vừa thiếu, và khi thử nghiệm bắt đầu, QA và người dùng đã từ bỏ việc báo cáo các mục ưu tiên thấp, vì họ biết rằng lỗi chính tả hoặc trục trặc trong khả năng sử dụng là lãng phí thời gian nếu chức năng cốt lõi của dự án đã hoàn toàn hosed. Nếu hệ thống hành lý tự động của bạn gặp sự cố với nhau và phá hủy hành lý , ai quan tâm nếu phông chữ trên thẻ quá 2pt?

Trong một tình huống như thế này, dự án đang thất bại. Nếu bạn nghi ngờ rằng đây thậm chí là một khả năng, bạn cần một trái tim với những người báo cáo khiếm khuyết để tìm hiểu. Nếu mọi người đang thổi phồng báo cáo lỗi, thì các câu trả lời khác sẽ giúp ích. Nếu các lỗi xấu như báo cáo, thì bạn cần phải có hành động cực đoan .

Hầu hết đã được nói, nhưng tôi sẽ chắt lọc danh sách "sở thú lỗi" xuống một cái gì đó ít chi tiết hơn:

Trả lời: Lỗi ngăn người dùng chết trong các bản nhạc của cô ấy, đưa ra đầu ra sai, thường làm cho hệ thống / tính năng / chức năng không thể sử dụng được. Đó là một lỗi "ưu tiên cao".

B: Mọi thứ khác. Đây là những lỗi "có thể thương lượng".

Các lỗi NEGOTIABLE thuộc nhiều mối quan tâm khác nhau (mà bạn đặt theo thứ tự cụ thể của riêng bạn):

1: Lỗi ảnh hưởng đến an ninh;

2: Lỗi ảnh hưởng đến khả năng sử dụng (thể dục cho mục đích dự định);

3: Lỗi ảnh hưởng đến thẩm mỹ;

4: Lỗi ảnh hưởng đến hiệu suất (có thể là tập hợp con của khả năng sử dụng?);

5: Lỗi xúc phạm sự nhạy cảm của bạn như một lập trình viên chuyên nghiệp;

6: Lỗi làm giảm TRUST NGƯỜI DÙNG;

Vì vậy, đó là thế giới không tưởng rằng không ai trong số chúng ta thực sự sống trong. Thở dài Để hoàn thành câu trả lời của tôi cho câu hỏi nêu của OP, trên toàn bộ ngành công nghiệp phần mềm, nó là hoàn toàn phổ biến cho các nỗ lực phát triển được trong một trạng thái nơi mỗi lỗi duy nhất là một priority- một siêu banger đặc biệt. Và bạn biết họ nói gì về "đặc biệt": khi mọi người đều đặc biệt, không ai là đặc biệt.

Về cơ bản vấn đề này bắt nguồn từ vấn đề phân cấp ưu tiên. Luôn phải có một số lượng người lẻ có khả năng ưu tiên khối lượng công việc của nhóm và 3 người là quá nhiều. Vì vậy, 1 người chịu trách nhiệm cho việc vận chuyển hiệu quả. Và nó nên là một người quản lý / phân tích, tham khảo ý kiến ​​với một nhà lãnh đạo / kiến ​​trúc sư dev. Và quy trình này khá đơn giản và cũng có thể được áp dụng cho các yêu cầu tính năng. Chi phí cho việc phát triển là gì? Giá trị của kết quả mong đợi cho doanh nghiệp là gì. Đầu ra của chức năng đó là ưu tiên được giao.

KHÓA HỌC mỗi người dùng muốn vấn đề của họ được khắc phục trước tiên. Và ngay khi bạn cho phép điều đó, sự hỗn loạn. Bạn không có ưu tiên hợp lệ. Bạn cần điều này được thực hiện bởi một người SINGLE có thẩm quyền (tham khảo ý kiến ​​với người khác khi cần thiết), người có TẦM NHÌN trong tất cả các vấn đề và nhu cầu kinh doanh, và đủ khả năng để thu thập lời khuyên chuyên gia về kinh doanh và CNTT cần thiết và từ đó đưa ra các ước tính chính xác về số liệu ở trên.

Có nguy cơ nêu rõ ràng tôi sẽ cho rằng không có phần mềm theo dõi lỗi nào đang đặt lỗi ở mức ưu tiên cao làm mặc định (hoặc đã được đặt thành cài đặt này).

Tôi e rằng, trong trường hợp không có kiểm soát, đây là kịch bản mặc định cho nhiều nhóm, khách hàng, v.v. báo cáo. Nếu hiện trạng bị lạm dụng thì một số quy trình xử lý chắc chắn theo thứ tự.

Một chiến thắng nhanh chóng mà tôi đã thấy làm việc rất tốt trong quá khứ là P1 (lỗi ưu tiên hàng đầu) sinh ra rất nhiều cảnh báo quản lý. Nếu hệ thống đã bị lạm dụng, nó sẽ bị sập ngay lập tức. Hoặc nếu nó thực sự khẩn cấp, một cuộc gọi hội nghị hoặc cuộc họp thực tế sẽ xảy ra để giải quyết vấn đề càng sớm càng tốt.

Tôi giả sử ở đây rằng bạn đang nói về tất cả các lỗi không chỉ những lỗi từ sự phát triển ban đầu. Nếu bạn thường là một khẩu súng phát triển lĩnh vực xanh cho thuê, thì chắc chắn không có gì lạ khi hầu hết các lỗi đều có mức độ ưu tiên cao sau khi phát hành alpha ban đầu.

Bạn không thể có một ưu tiên và mong đợi mọi thứ sẽ diễn ra một cách kỳ diệu. Đôi khi mọi người tự tìm ra nó, nhưng không phải lúc nào cũng vậy.

Để gán chính xác các ưu tiên, phải có một định nghĩa chính xác những gì cấu thành mỗi ưu tiên. Các tiêu chí này phải khách quan, để tránh sự thiên vị lỗi và ưu tiên chính trị. Nếu các tiêu chí khách quan không được tuân theo, bạn cần phải làm cho nhóm tuân theo nó.

Thực sự không có cách nào khác - nếu bạn không thể có tiêu chí khách quan cho lỗi xảy ra ở đâu và nếu mọi người cố tình từ chối tôn trọng các tiêu chí này, thì bạn cũng có thể không có các ưu tiên được chỉ định của người nộp - hoặc không có ưu tiên hoặc có một bên thứ ba chỉ định mức độ ưu tiên như những người khác đề xuất. Dữ liệu đám đông chỉ hoạt động nếu người gửi hợp tác và không chủ động phá hoại việc thu thập dữ liệu.

Nếu khó khăn xuất phát từ việc không thể tạo tiêu chí khách quan, bạn có thể sử dụng tiêu chí tương đối:

• Có một hàng đợi đơn giản của tất cả các lỗi. Người dùng có thể chèn lỗi bất cứ nơi nào trong hàng đợi. Họ chỉ nên chèn tại một vị trí nhất định nếu họ cảm thấy lỗi của họ quan trọng hơn mọi thứ bên dưới nó. Người sửa lỗi bắt đầu từ đầu hàng đợi.
• Giả sử bạn đã có một bộ các lỗi được phân loại tốt, hãy nói với mọi người rằng điều kiện để ưu tiên một lỗi Xlà nó phải quan trọng hơn tất cả các lỗi được ưu tiên X-1.
• Nói với người gửi rằng không có lúc nào số lượng lỗi có mức độ ưu tiên Xvượt quá số lượng lỗi được ưu tiên X-1.

Nhưng có vẻ như vấn đề của bạn không phải là định nghĩa, mà là niềm tin của những người gửi rằng các lỗi ưu tiên thấp không được khắc phục. Có lẽ, bạn không thể thuyết phục họ bằng cách khác, vì (từ những gì bạn nói) niềm tin của họ là có cơ sở trên thực tế. Sau đó, tại sao bạn làm cho họ gửi những lỗi này? Nó kết thúc không có gì ngoài công việc bận rộn. Ví dụ, bạn có thể đã đạt được một số lỗi hoạt động nhất định, nói với mọi người đừng bận tâm làm báo cáo trừ khi họ cảm thấy họ tìm thấy thứ gì đó quan trọng hơn hầu hết các lỗi nổi bật. Cấp, đây chỉ là giải pháp hàng đợi với giới hạn trên về chiều dài hàng đợi.