Cách thích hợp để xử lý các yêu cầu ngầm là gì?

Tôi đang làm R & D làm việc trên một sản phẩm phần mềm mới.

Quản lý tập trung một cách dễ hiểu vào các tính năng chính rõ ràng mang lại lợi thế cho khách hàng. Nhưng có nhiều yêu cầu có thể được xem là quan trọng (ví dụ như hiệu suất, khả năng mở rộng trong tương lai, truy xuất nguồn gốc dữ liệu, bảo mật, giao diện người dùng trơn tru ). Những yêu cầu ngầm này có lẽ là số lượng lớn hơn cho bất kỳ sản phẩm nào và nếu không được thực hiện có thể dẫn đến một khách hàng không hài lòng.

Tôi sợ rằng bằng cách nào đó dự kiến ​​rằng trong quá trình phát triển, những điều này sẽ tự động được thực hiện. Đối với tôi, tất cả mọi thứ là một khía cạnh nguyên tử đòi hỏi sự chú ý và nỗ lực phát triển của chính nó.

Tôi có cảm giác rằng quản lý có thể quá bận rộn để chú ý quá nhiều vào các khía cạnh như vậy. Vì niềm tự hào của nhà phát triển, kiểm soát chất lượng của riêng tôi và có thể tính đến công sức tôi bỏ ra, khi nào và làm thế nào tôi nên ghi lại và truyền đạt các yêu cầu ngầm?

(tức là các tính năng tồn tại trong một sản phẩm, nhưng chưa được nói rõ ràng với khách hàng hoặc quản lý)

Làm rõ

Cảm ơn bạn đã quan tâm đến câu hỏi, ý chính của các câu trả lời cho đến nay dường như là:

"Bạn cần phải làm cho các yêu cầu ngầm rõ ràng."

Chuột ... điều đó đã không xảy ra với tôi.

Các yêu cầu tôi có thể có các loại sau:

• Khách hàng không thể nghe về những yêu cầu này, vì tôi sẽ trình bày một danh sách dài các cách mà sản phẩm có thể thất bại, thay vì nói về cách nó sẽ khiến họ hài lòng.
• Quản lý bận rộn cảm thấy rằng tôi đang lãng phí thời gian của họ, khi tôi nói về các tính năng "rõ ràng".
• Tôi sẽ chỉ có thể mô tả một số các yêu cầu này trong khi thực hiện. Trong quá trình lập kế hoạch tôi có thể có cảm giác đặc biệt rằng một vấn đề cụ thể có thể đòi hỏi nỗ lực tập trung trong quá trình phát triển.
• Tôi không ở độ cao cần thiết trong cột totem của công ty để ra lệnh cho điều kiện làm việc của tôi.

Tôi đang yêu cầu hướng dẫn cách bán chính thức các yêu cầu [ngầm], trong khi nỗ lực ít hơn so với yêu cầu toàn diện, nhưng giữ cho tôi chuẩn bị cho ngày phán xét, để tôi không bị bắt tay.

Làm cho các yêu cầu ngầm rõ ràng là câu trả lời chính xác.

Về những hạn chế theo dõi của bạn:

Khách hàng không thể nghe về những yêu cầu này, vì tôi sẽ trình bày một danh sách dài các cách mà sản phẩm có thể thất bại, thay vì nói về cách nó sẽ khiến họ hài lòng.

Hãy tưởng tượng bạn là một kiến ​​trúc sư, bạn thiết kế các tòa nhà cho các công ty lớn.

Big Co. Inc. yêu cầu bạn xây dựng một tòa nhà chọc trời cho họ bên bờ. Nó phải có một bể bơi trên mái nhà, và một bể bơi khác trên tầng 10. Nó phải có một khu vườn trên tường bao phủ bức tường bên ngoài từ tầng 15 đến tầng 17.

Đây là yêu cầu của khách hàng. Bạn có ngần ngại thêm vào danh sách các yêu cầu để yêu cầu tòa nhà hỗ trợ trọng lượng của chính nó cộng với hai hồ chứa đầy nước và một khu vườn treo tường không?

Bạn có ngần ngại thêm rằng nó phải có hệ thống ống nước, hệ thống dây điện và hệ thống để làm đầy nước trong hồ bơi và giữ cho nước sạch?

