Cách quản lý và ước tính các yêu cầu phi cấu trúc nhận được từ khách hàng


21

Rất nhiều lần trong giai đoạn đấu thầu dự án, tôi nhận được yêu cầu của hệ thống phần mềm từ các khách hàng tiềm năng của chúng tôi ở định dạng không có cấu trúc từ nhiều nguồn khác nhau [email, tài liệu từ, excel]. Nó thường là một nhóm các anh chàng "phát triển sản phẩm" từ phía khách hàng đưa ra những "giải pháp được đề xuất" cho các vấn đề kinh doanh mà họ gặp phải. Mặc dù họ là chuyên gia trong lĩnh vực kinh doanh, rất nhiều lần họ không có giải pháp đúng.

Kết quả này trong

  • nhiều phiên bản của cùng một yêu cầu
  • trộn hai yêu cầu thành một
  • Một vài phiên bản của yêu cầu sau này xuống dòng, các yêu cầu được kết hợp lại được tách ra một lần nữa, mỗi phiên bản đều có một số bổ sung mới

Làm thế nào để bạn làm việc với các yêu cầu như vậy đến và sắp xếp chúng vào các trường hợp sử dụng thích hợp và trước khi bắt đầu phát triển? Những công cụ nào chúng ta có thể sử dụng để theo dõi lịch sử của một yêu cầu cụ thể, từ lần đầu tiên nó được hình thành cho đến khi nó được kết tinh thành một trường hợp sử dụng thích hợp? Ước tính công việc chống lại các yêu cầu nhận được theo cách như vậy là một cơn ác mộng dẫn đến việc mắc sai lầm trong việc hiểu chính xác yêu cầu và ước tính nỗ lực chống lại nó một cách chính xác.

Khi chúng tôi giành chiến thắng trong dự án, sau đó khách hàng đã suy nghĩ kỹ hơn về yêu cầu của họ và đã có thể nói rõ điều đó. Điều gì xảy ra trong trường hợp này là một số chức năng bị loại bỏ, một số được tăng cường, một số thay đổi hoàn toàn mới. Điều này về cơ bản có thể vô hiệu hóa một số ước tính của mục công việc đã được thực hiện trước khi dự án giành được. Tôi sẽ quan tâm đến việc biết liệu có bất kỳ hệ thống nào mà chúng ta có thể xây dựng một cây theo một yêu cầu cụ thể không và làm thế nào mỗi nhánh dẫn đến một ước tính khác nhau.

Bất kỳ lời khuyên, công cụ, thủ thuật để làm cho hoạt động này dễ quản lý hơn? Tôi chỉ đang cố gắng để có được một số hiểu biết từ một người có kinh nghiệm hơn tôi trong quản lý yêu cầu và ước tính nỗ lực.


1
Có ai trong nhóm của bạn làm việc với những người "phát triển sản phẩm" để phân tích yêu cầu (ví dụ như Chuyên viên phân tích nghiệp vụ) không?
Deco

Có, tôi làm điều đó trong mọi trường hợp chúng tôi không có ngân sách trong BA.
dùng2058

Câu trả lời:


17

Yêu cầu sẽ phát triển và thay đổi. Tôi không nghĩ ai có thể tranh luận điều đó.

Làm thế nào để thu thập và xử lý các yêu cầu đến .

Theo kinh nghiệm của tôi, nó giúp ích khi thu thập các yêu cầu nếu có một nhóm khách hàng duy nhất hoặc rất nhỏ đóng vai trò là bộ lọc để cung cấp các yêu cầu mới hoặc cập nhật cho một nhóm nhỏ các nhà hoạch định phát triển. Bất cứ ai từ phía họ có thể đề xuất hoặc viết chúng lên, nhưng việc giao hàng chỉ nên thông qua một số rất nhỏ. Càng ít người tham gia trao đổi từ bên này sang bên kia thì càng tốt.

Mục đích của việc lọc qua một nhóm người nhỏ hơn không phải là loại bỏ hoặc làm giảm nỗ lực và thông tin mà người khác đưa vào, ngay cả khi trùng lặp hoặc dường như không quan trọng trên bề mặt, nhưng để hạn chế các điểm thất bại: thông tin bị mất hoặc bị xử lý sai. Nó tuân theo một nguyên tắc tương tự như mục đích đóng gói và giao diện: bảo vệ dữ liệu riêng tư và thiết lập một giao thức chung để xử lý các yêu cầu tương tự. Hãy để tôi nhắc lại: nộp bản sao là ok. Là một người lập kế hoạch, điều đó cho tôi biết điều họ đang nói hoặc đề xuất là quan trọng. Lưu hoặc ghi lại mọi thứ.

Cách theo dõi và sắp xếp các yêu cầu

Trong ngắn hạn, đi công nghệ thấp

