Co robisz, gdy użytkownik prosi o funkcję, której nie zaimplementujesz?

Co robisz, gdy użytkownik prosi o złożoną funkcję, którą można zaimplementować, ale nie zamierzasz tego zrobić, ponieważ 1) dodaje niepotrzebnej złożoności innym użytkownikom 2) nie zamierzasz tego robić jako opcji, ponieważ nie chcesz, aby panel ustawień był skomplikowany.

Napisałem aplikację na iOS i jest kilku użytkowników, którzy poprosili mnie o pewne złożone funkcje, których nie mogę wykonać z powyższych powodów. Przez większość czasu odpowiadałem im, że „weźmiemy to pod uwagę”. Wyjaśnienie im, że są w mniejszości, która chce tej funkcji, również nie pomoże. Co robisz w takim przypadku?

Myślę, że postępujesz właściwie. Nie możesz zadowolić wszystkich i nie powinieneś! Bądź uprzejmy i profesjonalny, ale nie musisz robić wszystkiego, o co cię proszą.

Musisz dojść do kompromisu. Twój użytkownik (powód istnienia aplikacji) twierdzi, że nie spełnia jednej z jego / jej potrzeb.

Istnieje różnica między zaspokajaniem potrzeb użytkownika a umożliwieniem użytkownikowi zaprojektowania aplikacji. Spotkaj się z użytkownikiem i zapytaj: „Dlaczego?” pytania, dopóki nie dojdziesz do sedna zadania, które dana osoba próbuje wykonać i nie może, lub jest to po prostu zbyt kłopotliwe do wykonania w bieżącym interfejsie użytkownika. Zrób te notatki i naśladuj alternatywne podejścia, z którymi MOŻESZ żyć, i przedstaw je użytkownikowi.

Przede wszystkim: pamiętaj, że aplikacja nie istnieje, aby ułatwić Ci życie jako programista. Aplikacja ma służyć użytkownikowi.

Jeśli czytasz blog Setha Godinsa ( http://sethgodin.typepad.com/ ), zobaczysz tę samą wiadomość w kółko:

1. Wyślij coś (i wysłuchaj opinii)
2. 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.

Myślę, że powinieneś być szczery ze swoimi użytkownikami. Nie mów im, „weźmiemy to pod uwagę”, jeśli już zdecydowałeś, że tego nie zrobisz. Doprowadzi to użytkowników do przekonania, że ​​funkcja pojawi się kiedyś i będzie rozczarowana, ponieważ nigdy nie nadejdzie.

Wierzę, że na dłuższą metę przyniesie to największe korzyści.

Chciałbym im tylko podziękować za sugestię, ale powiedziałem, że nie ma jej teraz na mapie drogowej. Ludzie w większości zrozumieją, że masz ograniczone zasoby.

Zwykle robię trzy rzeczy, gdy jestem w takiej sytuacji:

1. Myślę dwa razy, czy pomysł użytkownika może być dobrym pomysłem. Nauczyłem się nie ufać mojemu pierwszemu instynktowi. Czasami użytkownik ma rację, a ja się mylę.
2. Wyjaśnij użytkownikowi, dlaczego nie możesz dołączyć tej funkcji.
3. Wyjaśnij użytkownikowi, w jaki sposób może osiągnąć to, czego potrzebuje dzięki posiadanemu oprogramowaniu

Myślę, że ostatni punkt jest najważniejszy. Większość użytkowników nie chce implementować dokładnie ich sugestii. Potrzebują tylko rozwiązania problemu i sugerują najprostsze możliwe rozwiązanie. Może znajdziesz lepsze rozwiązanie, które możesz wdrożyć.

Dla każdego z naszych produktów mamy „listę pomysłów na przyszłe wersje”. Dlatego mówimy naszym użytkownikom: „umieścimy twoją sugestię na tej liście” - i to jest uczciwe, faktycznie to robimy.

Lista nie ma priorytetów, ale regularnie wybieramy z niej różne rzeczy i wykorzystujemy je do uzupełnienia zaległości. Nie bierzemy ich „po kolei”, zamiast tego staramy się określić, które pomysły dają „najwyższy zysk” - największe korzyści dla jak największej liczby naszych użytkowników, przy rozsądnym wysiłku rozwojowym.

Żądania nowych funkcji w stosunku do integralności koncepcyjnej produktu prawdopodobnie pozostaną tam na zawsze. Ale czasami zdarza się, że przynajmniej niektóre z pomysłów zakopanych w tych żądaniach funkcji mogą zostać zrealizowane, może nie dokładnie tak, jak myśli osoba, która je zasugerowała, ale w sposób, który lepiej pasuje do architektury produktu.

Oto moja propozycja: nie mów tylko „weźmiemy to pod uwagę”. i zapomnij o tym, jak tylko skończysz rozmowa telefoniczna. Zamiast tego miej narzędzie, w którym przechowujesz pomysły i prośby o funkcje, może w narzędziu do śledzenia problemów, może na Wiki, może w arkuszu kalkulacyjnym, cokolwiek najlepiej odpowiada Twoim potrzebom.