Jak deweloper powinien odrzucić niemożliwe wymagania? [Zamknięte]

Oto problem, przed którym stoję:

Hej, Spark, przydzielam ci zadanie opracowania frameworka, który mógłby być wykorzystywany do wielu różnych aplikacji na iOS. Oto wymagania:

• Powinien być w stanie wykryć grubość kciuka lub palców używanych do manipulowania interfejsem użytkownika.
• Dzięki tym informacjom wszystkie elementy interfejsu powinny być automatycznie rozmieszczane i sortowane .
• W przypadku większego kciuka elementy powinny być umieszczone bliżej środka ekranu.
• W przypadku mniejszego kciuka elementy powinny być umieszczone bliżej rogów ekranu.
• W przypadku większego kciuka wszystkie czcionki powinny być mniejsze. (W tym przypadku zakładamy, że dorosły).
• W przypadku mniejszego kciuka wszystkie czcionki powinny być większe. (W tym przypadku zakładamy młodszą osobę).

Podsumowanie:

Ta struktura jest wymagana do programowego tworzenia przyjaznych interfejsów użytkownika. Ramy te powinny być opracowane w taki sposób, abyśmy mogli je wykorzystać do tylu projektów, ile potrzeba, a więc muszą być również bardzo przyjazne dla programistów.

Jestem programistą, któremu powierzono to zadanie, więc moje pytania są następujące:

• Jak mogę wyjaśnić, że te wymagania są trochę niedorzeczne?
• Jak mogę wyjaśnić, że lepiej skoncentrować się na opracowywaniu rzeczywistych projektów?
• Jak mam wytłumaczyć, że nawet gdyby to było możliwe, nie zalecałbym opracowania czegoś takiego?
• Jak powiedzieć NIE temu projektowi grzecznie, delikatnie i z szacunkiem?
• Jak mogę wyjaśnić, że nawet dla programisty z 3-letnim doświadczeniem może to nie być możliwe?

Jeśli otrzymasz zestaw wymagań, których fizycznie nie można wdrożyć, ponieważ urządzenie nie obsługuje i nie może obsługiwać pożądanej funkcjonalności, musisz to wyjaśnić osobie tworzącej wymagania.

Powinieneś być pełen szacunku i wyjaśnić, dlaczego wymagań nie można wdrożyć (tj. Ekran dotykowy nie rozróżnia kciuka, palca lub rysika. Nie ma wystarczającej rozdzielczości, aby wykryć szerokość palca.) - zachowaj rzeczywistość , wskazując na istniejąca dokumentacja, jeśli istnieje.

Nie wdawaj się w emocjonalne kłótnie i zachowaj spokój i profesjonalizm. Mówienie każdemu, że ich wymagania są głupie, nigdy nie jest zwycięską strategią.

Sprawdź, czy możesz zrozumieć rzeczywiste cele tej funkcji - dlaczego jest to postrzegane jako wymóg. Może to prowadzić do innej, lepszej funkcji, która zaspokoi potrzebę. (dzięki @spoike)

@ DarkStar33 sugeruje w komentarzach, aby przeprowadzić badania i podać rzeczywiste oszacowanie, ile będzie kosztować projekt i jak długo to potrwa, przy założeniu, że wynik będzie zbyt drogi i długi, aby był tego wart. Uzbrojenie w liczby i dane do ich wykonania z pewnością może pomóc w twojej sprawie, chociaż nadal patrzę na cele biznesowe, aby sprawdzić, czy można je (nawet częściowo) zrealizować w inny sposób.

Te wymagania nie są głupie, głupie ani śmieszne. Jest to w rzeczywistości bardzo ważny problem dla użytkowników ekranów dotykowych, ponieważ osobom z większymi palcami bardzo trudno jest wskazać cel, co często nie jest zrozumiałe dla małych palców.

