Bạn làm gì khi người dùng yêu cầu một tính năng bạn sẽ không thực hiện?


10

Bạn sẽ làm gì khi người dùng yêu cầu một tính năng phức tạp mà bạn có thể triển khai, nhưng bạn sẽ không làm điều đó vì 1) nó làm tăng thêm sự phức tạp không cần thiết cho người dùng khác 2) bạn sẽ không làm điều đó như một tùy chọn vì bạn không muốn bảng điều khiển cài đặt của bạn phức tạp.

Tôi đã viết một ứng dụng iOS và có một vài người dùng đã hỏi tôi về một số tính năng phức tạp mà tôi không thể làm được vì những lý do trên. Hầu hết thời gian tôi chỉ trả lời họ rằng "Chúng tôi sẽ cân nhắc điều đó". Giải thích cho họ rằng họ thuộc nhóm thiểu số muốn tính năng này cũng không giúp được gì. Vì vậy, bạn làm gì trong trường hợp như thế này?


4
Chính xác, không phải là một câu trả lời cho câu hỏi của bạn, nhưng trong ví dụ của bạn: bạn có thể dễ dàng có một giao diện rất đơn giản có nhiều tính năng bằng cách ẩn các tùy chọn nâng cao đi dưới một cái gì đó như "tùy chọn nâng cao". Cách quá nhiều ứng dụng chỉ làm cái này hay cái khác, hoàn toàn không cần thiết.
MGOwen

Bạn không thể thoát khỏi tính năng say mê người dùng. Họ đã thấy một cái gì đó ở đâu đó và bây giờ họ muốn điều đó trong ứng dụng của họ. Tôi đã trải nghiệm điều này quá thường xuyên. Tùy chọn tốt nhất là hiển thị hai từ "Lịch trình" và "Chi phí".
abhi

Tăng giá của tôi cho đến khi tôi có thể nhấn chìm cảm giác bán hết của mình trong mùi của những chiếc lưng xanh giòn!
Ewan

Đặt nó vào việc tồn đọng, ưu tiên = -1
ConditionRacer

Câu trả lời:


12

Tôi nghĩ rằng bạn đang làm điều đúng đắn. Bạn không thể làm hài lòng tất cả mọi người, và bạn không nên! Hãy lịch sự và chuyên nghiệp, nhưng bạn không cần phải làm mọi thứ bạn yêu cầu.


9

Bạn cần phải đi đến một thỏa hiệp. Người dùng của bạn (lý do ứng dụng tồn tại) nói rằng nó không đáp ứng một trong những nhu cầu của anh ấy / cô ấy.

Có một sự khác biệt giữa giải quyết nhu cầu của người dùng và cho phép người dùng cuối thiết kế ứng dụng của bạn. Có một cuộc họp với người dùng và hỏi rất nhiều "Tại sao?" các câu hỏi cho đến khi bạn đi đến cốt lõi của nhiệm vụ mà người đó đang cố gắng thực hiện và không thể, hoặc điều đó quá cồng kềnh để thực hiện trong giao diện người dùng hiện tại. Ghi lại những ghi chú đó và mô phỏng một số cách tiếp cận khác mà bạn CÓ THỂ sống cùng và trình bày lại cho người dùng.

Trên tất cả: Hãy nhớ rằng ứng dụng không tồn tại để giúp cuộc sống của bạn trở thành một lập trình viên dễ dàng hơn. Ứng dụng có mặt để phục vụ người dùng.


2
Có ý nghĩa nếu bạn đang xử lý một ứng dụng được sử dụng bởi một số ít người dùng (ví dụ: ứng dụng doanh nghiệp), nhưng sẽ quá mức nếu bạn đang cố gắng xoa dịu một người dùng ứng dụng iOS có hàng chục nghìn người dùng khác . Nếu bạn dành tất cả thời gian của mình để cố gắng xoa dịu 0,01% người dùng của bạn, bạn sẽ phát điên và phá vỡ.
Ant

1
Bạn đang thực hiện rất nhiều giả định ở đó. Chủ yếu là nỗi đau của một người dùng này không được chia sẻ với những người khác. Một cách tốt khác để phá vỡ là bỏ qua mong muốn / nhu cầu của khách hàng của bạn.
JohnFx

6

