Phải làm gì về sự thất bại trong việc thúc đẩy phát triển

Tại cửa hàng của chúng tôi, chúng tôi cố gắng để được nhanh nhẹn. Và tôi muốn nói rằng chúng ta đang có những bước tiến lớn. Điều đó nói rằng, một vài người trong chúng ta đã phát hiện ra một mô hình mà chúng ta đã bắt đầu gọi là "Thất bại trong phát triển theo hướng".

Thất bại trong việc phát triển theo hướng cơ bản có thể được coi là một chu trình phát hành / lặp nhanh, trong đó các lỗi / tính năng được hướng dẫn không phải bởi các tác vụ và câu chuyện với tiêu chí chấp nhận, nhưng có lỗi trong phần mềm theo dõi lỗi.

Nhóm của chúng tôi có một Người quản lý dự án tuyệt vời, người cố gắng để có được các tiêu chí chấp nhận từ (các) khách hàng, nhưng không phải lúc nào cũng có thể. Từ chủ tịch phát triển của tôi, điều này là do khách hàng không biết chính xác họ muốn gì (và đây là người đá) hai "trại" khác nhau trong cuộc xung đột văn phòng chính của khách hàng với cách thực hiện câu chuyện. Trại A sẽ lỏng lẻo dictate rằng công trình Tính năng X như này , sau đó trại B sẽ thất bại đó do không hoạt động như rằng . Do đó, thuật ngữ "FDD". Quá trình này được thúc đẩy bởi "thất bại".

Điều này dẫn đến câu hỏi của tôi: Có ai khác gặp phải điều này không và nếu có, có bất kỳ lời khuyên / đề xuất nào để xử lý nó không?

Tất nhiên, chúng tôi đã cố gắng để Trại A và B đồng ý trước, nhưng mọi người đều biết điều này không phải luôn luôn như vậy.

Cảm ơn

Yêu cầu mâu thuẫn dữ dội không phải là bất thường trong thế giới doanh nghiệp. Và đây thường là lý do khiến các dự án tự động hóa quy trình kinh doanh "thất bại". Nó có thể đơn giản như "hướng dẫn thủ tục và chính sách nói là làm X" trong khi những người thực sự làm công việc Y. Làm phần mềm làm Y nghĩa là những người trả tiền cho phần mềm sẽ khăng khăng rằng phần mềm bị lỗi từ họ quan điểm. Làm cho phần mềm làm X có nghĩa là những người thực sự hoàn thành công việc không thể hoàn thành công việc.

Thông thường, hầu hết các công ty phát triển sẽ chọn những gì các nhà quản lý nói về những gì công nhân tuyên bố vì đó là cách các hóa đơn được thanh toán. Trong thế giới lý tưởng, không có sự không phù hợp trở kháng giữa các chính sách bằng văn bản và thực tế; trong thế giới thực, nhiều công việc văn phòng được phân vùng không chính thức và không có giấy tờ.

Trại A sẽ quyết định một cách rõ ràng rằng Tính năng X hoạt động như thế này, sau đó Trại B sẽ thất bại do không hoạt động như thế.

Sự không phù hợp giữa CampA và CampB là vấn đề chính trị và không phải là vấn đề phần mềm. Giải quyết vấn đề sẽ liên quan đến việc nói chuyện với mọi người và có được một người chiến thắng rõ ràng.

Một trong những lý do chính để sử dụng phát triển lặp là vì bạn có một nhóm khách hàng không có ý tưởng tốt về những gì họ muốn.

Đây không phải là thất bại. Nhiều khách hàng chỉ đơn giản là không có ý tưởng về chính xác những gì họ cần cho đến khi họ có được thứ gì đó trong tay. Đây là lý do tại sao lần đầu tiên khách hàng nhìn thấy hệ thống không nên sau khi tất cả sự phù hợp và hoàn thành đã được thực hiện. Hãy để họ nhìn thấy nó sớm và thường xuyên.

Nói cách khác, nếu đó là vấn đề duy nhất, thì không cần phải hoảng sợ trừ khi bạn rơi vào tình huống bạn chỉ cần thử lại vô tận.

Vấn đề bất đồng giữa các khách hàng là vấn đề Trình quản lý sản phẩm không nên rò rỉ cho bạn. Hầu hết bạn nên xem là tồn đọng / nhiệm vụ / bất cứ điều gì. Tất nhiên, Thủ tướng sẽ thường mạo hiểm trong phạm vi phát triển vì đó là nơi duy nhất họ có thể, nhưng nó không ảnh hưởng đến bạn.

Cách thức quản lý sẽ phụ thuộc rất nhiều vào việc Trại A và Trại B là ai.

Nếu Trại A và Trại B đại diện cho hai cấp cao hơn, thì hãy mang đến một người thực sự sẽ sử dụng hệ thống để cho bạn biết những gì bạn cần. Đôi khi bạn nhận được không khí hiếm hoi trong đất quản lý gây ra sự mất kết nối với thực tế. Một người nào đó thực hành thường có thể vượt qua chủ nghĩa duy tâm và chỉ ra những gì thực sự cần thiết.

Mặt khác, nếu A và B là nhóm người dùng, bạn sử dụng biện pháp ngược lại là nhờ ai đó quản lý để đưa ra luật.

Trong mọi trường hợp, sự hoàn hảo là kẻ thù của đủ tốt.

Những gì bạn mô tả là một triển khai sai lầm điển hình của Agile. Bạn không chấp nhận thay đổi, bạn là nô lệ của nó .

Bạn có chủ sở hữu sản phẩm? Bạn có thể nói chuyện với họ khi cần thiết? Bạn đang thực hiện đánh giá nước rút với người dùng? Người dùng có tham gia vào quá trình (thông qua chủ sở hữu sản phẩm) trong kế hoạch chạy nước rút không? Bạn có người thử nghiệm trong đội chính?

Tôi đặc biệt khuyên bạn nên thuê một huấn luyện viên Agile và / hoặc gửi đội của bạn đi đào tạo.

Một giải pháp khác là ngừng làm Agile.

Nếu họ đang chơi bóng bàn (A nói làm x, B từ chối, nói y, sau đó A từ chối và quay lại x), thì khách hàng tiềm năng của bạn (PO hoặc bất cứ điều gì bạn có) cần phải đánh bại họ để bù đắp tâm trí của họ .

Sẽ ổn thôi nếu lần đầu tiên kết thúc không đáp ứng nhu cầu của họ (toàn bộ vấn đề này là cung cấp cho họ thứ gì đó để xem) nhưng nếu họ ngồi đó và xoay qua lắc lại những lần lặp lại tiếp theo, bạn sẽ không bao giờ hoàn thành.

Vấn đề ở đây dường như không phải là "Tôi sẽ biết khi tôi nhìn thấy nó". Wireframes có thể giúp (tối đa một điểm) với vấn đề cụ thể đó.

Vấn đề ở đây là, dường như đối với tôi, hai phe cạnh tranh trong khách hàng của bạn. Các trại lý tưởng A và B sẽ đưa ra một số tầm nhìn chung được đàm phán mà họ có thể trình bày với bạn.

Có lẽ họ có thể bị buộc phải lên bàn bởi bạn giải thích chi phí chiến đấu của họ là bao nhiêu khi bạn một lần nữa làm lại những gì A yêu cầu cho B (hoặc ngược lại).

Giữ ghi chú chi tiết về chi tiêu thời gian của bạn sẽ giúp ở đây. (Công việc của tôi đã viết một ứng dụng sắp xếp thời gian gọn nhẹ: dễ sử dụng và dễ báo cáo và báo cáo thời gian trong các đoạn 15 phút. Thật dễ dàng để nói "Tôi đã dành n giờ cho tính năng X.")

Điều đó có nghĩa là bạn có nguy cơ làm phiền khách hàng hoặc trông rất tệ cho dù bạn có làm gì đi nữa, vì những gì bạn làm cho B có thể khiến A (hoặc ngược lại) ngược lại.

Hy vọng rằng bạn có thể tìm thấy một nhà vô địch tại khách hàng, người có thể chăm sóc nội bộ cho bạn.

Theo tôi thấy, vấn đề chỉ có thể được giải quyết một cách hiệu quả tại một khách hàng, điều này sẽ rất khó khăn.

Bạn đang đề cập rằng bạn đang phấn đấu cho sự nhanh nhẹn, vì vậy tôi sẽ xem xét nó từ quan điểm của scrum, đó là quá trình nhanh nhẹn mà tôi biết rõ nhất.