Rõ ràng có những giải pháp công nghệ thấp có thể có hiệu quả ở mức độ lớn trong việc tổ chức và theo dõi các yêu cầu đến: bảng trắng, hình dán, tấm áp phích, những gì có bạn. Đây có thể là tuyệt vời cho kế hoạch ngắn hạn. Chúng rất dễ nhìn, chấp nhận ký hiệu dạng tự do và dễ dàng 'cấu hình lại'.

Về lâu dài, hãy sử dụng một công cụ phần mềm có thể tìm kiếm, sắp xếp, có thể liên kết

Đối với những nỗ lực tầm xa hơn, một số loại phần mềm sẽ có giá trị. Có các công cụ quản lý yêu cầu chuyên biệt: Cửa ra vào, Clearcase / Clearquest, và nhiều công cụ khác. Những công cụ chuyên môn cao này rất tốt ở những gì họ làm, nhưng thường là quá mức cần thiết. Đôi khi ngay cả một bảng tính cũ đơn giản là quá đủ. Cá nhân tôi thấy các hệ thống theo dõi vấn đề chung khá hữu ích để thực hiện điều này, và ngay bây giờ yêu thích của tôi là redmine, nhưng những người khác tôi chắc chắn cũng sẽ ổn.

Với hệ thống theo dõi vấn đề, bất kỳ ai bạn chọn cho phép đều có thể tạo ra 'vấn đề mới' hoặc yêu cầu và thêm bất kỳ chi tiết nào họ thấy phù hợp để đưa vào. Họ có thể xem vấn đề và đưa ra phản hồi cho bất kỳ hành động nào bạn thực hiện với nó. Bạn có thể phân loại lại nó, điều chỉnh mức độ ưu tiên, viết lại phần thân, đính kèm thông tin bổ sung, liên kết nó với các 'vấn đề' khác, quảng bá đến một tính năng cấp cao hơn hoặc 'trường hợp sử dụng' hoặc bất kỳ thuật ngữ nào phù hợp với hệ thống của bạn, quảng cáo. Nói cách khác, bạn có thể làm rất nhiều để tạo ra một danh sách các yêu cầu liên quan có thể theo dõi, sắp xếp, ưu tiên, nhận biết lịch sử, thông qua các vấn đề. Ngoài ra, có thể cấu hình khá rõ ràng và nguồn mở, nếu công cụ không hoàn toàn là thứ tôi cần hoặc muốn, tôi có thể thay đổi nó khá dễ dàng để phù hợp hơn với nhu cầu của quy trình.

Một lưu ý cuối cùng về các công cụ, một số người tôi đã nói chuyện có rất nhiều thành công khi sử dụng các tệp văn bản cũ đơn giản trong một hệ thống quản lý và phiên bản thay đổi. Họ rõ ràng nhận được những lợi ích của các phiên bản lịch sử. Họ cũng sử dụng hệ điều hành cơ sở và các công cụ bổ sung để tìm kiếm, liên kết và lập danh mục các yêu cầu. Họ không thể thêm nhiều thông tin meta có cấu trúc, có liên quan, nhưng họ không cảm thấy họ cần nó và vì những nỗ lực của họ không đủ giá trị. Điều đó có thể hoặc không thể là trường hợp của bạn. Ưu điểm là có khả năng một vài phần mềm ít hơn trong ngăn xếp phát triển của bạn để quản lý và bảo trì.

Giải thưởng hợp đồng / yêu cầu khởi động dự án phát triển dự án

Khía cạnh cuối cùng của câu hỏi, là làm thế nào để quản lý các yêu cầu sau khi một nỗ lực đã bắt đầu. Tôi nghĩ có hai suy nghĩ hàng đầu về vấn đề này và một phần cách bạn xử lý chúng phụ thuộc vào bản chất mối quan hệ của bạn với khách hàng: thứ nhất, nếu theo hợp đồng với giá trị cố định, các yêu cầu có thể được đưa ra sau khi giải thưởng hợp đồng có thể được đưa vào. Hàm ý là họ có thể thay đổi phạm vi của nỗ lực, vì vậy tỷ lệ hoặc hóa đơn sẽ cao hơn khi những mục bổ sung đó được giao và chấp nhận; trừ khi một lượng nỗ lực tương đương được loại bỏ khỏi đề xuất được chấp nhận. Nếu nó sẽ thay đổi phạm vi, bạn phải đảm bảo khách hàng hiểu và chấp nhận hậu quả, nếu không, những bài nộp muộn đó sẽ phải được lập bảng.

Thứ hai, đối với các yêu cầu mới được đưa ra sau khi hợp đồng được trao, và hợp đồng được định hướng nhiều hơn về nỗ lực vật chất và thời gian (bất cứ điều gì cần thiết để hoàn thành công việc), bạn có thể và nên linh hoạt hơn một chút nếu khách hàng khăng khăng bao gồm nó trong suốt thời gian đó. Bạn sẽ được trả tiền cho dù bạn có bao gồm hay không, miễn là mọi thứ bạn nói bạn sẽ làm được hoàn thành.

