Xác minh yêu cầu của người dùng, làm thế nào?


8

Câu hỏi của tôi là: Làm thế nào bạn có thể xác minh sớm các yêu cầu của người dùng trong quy trình tạo phần mềm?

Tôi hiển thị thông số kỹ thuật người dùng, nguyên mẫu, bản trình diễn ... nhưng người dùng vẫn quên chia sẻ một số "chi tiết không đáng kể" về quy trình hoặc quy tắc kinh doanh và dữ liệu. Nó bật lên sau bài kiểm tra cuối cùng như một số "trường hợp ngoại lệ thực sự nhỏ và hiếm" - được chuyển thành yêu cầu thay đổi và tích lũy rất nhiều công việc.

Vì vậy, làm thế nào để bạn nguyên mẫu (hoặc xác minh) yêu cầu người dùng sớm trong dự án?

Câu trả lời:


2

Sử dụng phát triển lặp lại buộc bạn phải có phản hồi thường xuyên cho khách hàng / người dùng.

Đồng thời tăng sự hợp tác giữa các nhà phát triển và người dùng bằng cách loại bỏ (thường là vô dụng) như các nhà quản lý dự án hoặc thậm chí các nhà phân tích kinh doanh (sau này có thể rất cần thiết trong các lĩnh vực kinh doanh rất phức tạp).

Đó chỉ là một vài lời giới thiệu. Có rất nhiều điều để nói về chủ đề này.

Tôi đánh giá cao bạn nên xem Scrum . Mà cứu mạng tôi.


Quá trình lặp đi lặp lại. Nó rất tốt, nhưng vẫn không loại trừ "các chi tiết nhỏ" xuất hiện trong một lần lặp lại muộn ... nơi bạn phải thay đổi rất nhiều mã để tích hợp "chi tiết samll" này.
user7876

Theo đề xuất, bạn thường có thể giảm những chi tiết nhỏ đó bằng cách tăng sự cộng tác trực tiếp. Điều này sẽ không xóa sổ chúng. Bạn phải chấp nhận thực tế rằng bạn sẽ gặp lại những trường hợp đó và cách duy nhất để xử lý chúng là nắm lấy những thay đổi. Một tính năng không được hiểu theo yêu cầu? Điều này sẽ được cố định trong lần lặp lại tiếp theo.

5

Bắt đầu bằng cách không loại bỏ các trung gian như các nhà phân tích kinh doanh, bởi vì họ thực sự được đào tạo về việc này. Nếu bạn không có những người như vậy, hãy chấp nhận rằng ít nhất một trong số các nhà phát triển của bạn sẽ cần phát triển kỹ năng này.

Tiếp theo, theo thời gian, tích lũy một tập hợp các bản năng về các loại mà mọi người thường yêu cầu muộn trong các dự án, và đưa chúng vào cuộc trò chuyện sớm trong dự án. "Giảm giá sẽ luôn giống nhau cho tất cả các đơn đặt hàng, hay nó thay đổi theo khách hàng?" "Mọi người dùng có thể xem mọi báo cáo, hoặc một số chỉ dành cho người giám sát?" "Thuế doanh thu có luôn giống nhau không, hay nó phụ thuộc vào vị trí của khách hàng?" và như thế.

Ngoài ra, hãy cố gắng viết mã của bạn để nó được cách ly khỏi các loại thay đổi này đến muộn, bởi vì một số vẫn sẽ đến muộn bất kể điều gì. Nếu bạn có logic nghiệp vụ trong trình xử lý nhấp chuột cho các nút của mình, những thay đổi này thực sự gây tổn hại. Nếu bạn có logic kinh doanh trong một lớp cụ thể có tên giúp bạn dễ dàng tìm thấy nó và bạn có thể tận dụng tính đa hình để có các đơn đặt hàng thường xuyên và các đơn đặt hàng gấp và mỗi đơn hàng sẽ tính phí vận chuyển của riêng mình, sau đó thay đổi họ đã Yêu cầu là ít đau đớn hơn nhiều.

Bạn không thể ngăn chặn những thay đổi muộn. Luật thay đổi, trình điều khiển kinh doanh (khách hàng, những gì bán hàng hứa hẹn, ý tưởng tuyệt vời mà CEO có trong khi đọc một cái gì đó trên máy bay) thay đổi. Ngăn chặn những gì bạn có thể và nắm lấy phần còn lại bằng cách thiết kế mã của bạn để có thể thay đổi.