Jeśli jednak nie możesz wdrożyć tych wymagań, ponieważ czujniki urządzenia nie są w stanie zmierzyć rozmiaru palca, po prostu napisz to tak: Niestety, obecnie dostępne urządzenia nie obsługują takiej funkcjonalności

Będę tu grał trochę w Adwokata Diabła i powiem, że moim zdaniem zmierzenie wielkości kciuka osoby jest technicznie wykonalne. IPhone jest urządzeniem wielodotykowym. W celu kalibracji możesz poinstruować użytkownika, aby umieścił kciuki lub dwa palce na ekranie obok siebie i zmierzył odległość między tymi dotknięciami.

Oczywiście wymagałoby to testowania i eksperymentowania, aby zobaczyć, jak wykonalna jest moja intuicja. Być może kciuki musiałyby zostać przeciągnięte po ekranie, aby uzyskać lepszy odczyt.

To powiedziawszy, istnieją poważne problemy z użytecznością i wdrażaniem.

• Co się stanie, jeśli urządzenie zostanie udostępnione? Kiedy nastąpi kalibracja?
• Jak można dynamicznie określać dowolne położenie elementów interfejsu użytkownika we wszystkich aplikacjach zbudowanych z wykorzystaniem frameworka? Oczywiście każda aplikacja będzie miała inny interfejs użytkownika i inny układ.
• Prosta ankieta na temat aktualnych aplikacji na iOS pokazuje, że dobrze zaprojektowane wykorzystują całą dostępną przestrzeń poziomą, a już elementy kosmiczne, dzięki czemu ważne przyciski są tak duże, jak to możliwe i umieszczone w pobliżu krawędzi. Oczywiście cała szerokość urządzenia jest używana do tworzenia list i układu.
• Nawet jeśli byłoby to możliwe, jaka jest analiza kosztów i korzyści? Ile można by uzyskać z takiego systemu w porównaniu ze standardowymi kontrolkami interfejsu użytkownika? Czy nie byłoby łatwiej mieć prostą kontrolę wielkości czcionki, z której korzysta już wiele aplikacji?

To, co robisz, traktuje to poważnie i powraca z oszacowaniem, ile czasu to zajmie, i upewnia się, że oszacowanie jest bardzo wysokie i bardzo szczegółowe, aby nie mogli kwestionować wysokich liczb. Gdy pokażesz, że nie będzie to opłacalne, zostawią cię w spokoju. Pamiętaj, aby wskazać, które konkretne zadania nie są obecnie obsługiwane przez sprzęt i mogą, ale nie muszą, być wykonalne. Nie zapomnij dodać kosztów dla każdego rodzaju specjalistów dodatkowych osób, których możesz potrzebować do projektu o tej skali.

Ludzie w Apple już głęboko zastanawiali się nad tymi rzeczami i nie wymyślili skalowalnego interfejsu w zależności od wielkości kciuka / palca.

Jako użytkownik nienawidzę ruchomych celów pod palcami.

Jeśli martwisz się kłopotami z powodu spełnienia niemożliwych wymagań, najlepszym wyborem jest natychmiastowe poinformowanie ich, że jest to niemożliwe. Im dłużej pozwalasz im zbudować biznesplan na niemożliwym projekcie, tym bardziej prawdopodobne jest, że będą cię winić za niepowodzenie projektu.

Przede wszystkim staraj się nie martwić o rzeczy, które nie są twoją winą, wszyscy mamy dość zmartwień o to, że mamy kontrolę. Jeśli ktoś pociągnie cię do odpowiedzialności za niepowodzenie projektu, jest to niesprawiedliwe wobec ciebie. Wierzysz w karmę?

Jednym ze sposobów na przekierowanie nieuzasadnionego żądania jest pomoc klientowi w zrozumieniu natury problemu, który próbują rozwiązać. Poprzez technikę wywiadu planistycznego zwaną potocznie „ popping dlaczego stos ”, nadal pytasz rekurencyjnie „dlaczego” (w uprzejmy, inteligentny sposób oczywiście):

