Làm thế nào để xử lý tình huống không may giả định này với người dùng cuối?

Tôi làm việc trong một công ty cỡ trung bình nhưng với lực lượng CNTT rất nhỏ.

Năm ngoái (2011), tôi đã viết một ứng dụng rất phổ biến với một nhóm lớn người dùng cuối. Chúng tôi đã hoàn thành hạn chót vào cuối năm ngoái và một số chức năng (tôi sẽ gọi funcA từ bây giờ) đã không được thêm vào ứng dụng mong muốn vào cuối. Vì vậy, ứng dụng này đã được chạy trong sản xuất trực tiếp từ cuối năm 2011, tôi có thể thêm mà không có vấn đề gì.

Hôm qua, cả một nhóm người dùng cuối đã bắt đầu phàn nàn rằng funcA không bao giờ có trong ứng dụng không còn hoạt động. Ưu tiên của chúng tôi tại công ty này là nếu một ứng dụng bị hỏng thì phải sửa trước tiên trước các dự án ưu tiên.

Tôi đã so sánh mã và truy vấn và không có sự khác biệt kể từ năm 2011, đó là bằng chứngA. Sau đó tôi đã có thể khiến một trong những người dùng cuối thừa nhận rằng nó không bao giờ hoạt động bằng chứngB, nhưng kể từ đó, người dùng cuối đó đã quay lại và nói rằng nó đã hoạt động trước đó ... Tôi tin rằng đám người dùng cuối đã đồng hóa cô ấy. Tôi cũng đã xem xét các ghi chú của mình cho dự án này có các yêu cầu và cập nhật hàng ngày liên quan đến dự án, trong đó nêu rõ, "funcA không đạt được do hạn chế về thời gian", ProofC.

Tôi đã nói chuyện với nhiều người trong số họ và tôi có thể thấy họ có thể bị nhầm lẫn ở đâu vì họ ở rất xa nền tảng lập trình, nhưng tôi cũng biết họ đủ thông minh để hành động trong một nhóm để bỏ qua các đơn đặt hàng ưu tiên dự án để có được chức năng mà họ muốn làm cho công việc của họ dễ dàng hơn.

Điều tồi tệ nhất là bây giờ nhóm nghĩ rằng đang thiết lập và ông chủ của tôi và người đứng đầu CNTT thực sự bắt đầu tin họ, mặc dù không có thay đổi mã hoặc truy vấn. Theo như xem xét trạng thái của logic, nó rất chặt chẽ và khô khan đến mức nếu 1 = 1, funcA sẽ không hoạt động.

Vì vậy, đây là phần cuối của mô tả kịch bản của tôi, nhưng tôi đang cố gắng không bị ảnh hưởng nghiêm trọng đến các số liệu hiệu suất của mình do điều này về cơ bản sẽ khiến tôi chuyển sang khắc phục sự cố sản xuất không tồn tại mà có thể sẽ khắc phục 1 tháng.

Tranh chấp về các sự kiện dễ quan sát thực sự khá dễ giải quyết: chỉ cần quan sát các sự kiện. Nếu tôi nói "có một cây bằng gỗ màu tím bên ngoài nhà của tôi", bất cứ ai có thể đến nhà tôi đều có thể xác minh sự thật hoặc sai của tuyên bố của tôi cho chính họ.

Nếu họ phàn nàn rằng FuncA đã từng ở trong sản phẩm và đã từng hoạt động ở phiên bản trước đó và bây giờ nó không hoạt động, và bạn không nghĩ nó đã từng có trong sản phẩm, hãy yêu cầu họ chứng minh. (Hoặc, nói một cách nhẹ nhàng hơn, hãy nói điều gì đó như "chúng tôi gặp khó khăn khi tái tạo vấn đề. Bạn có thể giúp chúng tôi ra khỏi đây không?")

Đưa cho họ một bản sao của phiên bản trước nếu họ vẫn chưa có và lấy chúng trong LiveMeeting và để họ chỉ cho bạn cách họ sử dụng FuncA. Nếu họ không thể làm điều đó, thì (hy vọng) họ sẽ nhận ra rằng nó không tồn tại ở đó và thoát khỏi trường hợp của bạn về điều đó, hoặc ít nhất là thử một chiến thuật khác để thực hiện nó. (Và đảm bảo nhận được ai đó từ ban quản lý hoặc PM trong LiveMeeting.)

Đây không phải là một vấn đề có thể được giải quyết trên thực tế - nếu bạn cố gắng, bạn sẽ mất uy tín.

Đầu tiên, chấp nhận rằng phần mềm bị "hỏng" - vì nó không làm những gì người dùng muốn nó làm. Bây giờ, chấp nhận rằng người dùng có quyền yêu cầu phần mềm làm những gì họ muốn nó làm - đó là những gì phần mềm là do đó. Vì vậy, những gì chúng tôi có là phần mềm bị lỗi và một kỹ sư từ chối sửa chữa nó .....

Kết quả là nếu hệ thống bạn chạy để đặt mức độ ưu tiên, những người dùng này không thể sửa lỗi phần mềm của họ bằng cách đi qua các kênh thông thường, vì vậy họ đang sử dụng các kênh bên và leo lên một nửa sự thật cao hơn trong chuỗi thức ăn để cố gắng điều khiển hệ thống, trong thời gian trung bình, làm cho KPI của bạn trông tệ (mối quan tâm chính của bạn phải là khách hàng, không phải KPI của bạn) - KPI của bạn được coi là "thiệt hại tài sản thế chấp" nếu họ thích bạn, hoặc tác dụng phụ có lợi nếu họ không. Tuy nhiên, họ có một số kiểm soát về mức độ xảy ra - tốt nhất là họ thích bạn.