Nếu bạn không quen thuộc với chúng, bạn có thể muốn xem xét phương pháp Kanban và phương pháp Agile. Những kỹ thuật này có thể giúp tập trung vào các mối quan tâm trước mắt, mà không nhất thiết làm mất đi các mục tiêu phát triển dài hạn.

Trình bày các tùy chọn dưới dạng kịch bản 'what if' và cung cấp cho khách hàng sự lựa chọn và quyết định

Trong cả hai trường hợp, ước tính 'what if' là một chiến lược tốt để sử dụng khi đàm phán với khách hàng và nhóm của bạn. Xây dựng một so sánh song song về các nhiệm vụ, chi phí của họ và lịch trình theo kế hoạch, với một cột hiển thị cùng thông tin cho các phương pháp thay thế. Microsoft Project có lẽ là một ứng cử viên tốt để thực hiện điều này vì bạn có thể xây dựng các ước tính khác nhau dựa trên một nhóm nhiệm vụ tương tự nhau.

Tuy nhiên, ngay cả một bảng tính cơ bản thường chỉ có hiệu quả để chứng minh các thay đổi hoặc bao gồm cụ thể sẽ ảnh hưởng đến chi phí và lịch trình như thế nào. Một danh sách trong trường hợp này có lẽ cũng hiệu quả như một cái cây có thể thể hiện sự khác biệt. Công cụ và phương pháp bạn chọn để xây dựng các kịch bản này phần lớn phụ thuộc vào quy mô của dự án và nhân viên (nhưng thậm chí cả ba phần mềm A như MS Project cũng có giới hạn riêng về tính hữu dụng và khả năng).

Xem xét những điều này nếu kịch bản là các mục công việc nội bộ và lưu chúng trong suốt thời gian của dự án. Họ là những minh chứng quan trọng trong quá trình ra quyết định và đàm phán. Bạn cũng có thể phải xem lại chúng, hoặc lặp lại chúng cho một vòng tiếp theo của ifs.

Khi chuẩn bị những gì xảy ra nếu kịch bản, một lời giải thích bổ sung của pro và con từ góc độ kỹ thuật hoặc triển khai (theo thuật ngữ đơn giản) có thể hữu ích để giúp chứng minh tại sao một sự thay thế lại có tác động đáng kể như vậy.


4

Tôi sẽ xem đây là một quá trình lặp đi lặp lại. Bước 1 là thu thập các yêu cầu. Bước 2 là sắp xếp chúng. Bước 3 là ưu tiên chúng. Bước 4 là chia nhỏ thành từng bit đủ nhỏ để ước tính nỗ lực. Bước 5 là kết hợp các bit này vào một nhóm nỗ lực toàn cầu (giả sử là 84 người-ngày). Bước 6 là ánh xạ nỗ lực tới các tài nguyên (84 người-ngày / 2 devs = 42 ngày).

Vì vậy, ngay bây giờ bạn bị mắc kẹt giữa bước 1 và bước 2. Bạn có yêu cầu, nhưng bạn không có chúng ở dạng bạn cần.

Giả sử bạn có nhiều phiên bản của cùng một yêu cầu. Đây có phải là giống nhau không? Nếu vậy, chọn những gì có vẻ là rõ ràng nhất và sử dụng nó. Nếu chúng khác nhau về chi tiết, hãy chọn những gì có vẻ hợp lý nhất và sử dụng cái đó. Sau đó gửi tin nhắn cho khách hàng yêu cầu họ xác minh yêu cầu. Bạn có thể phải quay đi quay lại và số lần để có được yêu cầu đúng. Đừng bỏ cuộc hay nản lòng. Nhiều dự án đã thất bại do yêu cầu kém.

Sử dụng dự án của Microsoft để giữ cho công việc và lịch trình đồng bộ với các yêu cầu thay đổi. Nếu khách hàng yêu cầu thay đổi, hãy xác định công việc bổ sung, cắm nó vào mô hình của bạn và cho họ biết về ngày mới. Đừng bị cuốn hút vào việc tin rằng bạn chỉ có thể đưa các nhà phát triển mới vào các khoảng thời gian ngẫu nhiên để nhận lấy sự chậm chạp. Lịch trình của bạn phải chiếm thời gian tăng lên bất cứ khi nào một tài nguyên mới được thêm vào. Bạn sẽ chỉ có thể mô hình hóa điều này đúng nếu bạn chú ý đến từng dự án và học hỏi từ nó. Giả sử bạn đã đưa Bob lên tàu dự án X sau khi nó bắt đầu được 4 tháng. Làm thế nào anh ấy có năng suất trong tháng đầu tiên? Người thứ 3?

Bạn nên xem lại mô hình dự án hàng tuần, cập nhật bất cứ nơi nào cần thiết. Giữ một kỷ lục lịch sử của những thay đổi. Điều này sẽ giúp bạn cung cấp các ước tính tốt hơn trong tương lai.

đôi

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.