Jak przekonać kierownictwo do wyrzucenia prototypu?

16

Uwielbiam prototypowanie jako szybki i skuteczny sposób na umieszczenie interfejsu użytkownika przed użytkownikiem.

Jednak wiele razy kierownictwo przeszkadza, a prototyp zostaje wciągnięty i krzyczy do rozwoju głównego strumienia.

Jak zarządzasz zarządzaniem, aby tego nie robić?

ozz
źródło
11
Nie pokazuj dzieciom błyszczącej zabawki i nie będą mogły się nią bawić. Poważnie, spraw, aby było brzydsze, czy coś, spraw, aby NIE chciały tego, ale nadal pokazywały to, co próbujesz wyrazić.
Michael Todd
7
Przypadkowo zgub kod;)
Pemdas
9
Do napisania prototypu użyj swojego ulubionego języka programowania spoza głównego nurtu. Jeśli to nie zadziała, przynajmniej nie będziesz miał nic przeciwko utrzymywaniu go tak bardzo.
Larry Coleman,
3
Tak, spróbuj użyć Napkin Look i Feel napkinlaf.sourceforge.net
Job
1
Cóż, prototypy są tak nazywane z jakiegoś powodu. Mają zostać wyrzuceni. Jeśli tego nie rozumieją, zgadzam się z Larrym Colemanem.
sakisk

Odpowiedzi:

28

Użyj narzędzia takiego jak Microsoft SketchFlow lub stwórz swój prototyp w innym języku lub platformie, co praktycznie uniemożliwi integrację z głównym oprogramowaniem.

Jest także esej na temat oprogramowania joelons dotyczący pokazywania zrzutów ekranu i prototypów, w których sprawia, że ​​niezaimplementowane i nieobrobione aspekty wydają się oczywiście zepsute / niewdrożone, co wyraźnie pokazuje, gdzie należy jeszcze wykonać pracę.

Ważny wniosek drugi. Jeśli pokażesz programatorowi ekran z interfejsem użytkownika, który jest w 100% piękny, pomyślą, że program jest prawie gotowy.

...

Co możesz z tym zrobić? Kiedy zrozumiesz Sekret Lodowej Góry, łatwo będzie z nim pracować. Zrozum, że wszelkie dema, które robisz w zaciemnionym pokoju z projektorem, będą dotyczyły pikseli. Jeśli możesz, zbuduj swój interfejs w taki sposób, aby niedokończone części wyglądały na niedokończone. Na przykład używaj bazgrołów dla ikon na pasku narzędzi, dopóki funkcjonalność nie będzie dostępna. Podczas budowania usługi internetowej możesz rozważyć pominięcie funkcji ze strony głównej, dopóki funkcje te nie zostaną zbudowane. W ten sposób ludzie mogą oglądać, jak strona główna przechodzi z 3 poleceń do 20 poleceń w miarę tworzenia kolejnych elementów.

Spróbuj więc wykonać prototypy w Photoshopie zamiast Visual Studio lub coś w tym stylu.

Jaka jest nazwa?
źródło
1
tak, lubię Balsamiq!
ozz
+1 SketchFlow ma genialne podejście do tego powszechnego problemu; sprawiają, że interfejs wygląda na szkicowy. Czarno-biały, bezbarwny ... fantastyczne podejście do rozwiązywania tego typu problemów. Brzmi prosto, ale ma ogromny wpływ na tych, którzy widzą interfejs użytkownika, pozwalając im zrozumieć, że w rzeczywistości jest to prototyp.
Aaron McIver,
1
Słuszna uwaga. Jeśli jest to działająca aplikacja, to nie jest to prototyp.
JohnFx,
1
Możesz spróbować Ołówek zamiast SketchFlow. To nic
Brad
-1 główny link jest zepsuty
Michael Durrant
12

Nie prototypuj z działającym kodem. Prototyp z ołówkiem i papierem lub odpowiednikiem oprogramowania .

Korzystanie z makiet przypomina rysowanie, ale ponieważ jest cyfrowe, możesz go łatwo modyfikować i zmieniać. Zespoły mogą wymyślić projekt i iterować go w czasie rzeczywistym w trakcie spotkania.

http://www.balsamiq.com/images/mockups/screenshots/components.png

Korzystanie z papieru ma tę zaletę, że członkowie zespołu mogą z łatwością wskoczyć do niego i wszyscy rozumieją, że to tylko czysty arkusz papieru. To sprawia, że ​​wydaje się mniej cenny.

