Jak przekonać kierownictwo do wyrzucenia prototypu?

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ć?

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.

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.

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.

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.

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

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.

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.

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.