MarketingMotywacyjnieWordPress

Duży projekt w małej firmie – blaski i cienie

Pewnie nie raz i tobie obiło się o uszy, że każda firma, również zajmująca się stronami internetowymi, wraz ze swoim rozwojem sięga po co raz większe projekty, że to naturalny proces i z czasem przestaje się tworzyć strony za: “one dolar my friend” 😉 , że to wręcz pożądane, by w końcu przestać robić “proste stronki na WordPressie”. Bo rozwój, bo doświadczenie, bo ilość lat na rynku, bo wiele możliwości, bo… Sky is the limit! Czy naprawdę? Dziś widzę to z kompletnie innej strony. Ciekawi? Zapraszam!

Kiedy ostatni raz na pytanie “Co słychać?” usłyszałeś od kogoś “Świetnie!”? Żyjemy w kraju, w którym odpowiada się w najlepszym wypadku “Jakoś leci” (albo i chyba najczęściej “Stara bida”), prawda? Ja jednak należę do tych, którzy widzą szklankę do połowy pełną nawet, gdy jest pusta, więc co jakiś czas z dumą oznajmiam tu i ówdzie o swoich mniejszych i większych sukcesach. Nie dlatego, że lubię się przechwalać, ale dlatego, że podkreślanie dobrych, mocnych stron mi samej dodaje powera do dalszych działań!

Dziś będzie trochę inaczej. Bo końcem grudnia (zeszłego roku!) trafił do nas Klient, bo praktycznie 01.01.17 mieliśmy wszystko poustalane, bo po pięciu miesiącach wydawało się nam, że ukończyliśmy planowany na półtora miesiąca projekt, a po kolejnych 4 ujrzał w końcu światło dzienne. Dziś praktycznie i wprost o tym, co poszło “nie tak”.

Przychodzi Klient z dużym projektem…

Ba! Przychodzi Klient, który ma budżet i specyfikację! Zacierasz ręce myśląc: “To będzie COŚ! To naprawdę trafi do portfolio”. Planujesz, sprawdzasz, przewidujesz, rozrysowujesz, wyceniasz, spisujesz umowę, otrzymujesz zaliczkę na 50% i… działasz!

Dziubdziasz, integrujesz, szukasz, wertujesz, dopisujesz wciąż i wciąż kolejne linijki kodu. Sprawdzasz, testujesz i widzisz, jak twój kod działa i rośnie ci serducho 😀 Dwa tysiące linijek kodu później z lekkim opóźnieniem czasowym,  przepełniony dumą pokazujesz swoje dzieło Klientowi.

I otrzymujesz mail z “poprawkami”…

yyy… Znaczy się: z trzydziestoma paroma stronami screenów i opisów tego, jak bardzo Klient wszystko to wyobrażał sobie inaczej i…  Siadasz, czytasz, widzisz te niedookreślenia i różnice w pojmowaniu definicji, a z niedowierzania wszystko, co tylko może, opada ci tak nisko, jak to możliwe, a może i niżej i ziemia spod nóg się usuwa. Dosłownie.

Dzięki kolejnym siedmiu miesiącom współpracy mam o wiele więcej doświadczenia między innymi w tematyce “obsługa Klienta” i tym właśnie chcę się podzielić. Więc drogi developerze, zanim siądziesz do swego pierwszego w życiu “dużego projektu”, poczytaj.

Jeśli przejmujesz projekt po kimś – zastanów się dobrze, jakich informacji potrzebujesz.

My zastaliśmy postawiony już WordPress, zainstalowany i ustawiony motyw, wybrane wtyczki, a w specyfikacji określone: co z czym trzeba połączyć, by serwis działał. Idealnie, prawda? Przyjęliśmy więc, że Klient wie, co ma i chce od nas tego, co opisał w specyfikacji. To był nasz pierwszy błąd.

Jeśli przejmujesz projekt po kimś i ktoś wybrał WordPressa jako narzędzie do stworzenia serwisu – upewnij się, że Klient wie, czego chce i na co się umawia.

