Jeśli czytasz blog Setha Godinsa ( http://sethgodin.typepad.com/ ), zobaczysz tę samą wiadomość w kółko:
- Wyślij coś (i wysłuchaj opinii)
- Nie próbujcie zadowolić wszystkich ludzi przez cały czas.
Mam podobny problem z produktem, który sprzedaję. Otrzymałem wiele zapytań o wszystkie funkcje. Aplikacja stała się bardziej złożona, niż naprawdę chciałem. Każda opcja dodaje złożoności, czego chciałem uniknąć. A teraz mam większą złożoność, niż bym chciał.
Robi to zadowolenie większej liczby użytkowników. I odstrasza użytkowników, dla których konfiguracja jest zbyt trudna.
Prosta / zaawansowana konfiguracja jest wyjściem z wiązania. Aż do punktu. Jednak sprawia, że twój rozwój jest bardziej złożony.
We wszystkich przypadkach, w których otrzymuję prośbę, zawsze odpowiadam uprzejmie. Czasami wprost odmówię, choć jest to rzadkie. A gdy to robię, wyjaśniam, dlaczego zwykle byłby to odpowiedź na prośbę, która wymagałaby przebudowy całego interfejsu użytkownika, przedsięwzięcie tak ogromne, że po prostu tam nie pójdę. W takim przypadku wyjaśniam powody, ale dziękuję użytkownikowi za prośbę.
We WSZYSTKICH przypadkach, łącznie z tymi, które natychmiast odrzucam, loguję je w bazie danych funkcji i usterek w celu rozważenia na następne wydanie. Pozwala to nieco więcej czasu na przemyślenie wszystkiego i być może wymyślenie później alternatywy, która nie jest dokładnie tym, o co proszono, ale może wnieść dodatkową wartość.
Jeśli żądanie funkcji zostało rozpatrzone, opatrzone adnotacjami i ostatecznie (w czasie programowania) podjęta została decyzja o jego zabiciu, zamykam je. W przeciwnym razie pozostaną otwarte do ponownego rozpatrzenia później.
To nie jest idealne podejście, ale ostatecznie jako autor oprogramowania masz pewne zasady projektowania, których musisz albo trzymać się, albo porzucić. Wybór każdego podejścia powinien być starannie przemyślany.