Standardowy projekt
1. Klient jest najważniejszy
2. Zaczynamy projekt
3. ZBIERAMY wytyczne
4. KONSULTUJEMY z zespołem developerskim wykonalność projektu
5. Prezentujemy projekt klientowi
6. Prezentujemy poprawiony projekt
7. BRONIMY projektu - spotkanie
8. BRONIMY projektu – telefon
9. BRONIMY projektu - mail
10. Przekonaliśmy klienta
11. Implementujemy projekt
12. ROZMAWIAMY z zespołem developerów
13. Wprowadzamy korekty na bieżąco
14. Prezentujemy projekt i zbieramy laury
2. Zaczynamy projekt
Czy na pewno zaczynamy? Czy może już się rozpoczął
i dołączamy do niego.Ustalone są koszty, terminy itd.
Projekt wdrożeniowyProjekt utrzymaniowy
2.1 Projekt wdrożeniowy już się rozpoczął
Terminy wdrożenia ustalone Kosztorys i harmonogram przygotowane Jak zgrać tempo wszystkich osób w projekcie?
2.2 Dołączamy do projektu utrzymaniowego
Projekt jest już wdrożony Wprowadzamy nowe funkcjonalności Naprawiamy błędy Uaktualniamy istniejące funkcjonalności
4. Konsultujemy z zespołem developerskim wykonalność projektu
Brak komunikacji na linii: UX – Grafik UX – Front-end UX – Programista
5. Prezentujemy projekt klientowi
Ważny jest kontakt bezpośredni Ilość iteracji Zakres zmian względem założeń
projektowychZadawanie pytań i uzyskiwanie odpowiedzi
Przykłady:Grafika strony głównejZestaw makiet + RWD + Projekt koncepcyjny
6. Prezentujemy poprawiony projekt
Od tego momentu nie powinno być radykalnych zmian
w zakresie projektu.
Jeśli tu się poddamy projekt na pewno wymknie się spod kontroli.
Przykładowe sposoby otrzymywania uwag / zgłoszeń błędów: Skan wydrukowanej strony z naniesionymi na niej odręcznymi
poprawkami dostarczony mailowo. Zestaw uwag na Jira / Google docs otrzymany od klienta
(warto poświęcić czas na edukację klienta w przypadku dłuższych projektów)
7. Bronimy projektu - na spotkaniu
Na spotkaniu odwołujemy się do pozytywnych doświadczeń swoich i firmy oraz do prawidłowych wzorców projektowych i trendów panujących na rynku.
Przykład:Prezentacja działającego serwisu z benchmarku
8. Bronimy projektu - przez telefon
Rozmawiamy z klientem tak długo aż zrozumie jak niebezpieczny jest jego pomysł dla projektu.
Przedstawiamy jakie negatywne skutki niesie za sobą decyzja o mało istotnej zmianie w projekcie.
Przykład: „Jeśli Państwo nalegają, zrobimy to tak. Jednak nie
rekomendujemy takiego rozwiązania."
9. Bronimy projektu - korespondencja mailowa
Wizualizujemy klientowi zmiany oraz mówimy o kierunku, w którym zmierza projekt.
Należy wystrzegać się wizualizacji bardzo złych pomysłów, gdyż mogą one być odebrane jako właściwe rozwiązanie i ciężko będzie się z nich wycofać
Przykład:Zastosowanie niepoprawnego wzorca projektowego
10. Przekonaliśmy klienta
Klient przekonany o merytoryczności naszych działań staje się naszym sprzymierzeńcem.
O taki stan rzeczy należy dbać przez cały czas trwania projektu
Zaangażowanie wszystkich udziałowców projektu zwiększa jego szanse na sukces.
11. Implementujemy projekt
Nie zapominamy w tym momencie o projekcie. Wręcz przeciwnie: dopytujemy się o niego, pokazujemy, iż nas interesuje to co się dzieje.
Przykład:"Nie mam dziś czasu. Przyjdź z tym do mnie jutro.""Zrobimy, a potem się poprawi."
12. Rozmawiamy z zespołem developerów
Dzień po dniu dzięki rozmowie wiemy jak idą sprawy
w projekcie, czy są jakieś problemy.
Rozwiązujemy na bieżąco problemy pojawiające się
w projekcie.
Przykład:"To nie nasz problem tylko ludzi, co mają stare telefony.""Tak będzie działało szybciej i użytkownikowi będzie
łatwiej."
13. Wprowadzamy korekty na bieżąco
Optymalizacja projektu wymaga czasem konsultacji z klientem.
Nie bójmy się ulepszać projekt podczas jego tworzenia. Oczywiście, zmiany muszą być zaakceptowane przez klienta i mieć wymierną korzyść dla projektu.
Przykład: Nie róbmy nic. Klientowi się nie spodobają zmiany w grafice
jaką nam dostarczył. Tak jest napisane w wytycznych. Zastosujmy rozwiązania ułatwiające wprowadzenie RWD w
drugim etapie projektu (jeśli wygramy przetarg).
14. Prezentujemy projekt i zbieramy laury
Uwaga powdrożeniowa, co jeszcze można poprawić. Jeśli nie widzimy nic do poprawy, to bardzo źle.
Zawsze jest coś do poprawy, do zrobienia lepiej. I nie należy się tego wstydzić. To wręcz pożądane, by być coraz lepszym.
Przykład:
Zaprzestanie prac nad projektem spowodowane wykruszeniem się zespołu nieakceptującego metod pracy przy projekcie (przejście pracowników do innych firm).
Sukces i celebracja projektu, premie itd.
Wdrożenie i co dalej?
O ile umowa przewiduje utrzymanie serwisu warto dopytywać o statystyki, klientowi podpowiadać nowe rozwiązania.
Podczas wprowadzania ulepszeń developerskich zawsze należy służyć radą.
Przykład: Nie zmieniajmy nic. Klientom się podoba, bo kupują. Zaproponujemy klientowi listę funkcjonalności
rozwojowych, by mógł do nich powrócić, gdy serwis odniesie sukces i będą środki na ich realizację.
Projektowanie to decyzje…
W ciągu całego projektu podejmujemy ich nieskończoną ilość i nie możemy na końcu powiedzieć, że się pod tym nie podpiszemy. Nie możemy unosić się honorem eksperta i zapominać o adresatach projektu.
Przykład:Przeczytać w miesięczniku Wprost, iż portal jest idealnym
przykładem jak można zmarnować środki.Przeczytać artykuł, w którym dowiadujemy się, iż w trzy
miesiące od wdrożenia serwisu odwiedziło go 600 tys. użytkowników, którzy wygenerowali prawie 3.5 mln odsłon.
Top Related