Alex Feinman
źródło
1
+1: To! Za każdym razem, gdy prototypowałem coś z powodzeniem za pomocą kodu, żałowałem tego później, gdy warunki zmusiły mnie do ponownego użycia tego kodu, to sytuacje dawno minęły od zamierzonej daty ważności. Innymi słowy ... JEŻELI używasz języka kodu produkcyjnego, aby ulepszyć prototyp, nie zdziw się, jeśli później skończy się w kodzie produkcyjnym.
mummey,
+1 za link Balsamiq. Często go używam i jest absolutnie niesamowity.
Ryan Hayes
Uwielbiam Balsamiq, ale nawet taki szkicowy prototyp może stać się zbyt „cenny” i pominąć programistów. Często najlepiej używać starego dobrego długopisu i papieru - i trzymać długopis w ręce każdego członka zespołu!
Alex Feinman
5

Nigdy nie narażaj jakości swojego kodu.

Pisanie śmieciowego kodu to fałszywa ekonomia.

Jak sugerują inne plakaty, możesz to osiągnąć za pomocą specjalnych narzędzi do makiet.

Istnieją jednak różne powody do budowania prototypów. Czasami możesz pokazać, czego potrzebujesz bez pisania kodu, ale często tak nie jest. Interesariusz może chcieć, abyś zademonstrował techniczną wykonalność funkcji.

Zbuduj absolutnie najsmuklejszą rzecz, jaką możesz zademonstrować / udowodnić koncepcję. Pomiń wszystko inne.

W przypadku funkcji interfejsu użytkownika upewnij się, że nic nie rozwijasz na serwerze - nie dotykaj go wcale. Rozwijaj ponownie wbudowane kpiny / podróbki.

Jeśli musisz włożyć wysiłek w dostosowanie interfejsu użytkownika do stylu pozostałej części aplikacji, nie przejmuj się. Jeśli wygląda wystarczająco dobrze bez żadnego wysiłku, zmień kolory, aby się wyróżniał, a może nawet znak wodny, aby pokazać, że jest to prototyp.

Odkryłem, że najbardziej prawdopodobnymi przestępcami powodującymi przekształcenie prototypów w kod produkcyjny są sprzedawcy. Sprzedadzą twój produkt nowemu klientowi - bez tej nowej funkcji klient nie podpisałby się. Nie możesz ich winić, mają cele. Ostrożnie z nimi; upewnij się, że nie zmuszają cię do usunięcia rzeczy, które wskazują, że jest to prototyp. Musisz stawić czoła - prawdopodobnie i tak nie powinni wprowadzać klientów w błąd.

Twoje kierownictwo może zacząć zmuszać cię do przekształcenia prototypu w kod produkcyjny kawałek po kawałku, jeśli zastosujesz się do mojej pierwszej rady, aby nigdy nie pisać kiepskiego kodu, nie powinno być problemu. Stopniowo tworzysz oprogramowanie, bez kompromisów.

Następnie, jeśli kierownictwo zacznie cię zmuszać do obniżenia jakości, musisz zadać sobie pytanie, dlaczego. Czy są pasywni? słaby? rozpaczliwy? Żadna z tych rzeczy nie jest dobrym powodem do pozostania w firmie.

Dave Hillier
źródło
1
Popieram to. Po osiągnięciu pewnego poziomu doświadczenia zbudowanie prototypu z kodem jakości produkcyjnej jest równie łatwe, jak z kodem śmieci. A głównym sposobem na osiągnięcie tego poziomu doświadczenia jest odmowa pisania niepotrzebnego kodu.
Amy Blankenship
4

Naprawdę bardzo proste. Powiedz im, że w końcu straciliby swojego ulubionego klienta, gdyby w końcu wystawili ten błędny bałagan na pokaz.

I tak, poproś ich, aby zaryzykowali, jeśli naprawdę wiedzą lepiej.

Wreszcie: nie mów, że prototyp ma określone błędy A, B i C. Wtedy będziesz zmuszony naprawić ten błąd, a kierownictwo będzie twierdzić, że przekierowało energię na przygotowanie produkcji oprogramowania.

Są szanse na te premie za wyniki i przyszłe dotacje na akcje w tych dniach, będą słuchać.

Fanatyk 23
źródło
1

Pomiń problem w pierwszej kolejności. NIE KOŃCZ GO. Rozumiem przez to, żeby nie wyglądał ładnie lub pasował do istniejących stylów na stronie. Celem jest po prostu uzyskanie możliwie najbardziej zgrubnej działającej wersji, aby można było zobaczyć, że działa bardzo podstawowy przepływ interfejsu użytkownika. Jeśli rzucisz na nią istniejący styl strony lub nadmiernie go wypolerujesz, założą się, że możesz po prostu „podłączyć”. Zarządzanie jest jak Pakleds ze Star Trek. Chcą tylko, żebyś „sprawił, że zniknie”. Im bardziej jesteś gotów, by się wydawało, tym bardziej będą gotowi myśleć.