To trudne. Bo emocje, bo czas, bo każdemu się spieszy, bo – w naszym przypadku – jeszcze okoliczności (wszystko dopinaliśmy w przerwie Świąteczno-Noworocznej). Ale kiedy dostajesz specyfikację, to naprawdę upewnij się, że Klient wie, co dla niego zrobisz, a czego NIE zrobisz. My podczas jednej z ostatnich rozmów telefonicznych wyłapaliśmy np. że Klient chce jeszcze, żeby użytkownicy jego serwisu otrzymywali konkretne maile w konkretnych momentach, o czym w “specce” ani słowa nie było. Założyliśmy, że Klient wie, na co się umawiamy. To był nasz drugi błąd.

Jeśli programujesz i z logiki kodu wynikają decyzje, które trzeba podjąć – nigdy nie podejmuj ich na własną rękę.

To punkt, który można by wrzucić do worka: “Odwieczny konflikt programistyczno-graficzno-użytkowo-wizjonerski”. Bo programista widzi projekt inaczej, grafik widzi po swojemu, użytkownik ma swoją perspektywę, a wizjoner (często pomysłodawca) swoją. I zdarzy się nie raz, że wszystkie te idee się rozjadą. My przyjęliśmy, że jeśli coś wynika z logiki, to tak kodujemy. Później zobaczył to Klient. Okazało się, że to była nasz trzeci błąd.

Jeśli otrzymujesz listę poprawek do wykonanej pracy – zdecyduj, czy chcesz bez dodatkowej wyceny wprowadzać tylko poprawki, czy również zmiany. I bądź konsekwentny.

Nie przestaje mnie zadziwiać, że idąc do fryzjera i umawiając się na pasemka żadna pani nie ma pretensji o niewykonany balejaż, albo jadąc do mechanika i umawiając się na wymianę łożysk w kołach przednich żadnemu panu przy odbiorze samochodu nie przychodzi do głowy, by kłócić się o niewymienione przy okazji klocki hamulcowe. Natomiast Klienci firm tworzących strony internetowe notorycznie wymuszają zrobienie przy stronie więcej niż to, na co się umówili. Bo czegoś nie przewidzieli. Bo czegoś nie przemyśleli. Bo czegoś nie zaplanowali, nie dopatrzyli, nie potrafili sobie wyobrazić. Tak, my też przeszliśmy nie małą szarpaninę o: “Tego nie było w specyfikacji. Możemy to wykonać w dodatkowym czasie i po dodatkowej wycenie”.

Jeśli umawiasz się z Klientem, że zrobi on na końcu testy działania serwisu – koniecznie zróbcie to razem, via skype i z podglądem ekranu. A najlepiej jeszcze cały proces sobie nagraj.

Po pierwsze – będziesz mieć dokumentację z działania serwisu i bugów do poprawki. Po drugie – zobaczysz, co Klient testuje, na czym testuje i masz wpływ na merytorykę tych testów i poprawność ich wykonania. I po trzecie – na bieżąco wyjaśnisz Klientowi, że podpowiedź przeglądarki Safari o ustawieniu mocnego hasła, to nie jest twój skrypt i nie masz na to wpływu (true story!). My nie mogliśmy uwierzyć, że z testowaniem własnego serwisu można mieć masę problemów dopóki nie zobaczyliśmy tego na własne oczy. Jestem przekonana, że gdybyśmy usiedli do pierwszych testów z Klientem (a nie tylko do omawiania punktów przesłanych po ich wykonaniu), zakończylibyśmy prace o wiele szybciej.

Przy okazji nagrywania – masz też zrzut ekranu z sytuacji, kiedy Klient – podczas twojego wyjaśniania, dlaczego nie możesz się zgodzić na kolejne zmiany w projekcie – pokazuje ci język, bo zapomniał, że jest na podglądzie z kamery! 😉

I na koniec – zastanów się dobrze, czy w ogóle chcesz to robić.

