Ciężkie życie korporacyjnego projektanta

Cała sprawa wydarzyła się ponad dwa lata temu. Amerykański projektant interfejsów, Dustin Curtis, zmuszony do skorzystania z mało użytecznej i źle zaprojektowanej strony American Airlines poważnie się wkurzył i obiecał sobie nigdy więcej nie być klientem tej linii lotniczej. A potem zaprojektował nową wersję serwisu, tak jak powinien on według niego wyglądać, i wystosował otwarty list do American Airlines:

Jak to się stało? Gdybym prowadził firmę o takim znaczeniu i historii jak American Airlines byłoby mi głupio – a raczej wstyd – że ma ona serwis, który robi tak złe wrażenie na klientach. Jak wasz CEO, Gerard J. Arpey, usprawiedliwi traktowanie klientów w ten sposób? Czemu wasza rada nadzorcza pozwala na to? Wasza strona internetowa jest obrazą dla waszych klientów, ogranicza wasze przychody i trwale niszczy obraz waszej marki w umyśle każdego odwiedzającego użytkownika.

Tak wyglądał wtedy serwis AA.com (mocno go teraz poprawili):

aa.com

A tak zaprojektował go od nowa Curtis:

aa.com2

Akcja wywołała w sieci małe poruszenie i doczekała się odpowiedzi ze strony anonimowego pracownika American Airlines, zajmującego stanowisko głównego architekta user experience w zespole serwisu AA.com (więc chyba nie był aż tak bardzo anonimowy 😉 ). Patrząc na stronę trudno byłoby się domyślić, że istnieje tam jakiś zespół user experience, a jego szefem jest ktoś z 10 letnim doświadczeniem i podobno wieloma niezłymi projektami na koncie. Oto co napisał ten człowiek w odpowiedzi:

Masz rację. Masz wiele racji. Ale… (…) Problem z projektem AA.com nie wynika z braku naszych kompetencji, a ma więcej wspólnego z kulturą organizacyjną i wewnętrznymi procesami American Airlines.

Pozwól mi to wytłumaczyć. Zespół zajmujący się AA.com składa się 200 osób z wielu różnych działów, np. QA, planowania produktów, analizy biznesowej, IT, zarządzania serwisem, zarządzania projektem i user experience. Bardzo wielu ludzi wywiera bezpośredni wpływ na serwis, a jeszcze więcej osób ma swoje interesy, które oddziałują na jego funkcjonalność i to w jaki sposób w serwisie prezentowany jest content. (…) Chcę powiedzieć, że AA.com to wielkie korporacyjne przedsięwzięcie z wieloma mackami, które sięgają wielu osób. Nie jest to mała rzecz, w żadnym razie.

Och, jakbym chciał, żeby tak było! Wyobrażam sobie jak fajne rzeczy moglibyśmy robić, gdybyśmy działali jak 37signals z ich filozofią Getting Real! (…) Moglibyśmy powiedzieć „nie” żądaniom o nowe funkcje. (…) Moglibyśmy przeprojektować stronę główną AA.com nie grzęznąc w niekończących się cyklach akceptacji, poprawek i akceptacji poprawek.

Ale – i to jest rzecz, którą przede wszystkim chcę przekazać – przeprojektowanie samej strony głównej to bułka z masłem. Chcesz redesignu? Mam ich sześć w moim archiwum. Wystarczy parę godzin, żeby zrobić naprawdę nieźle wyglądającą wersję, jak to pokazałeś. Ale projektowanie nie jest najtrudniejszą częścią tej pracy, czego wiele osób nie rozumie, prawdopodobnie dlatego że wiele z nich pracuje w małych firmach. Jednak ci z nas, którzy pracują dla wielkich korporacji zdają sobie sprawę z tego, jak wielkie przeciwności musi pokonać nawet najmniejszy redesign.

