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:
- Gửi một cái gì đó (và lắng nghe phản hồi)
- Đừ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.