Tôi luôn luôn không hiểu làm thế nào một nhà phát triển có thể trở thành một nhà phát triển thành công mà không có các loại kỹ năng này. Các công ty lớn có thực sự thuê người để suy nghĩ cho các nhà phát triển, và sau đó cho phép các nhà phát triển của họ trở thành những người đánh máy trả tiền quá cao không?
Michael Shaw

3

Bạn thực sự chỉ cần trên đường đi đảm bảo rằng bạn đang đáp ứng các tiêu chí được liệt kê ở đó. Ví dụ: nếu nó nói "chức năng x nên có sẵn cho tất cả người dùng" thì hãy chắc chắn rằng điều này là đúng.

Trong quá trình phát triển sớm, điều này sẽ khó khăn nhưng càng gần đến thời hạn thì bạn càng có thể xác minh.

Có lẽ những điều bạn chưa thực hiện, bạn có thể xác minh chúng nằm trong các cân nhắc thiết kế để bạn biết rằng chúng đang được xem xét trong quá trình phát triển ban đầu.


Vấn đề là: người dùng thường đợi cho đến khi họ có phần mềm đang chạy và bắt đầu suy nghĩ về chi tiết. Đó là cách suy nghĩ logic thực sự. Đầu tiên quan trọng nhất, hơn các chi tiết. nhưng đối với các chi tiết phần mềm cũng quan trọng như logic chính.
dùng7876

Đợi đã ... bạn đang nói về người dùng xác minh một chương trình được xây dựng để phù hợp với nhu cầu hoặc nhà phát triển của họ?
Chris

Người dùng có các yêu cầu - nhà phát triển tạo ra phần mềm. Đừng quan tâm ai xác minh điều gì, vấn đề là chúng ta viết mã rất nhiều dòng và hơn là phải thay đổi chúng, vì thay đổi (hoặc thiếu) yêu cầu - câu hỏi: làm thế nào để tránh?
dùng7876

Quá trình phát triển nhanh / lặp đi lặp lại. Các chu kỳ phát triển nhỏ hơn sẽ cho phép xem xét / xác nhận thường xuyên hơn mà cơ sở mã của bạn === thông số kỹ thuật của bạn.
Chris

1
Không phải là mã không đáp ứng các thông số kỹ thuật, vấn đề là các thông số kỹ thuật chưa hoàn chỉnh và vì không có gì viết sai, không ai phát hiện ra cho đến khi người dùng cuối có chương trình trước mặt họ và thấy rằng họ đặc biệt cách làm việc không được thực hiện.
Michael Shaw

2

Tôi nhớ là trong một cuộc họp kinh doanh và có một trong những nhà phân tích kinh doanh nói rằng thật tuyệt khi là một nhà phát triển luôn có một đặc tả cố định để làm việc.

Trong thế giới thực, có một vài điều giúp ích rất nhiều cho việc này. Điều đầu tiên, là chấp nhận rằng những chi tiết vào phút cuối này là một thực tế của cuộc sống. đặc điểm kỹ thuật hoàn chỉnh 100% duy nhất của sản phẩm cuối cùng là mã nguồn. Nếu khách hàng đã có cái này rồi thì họ không cần bạn viết nó phải không?

Điều thứ hai cần làm là tích cực cố gắng tuôn ra các chi tiết đặc tả còn thiếu. bây giờ bạn có thể thử để khách hàng đăng xuất 300 trang Tài liệu tình huống sử dụng và các cơ chế hợp đồng khác, nhưng cuối cùng, tôi có thể nói với sự tự tin 100%, cách tốt nhất là giao phần mềm cho khách hàng của bạn. Yêu cầu họ xem xét nó, sử dụng nó, tích cực khuyến khích họ thay đổi đặc điểm kỹ thuật theo nhu cầu của họ (và khi thích hợp để tính phí cho công việc). Ngay cả khi chỉ một số tính năng được triển khai, phản hồi của khách hàng là chính.

Thứ ba, khi đọc đặc tả, hãy nghĩ về điều gì sẽ khiến yêu cầu này thay đổi và cách bạn có thể xử lý các biến thể. Kỹ sư thường không nhạy cảm với những thay đổi có thể không xuất hiện, nhưng có kế hoạch và quan trọng là không thiết kế trong những khó khăn thêm sẽ giúp cuộc sống của bạn dễ dàng hơn nhiều - và những điểm bổ sung để giữ bình tĩnh và tự tin khi bạn nói 'chúng tôi có thể xử lý việc đó bằng .... và sẽ mất khoảng 4 ngày để làm.' sẽ truyền cảm hứng cho người khác để có niềm tin vào bạn.


2