Jeśli to nie rozwiąże twojego problemu, znajdź pracę w przynajmniej jednej firmie o znanej marce na rok. Umieść swój adres e-mail i numer w życiorysie online, a będziesz walczył z rekruterami z powrotem przy pomocy kija, co pozwoli ci powiedzieć im „absolutnie nie” z pewnością autora, który wie, co robią i może dostać nową pracę jutro, gdzie mam nadzieję, że wasza wiedza specjalistyczna w tej sprawie jest traktowana poważniej.

Obecnie pracuję nad bazą kodu, która ma nie dwa, ale potrójny stos Railsów, .NET i Java. Powodem, dla którego dostaliśmy Railsy, ​​był fakt, że prototyp został wykonany w Railsach, a czołowy pies w firmie powiedział „zrób to”. Czasami musimy odmawiać. Dopóki nie robimy tego cały czas, powinniśmy traktować nas poważnie.

Ale tak, cokolwiek zrobisz z prototypem, upewnij się, że zaczyna się naprawdę brzydko.

Erik Reppen
źródło
1

Nie martw się o to.

Jeśli usiądziesz i rzucisz kontrolki interfejsu użytkownika dla „prototypu”, nie ma dokładnie żadnego powodu, dla którego powinieneś automatycznie wyrzucić ten projekt. Jeśli było wystarczająco dobre, aby pokazać zarządzanie, to jest to dobre miejsce, aby zacząć, kiedy kodować „prawdziwy” program.

Przejście od prototypu do bardziej „dopracowanego” interfejsu użytkownika powinno być niczym więcej niż serią całkowicie uzasadnionych kroków. Trzeba było dodać drugi przycisk. Otrzymałeś opinię od użytkowników, że uznali zamówienie za mylące. Grupa standardów Twojej organizacji podyktowała drobną zmianę. Trzeba było zmienić rozmiar pola tekstowego na potrzeby internacjonalizacji.

Ani jeden z tych powodów nie jest „cóż, to był tylko prototyp”. W projektowaniu interfejsu użytkownika, w kodzie lub na piśmie, WSZYSTKO może zakończyć życie na zawsze. A ci, którzy nie wszyscy, powinni mieć bardzo dobre powody, aby je zabić.

A zarządzania prawdopodobnie nie obchodzi.

Realistycznie, jeśli powodem, dla którego po prostu nie wprowadziłeś interfejsu użytkownika do istniejącego kodu, było „Musiałem przepisać go w naszym poprawnym środowisku”, to powinno wystarczyć. A jeśli nie, prawdopodobnie powinieneś porozmawiać o samym frameworku interfejsu użytkownika, ale to kolejne pytanie.

DougM
źródło
0

Miałem ten problem, dopóki nie zdałem sobie sprawy, że to nie był problem, ale sposób na uwolnienie się od raczej przestarzałych standardów programistycznych narzuconych większości sklepów.

Mówisz więc swojemu kierownictwu, że piszesz prototyp, wybierasz technologie, które najlepiej dla Ciebie działają w tym obszarze problemowym, a następnie piszesz oprogramowanie z pełną świadomością, że trafi ono do produkcji.

Unikasz nudy „aplikacje muszą być w Javie 1.6 za pomocą sieci (wstaw drogi silnik J2EE do wyboru przez kierownictwo)” i bezsensownych standardów nazewnictwa itp.

Moimi obecnie wybranymi językami prototypowymi są „php” (które można skalować do środowisk produkcyjnych o dużej wytrzymałości - wystarczy zapytać Facebooka) oraz bardzo eleganckie połączenie Groovy / Java z Tomcat lub Jetty.

Połączenie groovy / java doskonale nadaje się do szybkiego rozwoju. Groovy jest przyjemny w użyciu, szybko się rozwija, ale działa jak ślimak geriatryczny, jednak niezwykle łatwo jest zmienić czynniki krytyczne pod względem wydajności na czystą Javę. Poślubienie aplikacji do Tomcat lub Jetty oznacza, że ​​już nigdy nie będziesz mieć do czynienia z EJB i innymi okropnościami J2EE.

Główną zaletą posiadania działającego prototypu w przeciwieństwie do szkicu zaproponowanego przez kilka plakatów jest informacja zwrotna od użytkowników. Prototypy to świetny sposób na prawdziwe zaangażowanie firmy w projektowanie. Kiedy zdadzą sobie sprawę, że mogą powiedzieć: „czy to pole nie powinno być na ekranie głównym” i hej presto! tam jest na ekranie głównym podczas następnej wersji demo, którą otwierają i angażują się w projektowanie, przynosząc do projektu lata cennych doświadczeń biznesowych.

James Anderson
źródło
„Groovy jest przyjemny w użyciu, szybko się rozwija, ale działa jak ślimak geriatryczny, jednak niezwykle łatwo jest zmienić czynniki krytyczne pod względem wydajności na czystą Javę”. Naprawdę musisz przebudować cały prototyp na Javę, jeśli używasz Groovy do zbudowania prototypu.
Vorg van Geir