Nếu bạn đọc blog Seth Godins ( http://sethgodin.typepad.com/ ) bạn sẽ thấy thông điệp tương tự lặp đi lặp lại:

  1. Gửi một cái gì đó (và lắng nghe phản hồi)
  2. Đừng cố gắng và làm hài lòng tất cả mọi người mọi lúc.

Tôi đã có một vấn đề tương tự với bạn với một sản phẩm tôi bán. Tôi đã có tất cả các loại yêu cầu cho tất cả các loại tính năng. Ứng dụng đã trở nên phức tạp hơn tôi thực sự muốn. Mỗi tùy chọn thêm sự phức tạp, một cái gì đó tôi muốn tránh. Và bây giờ tôi có sự phức tạp hơn tôi muốn.

Làm điều này làm hài lòng nhiều người dùng hơn. Và loại bỏ những người dùng cảm thấy quá khó để thiết lập.

Có thiết lập đơn giản / nâng cao là một cách thoát khỏi liên kết. Lên đến một điểm. Nó làm cho sự phát triển của bạn phức tạp hơn, mặc dù.

Trong mọi trường hợp tôi nhận được yêu cầu, tôi luôn trả lời một cách lịch sự. Đôi khi tôi sẽ hoàn toàn từ chối, mặc dù điều này rất hiếm. Và nơi tôi làm điều này tôi giải thích lý do tại sao, thông thường nó sẽ đáp ứng yêu cầu yêu cầu toàn bộ giao diện người dùng phải được tân trang lại, một công việc khổng lồ mà tôi sẽ không đến đó. Trong trường hợp đó tôi giải thích lý do của mình, nhưng cảm ơn người dùng đã yêu cầu.

Trong TẤT CẢ các trường hợp, bao gồm cả những trường hợp tôi từ chối ngay lập tức, tôi đăng nhập chúng vào cơ sở dữ liệu các tính năng & lỗi để xem xét cho lần phát hành tiếp theo. Điều này cho phép thêm một chút thời gian để suy nghĩ về tất cả, và có thể đến sau với một giải pháp thay thế không chính xác những gì được yêu cầu nhưng có thể thêm một số giá trị.

Nếu một yêu cầu tính năng đã được xem xét, chú thích và cuối cùng một quyết định (tại thời điểm phát triển) được đưa ra để giết nó, thì tôi sẽ đóng nó lại. Nếu không, họ sẽ bị bỏ ngỏ để xem xét lại sau này.

Đây không phải là một cách tiếp cận hoàn hảo, nhưng cuối cùng, với tư cách là tác giả phần mềm, bạn có những nguyên tắc thiết kế nhất định mà bạn cần phải gắn bó hoặc từ bỏ. Sự lựa chọn của từng phương pháp nên được xem xét cẩn thận.


2

Tôi nghĩ rằng bạn nên trung thực với người dùng của bạn. Đừng nói với họ, "Chúng tôi sẽ cân nhắc điều đó", nếu bạn đã quyết định rằng bạn sẽ không làm thế. Điều đó sẽ khiến người dùng tin rằng tính năng này sẽ đến vào một ngày nào đó và trở nên thất vọng vì nó không bao giờ đến.

Về lâu dài, điều đó sẽ có lợi cho bạn nhất, tôi tin.


1

Tôi chỉ cảm ơn họ vì lời đề nghị nhưng nói rằng nó không có trên bản đồ đường bộ của bạn ngay bây giờ. Mọi người sẽ hiểu rằng bạn có nguồn lực hạn chế.


1

Tôi thường làm ba việc khi tôi ở trong tình huống như vậy:

  1. Tôi nghĩ hai lần nếu ý tưởng của người dùng có thể là một ý tưởng tốt sau tất cả. Tôi học cách không tin vào bản năng đầu tiên của mình. Đôi khi người dùng đúng và tôi sai.
  2. Giải thích cho người dùng lý do tại sao bạn không thể bao gồm tính năng đó.
  3. Giải thích cho người dùng cách cô ấy có thể nhận được những gì cô ấy cần với phần mềm cô ấy có

Tôi nghĩ rằng điểm cuối cùng là quan trọng nhất. Hầu hết người dùng không muốn chính xác đề xuất của họ được thực hiện. Họ chỉ cần một giải pháp cho một vấn đề và họ đề xuất giải pháp đơn giản nhất có thể mà họ có thể nghĩ ra. Có lẽ bạn có thể tìm thấy một giải pháp tốt hơn mà bạn có thể thực hiện.


1

Đối với mỗi sản phẩm của chúng tôi, chúng tôi có một "danh sách các ý tưởng cho các phiên bản trong tương lai". Vì vậy, những gì chúng tôi nói với người dùng của mình là "chúng tôi sẽ đưa đề xuất của bạn vào danh sách đó" - và đó là sự thật, chúng tôi thực sự làm điều đó.

Danh sách này không có ưu tiên, nhưng chúng tôi thường xuyên chọn những thứ từ nó và sử dụng chúng để cung cấp cho hồ sơ tồn đọng của chúng tôi. Chúng tôi không đưa chúng "theo thứ tự", thay vào đó chúng tôi cố gắng xác định những ý tưởng nào mang lại "nhiều lợi ích nhất" - lợi ích cao nhất cho càng nhiều người dùng của chúng tôi càng tốt, cho nỗ lực phát triển hợp lý.

Các yêu cầu tính năng chống lại tính toàn vẹn về mặt khái niệm của sản phẩm có khả năng ở đó mãi mãi. Nhưng đôi khi, có thể nhận ra rằng ít nhất một số ý tưởng bị chôn vùi trong các yêu cầu tính năng đó có thể được nhận ra, có thể không chính xác theo cách mà người đề xuất đã nghĩ ra, nhưng theo cách phù hợp hơn với kiến ​​trúc của sản phẩm.

Vì vậy, đề nghị của tôi ở đây là: đừng chỉ nói "Chúng tôi sẽ cân nhắc điều đó". và quên ý tưởng ngay khi bạn kết thúc cuộc gọi. Thay vào đó, có một công cụ nơi bạn lưu trữ các ý tưởng và yêu cầu tính năng, có thể trong trình theo dõi vấn đề, có thể trong Wiki, có thể trong bảng tính, bất cứ điều gì phù hợp với nhu cầu của bạn nhất.

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.