Theo scrum, bạn có một vai trò cụ thể, chủ sở hữu sản phẩm, người chịu trách nhiệm ưu tiên các câu chuyện / lỗi / phát hành của người dùng, v.v ... Điều này lý tưởng chỉ nên là một người. Nếu có nhiều bên quan tâm với các quan điểm khác nhau trên cùng một phần mềm, thì trách nhiệm của chủ sở hữu sản phẩm là sản phẩm làm hài lòng tất cả các bên quan tâm.

Với tôi, người quản lý dự án của bạn có vai trò này. Nhưng vì anh ta được gọi là người quản lý dự án chứ không phải chủ sở hữu sản phẩm, tôi được tin rằng anh ta cũng phải chịu gánh nặng với các nhiệm vụ khác (nhiệm vụ quản lý truyền thống, không nhanh nhẹn?), Và không có đủ thời gian để theo đuổi vai trò chủ sở hữu sản phẩm.

Vì vậy, tôi tin rằng bạn cần một người có trách nhiệm điều phối các nhu cầu giữa các nhóm khác nhau tại khách hàng, đảm bảo rằng các yêu cầu / câu chuyện người dùng được gửi cho nhà phát triển đã được xác minh bởi cả hai nhóm tại khách hàng. Theo đuổi vai trò này có thể dễ dàng là một công việc toàn thời gian, đặc biệt là với khách hàng mà bạn có.

Điều thực sự lý tưởng là chuyển trách nhiệm này đến khách hàng, để một nhân viên của khách hàng của bạn có vai trò chủ sở hữu sản phẩm. Miễn là khách hàng không có vai trò này, khách hàng không cam kết giải quyết những bất đồng nội bộ của họ và họ để bạn giải quyết vấn đề đó, điều mà rất có thể bạn sẽ không thể làm được. Và đó là lý do tại sao tôi tin rằng giải pháp hiệu quả duy nhất là giao cho khách hàng trách nhiệm này.

Nhưng với thực tế là bạn đã bắt đầu hợp tác, tôi tin rằng bạn sẽ có một thời gian khó khăn để thực hiện thay đổi đó.

Để có được phần mềm của bạn được khách hàng chấp nhận, nó phải đáp ứng đầy đủ các yêu cầu do khách hàng đặt ra theo tiêu chí chấp nhận.

Bạn có một tập hợp các yêu cầu của người dùng ở dạng câu chuyện và tiêu chí chấp nhận, nhưng các bộ phận của tổ chức khách hàng có cách hiểu khác nhau về câu chuyện của người dùng, dẫn đến sự mơ hồ.

Bạn có thể thoát khỏi tình huống này bằng cách mô tả thiết kế chức năng và các quy tắc kinh doanh được thực hiện và nhận được những chữ ký này của khách hàng. Đây sẽ là những gì được thử nghiệm trong quá trình chấp nhận. Điều này phải được khách hàng đồng ý trước để ngăn chặn các cuộc thảo luận về ý nghĩa của tất cả các tài liệu sau đó.

Miễn là nhóm của bạn không thể mô tả phần mềm bạn đang xây dựng theo cách mà cả hai nhóm đồng ý với nó, bạn vẫn đang trong giai đoạn phân tích yêu cầu của dự án.

Người quản lý dự án của bạn có thể / nên cung cấp tư vấn trả tiền như một phần của dự án để giải quyết sự mơ hồ trong các yêu cầu chức năng.

Tôi nghĩ rằng tất cả chúng ta đã thấy trường hợp chúng tôi nhận được yêu cầu chi tiết từ người dùng, thực hiện chúng, sau đó nghe từ người dùng "Đợi đã, điều đó sẽ không hiệu quả với tôi" khi nó được thực hiện.

Một điều có thể giúp là thực hiện một dạng QA theo yêu cầu bằng cách cung cấp cho người dùng các ví dụ chi tiết với hành vi hệ thống dự kiến. Ví dụ: bạn có thể nói: "Đây là một trường hợp ví dụ. Nếu chúng tôi triển khai X, thì Y sẽ là kết quả và Z là một trong những hậu quả." Bằng cách đó, bạn có thể đến "Đợi, điều đó sẽ không hoạt động" trước khi bạn viết mã thay vì sau đó.