Bạn là kiến ​​trúc sư, bạn biết những gì cần thiết cho một tòa nhà, đó là những gì họ đang trả tiền cho bạn.

Bạn biết rằng một tòa nhà có hơn ba tầng sẽ cần một thang máy, bạn không cần ai nói với bạn điều đó.

Quản lý bận rộn cảm thấy rằng tôi đang lãng phí thời gian của họ, khi tôi nói về các tính năng "rõ ràng".

Vì vậy, thang máy là rõ ràng. Rõ ràng như nó là, nó vẫn có tác động trong chi phí tổng thể, lực lượng lao động tổng thể cần thiết, ETA cho dự án và có thể các khía cạnh khác.

Tôi sẽ chỉ có thể mô tả một số các yêu cầu này trong khi thực hiện. Trong quá trình lập kế hoạch tôi có thể có cảm giác đặc biệt rằng một vấn đề cụ thể có thể đòi hỏi nỗ lực tập trung trong quá trình phát triển.

Đây là nơi mà kiến ​​trúc sư tương tự phá vỡ, chủ yếu là do tính chất lỏng của CNTT. Lời khuyên duy nhất của tôi ở đây là bạn có thể được hưởng lợi từ một quá trình lặp đi lặp lại cho phép bạn lên kế hoạch cho những điều không có kế hoạch. Agile có vẻ khá phổ biến.

Tôi không ở độ cao cần thiết trong cột totem của công ty để ra lệnh cho điều kiện làm việc của tôi.

Công ty của bạn nên có người chịu trách nhiệm đảm bảo danh sách yêu cầu đã hoàn thành.

• Nếu họ không có vấn đề lớn, hãy cố gắng để họ sửa nó hoặc bắt đầu đánh bóng sơ yếu lý lịch của bạn.
• Nếu họ làm nhưng người đó không làm đúng công việc của anh ta, hãy gọi anh ta trên đó và leo thang khi cần thiết.
• Nếu họ làm và người đó là bạn, nhưng bạn không được trao quyền để thực hiện công việc của mình, thì họ sẽ yêu cầu bạn làm điều gì đó không thể, cách tốt nhất của bạn là không chơi (hay cố gắng để họ sửa nó hoặc bắt đầu đánh bóng sơ yếu lý lịch của bạn).

Xác định mọi thứ. Điểm trừ tiềm năng duy nhất để làm như vậy là bạn có thể nhận lại được điều gì đó phàn nàn rằng họ cảm thấy bạn nói rõ điều đó.

Nhà nước rõ ràng rồi.

Đây là chìa khóa: Bất cứ điều gì bạn không xác định có thể bị ném lại vào mặt bạn với "bạn không bao giờ nói với chúng tôi ..."

Bất cứ điều gì không được xác định có thể có khả năng nổ tung trên khuôn mặt của bạn. "An toàn hơn xin lỗi" là những từ tuyệt vời để sống.

Thuật ngữ công nghiệp cho các yêu cầu như bạn mô tả được gọi là:

Những yêu cầu vô lý

Chúng dưới mọi khía cạnh phải được xác định bởi các nguồn lực kỹ thuật và được thêm vào kế hoạch dự án dưới dạng các đơn vị công việc nguyên tử. Nếu bạn đang thực hiện một dự án Agile thì chúng sẽ được viết dưới dạng câu chuyện người dùng và thêm vào hồ sơ tồn đọng để xử lý. Là tài nguyên kỹ thuật, bạn cần phải ủng hộ thời gian để làm việc trên những thứ này và đảm bảo rằng chúng có mức độ ưu tiên phù hợp trong quá trình lập kế hoạch nước rút hoặc kế hoạch dự án của bạn với doanh nghiệp. Hơn nữa, QA cần phải đưa ra một kế hoạch kiểm tra thích hợp cho các đơn vị công việc này.

Khi điều đó xảy ra, chúng tôi đã có một số yêu cầu ngầm đó cắn chúng tôi vì chúng không được xác định và do đó QA đã không kiểm tra chúng và các lỗi đã được sản xuất và không được tìm thấy trong một thời gian, không chỉ gây rắc rối cho việc giải thích cho khách hàng vấn đề và tại sao nó không được tìm thấy trước đó nhưng là một vấn đề pháp lý thực sự cho công ty chúng tôi. (Đó là một báo cáo xử lý thông tin phải được báo cáo cho chính phủ.)

