Làm thế nào để đối phó với những thay đổi yêu cầu thường xuyên?

Tôi đang đối phó với tình huống khá căng thẳng (theo ý kiến ​​của tôi) tại nơi làm việc hiện tại của tôi.

Chúng tôi đã bắt đầu phát triển dự án mới, nhận một số yêu cầu, thực hiện nó và sau đó hiển thị cho ai đó bạn có thể gọi là 'cố vấn kinh doanh' (người biết yêu cầu kinh doanh nhưng sẽ không sử dụng chương trình). Người đó có nhiệm vụ đánh giá ứng dụng theo quan điểm của khách hàng, kiểm tra nó, v.v.

Dưới đây là 'quá trình' trông như thế nào:

1. cố vấn kinh doanh nói chuyện vào buổi tối với sếp của tôi trong một hoặc hai giờ trên windows messenger
2. ngày hôm sau tôi nhận được email với bản sao của cuộc trò chuyện đó. Tôi phải chọn các nhiệm vụ từ đó, kiểm tra các lỗi được báo cáo (thường không phải là lỗi, chỉ là kiểm tra kém và quên về các cơ sở trong quá khứ)
3. Tôi thực hiện các thay đổi, triển khai được chấp nhận và sau đó một hoặc hai tuần, hóa ra đó không phải là điều họ muốn (họ đã nói chuyện với một số khách hàng tiềm năng đã thấy phần mềm trong 5 phút và anh ấy đề nghị thay đổi) - Tôi phải thực hiện các thay đổi mới

Đừng hiểu lầm tôi, tôi hiểu rằng đôi khi các yêu cầu thay đổi. Điều làm tôi khó chịu là tần suất thay đổi xảy ra tại nơi làm việc của tôi và mức độ dễ dàng cho 'quản lý' là hai yêu cầu mới hoặc đôi khi thay đổi cơ bản đối với các tính năng hiện có.

Đồng thời, chúng tôi làm việc theo thời hạn chặt chẽ và tôi có ấn tượng rằng thay vì tiếp tục với phần mềm của mình, chúng tôi đang chạy vòng tròn.

Tôi tìm kiếm lời khuyên từ bạn làm thế nào để đối phó với tình huống này? Đây có phải là tình huống bình thường và tôi chỉ quá nhạy cảm về nó?

Nếu có thể, hãy thực hiện cuộc hội thoại mà bạn đã gửi qua email và biến nó thành tài liệu yêu cầu. Liệt kê các nhiệm vụ mà bạn có thể lượm lặt được từ nó và sắp xếp chúng theo những gì bạn cho là ưu tiên và gán ước tính cho từng nhiệm vụ. Sau đó hỏi những tính năng mà họ muốn cho phiên bản tiếp theo.

Về cơ bản, buộc một số loại vòng phản hồi trong đó ban quản lý nhận thức được bạn sẽ xây dựng cái gì. Viết tài liệu yêu cầu của riêng bạn cho đến khi họ nhận được tin nhắn.

Thẻ câu chuyện

Tôi nghĩ rằng tình huống của bạn rất phù hợp để giới thiệu những câu chuyện của người dùng . Chúng thực sự hữu ích trong việc cung cấp một cách tương tác liên tục để người quản lý của bạn đặt ưu tiên và anh ấy thậm chí có thể vứt bỏ chúng khi anh ấy quay lại ý tưởng một tuần sau đó và nhận ra rằng nó không khả thi.

Trong thế giới thực, các yêu cầu thay đổi thường xuyên. Về mặt tích cực, bạn tìm hiểu về nó trước khi hoàn thành việc xây dựng phần mềm và phát hành nó - bạn có một chu kỳ phản hồi chặt chẽ từ người dùng trực tiếp phần mềm, điều này thực sự tuyệt vời.

Có vẻ như vấn đề lớn nhất ở đây là cách thức rất đặc biệt mà sự thay đổi được quản lý. Bạn có những gì nhanh nhẹn / Scrum coi là "chủ sở hữu sản phẩm", người đưa ra phản hồi, nhưng quá trình này được ghi chép kém và suy nghĩ kém.

Bạn có thể muốn xem các mô hình trong Scrum và quan điểm của họ về chủ sở hữu sản phẩm hiệu quả là gì, để giúp thông báo các bước tiếp theo của bạn.

Vì vậy, thay vì có quy trình đặc biệt này, hãy hướng đến một thế giới nơi bạn có mối quan hệ gần gũi và hữu ích hơn với "cố vấn kinh doanh" và nơi mọi người ở trên cùng một trang về kết quả của những thay đổi mà họ đang thảo luận .

Quá trình hiện tại của bạn làm cho quá dễ dàng để những người này chỉ cần động não các ý tưởng mà không phải hối tiếc về tài nguyên và tiền sẽ tiêu tốn. Nếu họ muốn tất cả các tính năng này, họ cần có được một số "skin trong trò chơi".

Lấy email của cuộc trò chuyện và đưa nó vào một số loại ứng dụng theo dõi lỗi / tính năng ngay cả khi nó chỉ là một bảng tính. Gửi các bổ sung mới trở lại cho cố vấn kinh doanh và yêu cầu anh ấy / cô ấy đăng xuất trên mỗi mục hoặc cung cấp sửa chữa. Cùng với việc đăng xuất, họ nên ưu tiên (bạn muốn ưu tiên cái nào trước?).

Sau khi họ chấp thuận, hãy gửi lại cho họ lịch trình của bạn khi nào các hạng mục sẽ được hoàn thành để thử nghiệm và khiến họ cam kết một thời gian để thực hiện thử nghiệm / phê duyệt hoàn thành.

Tôi biết việc tạo loại tài liệu này không phải là lý do tại sao bạn trở thành lập trình viên, nhưng bạn có thể mạo hiểm vứt bỏ những danh sách này hoặc tiếp tục ném mã khó kiếm của bạn đi.

Đẩy lùi. Những người phụ trách cần phải xem các yêu cầu này có giá bao nhiêu.

Yêu cầu thay đổi không phải lúc nào cũng xấu. Điều quan trọng là ghi nhớ khách hàng của bạn. Có khả năng ông chủ của bạn là khách hàng của bạn trong trường hợp này. Bạn cần thông báo cho sếp của bạn rằng bạn biết những thay đổi yêu cầu liên tục này đang hạn chế khả năng sản xuất sản phẩm hữu ích nhất đối với anh ấy. Hoàn toàn có thể là lợi ích kinh doanh từ bạn liên tục phản ứng với những thay đổi. Nếu vậy, đó là mô hình kinh doanh của họ, và bạn không làm gì sai, mặc dù tôi khuyên bạn nên chạy cho những ngọn đồi trong trường hợp đó!

Những người thất vọng với các thay đổi yêu cầu thường được đánh giá cao bằng cách họ quản lý tốt từng thay đổi. Số liệu "số lượng thay đổi được xử lý đầy đủ" này có lẽ là nguồn gốc của rắc rối thực sự của bạn. Xem xét thảo luận về số liệu tốt hơn với sếp của bạn. Khi tôi phải đối mặt với những yêu cầu liên tục thay đổi, tôi cố gắng viết nội dung cho phép tôi thích nghi với những yêu cầu liên tục thay đổi. Thay vì chạy mô phỏng và phân tích dữ liệu mỗi ngày, tôi sẽ viết các công cụ giúp quá trình chạy mô phỏng và phân tích dữ liệu rẻ hơn và gặt hái những phần thưởng theo thời gian. Nếu điều đó vẫn còn quá điên rồ, tôi thậm chí có thể viết một công cụ để viết các công cụ!

Quá trình của bạn có thể được hưởng lợi từ một số nguyên tắc nhanh, như bị khóa trong các lần lặp. Tôi nghĩ rằng một tuần là hợp lý với những thay đổi nhịp độ nhanh như bạn đang mô tả. 2 tuần cuối cùng có thể làm việc tốt hơn.

Một khi các yêu cầu đủ quan trọng đã được xác định, yêu cầu người Project Ownerđóng vai trò ký vào chúng và khóa chúng trong khoảng thời gian một tuần trong khi bạn xây dựng chúng. Phân bổ đủ công việc cho bản thân đến nơi bạn sẽ bận rộn và để cho các quyền hạn được biết về sự phân bổ của bạn. tức là nếu mỗi tuần bạn có thể tạo ra công việc 16 điểm và bạn có 16 điểm công việc, thì bạn được sử dụng đầy đủ cho tuần đó. (Khái niệm điểm xuất phát từ luồng công việc nhanh nhẹn)

Nếu thay đổi đến vào giữa tuần, hãy thốt ra những lời kỳ diệu sau:

Tôi có thể làm [tính năng mới này], [thay đổi mới này], [vv], nhưng bạn không muốn làm gì?

Đó là, bạn là một nguồn lực hạn chế, bạn chỉ có thể đảm nhận rất nhiều công việc. Nếu một mục công việc mới xuất hiện, bạn được phép trở thành tài nguyên giới hạn mà bạn đang có và gán điểm cho mục mới và thả / thay đổi các mục khác thay cho thay đổi mới này. Ưu tiên lại danh sách lặp của bạn cùng với chủ dự án và bạn sẽ tốt hơn trong việc xử lý thay đổi.

Nếu các yêu cầu thay đổi thường xuyên hơn thế, bạn có thể cần phải đàm phán ổn định hơn trong môi trường của mình.

Cụm từ "Yêu cầu thay đổi" đôi khi bị lạm dụng bởi những người CNTT. Những gì bạn đang mô tả thực sự là thay đổi các yêu cầu nhưng điều này có thể là do một hoặc nhiều điều sau đây (tôi không biết đủ về trường hợp của bạn, vì vậy những điều sau đây có thể hoặc không thể áp dụng):

1. Tham vọng của ban quản lý là làm cho người dùng cuối hài lòng nhanh nhất có thể và cho thấy sự tiến bộ nhanh chóng.

2. Thiếu phân tích chi tiết. Hãy nhớ rằng các nhà phân tích cần phải đặt câu hỏi về lý do tại sao không chỉ những gì. Các nhà phân tích cần "suy nghĩ" với người dùng cuối về một "giải pháp" không chỉ nhận đơn đặt hàng.

3. Thiếu một quy trình chính thức để xác minh và xác nhận yêu cầu, sau đó là phê duyệt.

4. Yêu cầu người không chính xác thực hiện một hoặc nhiều vai trò mà họ không nhất thiết phải được đào tạo như vai trò Nhà phân tích kinh doanh hoặc Nhà phân tích hệ thống.

5. Tạo mẫu hạn chế.

6. Giả định / sợ rằng nó phải được thực hiện nhanh chóng và nếu không phải là CNTT của nó để đổ lỗi.

Trừ khi một địa chỉ giải quyết đúng tất cả những điều trên, mối quan hệ giữa CNTT và người dùng cuối / doanh nghiệp sẽ rất căng thẳng. Xin lưu ý rằng điều này không ngụ ý rằng điểm trên là kết luận. Có những yếu tố khác dẫn đến tình huống căng thẳng tương tự như tình huống của bạn nhưng tôi nghĩ danh sách này sẽ giúp bạn đi.

Tôi nghĩ bạn nên tiếp cận điều này từ một vài hướng:

1. Có tất cả những người nắm giữ cổ phần (bao gồm toàn bộ nhóm phát triển) gặp gỡ (ngoại tuyến / trực tuyến) với cố vấn kinh doanh và cố gắng hiểu tên miền, tầm nhìn và sau đó cùng nhau động não.

2. Chính thức hóa các yêu cầu / câu chuyện của người dùng, chấm điểm từng người:
   a. Ưu tiên (cấp bách / quan trọng)
   b. Thời gian đáo hạn (được xác định rõ như thế nào - được hiểu và đồng ý bởi đa số các bên liên quan *)
   c. Độ phức tạp (ước tính sơ bộ)
   
   Khi chọn yêu cầu / kho người dùng để làm việc tiếp theo, hãy tính đến cả ba yếu tố. Nếu yêu cầu có độ chín thấp, hãy thêm một nhiệm vụ nghiên cứu trước khi yêu cầu, trong đó bạn liên hệ với tất cả các bên liên quan, điều tra lý do đằng sau yêu cầu và xác định rõ hơn yêu cầu (viết trường hợp sử dụng và / hoặc tạo khung dây và trình bày chúng) trước khi hành động trên no.

3. Cố gắng suy nghĩ trước một vài bước trong khi thiết kế trước mỗi lần thực hiện - thiết kế một kiến ​​trúc linh hoạt có chỗ để phù hợp với những thay đổi.

4. Cố gắng điều chỉnh quy trình phát triển nhanh, ví dụ SCRUM hoặc Kanban - điều này sẽ cung cấp cho bạn bộ công cụ để phát triển sản phẩm với các yêu cầu thay đổi.

Bạn cũng nên xem xét việc yêu cầu người điều hành chuyển câu hỏi này sang PM.stackexchange.com (bằng cách gắn cờ) vì mặc dù câu hỏi này phù hợp ở đây, nhưng nó sẽ phù hợp hơn ở đó.

(*) Các bên liên quan để thỏa thuận: kinh doanh, tiếp thị, quản lý dự án, phát triển và QA.