Tôi nghĩ bạn không được quên phía bên kia. Đối với bất kỳ người dùng nào, thật khó để tạo ra một danh sách đầy đủ các chi tiết về những gì bạn muốn. Nghĩ về bản thân bạn, bạn nghĩ về những điều mới mọi lúc.

Đó là một công việc khó khăn đáng kinh ngạc để đưa ra tất cả các yêu cầu và chi tiết của một cái gì đó bạn chỉ có một ý tưởng mơ hồ về. Tôi không nghĩ ai có thể.

Tôi có một cuốn sách ở đây từ những năm 70 được gọi là "tại sao các dự án phần mềm thất bại". Khi tôi đọc trên blog và nhận được tạp chí CNTT, tôi đã đọc trên trang bìa "tại sao các dự án phần mềm thất bại". Và khi tôi so sánh nội dung sách với danh sách hiện tại .... không có gì thay đổi. Phát triển lặp: có rất nhiều biến thể và nó giúp ở một mức độ nào đó. Nhưng sau tất cả thời gian này, nội dung của các tạp chí có cùng trang bìa. Nếu bạn không tin tôi hãy tìm kiếm một số magz từ quá khứ và xem làm thế nào bạn có thể sao chép và dán văn bản vào bây giờ.

Vấn đề này không thể giải quyết được ở phần cuối CNTT. Chúng tôi đã phát minh ra các công cụ mới, quy trình, danh sách kiểm tra, sơ đồ phân tích yêu cầu, trường hợp sử dụng (doanh nghiệp), khung phát triển, BPM, SOA, bạn gọi nó và vẫn tồn tại cùng một vấn đề ...

Bạn cần tối ưu hóa điều này xung quanh 'trình xác định yêu cầu'. Vì vậy, bạn cần cung cấp cho những người đó các công cụ đầy đủ, bất cứ điều gì để cho phép họ đưa cấp độ của họ cao hơn:

Vì vậy, ví dụ như đối với những người này: mô hình cụ thể ra khỏi hộp, đầu vào từ các dự án và công ty khác thực hiện cùng một bản sao các yêu cầu và bài học về kết quả cuối cùng của họ, đưa mọi người vào đó đã vượt qua mọi thứ và có thể giúp người này xác định mọi thứ điều đó gây ra những vấn đề lớn nhất và không "tầm thường" mà chỉ có thể học được sau khi thực hiện nó (ví dụ như các chuyên gia tư vấn kỹ thuật cao cấp làm công việc tương tự tại các công ty khác), cung cấp cho những người này yêu cầu công cụ soạn nhạc, cho bảo hiểm, ngân hàng, telco, v.v. : không phát minh ra các quy trình của riêng bạn mua các quy trình chung ra khỏi hộp, v.v ... chúng CẦN các công cụ giống như nhà phát triển cần các công cụ và các mẫu và khung.

Không giải quyết nó nhưng cải thiện đáng kể IMHO cải tiến nên ở xung quanh khu vực đó và không muộn hơn.

Giống như một nhà phát triển, những người này chỉ cố gắng làm tốt nhất có thể. Nhưng không giống như các nhà phát triển cho lĩnh vực của họ, hầu hết những thứ chúng ta được cấp sau 30 năm thậm chí không có mặt trong lĩnh vực đó. Nói chung các công cụ của họ là triển vọng, excel, từ và một bảng. Quá trình của họ là phiên động não. Rất nhiều cải tiến có thể được thực hiện trong lĩnh vực này. Tất nhiên, vấn đề chủ yếu là họ đang ngồi "bên ngoài" CNTT nên thậm chí còn có kế hoạch từ CIO để cải thiện tình hình trong lĩnh vực đó rơi vào tai người điếc ... nhưng đó là một câu hỏi khác: làm thế nào để "bán" thứ này.


1

Vấn đề trứng gà

Những gì bạn đang vật lộn được gọi là một vấn đề trứng gà trong giai đoạn phân tích yêu cầu phần mềm. Khách hàng không chia sẻ chi tiết yêu cầu vì họ không biết kiến ​​trúc chi tiết và kiến ​​trúc sư không thể tạo ra kiến ​​trúc chi tiết vì họ không biết chi tiết của tất cả các yêu cầu.

Giải pháp đôi đỉnh

Tuy nhiên, có một giải pháp nổi tiếng của vấn đề này. Đó là mô hình đỉnh đôi. Trong mô hình này, bạn phải thực hiện một số lần lặp lại giao tiếp với khách hàng bắt đầu từ yêu cầu chung đến yêu cầu cụ thể cũng như bạn phải phát triển kiến ​​trúc của mình từ chung đến chi tiết cụ thể.

nhập mô tả hình ảnh ở đây