Vì vậy, những gì đang xảy ra là hệ thống bị hỏng, và mọi người đang cố gắng thao túng mọi thứ để có được những gì họ muốn. Họ muốn có một tính năng và bạn muốn giữ KPI của mình.

Trừ khi bạn có thể sửa chữa hệ thống hoặc học cách chơi chính trị văn phòng thực sự nhanh chóng, trò chơi kết thúc: bạn thua.

Lưu ý: Không có cuộc thảo luận nào liên quan đến Hạn chót, lỗi so với thảo luận về tính năng, ai đang trả tiền, v.v ... Đây là Sự thật - và sự thật không quan trọng (tốt, chúng có thể làm được, nhưng chúng có thể bị thao túng theo nhiều cách .... ) trong chính trị văn phòng.

Về mặt tổ chức, tôi cảm thấy một vấn đề.

Có một hệ thống phân cấp bao gồm người đứng đầu CNTT và ông chủ của bạn. Nếu tổ chức của bạn là truyền thống (có vẻ như không phải là Agile), bạn là một tài nguyên và họ là người quản lý tài nguyên. Bạn có một công việc toàn thời gian gọi là phát triển phần mềm. Nếu người dùng cuối đang trực tiếp yêu cầu các tính năng, đặt ưu tiên của bạn và cố gắng quản lý thời gian của bạn, thì người quản lý của bạn là người thừa. Họ có thể chịu trách nhiệm với người dùng cuối, nhưng nếu họ đang thực hiện công việc của mình, bạn phải chịu trách nhiệm với họ và họ cần bảo vệ bạn khỏi chế độ nhà phát triển tập trung vào chế độ nhà phát triển phòng thủ .

Một vài điểm để đặt bối cảnh cho câu trả lời của tôi:

• Các nhà phát triển phần mềm không phải là những người du hành thời gian, vì vậy kết quả cần được đánh giá cho những gì họ là, chứ không phải những gì họ có thể có được.
• Nếu một tính năng nằm trong đặc tả yêu cầu, lịch biểu và được ưu tiên trên công việc đã hoàn thành, có thể có khiếu nại hợp pháp. Nếu không, sự biện minh để giữ bạn có trách nhiệm là gì?
• Hình phạt của bạn, nếu có công, cần phải đến từ chuỗi mệnh lệnh của bạn. Giống như tiếp thị và bán hàng sẽ không thích nếu phát triển sản phẩm mắng khách hàng, hầu hết các tổ chức đều có người quản lý sản phẩm để nhận được sự phẫn nộ của khách hàng (và khen ngợi) và truyền tải nó qua các kênh.
• Các nhà quản lý sản phẩm có thể tạo ra các mối quan hệ cực kỳ khó khăn nếu họ đắm mình trong sự ấm áp của các phần thành công của các dự án, nhưng chỉ bị roi vọt khi họ đối mặt với các nhà phát triển.
• Nếu bạn đã phân phối sản phẩm chức năng với giá trị công việc trong một năm và phải mất một tháng (hoặc hai) để thêm tính năng mong muốn, từ những gì tôi đã thấy trong ngành của chúng tôi, ước tính của bạn là trên trung bình.
• Giải quyết vấn đề một cách công bằng và hiệu quả đòi hỏi mọi người phải bỏ những ngón tay đổ lỗi vào túi của họ và lên kế hoạch đi tiếp.

Bạn sẽ có thể làm công việc có chất lượng tốt hơn nhiều với động lực tốt hơn nếu bạn được đánh giá cao thay vì là con dê trong một quy trình mà người đứng đầu CNTT nên sở hữu. Đó là cách công bằng và cách làm việc hiệu quả. Tôi hy vọng bạn sẽ được quản lý theo cách đó, và đôi khi trong tương lai, tôi hy vọng bạn sẽ quản lý người khác theo cách đó.

Trong trường hợp thất bại thực tế như thế này, điều tốt nhất là tiến về phía trước. Thay vì tranh cãi về quá khứ, hãy nói về việc làm cho nó hoạt động và việc đó sẽ dễ hay khó. Nó không thực sự quan trọng nếu vấn đề là sửa nó hoặc thực hiện lần đầu tiên. Nếu quản lý muốn A thực hiện trước khi B làm cho nó như vậy.

Bạn có phải là nhà phát triển duy nhất đã làm việc trong dự án này? Âm thanh như bạn đã trả lời cho ai đó trong khi thực hiện dự án. Người đó ở đâu trong tất cả những điều này? Tài liệu cho dự án nói những gì đã được giao?

Cần có một dấu vết giấy tờ tài liệu. Một tài liệu đào tạo cho thấy làm thế nào để sử dụng ứng dụng. Một đặc tả chức năng phác thảo những gì đã được phát triển. Nếu một tính năng không được bao gồm, cũng nên có tài liệu về điều đó. Ai đó đáng lẽ phải ký tắt nói rằng họ chấp nhận điều đó.

Nó không nên là từ của bạn chống lại họ, nó nên có trong tài liệu.

Nếu bạn không có tài liệu này ... thì tôi sợ bạn sẽ phải cắn tài liệu này. Coi đó là một bài học cuộc sống Vào cuối ngày, người dùng của bạn là khách hàng của bạn và như người ta vẫn nói: khách hàng luôn luôn đúng. Vẽ cách thêm tính năng này và mất bao lâu. Có một cuộc họp và nói điều gì đó dọc theo 'Hồ sơ của chúng tôi cho thấy tính năng này chưa bao giờ được triển khai, nhưng chúng tôi có thể có được cuộc sống trong x tuần. Chúng ta có nên đi đầu không? '

Và vì tình yêu của tất cả những gì là thiêng liêng .... hãy lấy tài liệu bạn cần cho thấy nó đã được chấp thuận.