Jednym z ważnych narzędzi zarówno do rozpoczęcia komunikacji, jak i „przejścia do sedna” konkretnych problemów jest to, co Barrett nazywa stosem „dlaczego”. Jest to po prostu zadawanie pytania „dlaczego tak się dzieje?” o wymaganiach projektowych. Podał archetypowy przykład tego, co technika może odkryć: „Kiedyś pracowałem z klientem, w którym istniało wymaganie, aby dane były drukowane na określonym etapie procesu, więc zapytałem, dlaczego” - powiedział. „Odpowiedź brzmiała, że ​​departament otrzymujący dane potrzebował ich do wpisania. Nigdy nie przyszło im do głowy, że dane mogą zostać automatycznie przesłane do aplikacji”.

Celem jest osiągnięcie podstawowej wartości biznesowej funkcji:

• Chroń przychody
• Wzrost przychodów
• Zarządzaj kosztami
• Zwiększ wartość marki
• Spraw, aby produkt był niezwykły
• Zapewnij większą wartość swoim klientom

(Przedmioty z wiki Ogórek )

Jeśli funkcja nie pasuje do jednej z tych kategorii, może pomóc klientowi zobaczyć, że są albo ważniejsze rzeczy, na których można się skupić, lub poprzez ten proces myślowy możesz być w stanie doradzić, jak rozwiązać problem, który „ próbuję rozwiązać w bardziej znaczący sposób. Często prawdziwy problem polega na wyższym poziomie abstrakcji niż problem, który zażądali od ciebie.

Aby użyć przykładu skanowania rozmiarów kciuka:

Klient: Chcemy, aby wykryć grubości kciuka lub palców wykorzystywane do manipulowania UI.

Dev: Dlaczego chcesz to zrobić?

Klient: Ponieważ kiedy próbuję dotknąć tych małych przycisków, często uderzam w niewłaściwą rzecz, a z naszego oprogramowania korzysta wielu pracowników budowlanych o dużych rękach, takich jak ja. Gdyby mogli skalibrować interfejs użytkownika pod kątem rozmiaru palca, byłoby to łatwiejsze w użyciu.

Dev: Łatwość użycia byłaby z pewnością cenna dla klienta, ale dlaczego miałby chcieć skalibrować interfejs? Jeśli ludzie używający tego mają duże ręce, dlaczego nie dostosować projektu do tego przypadku użycia?

Klient: Nigdy nie myślałem o tym w ten sposób, jak sądzę czystszy konstrukcja będzie działać równie dobrze dla osób z małymi dłońmi też!

Oświadczenie - nie wiem, czy twoja prośba jest możliwa, a jeśli jest to możliwe, musisz określić, jak długo to potrwa, i przekazać swoją opinię swojemu przełożonemu. Ale piszę tę odpowiedź z założeniem, że jest to niewykonalne, przynajmniej przy użyciu standardowego frameworka - i rozszerzam moją odpowiedź na bardziej ogólny przypadek, gdy naprawdę nie możesz lub nie powinieneś nic robić.

Po prostu powiedz nie.

W tym wątku jest wiele odpowiedzi „nigdy nie odmawiaj”, które moim zdaniem są łagodne i uległe. Pomyśl o tym w ten sposób - jestem ekspertem technicznym w tym zespole, a pozostali członkowie mojego zespołu próbują zrobić coś, co moim zdaniem jest niewykonalne, nadmiernie skomplikowane, potencjalnie niemożliwe. Moim obowiązkiem jest powiedzieć „nie”.

Oczywiście, że nie mogę i nie powinienem łagodnie odmawiać; Mogę „zdecydowanie odradzać to”, jednocześnie oferując „zbadanie, czy jest to możliwe”, zanim powie „nie”. Ale ostatecznie zamierzam powiedzieć nie, bo to moja praca.

Istnieje wiele analogii do tego