Chciałoby się powiedzieć: święta prawda. Pracuję dla klientów korporacyjnych już od dobrych kilku lat. Często okazuje się, że największym wyzwaniem jakie stoi przed projektantem dużych serwisów dla dużych klientów nie jest maksymalizacja użyteczności ani poprawa skuteczności biznesowej, ale obronienie spójności i sensu jak największej części projektu przed zupełnym zniszczeniem przez korporacyjną machinę. Kto nie brał udziału w całodniowych spotkaniach projektowych, w których uczestniczy 15 osób po stronie klienta, z których połowa nie wie w ogóle o czym mowa, ale czuje że musi zaznaczyć swoją obecność zgłaszając jakieś uwagi, ten nie zrozumie. Bywa, że wiele trzeba odpuścić, żeby udało się przepchnąć rzeczy najważniejsze. Oczekiwania różnych działów korporacji są czasem zupełnie sprzeczne i nie przyświeca im żaden nadrzędny cel. Zwykle brak także myślenia o celach użytkowników i scenariuszach użycia produktu, cała para idzie za to w wymyślanie jak największej liczby funkcji. Nierzadko po tygodniach projektowania dowiadujemy się spraw, które wywracają projekt do góry nogami. Akceptacje przez kilka pionów oraz prezesa, niekończące się zgłaszanie zmian przez różne osoby i kilkanaście wersji jednego elementu to w wielu firmach standard. Brałem udział w projekcie portalu, który ciągnął się przez dwa lata i skończył się średnio mimo, że był modelowym procesem user-centered design. W niektórych projektach przygotowanie samej strony głównej, to ponad miesiąc z głowy i kilkadziesiąt wersji. Mowa o samym projekcie architektury informacji, zanim zacznie się znęcanie nad grafiką. Aby było jasne – nie mam tu na myśli ulepszania projektu przez wiele iteracji, co jest jak najbardziej OK. Chodzi o zapętlające się cykle zmian, które prowadzą donikąd, bo wynikają z nieskoordynowanych uwag zbieranych nawet od kilkudziesięciu osób, zwykle bez podstawowej wiedzy o projektowaniu.

Według moich obserwacji istnieją dwie możliwe sytuacje, w których z wielkiego korporacyjnego projektu może wyjść coś dobrego (patrząc na to z perspektywy współpracy z zewnętrzną agencji świadczącą usługi projektowe B2B).

Po pierwsze – kiedy korporacja uzna projekt za mało ważny lub innym dziwnym zbiegiem okoliczności nie będzie się wtrącać w szczegóły procesu projektowego zostawiając to w całości wykonawcy 🙂 To jednak zdarza się niezmiernie rzadko… Nie gwarantuje to oczywiście sukcesu, ale pozwala przynajmniej zachować spójność rozwiązań, co jest sprawą niebagatelną.

Druga (idealna) możliwość, to sytuacja w której po stronie klienta znajdzie się jedna osoba zarządzająca projektem i mająca ostatecznie decydujący głos w każdej sprawie, która projektu dotyczy – kompetentna, dyspozycyjna, nie unikająca odpowiedzialności i mogąca przeciwstawić się wewnętrznym naciskom. Na szczęście podczas pracy z dużymi korporacjami coraz częściej zdarza mi się spotykać z dobrymi project managerami, którzy potrafią zapewnić przepływ informacji i efektywnie pokierować przebiegiem prac szybko podejmując decyzje jeśli zachodzi sprzeczność interesów i odfiltrowując niemądre pomysły. Tylko kiedy po stronie klienta zaistnieje ktoś taki, możliwe jest że duży korporacyjny projekt zakończy się stworzeniem naprawdę udanego produktu.

Kiedy nie zachodzi żadna z tych sytuacji rzadko udaje się doprowadzić projekt do szczęśliwego zakończenia i wymaga to wielu walk. Zwykle kończy się wtedy na projektowaniu przez komitet i często najgorszym z możliwych kompromisowym rozwiązaniu – jak w przypadku opcji wylogowania z Windows Vista, która udostępniała aż 9 możliwości do wyboru.

vistaOff

