Mục lục:
- Giới thiệu
- Câu chuyện của người dùng
- Phiên động não
- Phiên đánh giá
- Những gì cần bao gồm trong báo cáo tình trạng dự án hàng tuần
- Sơ đồ quy trình
- Tiếp tục hỏi tại sao
Giới thiệu
Thu thập các yêu cầu từ các bên liên quan của dự án thường cảm thấy giống như nhổ răng. Và nếu bạn không thực hiện tất cả các yêu cầu trước khi bắt đầu phát triển trong một dự án, bạn sẽ gặp phải một danh sách rất dài các vấn đề trong quá trình thử nghiệm mà lẽ ra phải được ghi lại thành các yêu cầu. Có nhiều cách để thúc đẩy cuộc trò chuyện để đảm bảo bạn nắm bắt được tất cả các yêu cầu như một phần của dự án, chẳng hạn như thu thập câu chuyện của người dùng, thiết lập các phiên động não, lập sơ đồ quy trình, v.v. Cho dù bạn là người quản lý dự án hay nhà phân tích kinh doanh, bài viết này sẽ hướng dẫn bạn một số phương pháp tiếp cận tiêu chuẩn hơn để thu thập các yêu cầu của dự án để đảm bảo dự án của bạn được bắt đầu đúng hướng.
Câu chuyện của người dùng thường được đóng khung xung quanh vai trò của người yêu cầu, họ muốn gì và tại sao họ muốn điều đó.
Designmodo
Câu chuyện của người dùng
Cho dù bạn đang xây dựng một cái gì đó hoàn toàn mới hay cập nhật một ứng dụng hiện có, thì vòng yêu cầu đầu tiên phải luôn được nắm bắt thông qua các câu chuyện của người dùng. Cho dù những câu chuyện này đến từ người dùng cuối hay các bên liên quan không quan trọng và bạn có thể thu thập chúng từ bất kỳ ai. Mục tiêu là nắm bắt được kỳ vọng của họ về những gì sắp được xây dựng và chi tiết về cách họ muốn nó hoạt động. Có nhiều định dạng khác nhau để nắm bắt câu chuyện của người dùng, nhưng tất cả chúng đều ghi lại vai trò liên quan đến người yêu cầu, người đó muốn gì và tại sao họ muốn điều đó. Những câu chuyện này sẽ cần được bổ sung thêm trong quá trình dự án.
Phiên động não
Các phiên động não thường có sự tham gia của tất cả các bên liên quan đã xác định và một số người dùng cuối tiềm năng cùng họp trong một căn phòng và đưa ra ý tưởng của họ về những yêu cầu đối với một dự án. Mục đích là giữ cho cuộc thảo luận tiếp tục và để mọi người nói chuyện. Nếu có sự khác biệt giữa các yêu cầu đã được nói ra hoặc cách giải thích của bạn về các yêu cầu, hãy đưa nó ra đó để nhóm bắt đầu. Vì các phiên này thường diễn ra cực kỳ nhanh chóng, nên tốt nhất bạn nên ghi lại cuộc trò chuyện hoặc có một người ghi chép chuyên dụng để bạn có thể tập trung vào việc trở thành một người tham gia tích cực hơn là cố gắng nắm bắt mọi thứ. Nếu bạn đi theo con đường này, không có gì lạ khi có nhiều hơn một trong những phiên này để đảm bảo rằng mọi thứ được thảo luận.
Mặc dù các phiên họp động não là rất tốt để đưa ra tất cả các yêu cầu một cách cởi mở và có một cuộc trò chuyện xung quanh chúng, nhưng việc sắp xếp mọi thứ sau một trong những cuộc họp này có thể gây khó khăn, với khối lượng thông tin.
PM Alliance
Phiên đánh giá
Tiếp tục đưa các yêu cầu trước mặt các bên liên quan của dự án để xem xét, và đừng đánh giá thấp khoảng thời gian mà một nhóm có thể mất để đạt được thỏa thuận về tất cả các yêu cầu của một dự án. Không có gì lạ khi việc thảo luận cho một dự án nhỏ có thể mất vài tuần. Một cách tiếp cận là đợi cho đến khi mọi người đồng ý bằng lời nói về các yêu cầu và sau đó đợi vài ngày trước khi quay lại với mọi người để lấy chữ ký của họ trên một tài liệu chính thức, nơi bạn có thể yêu cầu họ xem nhanh một lần nữa — chỉ ở bên an toàn. Một cách tiếp cận khác là nhờ một người khác trong doanh nghiệp có kiến thức về những gì bạn đang làm xem xét các yêu cầu để đảm bảo rằng mọi thứ đều kín đáo nhất có thể.
Những gì cần bao gồm trong báo cáo tình trạng dự án hàng tuần
Sơ đồ quy trình
Sơ đồ quy trình là nơi bạn tập hợp toàn bộ nhóm lại với nhau và thực hiện quy trình cho từng quy trình đã xác định sẽ là một phần của dự án. Điều này buộc các bên liên quan phải suy nghĩ về từng bước thông qua ứng dụng được yêu cầu và thường đưa ra các yêu cầu mới mà trước đây chưa ai xem xét. Đầu ra của các phiên này cũng đóng vai trò là đầu vào tuyệt vời cho wireframing.
Tiếp tục hỏi tại sao
Hỏi tại sao lại là một trình điều khiển mạnh mẽ trong các cuộc trò chuyện yêu cầu và các yêu cầu cụ thể, rõ ràng sẽ không được xác định một cách đáng tin cậy cho đến khi không còn hợp lý khi đặt câu hỏi đó. Nó buộc các bên liên quan phải suy nghĩ về các thành phần cụ thể của yêu cầu ban đầu của họ, điều này có thể gây khó khăn và tốn thời gian. Ngoài ra, đôi khi việc hỏi liên tục cuối cùng có thể làm lộ ra điều gì đó mà ban đầu được cho là một yêu cầu mà sau cùng thì không cần phải là một yêu cầu.
© 2017 Max Dalton