Tak, bo duży projekt w małej firmie oznacza, że:

  • do projektowania serwisu, kodowania serwisu i testowania swojego kodu będziesz sam (w najlepszym razie będzie was – jak nas – dwóch lub dwoje + ktoś, kogo poprosisz o przysługę),
  • od twoich umiejętności komunikacyjnych ogromnie wiele zależy we współpracy,
  • będziesz codziennie siedział w tym samym projekcie przez najbliższy miesiąc/dwa/trzy/dziewięć,
  • zaczniesz widzieć swoje życie w kategoriach: “przed projektem” i “po projekcie”,
  • będziesz tworzył kolejkę Klientów na “po projekcie”,
  • przyjdzie moment, kiedy dopadnie cię znużenie, zmęczenie, a wiele jeszcze w projekcie będzie do zrobienia,
  • przynajmniej kilka razy zwątpisz, że w ogóle to skończysz,
  • nagle okaże się, że Klient wiele razy co innego miał na myśli niż wyraził, a reszta – której nie wyraził – powinna być dla ciebie logiczna,
  • nie będziesz miał czasu na nic innego poza projektem,
  • zaczniesz ulegać kolejnym “drobnym” zmianom i poprawkom poprawek, byle tylko ten projekt “dowieźć”,
  • nie raz poczujesz się, jakbyś trafił w środek karnawału, dokładnie w ten moment, kiedy nagle cichnie muzyka i każdy ściąga maskę i przestaje być śmiesznie…

A zyski? Czy naprawdę może być tylko źle?

Oczywiście nie. Z takich projektów można wiele wyciągnąć (nie tylko $$). Najpierw i najważniejsze – doświadczenie programistyczne. Każdy developer marzy, by rozwiązywać wciąż nowe problemy, by wdrażać co raz bardziej zaawansowane rozwiązania, by się rozwijać. Duży projekt to plus milion do doświadczenia! Potem – obsługa Klienta. Tak, nie raz trzeba się wykazać mega opanowaniem, cierpliwością i wyrozumiałością. Z drugiej strony taka współpraca uczy stawiania granic. Nam koniec końców z pierwszego zlecenia urodziło się drugie po tym, jak Klienci zorientowali się, że wiele kroków chcą zaprojektować inaczej niż rozwiązywał to wybrany na początku motyw. Następnie – project management. Ogarnięcie specyfikacji (bo przecież w bólu, ale w końcu porządna się zrodziła), ścieżek użytkowników, zakodowanie ich, przetestowanie, nauczenie Klienta korzystania z serwisu i administrowania nim, ustalenie i realizacja etapów… To wszystko to kolejny plus milion do twoich umiejętności miękkich. I wreszcie – stałe zlecenie. Wierz mi, po takiej współpracy jesteście z Klientem tak “podocierani”, że nic tylko wspólnie dalej rozwijać projekt! No i marne szanse, że znajdzie się ktoś, kto będzie chciał przedzierać się przez twoje – bagatela! – cztery tysiące linijek kodu, gdyby Klient chciał cię wymienić 😉

A! No i oczywiście taki projekt świetnie wygląda w portfolio!

——————————————————

p.s. miałam spore wątpliwości, czy pisać ten wpis, dlatego też celowo nie wymieniam projektu z nazwy.

Share:

Dodaj komentarz

2 komentarzy do "Duży projekt w małej firmie – blaski i cienie"

Powiadom o
avatar
Sortuj wg:   najnowszy | najstarszy | oceniany
Aga
Gość

O, o projektach można książkę napisać 😉 A o wielkich projektach…
Pół biedy, jak klient mimo totalnego braku zrozumienia ma chęć i wolę współpracy, wtedy, tak jak opisałaś, można dojść do porozumienia. Gorzej, jeśli tej woli nie ma, ale jest roszczeniowa postawa. Bo ja się nie znam, to wy jesteście od tego, żeby się znać.
Gratuluję dobrnięcia do końca i pozytywnego zakończenia 🙂

wpDiscuz