Jak przekonać klienta nietechnicznego, że specyfikacja aplikacji wymaga uproszczenia?

Często mam do czynienia z sytuacją, w której przychodzi do mnie nowy klient z aplikacją, która ma dosłownie setki niepotrzebnych funkcji i jest całkiem jasne, że należy drastycznie uprościć projekt, aby miał szansę powodzenia. Jak przekonać klienta do przyjęcia bardziej uproszczonego podejścia opartego na minimalnym produkcie żywotnym (MVP)?

edytować:

Tak więc obecną najlepszą odpowiedzią jest dostarczenie klientowi oszacowania czasu / kosztu dla ogromnej aplikacji. Nie przepadam za tą odpowiedzią, ponieważ nie rozwiązuje ona prawdziwego problemu z tą sytuacją. I to jest - złą praktyką jest spreparowanie ogromnej aplikacji, a następnie próba zbudowania jej od samego początku. Na początku czuję się znacznie bardziej komfortowo, budując mały, prosty fundament MVP. A następnie dodając po kolei małe funkcje do tej podstawy. Jak więc przekonać klienta do takiego podejścia do tworzenia oprogramowania?

Szacując, ile pieniędzy / czasu będzie kosztowało wykonanie setek funkcji o wysokiej jakości. Bardzo niewielu klientów wkłada pieniądze tam, gdzie jest ich usta.

Dwa słowa: historie użytkowników.

Dowiedziałem się, że najszybszym sposobem pomocy klientowi w zdobyciu wskazówki Aue jest poprowadzenie go przez historię użytkownika dla każdej funkcji lub strony, której chcą. Stało się kilka rzeczy, w tym:

1. Muszą pomyśleć o tym, co do cholery ma zrobić strona / funkcja.
2. Kiedy prosisz o coraz więcej szczegółów („a potem? ... a potem? ...”), zaczynają rozumieć, że cała ta sprawa nie powstanie, gdy Magic Space Monkeys ™ przyleci i zrobi to w weekend.
3. Stają się prawdziwymi partnerami w procesie tworzenia. Co oznacza, że ​​zrozumieją, dlaczego zmiana zdania na temat czegoś, co jest już ukończone w 80%, spowoduje a) opóźnienie harmonogramu i b) wzrost kosztów.

Poważnie. Historie użytkowników autorstwa właścicieli to jedno z najlepszych narzędzi, jakie znam, aby wnieść przynajmniej trochę rozsądku do procesu.

Omawiając aspekt kosztów i czasu produkcji, poproś o ranking wymagań („musi mieć”, „powinien mieć” i „miło mieć”), aby minimalny zestaw istotnych cech produktu, które są niezbędne, to: „must have” w wersji 1, a następnie umieść resztę wymagań w zestawach zaległości, które można wykonać jako sprinty po pierwszej wersji. Mamy nadzieję, że nieistotne „miło mieć” przejdą na tył paczki i do czasu, gdy dotrzesz do sprintu, nowe, które są bardziej istotne (od rzeczywistego doświadczenia z produktem), będą pływać na szczyt.

Klient powinien docenić fakt, że bierzesz pod uwagę koszt jego działalności i znaczenie szybkiego uzyskania produktu, i nie odrzuca się bezpośrednio jego „miło mieć”, umieszczając je w zaległościach.

Edytuj, aby odpowiedzieć na edycję OP: Aby przekonać klienta, dlaczego dobrym pomysłem jest wczesne wydanie minimalnego możliwego do zrealizowania produktu, wyjaśnij, że dopóki rzeczywisty użytkownik nie użyje tego produktu, trudno jest ustalić, czy odniesie sukces (szczególnie pod względem użyteczności). Jeśli klient waha się przed wydaniem wczesnego produktu całej swojej grupie użytkowników, zaleca się wykonanie „ograniczonej wersji beta”, w przypadku gdy jest on dostępny tylko dla określonej grupy klientów. Powiedz im, że drugą stroną tego podejścia jest długi, kosztowny cykl rozwoju z późnym ustaleniem, że produkt nie nadaje się do użytku. 37 Firma Signals opracowała kilka dobrych referencji na ten temat: „ Real Real and Rework” . The Real Real jest dostępny w Internecie za darmo.

Główną przyczyną twojej frustracji sytuacją jest prawdopodobnie spostrzeganie i wprowadzanie w błąd / niewłaściwe terminy stosowane przez klienta. Klient zwykle nie przychodzi do ciebie z listą wymagań , ale lista życzeń każdej rzeczy, o której może pomyśleć, może być dla nich przydatna. Nie są to wszystkie wymagania, ponieważ klient nie spędził jeszcze czasu, aby naprawdę zastanowić się, czy każda funkcja jest naprawdę wymagana .

Nie zawsze jest to problem

Jeśli twój klient ma pieniądze na wszystkie te funkcje i chce się z nim rozstać, a tak naprawdę nie zależy ci na rozwiązaniu rzeczywistych, rzeczywistych problemów, jakie ma klient, może to być bardzo lukratywny projekt. Zdarza się to bardzo, bardzo rzadko, a dla większości programistów zabija duszę, ponieważ możesz z góry poczuć, że projekt ostatecznie nie odniesie sukcesu dla klienta (nawet jeśli odniesie sukces finansowy dla Ciebie jako programisty). Jest to również wysokie ryzyko, ponieważ prawdopodobnie skończysz z projektem o stałym koszcie z dużą niepewnością, a naprawdę błędem jest oszacowanie ryzyka w dużych projektach.

Co jeśli jest to problem?

Załóżmy, że nie jesteś w tak rzadkiej sytuacji. W takim przypadku będziesz chciał zająć się dwoma głównymi niedociągnięciami na liście życzeń, jak podano:

1. Jest mało prawdopodobne, aby klient miał dobre pojęcie o kosztach opracowania tak dużej listy wymagań, więc jest mało prawdopodobne, aby uzyskać umowę na kwotę, której faktycznie potrzebujesz.
2. Jest mało prawdopodobne, aby ta lista życzeń dokładnie i zwięźle opisała prawdziwy problem, który klient ma i chce rozwiązać.

Z mojego doświadczenia wynika, że ​​trzeba rozwiązać problem 2, aby naprawić 1. Drobiazgowanie do rzeczywistego problemu oznacza, że ​​Ty, programista, masz teraz niezbędny wkład, aby dokonać kreatywnych kroków w rozwiązaniu problemu w sposób, o którym sam klient nawet nie pomyślał. Rozwiązania te będą prawdopodobnie znacznie tańsze i szybsze niż wdrożenie pełnej listy życzeń.

Jak to naprawić?
Jak mówi Matthew Flynn w swojej odpowiedzi - zacznij od tego, aby klient nadał priorytet wymaganiom. Nie zawsze jest to łatwe, ale zmusza ich do zrobienia tego. Jeśli to konieczne, użyj wyrażenia „Jeśli ktoś trzymałby ci pistolet przy głowie, jaki pojedynczy warunek byś zachował?” Podczas tego procesu często przekonasz się, że klient tak naprawdę nie ma jasnego pojęcia, co oznaczają poszczególne wymagania. W takim przypadku zrób to, co sugeruje Peter Rowell, i przekonaj klienta do pracy za pośrednictwem historii użytkowników. Ty i klient zaczniecie lepiej rozumieć problem i wymagania, a następnie będziecie mogli powrócić do ustalania priorytetów. Powtarzaj te kroki tak często, jak potrzebujesz, aż poczujesz się komfortowo, wiedząc, że możesz rozwiązać problem klienta .

Jak to odpowiada na pytanie dotyczące opracowania rozwiązania? Po utworzeniu listy wymagań z priorytetami, masz dane potrzebne do zasugerowania klientowi stopniowego procesu rozwoju. Nie musisz nazywać go Zwinnym, ale możesz zasugerować, aby rozbić umowę na mniejsze części dla każdego wymagania (lub niepodzielnego zestawu wymagań) i dostarczyć je pojedynczo, z potwierdzeniem przez klienta. Możesz też zrobić wszystko i wykorzystać wiele zasobów dostępnych online i offline, aby przekonać klienta, że ​​w ich najlepszym interesie jest współpraca w jednym ze zwinnych stylów programowania. W każdym razie możesz przedstawić swoją umowę / propozycję projektu w formie, która wyraźnie sugeruje te elementy składowe wymagań w kolejności priorytetowej, każda z własnym kosztem i wnioskiem. Trzymaj marchewkę przed klientem,

Najpierw spróbuję wyjaśnić, że ich wymagania nie są realistyczne, i przedstawię im zestaw wymagań przeciwnych. Wyjaśnij, że rozwiąże to ich problem prościej i szybciej, a tym samym przy niższych kosztach i ryzyku. Nie próbuj przerabiać tego na dyskusję techniczną, klient nie dba o to. Klientowi zależy na tym, aby uzyskać dobry produkt na czas, rozwiązując swój przypadek biznesowy. Jeśli klient się nie ruszy, albo zaakceptuj umowę i wykonaj pracę, albo odrzuć i wyjaśnij klientowi, dlaczego nie możesz wziąć odpowiedzialności za projekt w tym formularzu.

Podobnie do tego, co sugerowali inni ludzie, ale nieco inaczej, sugerowałbym, że wszystko, co klient może być ważny, musi jednak PRIORYTETOWAĆ. Który przedmiot musi być zrobiony pierwszy. Który przedmiot należy zrobić jako drugi. Co najważniejsze, jeśli zabraknie Ci czasu, których przedmiotów będzie najmniej bolało, których nie będziesz mieć. Priorytetyzuj każdy element od 1 do 732 (lub cokolwiek) i wypełniaj je w tej kolejności.

Historycznym przykładem aplikacji, która skończyła się z przekroczeniem budżetu i opóźnieniem z powodu nadmiernych wymagań, jest wirtualny plik sprawy FBI. Miało to zastąpić kilkadziesiąt istniejących aplikacji i wszystkie musiały działać całkowicie od razu po przełączeniu. Projekt został ostatecznie anulowany. Sukcesem byłoby zaprojektowanie frameworka i stopniowe zastępowanie poszczególnych aplikacji nowym systemem. Zamiast tego polityka i walki doprowadziły do ​​tego, że każdy interesariusz aplikacji oświadczył, że jej aplikacja jest najważniejsza, a wszyscy wybrali swoją specyfikację słowami „must have” ze wszystkich funkcji, które chcieli dodać do istniejącej aplikacji. Do końca liczba żądań zmian pisanych każdego dnia przekroczyła ilość kodu pisaną każdego dnia.

Widziałem, że „muszę mieć wszystko” działa w 2 przypadkach. W jednym duży klient finansowy (korzystający z wodospadu wszystkich rzeczy) miał 40 różnych systemów (nasza firma dokonała jednego z 40), które zostały wymienione i uruchomione za jednym zamachem. Testy integracyjne i komunikacja były ogromnymi problemami. Szacuję, że spłonęły one około 100 tys. USD dziennie podczas połączeń konferencyjnych (licząc stawkę naliczania opłat za wszystkie połączenia). W obu przypadkach potrzebni byli silni negocjatorzy, aby opracować listę tego, co miało zostać dostarczone, a następnie przybili wszystkich do ziemi. Nie było ruchu bramek, renegocjacji. Oba zadania zakończyły się terminowo i zgodnie ze specyfikacją. Jeden z nich był znacznie wyższy niż budżet, a drugi budżet. W tym celu potrzebujesz bardzo dobrych kierowników projektów, którzy wiedzą, co mogą zapewnić ich zespoły (tacy, którzy mogą powiedzieć, że funkcja Q zajmuje 3.

Brak doskonałych PM, negocjatorów i wskaźników, radziłbym popchnąć klienta w kierunku dostaw przyrostowych. Jeśli nadal chcą od razu całego złotego klocka, można im lepiej pomóc, pomagając im znaleźć inne doradztwo. Czasami najlepszą odpowiedzią jest „nie możemy ci pomóc”.

Krótka odpowiedź: chciałbym wysłuchać mojego klienta i znaleźć z nim podejście pośrednie.

Proponuję wysłuchać klienta i w zależności od jego budżetu i harmonogramu podzielić projekt na etapy (wydanie, wydanie 2 itp.).

Następnie możesz kontynuować szacowanie każdego etapu dostarczania, budżetu i ustalanie priorytetów wymaganych funkcji, które powinna zapewnić aplikacja.

W ten sposób można określić zakres prac i rezultatów :)

Jak podają inne odpowiedzi, ustalanie priorytetów jest bardzo ważne. Przydatnym sposobem na to jest metoda MoSCoW . Ale możesz zacząć od podzielenia całej listy, w przeciwnym razie sama lista funkcji sprawi (lub twojemu klientowi) problemy ze zrozumieniem :)

Oprócz tego masz problem z postrzeganiem problemu jako całości. Prawdopodobnie możesz to rozwiązać, siedząc z klientem i wykonując następujące czynności:

• Przeglądaj globalnie funkcje i destyluj z nich kategorie
• Określ priorytety (używając MoSCoW) kategorii i może zdefiniuj hierarchię (jedna podstawowa kategoria z domyślnymi funkcjami, kategorie głównych tematów, kategorie dla określonych odmian głównych tematów). Może to zmienić kategorie zdefiniowane w poprzednim kroku (dzięki nowym informacjom).
• Przejrzyj kolejno każdą funkcję i przypisz ją do kategorii
• Priorytetyzuj (używając MoSCoW) elementy w pierwszej kategorii.

Zapewni to ładny i zwięzły widok z góry żądanych funkcji i da kierownicę do definiowania różnych iteracji, aby rozpocząć od bazy i rozszerzyć ją o inne funkcje.