Po artykule krytykującym ten ficzer napisanym przez Joela Spolsky’ego, jeden z byłych programistów Microsoftu, który przez rok (!) pracował nad menu wylogowania z Visty, ujawnił w jaki sposób doszło do takiego projektu. Warto poznać tę straszną historię ku przestrodze 😉

Spędziłem cały rok pracując nad funkcją, która powinna zostać zaprojektowana, zaimplementowana i przetestowana w ciągu tygodnia (…).

Mój zespół miał bardzo utalentowanego projektanta interfejsów i świetnego PMa z wiedzą na temat user experience. Mieliśmy Maca (prywatną własność jednego z członków zespołu), na którego patrzyliśmy jako na wzór prostego interfejsu. (…) Mieliśmy też eksperta UX, zespół testerów, kilka poziomów managmentu i mnie piszącego kod.

Tylko w moim teamie, następujące osoby uczestniczyły w każdym spotkaniu:

  • 1 program manager
  • 1 developer
  • 1 lider developerów
  • 2 testerów
  • 1 lider testerów
  • 1 UI designer
  • 1 ekspert user experience

Łącznie 8 osób.

Spotkania odbywały się każdego tygodnia przez cały rok, kiedy pracowałem nad Windows.

Ponadto byliśmy zależni od zespołu shella (ludzi, którzy pisali i testowali pozostałą część menu “Start”) i od teamu kernela. (…) Każda z części tych zespołów, z którymi współpracowaliśmy liczyła mniej więcej tyle samo osób, co nasz team. (…) Co więcej, każdy zespół był oddzielony przez 6 warstw managementu, co daje 24 + (6 * 3) + 1 (jeden wspólny manager) 43 osoby mające decyzję w sprawie jednej funkcji.

Zresztą “funkcja” to zbyt mocne słowo, bardziej odpowiednie byłoby “menu”. Naprawdę. Kiedy odchodziłem, cały kod, który stworzyłem liczył najwyżej kilkaset linii.

Oto jak wyglądał nasz proces projektowy: mniej więcej co 4 tygodnie na naszym cotygodniowym spotkaniu PM mówił “shell team nie zgadza się, że to ma tak wyglądać/działać/zachowywać się” i “kernel team podjął decyzję, że zrobi/nie zrobić coś, co pozwoli/nie pozwoli nam coś zrobić”. I wtedy spędzaliśmy 90 minut debatując, jak nasza funkcja – tzn. menu – powinno wyglądać opierając się na tych “nowych” informacjach. Potem na naszym następnym cotygodniowym spotkaniu spędzaliśmy następne 90 minut dyskutując o projekcie, na następnym cotygodniowym spotkaniu robiliśmy to samo, a potem na następnym cotygodniowym spotkaniu udawało nam się ustalić jedną wersję. Wtedy na naszym kolejnym cotygodniowym spotkaniu dostawaliśmy jakąś brakującą informację z zespołów shella lub kernela i zaczynaliśmy cały proces od nowa.

(…) Pomijając wszystkie problemy z podejmowaniem decyzji, żaden team nie miał pojęcia, co robi inny team, dopóki nie minęły tygodnie.

Efekt końcowy jest tym, co znalazło się w gotowym produkcie: najniższa możliwa denominacja, najłatwiejsze i najmniej kontrowersyjne rozwiązanie.

Jeśli brak dobrego procesu pracy i odpowiedniej kultury organizacyjnej na nic mogą się okazać nawet najlepsi projektanci. To jest odpowiedź na pytanie dlaczego tak wiele dużych firm, które zatrudniają przecież wielu inteligentnych i zdolnych ludzi ma tak źle zaprojektowane produkty i usługi.

PS. Bardzo pomagają też projektowi deadline-y, które ucinają zbyt długie dyskusje, ale tylko pod warunkiem że są przestrzegane przez wszystkie strony, a nie tylko wymagane od projektanta.

PS2. Projektant powinien mieć także możliwość kontrolowania późniejszych prac developerskich – integrator informatyczny puszczony samopas nawet z najlepszego projektu potrafi zrobić coś nieużywalnego.

PS3. Polecam też ten tekst: Product Management Then and Now.