• Mój księgowy, chcę, żebyś odłożył mój obiad w Święto Dziękczynienia jako ulgę podatkową
• Panie szefie, chciałbym, żeby mój kurczak zostawił na ladzie na noc i podał na surowo.
• Mój prawniku, chcę pozwać moje dzieci za to, że nie sprzątają swoich sypialni
• Panie Mechanik, proszę zainstalować turbosprężarkę w moim samochodzie elektrycznym

Możesz poprosić wszystkie te osoby o wykonanie zadań, które uznają za głupie, marnotrawne, niebezpieczne lub złe. I spodziewałbyś się, że wszyscy odradzają te działania i ostatecznie odmawiają (przynajmniej mam taką nadzieję). Jeśli któryś z tych profesjonalistów odpowiedziałby „Hmm, dobrze, myślę, że możemy to zrobić” - nie dając mi wprost „This Is A Bad Idea” - to szczerze mówiąc, i tak nie chciałbym ich zatrudniać.

Twoi koledzy docenią i szanują twoją uczciwość, a ty zaoszczędzisz wszystkim dużo czasu i pieniędzy, jeśli przekażesz użyteczne informacje zwrotne zamiast postępować zgodnie z czymś, o czym wiesz, że nie zadziała.

Nie powinno być zbyt trudne powiedzenie klientowi, że nie możesz zaimplementować czegoś, na co nie pozwala platforma docelowa. Ale cofnij się i zadaj sobie pytanie, jaka jest logika tych raczej absurdalnych wymagań? Z tego, co mogę przeczytać, bardzo martwią się o łatwość obsługi. Następnie zapytaj ich, kop głębiej, aż powiedzą ci to samo: „chcemy interfejsu przyjaznego dla użytkownika”. Następnie poprowadź ich do tego, co jest wykonalne, a co nie. Powiedz im, że jeśli chcą łatwego interfejsu użytkownika, istnieją łatwe (i tańsze) sposoby, takie jak pozwolenie użytkownikowi na ustawienie rozmiaru czcionki / ikony (zakładam, że jest to możliwe w IoS). Może możesz pozwolić użytkownikowi kontrolować rozmiar czcionki / rozmiar ikony i układ aplikacji za pomocą karty ustawień? To powinno być łatwiejsze (i dokładniejsze!) Niż próba odgadnięcia wieku osoby na podstawie wielkości kciuka! Ostatnią rzeczą, jakiej chciałby twój menedżer, był niepotrzebny, rozdęty, trudny w utrzymaniu kod, który osiąga to samo, co już zapewnia system operacyjny. Poinformuj swojego klienta, że ​​użytkownicy wolą kontrolować aplikację niż aplikację kontrolującą je w sposób, który może ich wkurzyć.

Moja odpowiedź byłaby taka, że ​​zacznę badać niektóre z tych niespróbowanych technologii i dam im znać, czy to w ogóle możliwe. Na podstawie tych odkryć można rozpocząć potencjalny plan rozwoju.

Nie sądzę, że będziesz w stanie odróżnić kciuk jednej osoby od kogoś innego, ale możesz uzyskać wystarczającą liczbę wymiarów z palców, aby wiedzieć, kiedy używa kciuka. Prawdziwy problem polega na tym, że kąt kciuka może nie dotykać więcej miejsca na ekranie niż inne. Nikt nigdy nie używa telefonu kciukiem i umieszcza go płasko na ekranie, jakbyś miał odcisk kciuka.

Opuść firmę. Dowiedz się, jak to zrobić. Sprzedaj to za dużo więcej pieniędzy niż zarabiasz teraz.

Jeśli chodzi o wymagania, zwykle robię to w ten sposób: staram się oszacować, ile czasu zajmie realizacja określonego wymagania.

W przypadku wymagań, które mogą być niemożliwe, poproś o kilka dni lub czas potrzebny, aby dowiedzieć się, czy jest to możliwe. W twoim przypadku pytanie brzmi: „Czy można określić, jak gruby jest palec użytkownika?”

W rzeczywistości pytanie to jest jeszcze bardziej złożone: „Czy można określić, jak gruby jest palec użytkownika po pierwszym dotknięciu w mniej niż 200 milisekund, aby umożliwić natychmiastową interakcję?” (zastąp najpierw 2 lub 2; 200 ms 300 ms lub cokolwiek innego ...)

Może nawet odpowiedź na to pytanie potrwa miesiąc. Może nawet jeśli jest to mniej lub bardziej wykonalne, wymaga bardzo złożonego algorytmu, który działa dobrze tylko w 80% przypadków.

Widzisz gdzie idę?

Ludzie często błędnie zakładają możliwości, ponieważ mają małą wiedzę i doświadczenie w danej dziedzinie. Dlatego nie możesz argumentować intuicyjnie, ale potrzebujesz faktów.

Jeśli inni interesariusze zdadzą sobie sprawę, że ta funkcja zajęłaby 2 osobolat i wymaga, aby iPhone 10 przybył przed 2014 r., Szybko zmniejszy ich wymagania.

Brzmi to skomplikowanie, ale wcale nie jest niemożliwe; punkt, w którym ekran dotykowy nie rozróżnia kciuka środkowego palca lub rysika, jest dyskusyjny; przy inicjalizacji (uruchamianie sesji, cokolwiek) użytkownik jest proszony o umieszczenie kciuka, następnie środkowego palca itp. o skalibrowanie rozmiarów (wykonanie średnich statystycznych) za pomocą kilku ruchów itp.

Zastanowiłbym się nad rozwiązaniem problemu roota w inny sposób, zanim stwierdzę, że nie da się tego zrobić.

Na przykład, jeśli użytkownik często próbuje kliknąć mały przycisk i chybia, możesz obejrzeć obszar wokół przycisku i użyć go do ponownej kalibracji wszystkich innych kliknięć.

Przedstawienie takiego kreatywnego rozwiązania jest prawdopodobnie tym, czego oczekują, niż proszeniem cię o magiczne określenie szerokości palca (o czym możesz poinformować, że nie ma go w interfejsie API).

Może to wciąż być trudne - umieszczenie obszaru wokół przycisków w celu wykrycia nieudanych prób - oszacuj więcej godzin.

Nie mów wprost, że to nie zaszkodzi jego uczuciom. Wyjaśnij tylko, że z powodu ograniczeń technologicznych 60% czasu będzie działać za każdym razem.

A kiedy zda sobie sprawę z niepraktyczności i kosztów związanych z takim przedsięwzięciem, zaproponuj bardziej praktyczne podejście w ramach swojego budżetu, takie jak ustawienie, które pozwala zmienić rozmiar tekstu. A Rosjanie zabrali ołówek w kosmos.

Postaraj się, aby przedstawił problem i wymagania, a nie rozwiązanie i projekt dla przyszłych projektów.

Lubię podchodzić do problemu z perspektywy zespołu. W takim przypadku kierownik projektu i ja musimy znaleźć rozwiązanie. Lubię też pokazywać, że przychodzę z otwartym umysłem. Jeśli słyszę, jak myślę, niemożliwości, istnieje szansa, że ​​istnieje nieporozumienie między mną a kierownikiem projektu. A może nie osiągnęliśmy tej chwili aha.

Gdy zdecydujemy się na skok i otwartą rozmowę, najłatwiej jest mi potraktować problem jako ekonomiczny. W technologii prawie wszystko jest możliwe przy nieskończonej ilości zasobów. Omawianie tego, co trzeba zrobić, wiele razy jest najłatwiejszym sposobem, aby z szacunkiem „powiedzieć nie”. I to byłby sposób na usunięcie ewentualnych nieporozumień. Chociaż, szczerze mówiąc, nie do końca mówimy „nie”. Jaki jest cel odmowy. Jeśli praca nie jest warta wykonania, nie ma znaczenia, czy chcemy to zrobić, czy nie.