Ưu điểm của mô hình Twin-Peak:

  • Yêu cầu đưa giới hạn hệ thống vào tài khoản
  • Phát triển nhanh các phương án thiết kế
  • Tạo nhanh các nguyên mẫu
  • Phát triển hiệu quả kiến ​​trúc thông qua việc sử dụng các giải pháp hiện có
  • Khối lượng công việc của các yêu cầu có thể được ước tính từ kế hoạch kiến ​​trúc thô đầu tiên
  • Giảm chi phí vì các yêu cầu trực tuyến không thực tế được xác định trước khi giải pháp phát triển
  • Giảm thiểu rủi ro trong phát triển

Tài liệu tham khảo


1
Một trong những phương pháp phân tích đáng tin cậy nhất là để một nhà phân tích thực sự thực hiện hoặc có kinh nghiệm thực hiện trước đó, công việc họ đang được yêu cầu phân tích. Vấn đề về yêu cầu giao tiếp đầy đủ phát sinh phần lớn do nhiều nhà phân tích (hoặc các chuyên gia liên quan đến CNTT cần phải phân tích) có ít hoặc không có kinh nghiệm vận hành để bổ sung cho bất kỳ kỹ năng phân tích nào.
Steve

0

Bạn cần cho người dùng biết rằng 'yêu cầu' càng được xác định trong dự án, chi phí sẽ càng cao. Rốt cuộc họ có thể quyết định rằng họ không thực sự cần sự thay đổi. Nếu họ khăng khăng thay đổi, nhưng từ chối thêm chi phí / thời gian trì hoãn, bạn có một vấn đề cần được thương lượng. Điều đó sẽ không được giải quyết thông qua công nghệ hoặc lập kế hoạch mà bằng cách bán hàng và quản lý quan hệ khách hàng.

Liên tục nhận được phần mềm làm việc trước mặt họ và yêu cầu họ nỗ lực sử dụng / kiểm tra / đánh giá là đặt cược tốt nhất của bạn. Họ sẽ không hoàn toàn hiểu được hợp đồng, thông số kỹ thuật, sơ đồ và câu chuyện của người dùng.

Đây là một phần của bài kiểm tra Joel. Lấy bất cứ ai bạn có thể tìm thấy để kiểm tra phần mềm càng nhiều càng tốt trong toàn bộ quá trình phát triển.


0

Nếu bạn thực sự muốn thực hiện công việc ngay, trước khi bạn bắt đầu làm việc về mã hoặc thiết kế kiến ​​trúc, hãy ngồi xuống với một số người sẽ là người sử dụng mã của bạn (không phải quản lý của họ hoặc bất kỳ bên liên quan cấp cao nào khác) và nhận chúng để chỉ cho bạn cách làm công việc của họ. Lý tưởng thực sự làm công việc trong một hoặc hai ngày. Điều đó sẽ cho bạn hiểu về cách thức hoạt động của hệ thống hiện tại và loại người đang làm việc đó. Nó cũng sẽ cho bạn thấy sự thất vọng của họ đối với hệ thống hiện tại và những thứ đang đánh vào năng suất của họ. Bạn cũng cần phải nghe tất cả những khó khăn và phiền toái hàng ngày, điều đó có nghĩa là bạn phải làm những gì cần thiết để đảm bảo phản hồi của họ dừng lại với bạn hoặc nhóm thiết kế của bạn, nếu ý tưởng chuyển quan điểm của họ cho các thành viên khác trong tổ chức của họ là có khả năng ức chế điều đó.

Đối với mỗi nhóm người dùng, bạn cần có một người sẽ làm việc trong việc phát triển phần đó làm điều tương tự. Sau đó, tất cả bạn có thể gặp gỡ và thảo luận về những gì bạn đã học được trong các vai trò mà bạn đã che giấu để xem liệu có các khu vực giao nhau và làm thế nào bạn có thể làm mọi thứ dễ dàng nhất cho mọi người tham gia.

Tôi không đề xuất điều này thay thế các quy trình thu thập yêu cầu khác, nhưng nó là phần bổ sung cho phép bạn hiểu người dùng thực sự cần gì từ hệ thống của bạn. Dù quản lý nghĩ gì họ cần, có khả năng các nhà quản lý và phân tích kinh doanh sẽ không phải là người dùng thực sự của hệ thống, nhưng nếu bạn có thể làm cho hệ thống hoạt động tốt cho những người dùng đó, họ sẽ làm cho họ làm việc hiệu quả hơn, làm cho các nhà quản lý hài lòng và làm cho công ty của bạn trông tốt

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.