31 komentarzy

  1. Świetny tekst! Jeśli jest gdzieś jego anglojęzyczna wersja to chętnie go wyślę do ludzi z „mojej organizacji” 😉

  2. Ciekawy tekst, ważny temat. Dobrze, że mało kto potrafi. Szkoda, że sporo ciekawej dyskusji toczy się na FB i generalne wszędzie tylko nie tu 😉

  3. Prawdziwe!

    Od kilku lat mawiam, że serwisy dużych organizacji odzwierciedlają strukturę tych organizacji oraz problemy organizacyjne, a nie zdolności jej pracowników – w tym projektantów.

  4. Jako osoba odpowiedzialna za UX w dużej korporacji potwierdzam, projektowanie wygląda w ten sposób, czasem jeszcze gorzej.

  5. To się w końcu zmieni, dobrze być otwartym i gotowym na tych „świadomych” PMów 🙂 I nie oszukujmy się, nie wszyscy „projektanci” są faktycznie kompetentni w stopniu uzasadniającym zaniechanie micromanagementu przez menedżerów, których premie zależą od powodzenia przedsięwzięcia. Tak samo ucieczkowe rozmycie odpowiedzialności nie pojawia się zawsze i automatycznie.

  6. Bardzo fajny i trafny tekst z dwóch powodów:
    1. Dla środowiska UX:
    pokazuje pewien temat i tłumaczy, że bardzo często rzeczy nie są oczywiste – robota w dużej organizacji ma naprawdę wiele wyzwań i mam nadzieję rzuca inne światło na tych klientów
    2 Dla osób zaangażowanych w te rzeczy po stornie korporacji (należę do nich) po raz kolejny unaocznia tę sytuację i dzięki temu daje (mi ten tekst daje) znowu powera, żeby cisnąc tematy i nie odpuszczać i pokazuje (marne to pocieszenie) że inni mają podobnie.

    Co to wnosi całościowo. Otóż na styku firma – klient bardzo dużo wiedzy praktycznej właśnie do zrozumienia obu stron. Rozumiem doskonale podział ról ale momentami mam dość sytuacji, jak ktoś gdzieś jedzie po kimś (w sensie projekcie) i pokazuje, że można lepiej ale nigdy niczego tak naprawdę nie wdrożył, tylko pozostawił na etapie wizji.

    Bardzo dziękuje za ten temat.

  7. To wszystko prawda, a w efekcie powoduje to niezdolność korporacji do szybkiego dostosowywania się do nowych realiów świata interaktywnego. Jest 2012, a większość korporacyjnych produkcji nie uwzględnia wersji mobilnych stron (i zwykle jest to odwrotnie proporcjonalne do chęci agencji lub wewnętrznych zespołów), a o stałej pracy nad produktem internetowym nie wspomnę.

    Dlatego też tak popularne kiedyś „robienie portali społecznościowych” pod egidą korporacji okazało się niewypałem (długie i siermiężne procesy akceptacji wszystkiego uniemożliwiają testowanie, eksperymentowanie i dostosowywanie się do społeczności).

    Myślę, że część korporacji pójdzie po rozum do głowy i przyjmie bardziej start-upowe procesy rozwoju produktów. Uważam też, że częściej korporacje będą wchodzić w partnerstwo z różnymi start-upami, aby nie wymyślać koła na nowo. Szczególnie, że zwykle kończy się na wielokącie i tylko czasami foremnym.

  8. Przeklejajac moje wypowiedzi z rozproszonych dyskusji na FB:

    Rozwiazanie jakie widzę to porządny pm, scisle okreslony zakres (celami biznesowymi, a nie ficzerami dla np. projektanta czy grafika), przestrzeganie deadline na każdym etapie, świadomy product owner, zamordyzm w każdym najdrobniejszym elemencie, każda zmiana to decyzja na podstawie wyceny czasowej ORAZ kosztowej plus wpływ na otoczenie projektu.

    Projektant ma dostarczyć coś co spełni biznesowe wymagania biznesu. To biznes (PO) odpowiada za wyniki produktu i powinien wiedzieć czego chce, co chce osiągnąć. Więc rozliczanie projektanta za to jak pracuje produkt nie zawsze jest odpowiednie (szczególnie w kontencie – słaby kontent nie będzie pracował, nawet jak projektant da z siebie maksa). Projektant jest wykonawca, rzemieslnikiem który ma wykonać swoją robotę najlepiej. Biznes powinien wiedzieć ile może wydać na budowę produktu i ew. godzić się z tym, ze nie wszystkie cele zostaną zrealizowane.

  9. Nadzwyczaj to zyciowe, mimo ze smutne. To znaczy zjawisko smutne, bo sam tekst swietnie napisany. Pracujac w korporacji, niestety tego typu zjawiska staja sie codziennoscia i trudno mi bedzie uwierzyc, ze to sie wkrotce jakos zasadniczo zmieni, bo calosc opiera sie na bardzo ludzkich slabosciach.

  10. Zgodzę się z przedpiścami. Prawdziwe, ale bardzo smutne.

    Czuję, że zrobi się z tego kanoniczny tekst, do którego będziemy odsyłać sfrustrowanych coworkerów.

    Dzięki, że poruszyłeś ten temat. Od jakiegoś czasu zastanawiałem się jak go ugryźć.

  11. Mój ulubiony fragment: „Kto nie brał udziału w całodniowych spotkaniach projektowych, w których uczestniczy 15 osób po stronie klienta…”
    To zło w postaci czystej, trzeba wycinać na samym początku – od pierwszego dnia stwarza zagrożenie dla projektu. Wysysa energię i jakość.
    To wszystko jest na tyle istotne, że odnoszę się do tematu u siebie.

  12. Pingback: Tebe Gada
  13. smutne ale pocieszajace, myslalam ze tak jest tylko u mnie.. :/ pracuje w miedzynarodowej firmie ktora zatrudnia ponad 100,000 ludzi na calym swiecie.. proces akceptowanie nowych rozwiazan trwa wieki.. a wersja do implementacji praktycznie niczym nie rozni sie od poprzedniej..

    wszystko sprowadza sie do jednego – „The public is more familiar with bad design than good design. It is, in effect, conditioned to prefer bad design, because that is what it lives with. He new becomes threatening, the old reassuring.” (Paul Rand)

  14. Proces akceptacji/sugerowania zmian wiąże się ściśle z pozycją w hierarchii służbowej.
    Odrzucając nadrzędne cele organizacji czy konkretnego projektu, jednostka decyzyjna musi zaznaczyć obecność i uzasadnić potrzebę swojego istnienia poprzez wtrącanie się do procesu, nawet jeśli nie wnosi to niczego nowego a nawet zaciemnia obraz czy utrudnia realizację projektu.

    Koniec końców ten na samym dole, otrzymuje 15 czy 20 różnych opinii, choć właściwie są to, zależnie od mocy sprawczej, sugestie lub polecenia, często sprzecznych ze sobą i ma zrobić tak, by wszystkie je zawrzeć w projekcie. Co właściwie jest niemożliwe, ale próbować trzeba, wszak przy kolejnym spotkaniu, to pierwsze o co będą pytać.

    Co jednak ciekawe i warte wspomnienia, często gęsto osoby stojące w hierarchii najniżej, awansując, przejmują zwyczaje i zamiast wdrażać dobre modele, doskonale wpasowują się w te, na które, będąc na dole, narzekali. Koło się zamyka.

  15. Ja bym tak projektanta nie wybielał. To projektant projektuje, więc to on powinien walnąć pięścią w stół i powiedzieć: „NIE!” kiedy słyszy głupie porady.
    UX to sztuka. Myślicie, że np. satyrykom nie radzą różni ludzie, aby żartowali na inne tematy, nie podsuwają im pomysłów? Myślicie, że Beksińskiemu nie mówiono: „A może namalowałby pan coś bardziej optymistycznego?” 😉
    Jeśli ktoś twierdzi, że głęboko wierzy w UCD, a potem projektuje gniota, bo o to go poproszono, a jest pewien, że to złe podejście, to znaczy, że łże jak pies. Zamykanie systemu Vista to żenada. Nie mówię nawet o tym, że trzeba kliknąć „Start” by zamknąć! Klikasz Zamknij, a system się nie zamyka, otwiera się kolejne okienko, w którym musisz znaleźć polecenie Zamknij. To frustruje użytkownika! A użytkownik sfrustrowany kupuje inny produkt. Ja kupiłem Maca 😉
    Klient płaci, klient wymaga. Ale trzeba mu uświadomić, że jeśli projektant popełni błąd, to on, klient, nie zarobi pieniędzy, na których mu zależy.
    Trzeba mieć jaja, żeby się postawić i tego wszystkim projektantom życzę 🙂

  16. Po opublikowaniu tego tekstu w niedzielę wieczorem przeczytało go prawie 2000 osób, a następnego dnia drugie tyle, setki lajków, twittów, kilkadziesiąt wykopów, dyskusje w różnych miejscach – to chyba rekord tego bloga i wszystko to potwierdza, że dotknąłem ważnego dla wielu osób tematu.
    Tekst jest napisany z konkretnej perspektywy – jestem projektantem pracującym w stosunkowo niewielkiej firmie dla przedsiębiorstw, które mają tysiące pracowników. Dotyczy też szczególnej, ale nierzadkiej sytuacji, kiedy jest dobry zespół, są dobre pomysły, są środki, chcemy dobrze, ale zamiast męczyć się nad jak najlepszym projektem męczymy się ze sobą…
    Dość długo zastanawiałem się jak ten temat ugryźć, żeby pokazać problem, a przy tym nie prać własnych brudów. Bo mam trochę doświadczeń, które są nie mniejszymi horror stories, niż przykłady we wpisie.
    Co mnie cieszy w Waszym odbiorze to dwie rzeczy:
    – Po pierwsze nie śpieszmy się obrzucać błotem autorów projektów o powstaniu, których i ich uwarunkowaniach niewiele wiemy. Do krytyki pierwszy jest zwykle ten, kto sam niczego ciekawego nie dokonał. To oczywiście nie znaczy, żeby udawać, że złe projekty są dobre, ale też niekoniecznie oznacza to niekompetencje wszystkich zaangażowanych.
    – Druga rzecz, to dyskusja o bardzo ważnej roli PMa. Im więcej dobrych ludzi na tym stanowisku, tym nasze życie będzie prostsze 🙂 Wiele dużych przedsiębiorstw (usługi, finanse i inne) nie wykształciło kultury i kompetencji związanych z designem, bo nie było im to potrzebne. Internet, usability, fakt że user experience i design stają się wartością dla konsumenta, to coś co dopiero do nich trafia. Na pewno migracja ludzi z agencji interaktywnych, czy mniejszych firm internetowych na stronę klienta do korporacji poprawia sytuację. Ten proces będzie postępował i to dobrze. Zupełnie inaczej pracuje się z ludźmi, którzy znają tę pracę od podstaw z naszej strony. Micromanagment – niech nawet będzie, ale do tego to dopiero musi być osoba kompetentna 🙂
    Prawda też, że kierownik projektu powinien być dość wysoko umocowany w hierarchii, aby był efektywny. Dla przykładu kiedy pracowaliśmy nad redesignem Pekao24 naszym project managerem po stronie klienta był dyrektor operacyjny banku (pozdrawiam Pana Rafała 😉 ) – gdyby nie to mogłoby być ciężko.
    Polecam też książkę „Inside Apple” Adama Lashinsky’ego – obraz firmy, który się z niej wyłania wcale nie jest taki różowy, ale jest wiele cennych obserwacji – bardzo małe i mocno zmotywowane teamy projektowe (kilkanaście osób pracujących na kluczowymi funkcjami iOS), czy instytucja DRI (directly responsible individual) dla każdego projektu.

  17. przeprowadzanie zmian, na których znają się wszyscy jest trudne. Nawet dla WP 😉
    Jednak rozwiązanie nie jest tak proste, jak sugeruje Maciek. Tupanie nogą kierownika projektu może w korpo wywołać co najwyżej radość na twarzy, za to robienie po cichu, to kręcenie na siebie bicza.
    Jedyną możliwością jest umocowanie projektu przez sponsora (komitet sterujący) z silną pozycją. Jak to się w projekcie uda, to reszta już jakoś idzie 😉

  18. @ąę
    Komitet sterujący nie jest od pracy na poziomie operacyjnym i od zapewniania przepływu informacji. I niestety, to że istnieje jakiś komitet sterujący z silną pozycją, to nie znaczy od razu, że dobrze idzie 😉

  19. Za komunikację w projekcie odpowiada kierownik projektu, ale to od komitetu sterującego zależy, czy projekt jest strategiczny, czy jest pierdem. A dla ważnego projektu inaczej się pracuje.

    Komunikacja (wbrew 3/4 szkoleń z zarządzania projektami) to nie jest w korpo olbrzymi problem – zwykle są procedury, procesy i wiadomo, kto z kim ma gadać. Jak komunikacji nie będzie, bo projekt jest robiony po cichu, to będzie siwy dym.

    Problemem jest ostateczna akceptacja AI/UX czyli decyzja – jednoosobowa albo rozproszona, co wiąże się z przekonaniem większości zainteresowanych działów, mających sprzeczne cele, że jednak ten projektant wie co robi. No i sorry ale, że muszą być bredkramby to teraz wszyscy wiedzą, więc na juzabylyty to teraz każdy się zna. Największego betonu to i badaniami nie przekonasz 😉

  20. @Maciek Widzę, że mój pierwszy wpis powstawał równolegle do Twojego podsumowania 😉
    IMO ważne dla sukcesu:
    1. dobrze umocowany projekt i Project Manager, co wiąże się z 2
    2. dobry sposób na podejmowanie decyzji po stronie odbiorcy – albo oświecony zamawiający, albo mega przekonujący projektant 😉

  21. @ąę
    To widać inne korporacje spotykamy. Z komunikacją (i to szybką, a nie jak będzie, to będzie, a w ogóle to może sobie sami poszukajcie) też bywają problemy, tak samo jak z podejmowaniem decyzji.
    Procesy i procedury, to już samo w sobie brzmi groźnie w kontekście megakorpu i często wymusza poświęcanie czasu na pisanie makulatury, która pójdzie do kosza, a nie doskonalenie projektu.
    A projekt strategiczny zwykle oznacza więcej osób zaangażowanych (patrz komunikacja) i większy strach przed podejmowaniem decyzji. Liczą się ludzie i kultura, a nie procesy i procedury wg mnie.
    A poza tym to myślę, że się zgadzamy 🙂

  22. ęk, przypominający szurnięcie druucianej Ogromny borland delphi.
    szczotki po desce. kliknij następującyartykuł;
    Dorie, Pistolety PSM,
    etatowe akcesoria rosyjskiego wywiadu, miały integralne
    tłumiki.
    Pozostały pobrzmiewanie, zlewający się bez mała z ów konstytutywnym,
    odpychający, mlaszczący, podczas gdy
    pocisk trafił w cel, Głuche stęknięcie, jęczenie.

    Frodo zacisnął powieki.
    Rozbiegany wyraz radości Kirpiczewa. Westchnienie.
    A także cisza, Finał, tłukło się w czuprynie
    niz.

  23. Bardzo dobry tekst, niestety wciąż aktualny i to na różnych projektowych stanowiskach.

  24. Tekst zdecydowanie aktualny… Co więcej, nie tylko w wielkich korporacjach, ale i w małych lub średnich firmach w Polsce. Projektant jest często traktowany jako osoba, która co najwyżej w swoim projekcie może określić „wytyczne”. Projekt to projekt, i powinien projektant UX powinien uczestniczyć od początku do końca i pilnować go przez „złymi” ludźmi, aż do zakończenia procesu 🙂

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *