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

15

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?

Ryan
źródło
3
Wygląda na to, że opisujesz różnicę między wodospadem a zwinnym / iteracyjnym rozwojem. Jeśli przejdziesz do Google za / przeciw tych dwóch podejść, zobaczysz wszystkie zalety zwinności i możesz użyć ich jako argumentu. Mam listę, ale w tej chwili nie jest przydatna.
Bob Horn,

Odpowiedzi:

15

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.

Telastyn
źródło
10
i przedstawiłbym alternatywę, która znacznie zwiększa szanse na uzyskanie projektu, z bardziej realistycznymi celami.
Paul Hiemstra
1
Tam, gdzie to możliwe, podziel szacunki na „rdzeń”, „miło mieć”, „musisz marzyć” (nie wypowiadaj tego w ten sposób przed klientem). Bądź jednak ostrożny, wykonując całą analizę biznesową za darmo.
mattnz
@PaulHiemstra - doskonały punkt. Jestem przyzwyczajony do pracy z klientami wewnętrznymi, ale rada też tam jest.
Telastyn
@Telastyn patrz edycja postów
Ryan
W rzeczywistości nie trzeba szacować wszystkich tych funkcji. bądź zwinny, wybierz pierwszą dwudziestkę i powiedz, że z przyjemnością umieścisz je w wersji 1.0 za $ x. Powiedz, że nie chcesz inwestować czasu z góry, szacując cenę wersji od 1.0 do 1.8.
MSalters
12

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.

Peter Rowell
źródło
7

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.

Dozorca więzienny
źródło
To jest właśnie użycie uprzejmości :) Nie usuwając go z listy, ludzie pozostają zadowoleni!
Geerten,
Podobnie jest w przypadku podejścia MuSCoW.
Thinhbk,
3

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,

Joris Timmermans
źródło
Dzięki. Ale jeśli wiesz, że klient chce płacić na podstawie projektu i cała ta analiza musi zostać wykonana z góry (co może potrwać kilkadziesiąt godzin), zanim cena projektu zostanie ustalona, ​​to w jaki sposób ustrukturyzujesz rekompensatę za wstępne prace analityczne?
Ryan
@Ryan - wprost odmówiłbym wykonania jakiejkolwiek szczegółowej analizy z góry dla dużego projektu, ponieważ a) dałby zły pomysł (patrz „Stożek niepewności” - en.wikipedia.org/wiki/Cone_of_Uncertainty ) ib ) jest to naprawdę cenna praca, którą klient mógłby podjąć w innym miejscu, aby zrealizować projekt. Po tym, jak przynajmniej raz znalazłem się w dokładnie takiej sytuacji, co wiem, teraz upewniam się, że pobieramy również opłatę za prace analityczne (podlega zwrotowi, jeśli klient zaakceptuje projekt).
Joris Timmermans
1

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.

Paul Hiemstra
źródło
1

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.

Matthew Flynn
źródło
1

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”.

Tangurena
źródło
0

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 :)

Jusubow
źródło
0

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.

Geerten
źródło
W porządku. Ale jeśli klient chce pracować dla każdego projektu, jak przekonać go, aby zapłacił ci za całą pracę związaną z planowaniem, zanim zostanie podjęta decyzja w sprawie projektu?
Ryan,