Nếu nó đủ quan trọng để làm, nó cần phải được kiểm tra và do đó nó cần phải là một phần của các yêu cầu.

Các yêu cầu có thể đến từ bất kỳ nguồn nào, miễn là chúng có thể truy nguyên được từ nơi chúng đến và không xung đột với nhau. Khách hàng có thể cung cấp các yêu cầu của họ, nhưng các yêu cầu cũng đến từ luật pháp và quy định, tiêu chuẩn ngành, nhu cầu kinh doanh và thậm chí cả kinh nghiệm trước khi học bằng cách cung cấp các sản phẩm tương tự cho các khách hàng khác.

Mỗi yêu cầu này phải được nắm bắt trong bất kỳ phương pháp nào bạn sử dụng để nắm bắt các yêu cầu để không bị lãng quên. Làm điều này cũng sẽ cho phép chúng được so sánh để đảm bảo rằng một yêu cầu bổ sung không thực sự mâu thuẫn với yêu cầu của khách hàng hoặc yêu cầu của khách hàng không mâu thuẫn với các quy định, chẳng hạn.

Bạn nên nắm bắt những yêu cầu này và quản lý chúng ngay từ khi bắt đầu dự án và chuyển chúng xuống cho đội ngũ nhân viên đang thiết kế, thực hiện và thử nghiệm phần mềm. Làm điều này sẽ đảm bảo rằng mọi người đều hiểu đầy đủ phần mềm được phân phối là gì.

Tuy nhiên, khi bạn thêm một trong những yêu cầu này, bạn nên xác minh nó với các bên liên quan thích hợp. Bạn không thể chỉ cần thêm yêu cầu mà không đảm bảo rằng bạn vẫn có thể phân phối phần mềm trong lịch trình và ngân sách dự định.

Đây là khi có một nhóm đa dạng có những người chuyên về các lĩnh vực khác nhau tham gia. Nó cũng đòi hỏi nhiều sr hơn. người trong đội dẫn đầu phần còn lại.

Ví dụ, hiệu suất, khả năng mở rộng trong tương lai và truy xuất nguồn gốc dữ liệu thực sự nên là những điều được nghĩ đến ngay từ đầu. Chúng không phải là một hộp kiểm mà bạn có thể quay lại và thêm vào sau, chúng cần nằm trong nền tảng của thiết kế của bạn.

Về bảo mật, đây là khi có người quen thuộc với khu vực này ngay từ đầu trong nhóm của bạn để giúp đỡ trong quá trình thiết kế.

Thiết kế UI có xu hướng cắn một sản phẩm nếu không được thực hiện đúng cách. Có một người UX trong đội thực hiện các mô hình và dòng chảy màn hình cho đội là nơi điều này diễn ra. Nhưng, một lần nữa, đây là điều cần được thực hiện trước.

Yêu cầu của bạn có thể là một trang web cho phép người dùng tra cứu hàng tồn kho hiện tại của một cửa hàng địa phương. Làm thế nào bạn thiết kế hệ thống đó là nơi những yêu cầu ngầm đó rơi vào chơi.

Từ quan điểm quản lý dự án, điều này có nghĩa là cần phải có thời gian thiết kế trong ngân sách, cũng như thời gian thử nghiệm thích hợp. Cũng cần có những đăng ký với khách hàng để cho họ thấy những gì đã được thực hiện để đảm bảo bạn đang đi đúng hướng.

Bất kỳ yêu cầu ngầm nào sẽ kết thúc gây ra công việc cho nhóm nên được làm rõ ràng.
Nếu không, họ sẽ kết thúc

1. cắn bạn sau này khi mọi người đưa họ lên bằng mọi cách, gây ra sự phát triển quá mức
2. bỏ qua và sau đó báo cáo là lỗi
3. dù sao cũng được thực hiện, mặc dù chưa được lên lịch, gây ra lỗi tràn ngập và báo cáo lỗi vì chúng không được thực hiện vì khách hàng đã nghĩ rằng họ nên có nhưng không bao giờ được đề cập.

Vì vậy, bằng cách làm cho các yêu cầu ngầm rõ ràng, bạn tiết kiệm cho mình rất nhiều đau đầu.